[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