On Tue, 13 Jul 2004, Graham Leggett wrote: > 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".
Of course there is! It's apache with mod_proxy and mod_cache. Just as a content-transforming proxy is apache with mod_proxy and one or more content filter module. > > 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. AFAICS RFC2616 sanctions any of the three behaviours I'm proposing. Firstly noone is required to support ranges at all. Secondly the following passage from #14.35 seems to sum up the other options: If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire entity in reply, it SHOULD only return the requested range to its client. It SHOULD store the entire received response in its cache if that is consistent with its cache allocation policies. That's not explicit about whether the Range was forwarded, but neither AFAICS is anything else in the RFC. > 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. That is dirtying the filter API further. If filter modules are to be responsible for that, we should at least provide a higher-level API for them, ideally in a declarative form. Maybe something along the lines of an AP_IS_TRANSFORM flag or flags, that will transparently deal with Content-Length, Range and Warning headers on behalf of a filter when it is inserted. If we can abstract out the common processing required of every content-transforming filter into a simple magic-API, I'll be happy. -- Nick Kew
