left to the webserver admin to figure out what they were, and if you could use this.
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.
what I am proposing is something like:
1. the filter keeps a ordered list of range requests that the person requests.
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?
--Ian
