Commit d9c0dbc1 authored by Ruediger Pluem's avatar Ruediger Pluem
Browse files

* 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
parent af0e92b7

modules/http/http_request.c

+20 −3
Original line number Diff line number Diff line
@@ -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