At 10:57 AM 7/13/2004, Graham Leggett wrote: >Nick Kew wrote: > >>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.
Agree here, filters themselves know better than the administrator. >>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. I don't like where this conversation is heading at all. You are suggesting that every filter needs to become progressively more aware of the http module characteristics, but that's what we were moving away from in apache 2.0. Body/content generation or transformation should not be contending with these issues you raised above. It's not unreasonable to expect some metadata to pass through or be transformed (such as a content length, which some filter can tweak or discard altogether.) But it is getting very obscure to expect them to contend with byteranges. What's next? That's why I proposed a skip-forward semantic to support byte ranges. It's far abstracted from http, is an optional feature (skip if you can, or read if your filter must in order to transform) and trivial to implement. And it's typical of bytestream APIs. The proxy solution is simpler, determine if end to end you have either http <> proxy, or if the intervening filters are all 1:1 stateless transformations. If they can't negotiate a protocol level pipe (because there are non-stateless content filters in the way), then it's up to http and proxy to stay out of the way, and make it possible for content filters to filter content. Bill
