httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Date Fri, 22 Sep 2000 15:55:25 GMT
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...

Mime
View raw message