Re: reconstruct HTTP requests in custom sniffer

[Cedric Cellier <rixed () happyleptic org>]

-[ Sun, Jan 09, 2011 at 02:19:53PM +0900, Andrej van der Zee ]----
> Is there anything to say about a rough time-schedule?

Support for TCP segmentation as well as new parsers that use this
feature should be pushed before end of week. Concerning the capture of
POST messages we should probably start working on this in february (this
is a small company so no schedule is ever definitive, so no promise).

> In some of our projects, we are only interested in the length of HTTP
> requests and responses therefor reassembling the whole requests would be
> overkill, as the segment lengths can be read from the TCP headers of packets
> in a TCP stream, obviously.

Yes, in theory we could follow the sizes associated with each request quite
precisely even with truncated packets as long as the "Content-length"
header lines are present. To be honest, truncated packets were
introduced very recently and were not tested much (since we do not
require this feature), thus I'm not certain junkie is very robust in this
regard ; but I'm going to check.

> In other projects, we definitely have to access
> the POST data need full-reassembly. Depending on the project, a different
> parsing-behavior is wanted. Will such behavior be configurable without
> having to write my own patches against junkie?

What we need here is to be able to tell junkie for which hosts we want to
keep all queries (including POST data). At first sight, I planned to
let junkie reassemble everything on HTTP and copies all HTTP requests in
whole, then drop everything I do not need in the callback that's called
after the parse. I find this approach simpler and I don't think we require
extra speed in the parse phase anyway. It will still be possible to
optimize this later anyway.


-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.