httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Mon, 12 Jul 2004 11:44:58 GMT
Ian Holsman wrote:

> ok, now before I start this let me say one thing, this is not for *ALL* 
> requests, it will only work for ones which don't have content-length 
> modifiable filters (like gzip) applied to the request, and it would be
> left to the webserver admin to figure out what they were, and if you 
> could use this.

Question:

When a request for a byte range arrives, and the byte range is returned, 
_and_ a transfer encoding is applied (eg gzip) (different to a content 
encoding) - is the gzip transfer encoding not applied to the byte range 
as a single unit?

As I understand it, if transfer encoding was done on the data, then it's 
done on the byte range, so handling something like mod_gzip separately 
in theory should not be a problem.

> ok..
> at the moment when a byterange request goes to a dynamic module, the
> dynamic module can not use any tricks to only serve the bytes requested,
> it *HAS* to serve the entire content up as buckets.

In theory, if mod_proxy (for example) gets a byte range request, it 
should only serve that byte range - ideally modules/filters should not 
"prop up" other modules/filters.

If a filter somewhere in the filter stack is going to break the byte 
range request in any way (for example something like mod_include) then 
that filter should be responsible for removing the Range header from the 
request before mod_proxy gets a chance to service the request.

In theory, as the byte range filter should be one of the topmost filters 
run, it would have seen the Range header and noted what range it should 
have been returning, so a downstream filter removing the Range header 
should not cause a problem for the byte range filter.

In turn, if a downstream filter/content handler has returned a 206 
Partial Content response, the byte range filter should know what to do 
(has my job already been done by a downstream filter? if so, I do 
nothing. Has a downstream filter given me a range bigger than what I was 
asked for? If so, intelligently chop up what I am receiving so that I 
return the byte range I was asked for).

This keeps each modules' behaviour simple and easy to predict, and 
doesn't need to include any new bucket types or "special" handling.

In fact thinking about this some more - mod_include might look at the 
byte range, and then intelligently decide to either include / not 
include certain included content based on the byte range. This could 
improve performance on some sites.

So to sum up:

- Teach the byte range filter that it might receive content from a 
content handler that already has the byte range applied, and to react 
intelligently when this happens. A content handler will indicate this by 
returning a 206 Partial Content and/or a Content-Range header, which is 
easily parsed by the byte range filter - no need for special flags or 
buckets.

- Teach certain content handlers (such as mod_proxy or mod_cache) to 
handle byte range requests themselves, using the standard RFC2616 
headers and responses to indicate whether ranges have been applied. 
Which content handlers will be taught this will depend on whether there 
is a performance gain to be had by getting the content handler to know 
about byte ranges.

- Teach certain problem modules (mod_gzip if appropriate) to react 
intelligently to the byte range headers, either by stripping them from 
the request (thus causing the downstream content handler to follow 
current behaviour of creating the full content), or by being more 
intelligent about it as each case arises.

Regards,
Graham
--

Mime
View raw message