Ethereal-dev: Re: [Ethereal-dev] HTTP gzip/deflate decompression patch - zlib a nd gzip on Win
On Fri, May 07, 2004 at 10:04:13AM +0200, Biot Olivier wrote:
> |From: Jerry Talkington
> |
> |On Thu, May 06, 2004 at 11:12:31PM +0200, Olivier Biot wrote:
> |
> |> One last remark: I've noticed that you don't provide access to
> |> the uncompressed data. Maybe we can provide a subtree item in
> |> the HTTP tree
> |>(I'd like to have some comments from other fellows here).
> |
> |In which case is it not available? If the data is passed to a
> |subdissector, clicking on that subdissector's subtree selects
> |all of the
> |uncompressed data. If there is no subdissector, it should be
> |displayed as "data."
>
> 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).
There's an option to disable decompression of the entity bodies. I
don't think any of the dissectors allow you to access data once it's
been passed to a lower handler. It would be pretty cinchy to add that,
but see below.
> I think that portion of the code is about line 693 of packet-http.c.
>
> I'd also suggest to replace "Entity body" with "Uncompressed entity
> body" or "Compressed entity body", or replace "compressed" with
> "decoded" in the add_new_data_source calls. This way it is clearer
> to the end-user that the data is (un)compressed.
I had originally done that. However, each data source requires a tab
with a fixed size equal to the name. That's ok with the original
layout, but if you choose, say, layout #2, the size of the hex pane
jumps around when selecting decoded HTTP frames.
With the new layouts, we should probably make the tabs overlap, so it's
possible to have any number of data sources without making panes jump
around. In the meantime, how important is it that Packet Bytes frame
say whether the body is uncompressed or not? Isn't the description in
the Packet Details pane enough?
--
GPG public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9D5B8762
