Temporary hack to ensure that the split results are within a brigade

attached to the proper pool. Otherwise, ctx->b would end up associated with
the request pool, and the SOCKET bucket from the CORE_IN filter would get
cleared at request end (thus the next request would go to CORE_IN for more
data and get APR_EOF, and figured there were no more requests).

This section of code was only triggered when a request had a body. The
symptom was closing the connection (even though it should have been a
keepalive) after the response was sent.

For more info, see Message-ID on dev@: <20010917061613.B466@lyra.org>

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

diff --git a/modules/http/http_protocol.c b/modules/http/http_protocol.c
index 456f486f38f3ce63e9e95229cc6f4ce2d5327cfa..e34b65891b5952f2401afa32d48ed4553217f345 100644 (file)
--- a/modules/http/http_protocol.c
+++ b/modules/http/http_protocol.c
@@ -687,7 +687,15 @@ apr_status_t ap_http_filter(ap_filter_t *f, apr_bucket_brigade *b, ap_input_mode
         apr_brigade_partition(ctx->b, *readbytes, &e);
         APR_BRIGADE_CONCAT(b, ctx->b);
         if (e != APR_BRIGADE_SENTINEL(ctx->b)) {
-            ctx->b = apr_brigade_split(b, e);
+            apr_bucket_brigade *temp;
+
+            temp = apr_brigade_split(b, e);
+
+            /* ### darn. gotta ensure the split brigade is in the proper pool.
+               ### this is a band-aid solution; we shouldn't even be doing
+               ### all of this brigade munging (per the comment above).
+               ### until then, this will get the right lifetimes. */
+            APR_BRIGADE_CONCAT(ctx->b, temp);
         }
         else {
             if (!APR_BRIGADE_EMPTY(ctx->b)) {