Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 20809 invoked by uid 500); 21 Sep 2000 19:22:44 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 20787 invoked from network); 21 Sep 2000 19:22:44 -0000 X-Authentication-Warning: koj: rbb owned process doing -bs Date: Thu, 21 Sep 2000 12:23:02 -0700 (PDT) From: rbb@covalent.net X-Sender: rbb@koj To: new-httpd@apache.org Subject: Re: subrequest filtering (yet again) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > 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 -------------------------------------------------------------------------------