| Bug ID |
10404
|
| Summary |
http display filter doesn't show response headers if the response body is truncated
|
| Product |
Wireshark
|
| Version |
1.8.2
|
| Hardware |
x86
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 13007 [details]
pcap with 2 http requests/responses, 2nd response body truncated
Build Information:
$ tshark -v
TShark 1.8.2 (SVNRev 44520 from /trunk-1.8)
Copyright 1998-2012 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GLib 2.32.2, with WinPcap (4_1_2), with libz 1.2.5,
without POSIX capabilities, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1,
without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, without Kerberos, with
GeoIP.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008).
Built using Microsoft Visual C++ 10.0 build 40219
=======================
$ tshark -v
TShark 1.2.2
Copyright 1998-2009 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GLib 2.12.3, with libpcap 0.9.4, with libz 1.2.3, with POSIX
capabilities (Linux), with libpcre 6.6, with SMI 0.4.5, without c-ares, without
ADNS, without Lua, with GnuTLS 1.4.1, with Gcrypt 1.2.4, with MIT Kerberos,
without GeoIP.
Running on Linux 2.6.18-371.4.1.el5, with libpcap version 0.9.4, GnuTLS 1.4.1,
Gcrypt 1.4.4.
Built using gcc 4.1.2 20080704 (Red Hat 4.1.2-44).
--
The http display filter does not show a response (even response headers) if a
response body is truncated.
Put this 10,008 line bug.txt file on a webserver:
This is a text file.
Request this 10,008 line file twice on the same connection (request connection
keep-alive)
but reset the connection partway through the response like this:
curl -H Connection:keep-alive -D/dev/stderr http://server/bug.txt
http://server/bug.txt | head -11000 > /dev/null
and notice that wireshark's http filter can't find the second response.
Search for the string BOGUS to make it easy to see.
The remainder of this file is filler to provoke the bug.
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
<9998 lines of 0 omitted>
Capture a request like this (which will truncate the second response body):
curl -H Connection:keep-alive -D/dev/stderr http://server/bug.txt
http://server/bug.txt | head -11000 > /dev/null
Display the capture with tshark (wireshark has the same problem but is less
convenient to paste into a bug):
$ tshark -R http -r bug.pcap
58159 0.001900 192.168.42.82 58159 172.27.36.120 80 HTTP GET /bug.txt
HTTP/1.1
http 0.077933 172.27.36.120 80 192.168.42.82 58159 HTTP HTTP/1.1 200 OK
(text/plain)
58159 0.083654 192.168.42.82 58159 172.27.36.120 80 HTTP GET /bug.txt
HTTP/1.1
Note the second http response is not displayed, however it is there:
$ strings bug.pcap | egrep 'HTTP|BOGUS'
GET /bug.txt HTTP/1.1
HTTP/1.1 200 OK
Search for the string BOGUS to make it easy to see.
GET /bug.txt HTTP/1.1
HTTP/1.1 200 OK
Search for the string BOGUS to make it easy to see.
Repeat the request and capture with the "| head -11000" removed so the whole
second response is captured and the result is correct:
59351 0.001880 192.168.42.82 59351 172.27.36.120 80 HTTP GET /bug.txt
HTTP/1.1
http 0.073178 172.27.36.120 80 192.168.42.82 59351 HTTP HTTP/1.1 200 OK
(text/plain)
59351 0.082685 192.168.42.82 59351 172.27.36.120 80 HTTP GET /bug.txt
HTTP/1.1
http 0.162633 172.27.36.120 80 192.168.42.82 59351 HTTP HTTP/1.1 200 OK
(text/plain)
It would be much more useful to display what is there, flagging it as
incomplete would be an added bonus.
Thanks!
You are receiving this mail because:
- You are watching all bug changes.