Alex Kirk wrote:
> I was just poking around with the HTTP dissector, wishing that there was a
> way to unzip the body of a gzipped HTTP response in TCP packets 2
through N,
> when I stumbled across HTTP body reassembly. I figured I'd struck gold,
but when I
> enabled it and TCP subdissector reassembly, I found that the display of
> packet 1 of an HTTP response had not changed at all, and that subsequent
packets
> didn't even show HTTP dissection -- I couldn't even click on the body of
the
> packet.
Did you also enable reassembly of HTTP headers? And does the HTTP
response have a Content-Length header?
If so, could you send us your capture? There might be a bug somewhere.
> This (as well as the fact that searching for "desgment" elsewhere in the
> file yields nothing of interest) suggests to me that reassembly of HTTP
> response bodies is not actually implemented yet,
Why? req_resp_hdrs_do_reassembly() is the routine that does all the
reassembly work (as the name suggests).
> 1. Is HTTP response body reassembly actually functional, just buried away
> somewhere that I'm missing it?
Yes, it's mostly functional, although there might be a bug that causes a
problem in your capture, or you might be running into the one case it
doesn't currently handle - it only works if the entity headers include a
Content-Length header so that the reassembly code knows how much to
reassemble; it doesn't currently handle the case where the body continues
until the connection is closed. Implementing that would require that the
TCP code call subdissectors with FIN segments even if the segment has no
data, *and* that all dissectors for protocols running atop TCP handle that
appropriately (in most cases, they'd just do nothing if it's an empty
segment with FIN set).
