> -----Original Message----- > From: Joe Orton > Sent: Dienstag, 8. Juni 2010 14:38 > To: dev@httpd.apache.org > Subject: [PATCH] PR 17629 and all that > > https://issues.apache.org/bugzilla/show_bug.cgi?id=17629 > > Here's an attempt at fixing the dreaded PR 17629. This is a > bug in the > handling of the output filter chain at the point where an internal > redirect is applied to a subrequest. Complications: > > a) a subrequest's filter chain may start at an arbitrary point in > r->main's filter chain > > -- for an SSI include, the output from the include must > continue from > the next filter along from the INCLUDES filter > > b) that point where the filter chains join cannot be lost by the > subrequest doing an internal redirect > > -- obvious breakage as per the PR is losing the DEFLATE filter for > the output of the redirect from the subreq > > c) the subrequest's filter chain cannot be preserved as-is, > since it may > contain filters which should not be applied to the destination URI > > The approach I've used is to distinguish inherited filters from > subreq-specific filters by seeing what f->r points to, and nuking all > but the inherited filters. Here's the patch - test case in the test > suite: > > Index: modules/http/http_request.c > =================================================================== > --- modules/http/http_request.c (revision 952555) > +++ modules/http/http_request.c (working copy) > @@ -460,17 +460,47 @@ > new->proto_output_filters = r->proto_output_filters; > new->proto_input_filters = r->proto_input_filters; > > - new->output_filters = new->proto_output_filters; > new->input_filters = new->proto_input_filters; > > if (new->main) { > - /* Add back the subrequest filter, which we lost when > - * we set output_filters to include only the protocol > - * output filters from the original request. > - */ > - ap_add_output_filter_handle(ap_subreq_core_filter_handle, > - NULL, new, new->connection); > + ap_filter_t *f, *nextf; > + > + /* If this is a subrequest, the filter chain may contain a > + * mixture of filters specific to the old request (r), and > + * some inherited from r->main. Here, inherit that filter > + * chain, and remove all those which are specific to the old > + * request; ensuring the subreq filter is left in place. */ > + new->output_filters = r->output_filters; > + > + f = new->output_filters; > + do { > + nextf = f->next; > + > + if (f->r == r && f->frec != > ap_subreq_core_filter_handle) {
Is it possible to have any non subrequest specific filters below the ap_subreq_core_filter_handle? It is no that the current patch does not handle this but wouldn't it be possible to just throw away any filter between r->output_filters and ap_subreq_core_filter_handle without any further test? Otherwise patch looks good. Regards Rüdiger