From: Justin Erenkrantz <jerenkrantz@apache.org>
Date: Sun, 28 Apr 2002 06:41:35 +0000 (+0000)
Subject: If a subreq added a filter (say INCLUDES) and the subreq was promoted via
X-Git-Tag: 2.0.36~53
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d8b443e424bffcd2abdb89f52d65459aface918f;p=apache

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 159ba3b0a6..fbdb7fc1e5 100644
--- 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 88e1434511..91bd422928 100644
--- 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)