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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
