httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject The Byterange filter -- a new design -- feel free to rip it to shreds
Date Mon, 12 Jul 2004 02:04:54 GMT
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.

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.

what I am proposing is something like:

1. the filter keeps a ordered list of range requests that the person 

2. it keeps state on how far it has processed in the file. thanks to 
knowing the length of the buckets processed so far.
   Q: when do the actual headers get put in.. I think they are after no?

3. it then examines the bucket + bucket length to see which range 
requests match this range, if some do it grabs that range (possibly 
splitting/copying if it meets multiple ranges) and puts it on the right 
bits of each range request.

4. if the top range request is finished, it passes those buckets through.

5. repeat until EOS/Sentinel, flushing the ordered list at the end.

now . for part 2, we would need a method of telling the byte-range 
filter that the incoming brigade only has parts X, Y, Z in it. The 
easiest way for something like mod-proxy to do this without a API change
would be for it to create a dummy bucket with the correct length, 
knowing that this would never be read. (yes I know it's a hack)

now.. this assumes that splitting a bucket (and copying) is a zero cost 
operation which doesn't actually *read* the bucket, is this true for 
most bucket types?

would this kind of thing work?


View raw message