subrequest filtering (was: BIG filtering patch.)

[Greg Stein <gs...@lyra.org>]

On Sat, Jul 08, 2000 at 11:21:31AM -0400, Rodent of Unusual Size wrote:
> Rodent of Unusual Size wrote:
> > 
> > AddFilter .cgi ssi-parse digestify
> > 
> > meaning that the output from the content handler for .cgi
> > would be run through the SSI parser, and the result of *that*
> > would then be passed through the digestifier.
> 
> Since CGI scripts in "include virtual" SSIs get processed
> as subrequests, *their* output would be parsed before being
> passed back into the calling ssi-parse filter.  But somehow
> digestify would have to be deferred to only being called once,
> on the final output.  Hmm..

Not a problem.

Please refer to my mod_gargle example that I posted a while back. All of the
sub-request's output would flow through the filter chain. This would also
include the "connection filters" (such as digesting), but skip the main
request's output filters.

In my patch, I classified filters according to two types: content filters
and connection filters. Digestifying is a connection filter. I also
postulated that a subrequset is not allowed to insert connection filters --
only the main request.

In the mod_gargle example, there was a "policy" decision that needed to be
made. Specifically, "which main-request's content filters are applied to the
subrequest output?" Note that the subrequest is going to have its own
filters, and it will alway go through the (main request's) connection
filters. The question is whether it makes a stop in the main request's
content filters. Imagine a parent filter chain such as:

    F1 -> F2 -> C1 -> C2

Fn are the content filters, Cn are the connection filters. Let's say F1 is
making the subrequest. Does the subrequest output (after its own filtering)
go into the output chain at F1, F2, or C1?

In my mod_gargle, the "policy" was that the output would go into the "next"
filter -- F2.

In your example above, the subrequest would simply never add a connection
filter. In my patch, I have no code that enforces this (but it could go into
ap_add_filter()). Instead, I figured that the digestify filter would simply
decline to insert itself when the request is a subrequest.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/