[Oisf-devel] Support for HTTP range requests

Christian Kreibich christian at lastline.com
Thu Oct 8 19:02:17 UTC 2015


On 10/08/2015 11:32 AM, Victor Julien wrote:
> Currently libhtp doesn't support this at all. Originally the plan was to
> have libhtp handle most of it, but since Ivan moved on things have been
> in limbo.

Got it. That was my sense, thanks Victor.

> We'll need to update libhtp a bit to start supporting this. I do think
> the 'reassembly' would better be done inside Suricata.

Mhmm yeah, this seems a bit tricky. There could be various policies you 
want to use to drive the reassembly. My intuition would be to have most 
of it happen in libhtp since the content-ranges are an HTTP-internal 
aspect that the library user may not care about at all.

> We do need to think on how to do the data storage. For simple cases we
> may look at the IPPair data structure, but for sites with multiple hosts
> serving a domain we'd need something else. Perhaps a new data store
> searchable by hostname + url.

In case it helps, RFC 7233 has this to say:

   When a 206 response is generated, the server MUST generate the
   following header fields, in addition to those required above, if the
   field would have been sent in a 200 (OK) response to the same
   request: Date, Cache-Control, ETag, Expires, Content-Location, and
   Vary.

So there are several ways to track the entity overall.

-C.



More information about the Oisf-devel mailing list