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 Tue, 13 Jul 2004 15:57:33 GMT
Nick Kew wrote:

> Indeed.  In a straight-through proxy that's right.
> But in the case of a cacheing proxy, it may be better for it to retrieve
> the entire document and manage byteranges locally.  And in the case of
> a content-transforming proxy, the filters may need the entire content to
> function at all.

Remember that in our case there is no such thing as a "caching proxy". 
mod_proxy in v2.0 has no caching capability whatsoever. Caching has been 
moved to mod_cache, and is handled completely separately from proxy.

mod_cache has it's own ranging issues, which are probably already solved 
by the byte range filter anyway.

> Bottom line: this has to be controlled by the server admin.  We offer
> the options of passthrough, process locally, or ignore ranges.

I think it's better to avoid adding extra directives, or giving the 
admin the power to override RFC2616. How to handle ranges is described 
fully in the HTTP/1.1 spec, the admin shouldn't really have the option 
to fiddle with it. Just adding more ways to get it wrong.

> Indeed, historically (possibly still) content length has been a problem
> for filters.  Simply removing the header may not be sufficient if the
> content-length filter reinserts it erroneously.  Ranges are more
> complex.
> Basically a proxy or other content generator that takes care of
> byteranges itself is going to be incompatible with certain output
> filters.  That has to be documented, and there has to be an easy
> way for filters to detect when they're not wanted, or for Apache
> to mark them inapplicable and refuse to run them at all.
> A situation where filters have to get their hands dirty with
> partial responses would be a serious problem.

Any filter that could get it's hands dirty (mod_include springs to mind) 
should just strip the Range header from the request, leaving the byte 
range filter to do the dirty work for it on the full response.

Any filter that fiddles with Content-Length is probably also going to 
have to be taught about ranges - either it must remove the Range request 
header as in mod_include above (the simplest case), or depending on 
what's practical, it might be taught to do something more intelligent 
about ranges.

The bottom line is this: a filter that might blow up on a range must 
either a) ignore range, as the filter is not affected, or b) be 
intelligent enough to handle the range or c) strip the Range header off 
the request and just generate a full response as happens now.

I stongly suspect most filters will be choosing option c) at the outset, 
moving to a) or b) as we slowly teach the filters that need teaching 
what to do with ranges.


View raw message