httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: subrequest filtering (yet again)
Date Thu, 21 Sep 2000 19:47:05 GMT
Jeff Trawick <trawickj@bellsouth.net> wrote:
>
>Now sometimes the filters defined for the subrequest will clash with
>the filters defined for the original request.  What if both the
>original request and the subrequest have a gzip filter defined?
>Garbage comes out.  What if both have some character set translation
>defined?  Garbage comes out.

I think that modules should examine the existing filter stack before
inserting their filters to ensure that the result makes sense. E.g.1
gzip only occurs in the main request filter chain. E.g.2 the output of
the sub-request's character set translation must be the input of the
main request's character set translation. This is rather gnarly and
easily leads to absurdly inefficient setups but I think we can
consider any that turn up in real life to be the webmaster's fault.

The alternative is to add loads of cleverness to the core to match
filter input and output types, but I don't think we know how to do
that :-)

>Assume the hopefully-normal case where the filters for the request and
>the filters for the subrequest don't clash:
>
>  When we create a subrequest, it inherits the full set of filters from
>  the request.  This is appropriate (I think) if the subrequest was
>  initiated by a handler (non-filter).

Yes, and it turns out to be a special case of the following...

>  If the subrequest was initiated by a filter, perhaps the filter could
>  set subrequest->output_filters to f->next after creating the
>  subrequest but before running it.  I think that this would cause
>  subsequent filters for the original request to be executed at the
>  right time.

I agree.

Tony.
-- 
en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y    dot@dotat.at
eatp o v eiti i d.    fanf@covalent.net

Mime
View raw message