httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Date Fri, 22 Sep 2000 16:02:58 GMT

Told I must be missing something BIG.  I looked at the code and saw r not
rr.  Blame it on bad eyes and staring at computers too much.  :-)

I would agree with you that this needs to be made much cleaner however.


On 22 Sep 2000, Jeff Trawick wrote:

> writes:
> > This won't work.  What we have just done here, unless I am missing
> > something BIG, is to set r->output_filters to the next filter in the
> > chain.  The problem is that when we get all the back up to the handler, it
> > will call ap_pass_brigade with r->output_filters, and it will bypass all
> > of the filters before the mod_include filter.
> Setting rr->output_filters only modifies the output filter list for the
> subrequest.  The request filters are unchanged.
> Suppose the configured filter chain for the request is
> and the configured filter chain for the subrequest is
>   W X Y Z
> and INCLUDES runs the subrequest...
> When INCLUDES calls ap_run_sub_req(), r->output_filters will be set to
>   D E F
> After the insert_filters hook runs (from ap_run_sub_req()), the
> filters for the subrequest will have been added and the chain will be
>   W X Y Z D E F
> Isn't that the plan?
> Without this change, content for the subrequest runs through
> > This patch needs to be backed out.  What we really want, IMHO, is a change
> > to the sub_request API to inform the sub_request of where it's filter
> > stack should begin.  Maybe, we need a new pointer in the request_rec,
> > something like:  r->sub_filter_start, which is set just before creating a
> > sub_request?
> Who would set r->sub_filter_start?  If the filter does that, I don't
> see how that is cleaner than the filter setting
> subrequest->output_filters.
> If we can modify the existing ap_sub_req_lookup_*() interfaces, we
> could pass in our filter pointer to ap_sub_req_lookup_*() (or NULL
> if we're a handler or our filter isn't actually going to run the
> subrequest) and subrequest->output_filters could then be set to
> f->next instead of request->output_filters.  That would be a change to
> existing handlers (albeit a small one).
> It seems that the right stuff is happening with my commit (for the
> hopefully-normal case where subrequest filters and subsequent request
> filters don't clash).  If this is true, then I don't see the need to
> back out forward progress (but of course improving it further is
> fine).
> -- 
> Jeff Trawick | | PGP public key at web site:
>           Born in Roswell... married an alien...

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

View raw message