If a subreq added a filter (say INCLUDES) and the subreq was promoted via

fast_redirect, the filter would still point at the subreq - rather than
the original r.  So, we must update any filters pointing at rr to be r.

This would cause lots of problems with mod_include with mod_dir requests
such as seen in PR 7966.  mod_include would be unsetting the headers_out
of rr instead of r.  But, we disassociate rr->headers_out and r->headers_out.
Therefore, the C-L header in r->headers_out would remain - even though it
bears no relation to what we will be outputting - causing problems.

This also now permits chunked-encoding of mod_dir/mod_include requests
which could never happen before and fixes the content-length problem
seen in PR 7966.

As hinted at in PR 7966, there is a race condition - if for some reason
the server stalls reading an included file (or even better, placing a
sleep in the cgi-bin script!), the invalid C-L may get propogated to the
client.

(Note that internal_internal_redirect has this same code fragment.)

PR: 7966

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94832 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/CHANGES b/CHANGES
index 159ba3b0a6baada13f9d7380717c29fc104be05b..fbdb7fc1e54fb5462389681a7425422a245158b0 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -1,5 +1,9 @@
 Changes with Apache 2.0.37
 
+  *) Fix subreqs that are promoted via fast_redirect from having invalid
+     frec->r structures.  This would cause subtle errors later on in
+     request processing such as seen in PR 7966.  [Justin Erenkrantz]
+
   *) More efficient pool recycling logic for the worker MPM [Brian Pane]
 
   *) Modify the worker MPM to not accept() new connections until

diff --git a/modules/http/http_request.c b/modules/http/http_request.c
index 88e1434511143860536a1cbaf909c1ea05b46037..91bd4229289756be7a92a6978908c45c8f0b6f28 100644 (file)
--- a/modules/http/http_request.c
+++ b/modules/http/http_request.c
@@ -408,6 +408,8 @@ static request_rec *internal_internal_redirect(const char *new_uri,
 /* XXX: Is this function is so bogus and fragile that we deep-6 it? */
 AP_DECLARE(void) ap_internal_fast_redirect(request_rec *rr, request_rec *r)
 {
+    ap_filter_t *filters;
+
     /* We need to tell POOL_DEBUG that we're guaranteeing that rr->pool
      * will exist as long as r->pool.  Otherwise we run into troubles because
      * some values in this request will be allocated in r->pool, and others in
@@ -446,6 +448,27 @@ AP_DECLARE(void) ap_internal_fast_redirect(request_rec *rr, request_rec *r)
         ap_remove_output_filter(r->output_filters);
         r->output_filters = r->output_filters->next;
     }
+
+    /* If any filters pointed at the now-defunct rr, we must point them
+     * at our "new" instance of r.  In particular, some of rr's structures
+     * will now be bogus (say rr->headers_out).  If a filter tried to modify
+     * their f->r structure when it is pointing to rr, the real request_rec
+     * will not get updated.  Fix that here.
+     */
+    filters = r->input_filters;
+    while (filters) {
+        if (filters->r == rr) {
+            filters->r = r;
+        } 
+        filters = filters->next;
+    }
+    filters = r->output_filters;
+    while (filters) {
+        if (filters->r == rr) {
+            filters->r = r;
+        } 
+        filters = filters->next;
+    }
 }
 
 AP_DECLARE(void) ap_internal_redirect(const char *new_uri, request_rec *r)