> 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