Wireshark · Ethereal-dev: Re: [Ethereal-dev] Need help on dissecting from multiple frames and scrollbars

[LEGO <luis.ontanon@xxxxxxxxx>]

> If by "decode multiple GETs when they are in the same packet" you mean
> "decode multiple (pipelined) requests or replies when they are in the
> same packet", there shouldn't be a preference setting for that - it
> should *always* happen.

Yes, I meant that. I made it optional because thought is was just the
(mis) behaviour of some broken mobile handsets I deal with. Since it
is something "normal" (although I haven't ever seen this before)  it
won't be an option but the normal behaviuor.

> You might also have to add to the existing code the ability to
> reassemble HTTP bodies split between two packets when there isn't a
> Content-Length header.  Section 4.4 "Message Length" in RFC 2616 says that

A behaviour I had seen already.

>         1) some response messages *never* have HTTP bodies - we currently don't
> handle those differently, but we probably should;

302, 304 and other "redirectors" I think.
I'll read the RFC(s) again I think I need it.

>         2) if the headers include a Transfer-Encoding field with a value other
> than "identity", the length is defined by use of the "chunked"
> transfer-encoding - or by the end of the connection;

I've never seen this, captures anyone?

>         3) if there's a Content-Length header, that specifies the length;

I got captures for this.

>         4) if the media type is multipart/byteranges, that type's format
> defines the length;

I've never seen this, captures anyone?

>         5) closing the connection ends the body in any case.

A very simple CGI script with no Content-Lenght should do?

> We should handle (1).  I think we already handle (2), except for the
> "end of the connection" part, and we already handle (3).  We don't
> currently handle (4), and we don't handle (5).
> 
> Handling (5) might require that we supply to subdissectors of the TCP
[snip]
> People have suggested that a better scheme than the current
> pinfo->private_data scheme be used, to better handle the case of a
> dissector being called from more than one dissector and expecting
> pinfo->private_data.  I'll have to dig up the mail about that to see
> what was suggested.
> 

here's mine:

==== in somecaller.h ====
typedef struct _some_private_data {
   guint32 id;
   ...
} some_priv;

=== in packet-caller.c ====
priv_data->id = SOME_PRIVDATA_ID

==== in othercaller.h ====
typedef struct _other_private_data {
   guint32 id;
   ...
} other_priv;

=== in packet-othercaller.c ====
priv_data->id = OTHER_PRIVDATA_ID

=== in packet-called.c ====
if (pinfo->private_data) {
   switch (*((guint32*)pinfo->private_data)) {
    case SOME_PRIVDATA_ID:
        ...
     case OTHER_PRIVDATA_ID:
        ...


> 
> Look for code that calls "scrolled_window_new()" in the gtk subdirectory.
> 

I will.

Thanks