httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: subrequest filtering (yet again)
Date Thu, 21 Sep 2000 19:23:02 GMT

> 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.

Yes it does.  Luckily both of those filters are pretty low in the filter
chain, or at least they should be.  They also aren't generally filters
that would be added for a sub-request.  When a filter is added, the thing
doing the adding should probably check if it is a sub-request, assuming it
know if the filter makes sense for sub-requests.

> 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.

> 
>   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.  We haven't gotten to the insert filters hook (sorry!) for
>   the subrequest yet so we still have time to add the filters
>   appropriate to the subrequest.

Yep, that was the thought.  

> As for the hopefully-rare case where the filters for the request and
> the filters for the subrequest clash:
> 
>   I guess your comment about the need to remove filters is intended to
>   cover this?

Mostly.  Some filters will need to know that they make no sense if called
from sub-requests.  They will either have to ensure that they are not
added, or that they are removed before they do any work.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message