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 --
smime.p7s
Description: S/MIME Cryptographic Signature
