-------- Original Message --------
Subject: Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date: Tue, 13 Jul 2004 10:35:45 -0500
From: William A. Rowe, Jr. <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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.
Bill
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
