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?