Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 2883] Timing of packets in a mess

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2883





--- Comment #6 from LEGO <luis.ontanon@xxxxxxxxx>  2008-09-22 14:03:24 PDT ---
(In reply to comment #4)
[...]
>  Is there a good reason for doing so ?
[...]

There's few:

First and Most: If not impossible it's at least very hard to know the contents
of a packet that has not arrived yet! :-)

Then we believe it is better to "show it when we have it all". Instead of
"having to decide in which packet to put what and keep track of it"...

To finish it HTTP is tricky to decode, specially when reassembling:

- Header size is not predictable (so the entire message's)

- Content-Length isn't mandatory, (i.e. sometimes the body's size is
unpredictable too)

- several Different encodings can be used, some even with a different concept
of size.

- Pipelining makes it become horrible!
  (a sequence of headers and boddies that can start/end enywhere between the
various packets of a tcp stream)


HTTP dissection and reassembly has some deep bugs to be fixed... for quite some
time.

\Lego


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.