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.
Ryan
On 22 Sep 2000, Jeff Trawick wrote:
> rbb@covalent.net 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
>
> A B C INCLUDES D E F
>
> 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
>
> W X Y Z A B C INCLUDES D E F
>
> > 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 | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
|