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 19:52:28 GMT
On Thu, 21 Sep 2000, Tony Finch wrote:

> Jeff Trawick <> 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 :-)

While I agree in theory, in practice, this just won't work.  The problem
is that the core may insert the filters, and the core doesn't know if a
filter makes sense to be in the stack twice.  This is why I would really
like to punt this to the filter.  Basically, the filter gets called once,
sets a flag, and if it is called a second time for the same data, the
second call is removed from the stack.  This has the nasty problem of not
working if the second call is the one that is desired, but I'm not sure
how often that will happen.


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

View raw message