httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Mon, 12 Jul 2004 13:49:08 GMT
Nick Kew wrote:

> That will not always be practicable.  mod_proxy should be configurable
> to pass byteranges headers straight through to the backend or strip them
> and assume the proxy will handle the ranges.

Byte ranges are a part of HTTP/1.1, and mod_proxy claims to be an 
HTTP/1.1 proxy. mod_proxy should behave how RFC2616 tells it to behave, 
and such behaviour should definitely not be configurable unless 
absolutely necessary.

> Doesn't that break modularity rather badly?  mod_include is concerned with
> simple content modifications, not HTTP.  It doesn't need more complexity.

It would not break modularity no - because the behaviour is in most 
cases "if Range header present, remove it, else do nothing". If 
mod_include was processing a non HTTP stream (for whatever reason) the 
"else do nothing" would apply, no problem.

>>In theory, as the byte range filter should be one of the topmost filters
>>run, it would have seen the Range header and noted what range it should
>>have been returning, so a downstream filter removing the Range header
>>should not cause a problem for the byte range filter.

> But if you adopt that approach, then *every* filter has to faff about
> with range headers (just in case),

Why would every filter have to faff with range headers?

> the first one strips it out, and
> the others run in blissful ignorance.  Makes more sense if only the
> byterange filter concerns itself with the header.

Which in turn means that every filter, now blissfully unaware of ranges, 
is forced to generate a full response for each byterange request. In the 
case of a downloaded ISO (for example), this means a significant amount 
of data (many hundreds of MB) is being processed by filters on each request.

Thus this discussion.

>>In fact thinking about this some more - mod_include might look at the
>>byte range, and then intelligently decide to either include / not
>>include certain included content based on the byte range. This could
>>improve performance on some sites.

> For mod_include to do that is an order of magnitude extra complexity
> (even if you solve the problem of measuring the length of each include
> without actually executing it).  For modules that generate entirely new
> data - such as those based on a markup processor (accessibility, xmlns,
> xinclude/xslt, proxy_html, annot - to name but a few) it becomes even
> bigger: we'd have to count every byte we write!

The key word above was "might". Obviously teaching modules about byte 
ranges would only make sense where it was justified.

If it were too complex for a module to handle byte ranged content, it's 
really simple - just tell it to strip the Range header off so the 
content handler never sees it.

>>So to sum up:
>>- Teach the byte range filter that it might receive content from a
>>content handler that already has the byte range applied, and to react
>>intelligently when this happens. A content handler will indicate this by
>>returning a 206 Partial Content and/or a Content-Range header, which is
>>easily parsed by the byte range filter - no need for special flags or

> That has to be configurable, as some filters can only run on a
> complete datastream.

The above does not need to be configurable at all - as the above is only 
concerned with the byte range filter receiving content from downstream 
that is already a byte range.

I am assuming the current behaviour of the byte range filter would apply 
the range to the content without checking first whether this has already 
been done. This fix is very straightforward.


View raw message