perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject [Fwd: Re: The Byterange filter -- a new design -- feel free to rip it to shreds]
Date Sun, 01 Aug 2004 21:55:28 GMT
Catching up with httpd-dev: So should we adjust our docs/tests to strip 
the input Range headers too, in addition to C-L in output filters? I'm 
not quite sure I understand what are the circumstances when this needs 
to be done.

-------- 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. <wrowe@rowe-clan.net>
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
References: <40F1F1C6.4030400@apache.org> <40F279BA.7050002@sharp.fm> 
<Pine.LNX.4.53.0407121400490.20952@hugin.webthing.com> 
<40F296D4.7090303@sharp.fm> <40F2AAD7.2030003@modperlcookbook.org> 
<40F3AC0A.20803@sharp.fm> <40F3DDC8.1000803@modperlcookbook.org> 
<40F3E752.1040205@sharp.fm>

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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message