Ethereal-dev: Re: [Ethereal-dev] HTTP gzip/deflate decompression patch - zlib andgzip on Win32
From: Jerry Talkington
| On Fri, May 07, 2004 at 10:04:13AM +0200, Biot Olivier wrote:
| >
| > That's correct, however you cannot select the gzip compressed
body,
| > you can only select the *uncompressed* bytes. So it would be nice
| > if it were possible to have an item in the HTTP protocol tree
| > where an end-user has the possibility to click on the compressed
| > body, and optionally on the uncompressed body if uncompression
| > succeeded (implying HAVE_ZLIB was true at compile time, of
course).
| >
| > I think that portion of the code is about line 693 of
packet-http.c.
|
| The checkin that you made for this doesn't work. You'd have to add
| another data source for the compressed data, or else it points to
the
| last data source selected.
I don't see what you mean here; maybe I don't have a capture which
illustrates the problem... I definitely didn't intend to break the
HTTP dissector. If I did, I'd be glad to correct this.
| I'm still not entirely sure that this should even be available,
since
| it's passed to a lower subdissector if decompression works, and I
don't
| think there are any other places where a data view is kept when
passed
| to another subdissector.
Hmmm... the *compressed* data oughtn't be in its own data source as it
is either in the TCP segment or the reassembled TCP data source. The
original code had a new data source added for the *uncompressed* data,
which is OK. I only wanted the possibility to be able to select the
*uncompressed* data in the protocol tree in order to be able to select
and view those bytes and optionally be able to save them to a file.
| Adding another data source will make the new Layout prefs useless
when
| decoding compressed HTTP, since there will be so many tabs it's be
| nearly impossible to read anything in a pane that is on the same
| horizontal level with the packet bytes.
I see what you mean. However, laying out multiple data sources is one
problem, which is different from the problem that an end-user may want
to access given portions of the data. I don't think we need an extra
data source for the *uncompressed* data (proto_tree_add_text() with
the correct data bytes highlighted is perfect for me), and AFAIK the
fixes I checked in did not introduce this; should this not be the case
then I made a mistake.
Regards,
Olivier
