httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 15:34:39 GMT
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
--

Mime
View raw message