From: Ruediger Pluem Date: Mon, 8 Dec 2008 22:18:27 +0000 (+0000) Subject: * Correctly remove the SUBREQ_CORE filter from the filter chain if we do an X-Git-Tag: 2.3.1~161 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=206fa0e2f47a9cbcc32af30e3730cd590b99e375;p=apache * Correctly remove the SUBREQ_CORE filter from the filter chain if we do an internal fast redirect and if the new redirected request is NO subrequest. This fixes at least one of the possible subtle issues mentioned in the comment to r620133. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@724515 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/modules/http/http_request.c b/modules/http/http_request.c index f3fe63fde6..255fc8951d 100644 --- a/modules/http/http_request.c +++ b/modules/http/http_request.c @@ -522,9 +522,26 @@ AP_DECLARE(void) ap_internal_fast_redirect(request_rec *rr, request_rec *r) ap_add_output_filter_handle(ap_subreq_core_filter_handle, NULL, r, r->connection); } - else if (r->output_filters->frec == ap_subreq_core_filter_handle) { - ap_remove_output_filter(r->output_filters); - r->output_filters = r->output_filters->next; + else { + /* + * We need to check if we now have the SUBREQ_CORE filter in our filter + * chain. If this is the case we need to remove it since we are NO + * subrequest. But we need to keep in mind that the SUBREQ_CORE filter + * does not necessarily need to be the first filter in our chain. So we + * need to go through the chain. But we only need to walk up the chain + * until the proto_output_filters as the SUBREQ_CORE filter is below the + * protocol filters. + */ + ap_filter_t *next; + + next = r->output_filters; + while (next && (next->frec != ap_subreq_core_filter_handle) + && (next != r->proto_output_filters)) { + next = next->next; + } + if (next && (next->frec == ap_subreq_core_filter_handle)) { + ap_remove_output_filter(next); + } } /* If any filters pointed at the now-defunct rr, we must point them