Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a trivial CGI script that outputs simple text content. It's written in Perl and using CGI module and it specifies only the most basic headers:

print $q->header(
    -type               => 'text/plain',
    -Content_length     => $length,
);
print $stuff;

There's no apparent issue with functionality—neither User Agent nor server do complain a bit, but I'm confused about the fact that Wireshark does not recognize the HTTP response as HTTP—it's marked as TCP.

Here is request and response, as shown in "Follow TCP Stream" dialog box:

GET /cgi-bin/memfile/memfile.pl?mbytes=1 HTTP/1.1
Host: 10.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: cs,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 05 Apr 2012 18:52:23 GMT
Server: Apache/2.2.15 (Win32) mod_ssl/2.2.15 OpenSSL/0.9.8m
Content-length: 1048616
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=ISO-8859-1

XXXXXXXX...

And here is the packet overview)

No.     Time        Source      srcp   Destination  dstp    Protocol    Info                                tcp.stream  abstime
5       0.112749    10.0.0.1    80     10.0.0.2     48072   TCP         [TCP segment of a reassembled PDU]  0           20:52:23.228063

Frame 5: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
Ethernet II, Src: 00:12:34:56:78:9a, Dst: 00:12:34:56:78:9b
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.2 (10.0.0.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 48072 (48072), Seq: 1, Ack: 330, Len: 1460

Now when I open the stream in Wireshark:

  • first three packets are usual TCP handshake
  • fourth packet the GET request shown as HTTP with this in "Info" field GET /cgi-bin/memfile/memfile.pl, as I expect
  • fifth packet contains the response, but is not marked as an HTTP response. I would expect Info field to be something like "HTTP 200 OK", but there's only a generic "[TCP segment of a reassembled PDU]". The real inconvenience is that this packet is not caught by "http.response" filter

Can somebody explain why Wireshark does not recognize HTTP nature of the fifth packet? Is there something wrong with the response?

share|improve this question
1  
Why don't you show the relevant packet instead? Without that any answer can only be guesswork. –  John Gardeniers Apr 5 '12 at 21:49
    
@JohnGardeniers Sorry but I'm not sure how should I interpret the packet here (possibly how to export such interpretation from Wireshark) to be most useful. I added overview and link to Pastebin where full detail is available, though. –  Alois Mahdal Apr 6 '12 at 8:52
    
you need to show the packet that you're asking about, not the one you have shown in your question. –  John Gardeniers Apr 7 '12 at 10:38
    
@JohnGardeniers We're starting to go in rounds. I am asking about that specific packet I have put on Pastebin and summarized in the Q. I'm confused why Wireshark classifies it only as TCP, not as HTTP response. –  Alois Mahdal Apr 8 '12 at 0:12
    
@JohnGardeniers I edited the question, hopefully making more clear wich one is confusing me :) –  Alois Mahdal Apr 8 '12 at 0:38
add comment

1 Answer

I've had the same issue myself and found the answer at Wireshark Q&A:

You can make Wireshark show the HTTP response straight away by disabling the "Allow Subdissector to reassemble TCP streams" in the TCP protocol preferences" (you need to restart Wireshark after disabling the option).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.