httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: subrequest filtering (yet again)
Date Thu, 21 Sep 2000 18:04:46 GMT
On Thu, 21 Sep 2000, Jim Winstead wrote:
> On Sep 21, Jeff Trawick wrote:
> > I gather that most folks want a subrequest to inherit the content
> > filters associated with the original request.  Why is this?  If the
> > set of filters isn't appropriate, you can't get rid of them.  If the
> > set of filters is appropriate, then the configuration associated with
> > the subrequest URI would have caused the right filters to be added
> > anyway (unless the URI of the subrequest is only requested via a
> > subrequest).
> > 
> > What am I missing?
> i don't see how including the results of a subrequest should be
> any different than including a file. or the results of an external
> request. or any other bit of data that a content-generator generates
> (whether it be the first thing in the filter-chain or something in
> the middle that is inserting content).
> it almost seems like it should be its own bucket-type. so the
> "output" of mod_include for this file:
>   <!--#include virtual="header.html"-->
>   <p>this is the real page content
>   <!--#include virtual="footer.html"-->

This is actually one of the designs that Tony and I considered, but it is
a bit non-orthogonal.  The problem is that sub-requests basically convert
to some other bucket, be it a file or heap, whatever.  It is not possible
to read from a sub-request bucket until it has been converted.  This
conversion could be hidden behind the read function, but it isn't
completely clean.

Imagine a sub-request that resovles to a CGI script that takes a long time
to output all of it's data.  The sub-request bucket has to stick around
throughout all of that processing.

> to it, lets say it is the gzip filter, it may decide that it actually
> needs the raw bits of the buckets, so it will call bucket->read
> (or whatever), which will actually trigger the subrequest to get
> the raw bits that result from that. (it may be an important
> distinction to think of it as the filter asking for the results of
> this subrequest, *not* the browser making the original request. so
> this subrequest shouldn't trigger any filters based on the user
> agent of the browser (unless the subrequest handler specifically
> looks to the original request), for example.)

The problem is that our output is usually handled as a push, and
sub-requests would have to be a pull.  It might work, but it might
not.  Again, we really need code to determine the "best" way to handle
this.  Until we have code, I fear we are thrashing.  :-)


> does that make any more sense? does it help? maybe i'm
> talking about a different filtering than what's going on in
> apache 2.0. unfortunately, i haven't had the time to follow
> the code very closely.
> jim

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message