Jeff Morriss
changed
bug 10363
Comment # 1
on bug 10363
from Jeff Morriss
I assume you mean that the GET in frame 7 has a response shown in frame 9 but
the GET in frame 27 has no (decoded) response?
I think the problem with frame 27 comes from frame 26: there the web server has
sent a 404/Not Found which looks more-or-less complete to me with a length of
205 bytes (though I don't work with http much) but the response contains a
Content-Length field indicating that the response has a length of 1245 bytes.
I think causes the TCP/HTTP dissector to go off trying to gather 1245 bytes to
reassemble that response which throws off the dissection of frame 27.
Disabling either of the HTTP dissector preferences about reassembling packets
makes frame 29 decode properly.
In my (relatively ignorant of http) opinion, the bug here is in the web server,
not in Wireshark. I'm not sure there's much Wireshark can do better here.
I'll leave this open for now for someone knowledgable in http to comment.
You are receiving this mail because:
- You are watching all bug changes.