You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/08/01 23:55:28 UTC
[Fwd: Re: The Byterange filter -- a new design -- feel free to rip
it to shreds]
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. <wr...@rowe-clan.net>
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
References: <40...@apache.org> <40...@sharp.fm>
<Pi...@hugin.webthing.com>
<40...@sharp.fm> <40...@modperlcookbook.org>
<40...@sharp.fm> <40...@modperlcookbook.org>
<40...@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
Re: [Fwd: Re: The Byterange filter -- a new design -- feel free to
rip it to shreds]
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>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.
>
>
> no, it is not required to strip Range at the moment - the short answer is to
> just forget about that thread :)
>
> the long answer is that the issue in the thread is that currently content
> handlers need to serve up all their content, even when byteserving, so that
> the byterange filter has all the data and can work. the suggestion made in
> the thread is essentially to let content handlers (more specifically
> mod_proxy, which isn't a content handler) do the byteserving themselves, in
> which case they would need to let future filters know that only the
> specified Range is actually coming down the brigade, not the entire content
> for the request.
>
> to really get a feel for what is going on, see graham's response to one of
> my posts early in the thread
>
> http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108972633012892&w=2
>
> this post seems to sum up where the thread was headed (and the dominant
> httpd-dev mindset) before it was restarted
>
> http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108973604000918&w=2
I skimmed through the whole thread in first place, so I'm up to date :)
But I was left with the impression that at the moment that wrowe was
talking about the current situation:
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108973489919749&w=2
> so basically, I wouldn't worry about Range at all, at least not at the
> moment - we may need to completely redesign our filter API if any of these
> proposed changes become real, but I really don't see that happening in the
> near future, certainly not with 2.0 and probably not even in 2.1.
OK, thanks Geoff.
--
__________________________________________________________________
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
Re: [Fwd: Re: The Byterange filter -- a new design -- feel free to
rip it to shreds]
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> 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.
no, it is not required to strip Range at the moment - the short answer is to
just forget about that thread :)
the long answer is that the issue in the thread is that currently content
handlers need to serve up all their content, even when byteserving, so that
the byterange filter has all the data and can work. the suggestion made in
the thread is essentially to let content handlers (more specifically
mod_proxy, which isn't a content handler) do the byteserving themselves, in
which case they would need to let future filters know that only the
specified Range is actually coming down the brigade, not the entire content
for the request.
to really get a feel for what is going on, see graham's response to one of
my posts early in the thread
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108972633012892&w=2
this post seems to sum up where the thread was headed (and the dominant
httpd-dev mindset) before it was restarted
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108973604000918&w=2
so basically, I wouldn't worry about Range at all, at least not at the
moment - we may need to completely redesign our filter API if any of these
proposed changes become real, but I really don't see that happening in the
near future, certainly not with 2.0 and probably not even in 2.1.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org