httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 15:35:45 GMT
At 08:44 AM 7/13/2004, Graham Leggett wrote:
>Geoffrey Young wrote:
>>ok, that isn't the idea I had about output filters at all.  my own concept
>>of how this all worked (or should work) is that content handlers are
>>supposed to just generate content.  specifically, they should not care at
>>all about RFC compliance - this is why we have a separate header filter,
>>byterange filter, and so on (and why I think ap_set_last_modified foo should
>>be in its own filter ;)
>In terms of very simple content handlers, such as a handler that might serve content stored
in a file on disk, the above is true - it doesn't care much about HTTP, that is mostly handled
by higher layers.
>The problem starts creeping in when the content handler is less trivial than the file
serving handler, such as mod_proxy, which receives an HTTP request from the input filter stack,
and returns an HTTP response to the output filter stack based on content and headers generated
by a backend server.

The confusion results because mod_proxy isn't implemented as a content
handler, it's a protocol handler in its own right.  Rather than insist on the
mod_http <> mod_proxy agreeing to streamline the response, we've put
it on every content module author to:

. remove output C-L header if the size is transformed
. remove input range headers if the content isn't 1:1 transformed

This is very kludgy and more an example of where mod_http <> mod_proxy
didn't quite get it right, and made it a little more difficult for folks who are
just trying to transform content bodies.

It would be nice in apache 2.2 to finally clean up this contract, with two
simple metadata element to pass through the filter chain:

. this request is unfiltered
. this request has a 1:1 filter (stateless)
. this request has a arbitrary content transformation

Each filter is the stack could promote the complexity but should never set
it to a lower state.  This would allow http/proxy modules to negotiate less
complex transformations in more efficient ways.


View raw message