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
--
|