On Sat, May 08, 2004 at 11:25:24PM +0200, Olivier Biot wrote:
> From: Jerry Talkington
> | 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.
Attached is a capture that has this problem. The first desegment HTTP
response shows the "Encoded entity body (gzip)", which points to
incorrect bytes.
> | 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
Not if the response was chunked. Until composite tvbuffs are
implemented, a new data source would have to be added.
> 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.
When you select the lower level dissector's protocol tree, it selects
all of the uncompressed data. (E.g. When you select "Line-based text
data: text/html", the all of the uncompressed bytes are there.
As for wanting to select the compressed data when it's uncompressable, I
don't think that's necessary. If the user wants the compressed data,
they should turn off decompression. When data is passed to any other
handler, it's no longer available to the upper levels (e.g. if the
entity-body is passed to the Line-based text dissector, it's no longer
selected as part of the HTTP data.) Why should this be any different?
> | 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.
You'd have to have a new data source for uncompressed bytes in any
event, since those bytes don't actually appear in the frames.
Compressed data could show up without a new data source, but not if the
response is chunked, until composite tvbuffs are implemented.
Again, I don't think it's that important to have the different labels
for the data sources in these three cases: "Uncompressed entity body",
"Compressed entity body", "De-chunked entity body". I think the data
source should just be labeled "Entity body".
When the user selects the item in the packet details pane, the label
they click on clearly states that the data is compressed, if that is the
case. Otherwise it's passed to a subdissector for know types. The only
time that it *might* be confusing for a user is when the media type of
the entity is not dissectable, in which case the "data" label doesn't
tell if it's compressed or not. I think that the best solution would be
to add a new subtree with a label such as ("Data (%s)", uncompressed ?
"uncompressed" : "Compressed"); this would make it clear to the user.
--
GPG public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9D5B8762