httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 16:21:00 GMT
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
>>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.


View raw message