This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

What makes a packet an HTTP one

2
1

I am trying to figure out why WireShark does not treat a packet as an HTTP one. Here is the scenario: A client ( from port x) sends a GET request to a server (to port 80). In response, the server (from port 80) sends a packet to the client (to port 80). WireShark recognizes the client -> server packet as an HTTP one, but does not recognize the response packet as an HTTP one even though it has the status line HTTP/1.0 200 OK.

I am wondering if anyone could offer some clue for understanding this. The response packet is the following:

Transmission Control Protocol, Src Port: http (80), Dst Port: 50374 (50374), Seq: 1, Ack: 628, Len: 100

Source port: http (80)
Destination port: 50374 (50374)
[Stream index: 15]
Sequence number: 1    (relative sequence number)
[Next sequence number: 101    (relative sequence number)]
Acknowledgement number: 628    (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
    000. .... .... = Reserved: Not set
    ...0 .... .... = Nonce: Not set
    .... 0... .... = Congestion Window Reduced (CWR): Not set
    .... .0.. .... = ECN-Echo: Not set
    .... ..0. .... = Urgent: Not set
    .... ...1 .... = Acknowledgement: Set
    .... .... 1... = Push: Set
    .... .... .0.. = Reset: Not set
    .... .... ..0. = Syn: Not set
    .... .... ...0 = Fin: Not set
Window size value: 3547
[Calculated window size: 7094]
[Window size scaling factor: 2]
Checksum: 0x248e [validation disabled]
    [Good Checksum: False]
    [Bad Checksum: False]
[SEQ/ACK analysis]
    [Bytes in flight: 100]
TCP segment data (100 bytes)

0000  00 24 8c d9 a4 33 00 40 8c be 65 28 08 00 45 00   [email protected](..E. 0010  00 8c 85 e6 40 00 40 06 32 1a c0 a8 00 5f c0 a8   [email protected]@.2...._.. 0020  00 bc 00 50 c4 c6 54 49 3f 4a 66 aa 68 4a 50 18   ...P..TI?Jf.hJP. 0030  0d db 24 8e 00 00 48 54 54 50 2f 31 2e 30 20 32   ..$...HTTP/1.0 2 0040  30 30 20 4f 4b 0d 0a 43 6f 6e 74 65 6e 74 2d 54   00 OK..Content-T 0050  79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e   ype: application 0060  2f 78 2d 72 74 73 70 2d 74 75 6e 6e 65 6c 6c 65   /x-rtsp-tunnelle 0070  64 0d 0a 44 61 74 65 3a 20 54 68 75 2c 20 30 38   d..Date: Thu, 08 0080  20 53 65 70 20 32 30 31 31 20 31 37 3a 34 33 3a    Sep 2011 17:43: 0090  32 32 20 47 4d 54 0d 0a 0d 0a                     22 GMT....

asked 08 Sep '11, 12:50

Hong's gravatar image

Hong
46459
accept rate: 0%

edited 08 Sep '11, 13:00


One Answer:

5

The TCP protocol preference "Allow Subdissector to reassemble TCP streams" is enabled. This means that any protocol than runs atop TCP can tell TCP to collect more data until it has a full PDU. In the case of HTTP, the HTTP dissector will try to collect a full HTTP response before showing it.

In the hex data that you supplied, the full HTTP header is visible. However, there is no "Content-Length" header and no "Transfer-Encoding: Chunked" header. This means the end of the HTTP PDU is when the TCP connection gets closed by the FIN packets. If the FIN packets are not in the trace, then Wireshark has no way of knowing that the HTTP response is complete and will keep trying to collect data until it sees the FIN.

You can make Wireshark show the HTTP response straight away by disabling the "Allow Subdissector to reassemble TCP streams" in the TCP protocol preferences.

answered 08 Sep '11, 14:07

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Thank you very much for the elucidation! Yes, the referred packet shows up as an HTTP one once "Allow Subdissector to reassemble TCP streams" is disabled.

(08 Sep '11, 15:18) Hong