httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Winstead <j...@trainedmonkey.com>
Subject Re: subrequest filtering (yet again)
Date Thu, 21 Sep 2000 17:27:08 GMT
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"-->

would be a stream ("brigade"?) that looks like:

  * bucket of type "headers" (headers output by mod_include)
  * bucket of type "subrequest" (for header.html)
  * bucket of type "data" (the real page content)
  * bucket of type "subrequest" (for footer.html)
  * bucket of type "end-of-stream"

now, when the next filter in the chain gets those buckets handed
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.)

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

Mime
View raw message