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: Biot Olivier <Olivier.Biot@xxxxxxxxxxx>
Date: Fri, 30 Apr 2004 10:28:24 +0200
|From: Jerry Talkington | | |On Thu, Apr 29, 2004 at 10:36:03PM +0200, Olivier Biot wrote: |> From: Jerry Talkington |> |> | 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. | |Sure, but 99% of the traces that I look at have at least one |object type |that doesn't have a dissector. I was just pontificating that it would |be useful to have the number of objects of X media type in the |hierarchy except... OK I got your point and it makes sense to me! Fortunately this can easily be dealt with, by defining a generic "media" dissector (which would be used instead of the generic "data" dissector) in case there was no match for a given media type. All dissectors that currently use the "media_type" string dissector table defined in packet-http.c will have to be updated then in order to call the "media" dissector instead of the "data" dissector in case of no match. And that leads to another function I think may be interesting to use (epan/packet.h): /* Look for a given perl-compatible regular expression in a given string dissector table and, if found, call the dissector with the arguments supplied, and return TRUE, otherwise return FALSE. */ extern gboolean dissector_try_string_pcre(dissector_table_t sub_dissectors, const gchar *string_pcre, tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree); /* Look for a given perl-compatible regular expression in a given string dissector table and, if found, return the dissector handle for that value. */ extern dissector_handle_t dissector_get_string_pcre_handle( dissector_table_t sub_dissectors, const gchar *string_pcre); This way, one could check for "(?i)[+]xml$" (for the line-based text dissector and "(?i)[+]wbxml$" for the WBXML dissector. I can add this (generic media dissector, pattern match in string dissector table) over the weekend. |> | 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. | |this. I was also thinking that I might just work on getting some |more/better HTTP statistics going. But, there are other things that I |want to work on first (mainly decompression of HTTP entity-bodies.) Go ahead! Regards, Olivier
- Prev by Date: [Ethereal-dev] protocol handoff still confusing / README.developer out of date
- Next by Date: RE: [Ethereal-dev] [RFC] specially mark protocol fields "generate d" byEthereal?
- Previous by thread: Re: [Ethereal-dev] HTTP chunked encoding and protocol hierarchy
- Next by thread: [Ethereal-dev] RTP Analysis - linking back to setup traffic?
- Index(es):
- Get Wireshark
- Download
- Code of Conduct