William A. Rowe, Jr. wrote:
The solution to this problem is *not* to become tightly coupled with the placement of filters, directly handling file streams, etc.
The clean solution is a new forward-space semantic for the filter or brigade, which would allow you to skip n bytes. This would allow those
filters which know their transformation (1:1 mappings, etc) to simply
pass this request forward, until it ultimately hits the core filesystem
filter which can seek(fd, CUR, n).
Those filters without expectations of the transformation without fully
reprocessing the stream (e.g. includes) would have to reprocess the data, no surprise there.
I don't follow...
If mod_proxy gets a Range header, in theory it should pass the range header as is to the backend server. In return, the backend server says "206 Partial Content" and returns content matching the range. mod_proxy now sends this already-ranged content up the filter stack.
At this point, what happens?
a) the filter stack falls over, as it does not understand 206 Partial Content
b) mod_proxy converts the range into something resembling the full response, but with dummy bits filling in the parts of the range that is not there, to be stripped out again by the byte range filter?
c) the filter stack recognises the response as a ranged response, and backs off as appropriate (by filters excusing themselves from the filter stack, or by filters like mod_include quitely removing the Range request header so proxy never sees it in the first place).
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
