Ethereal-dev: Re: [Ethereal-dev] HTTP gzip/deflate decompression patch - zlibandgzip on Win32
Let's summarize the discussion :)
1. The HTTP protocol can transport entity bodies, either
with or without transfer encoding and content encoding.
This yields 4 possibilities:
a. No transfer coding, no content coding
b. Chunked transfer coding, no content coding
c. No transfer coding, gzip/deflate content coding
d. Chunked transfer coding, gzip/deflate content coding
2. If we want to highlight the bytes that correspond with a
given field in the protocol tree, the bytes must exist in
a data source. This is true also when we hand data off to
a subdissector.
3. There is some concern about adding one data source per
decoding, as this would yield 2 extra notebook tabs
for situation (d), without counting the possible lower
layer reassembly tabs (Packet, IPv4, TCP).
This has been addressed by a recent fix from Ulf Lamping.
A second option is given in reply to the mail below.
4. The code that highlights the encoded entity body
incorrectly highlights the bytes when chunked *transfer*
coding *and* gzip/deflate *content* coding are being used
for the same entity body.
I moved the addition of the de-chunked data source to the
de-chunking code. This should fix the incorrect highlighting.
And below are answers to yet unanswered questions.
----- Original Message -----
From: Jerry Talkington
| On Sat, May 08, 2004 at 11:25:24PM +0200, Olivier Biot wrote:
| > From: Jerry Talkington
| 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?
In my situation it sometimes *is* necessary to see both uncompressed
*and compressed output, so that we can check that the compression was
done correctly. If you don't offer this data to the user, it cannot be
accessed as it's only used internally in the dissection.
| 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.
That's correct.
| 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".
This leads to 2 possibilities, which we may implement by means of
another HTTP preference which governs the way the entity bodies are
being displayed to the end-user. I would be the end-user willing to
see all transform steps (including the possibility to highlight the
uncompressed data). You would be the end-user who is only interested
in the final outcome, hence only one data source will be offered.
| 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.
That's another addition which I agree with.
Regards,
Olivier
