Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] HTTP chunked encoding and protocol hierarchy

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Olivier Biot" <ethereal@xxxxxxxxxx>
Date: Thu, 29 Apr 2004 22:36:03 +0200
From: Jerry Talkington

| On Tue, Apr 27, 2004 at 08:16:48AM -0700, Jerry Talkington wrote:
| > On Tue, Apr 27, 2004 at 03:35:09PM +0200, Biot Olivier wrote:
| >
| > > Should the chunked decoding appear as a subitem to the HTTP
tree, or as a
| > > "protocol"? Personally I'm more in favor of the 1st option.
| >
| > Now that I know it exists, I'm more in favor of a third option:
making
| > it an option.  If the hierarchy statistics are simply pulled from
the
| > middle pane, it should be a snap to add options allowing the user
to
| > specify where to stick it.
| >
| > If nobody objects, I'll re-implement the chunked decoder as a
| > "protocol", and give the user an option of including it in the
protocol
| > statistics.  I'll also give the user the option of including the
| > content-encoding, and media types in the hiearchy (I can't imagine
| > having "Line-based text data" is usefull to anybody, but the
actual
| > media type would be, so I'll stick the text data under the media
type.)
|
| The more I think about this/look at the code, the less I like this
idea.
| There doesn't really seem to be a way to add media types to the
protocol
| hierachy without creating a dissector for each one encountered.

Consider the fact that there is already a WBXML dissector, a GIF
dissector and a JPEG/JFIF dissector. Then there is also the
"line-based text" dissector. And there are more.

The way it is now makes much sense to me.

| I have a couple ideas for a generic dissector (i.e. you pass the
name
| and desciption, and a data dissector is created on the fly,) but I'm
not
| sure how worthwhile it would be, I'll have to do some more
| investigation.

This is not really required, I think. There are much more important
flaws in the protocol hierarchy code today as there is no means today
of distinguishing between protoX on top of protoX or just an
encapsulation of multiple protoX messages. This is easy to see with
many X11 captures where concatenation of X11 messages in one packet
are very common. The protocol hierarchy will show this as being X11
over X11 over ... over X11.

Believe me, there is no simple means of deciding whether once it is
encapsulation and the other time it is fragmentation or tunnelling.

| In the meantime, here's a patch to move the Chunked response and
encoded
| entity body items to the HTTP tree.

Checked in.

Regards,

Olivier