LEGO wrote:
I'm trying to add few features to http on ethereal:
in the dissector:
- fixed a stat_info leakage
- added http.request.uri
- added a preference to decode multiple GETs when they are in the same packet
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.
The problems I have are the followiwng:
1. Requests that are splitted in two packets
I do actually decode multiple GETs in the same packet, but if the last
one happens to end in the next packet I realy do not know what should
I do to decode it.
What you should do is to turn on the "Reassemble HTTP headers spanning
multiple TCP segments" and "Reassemble HTTP bodies spaning multiple TCP
segments" preferences - and possibly the "Reassemble chunked
transfer-coded bodies" and "Uncompress entity bodies" preferences - and
let the existing code in the HTTP dissector reassemble requests split
between two packets.
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
1) some response messages *never* have HTTP bodies - we currently don't
handle those differently, but we probably should;
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;
3) if there's a Content-Length header, that specifies the length;
4) if the media type is multipart/byteranges, that type's format
defines the length;
5) closing the connection ends the body in any case.
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
dissector an indication of whether the segment had FIN set - and that
dissectors know whether they're being called by the TCP dissector or
not, so they know whether pinfo->private_data points to a "struct
tcpinfo" or not.
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.
2. As I added the lists of uris and urls to the HTTP statistics window
it grew and now it needs a scrollbar. Any hints on where can I look
for examples on how to add a scrollbar to a window.
Look for code that calls "scrolled_window_new()" in the gtk subdirectory.