Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: trawick@bellsouth.net
To: new-httpd@apache.org
Subject: [PATCH] handle subrequest buckets with the wrong pool
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 06 Jun 2001 13:56:46 -0400
Message-ID: <m3ae3l331d.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 58
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

I think this is overzealous (don't always need to do it; instead
should think about whether or not it is going to be held onto by
CORE_OUT) and I don't know that there is a consensus on which solution
to use.

Index: server/request.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/request.c,v
retrieving revision 1.4
diff -u -r1.4 request.c
--- server/request.c	2001/06/06 12:51:21	1.4
+++ server/request.c	2001/06/06 17:58:06
@@ -808,7 +808,40 @@
     apr_bucket *e = APR_BRIGADE_LAST(bb);
 
     if (APR_BUCKET_IS_EOS(e)) {
+        apr_bucket_brigade *tmpbb;
+
         apr_bucket_delete(e);
+
+        if (!APR_BRIGADE_EMPTY(bb)) { /* avoid brigade create/destroy */
+
+            /* We need to be certain that any data in a bucket is valid
+             * after the subrequest pool is cleared.
+             */ 
+            tmpbb = apr_brigade_create(f->c->pool);
+            
+            APR_BRIGADE_FOREACH(e, bb) {
+                const char *str;
+                apr_size_t n;
+                apr_status_t rv;
+                
+                rv = apr_bucket_read(e, &str, &n, APR_BLOCK_READ);
+                /* XXX handle rv! */
+                
+                /* This apr_brigade_write does not use a flush function
+                   because we assume that we will not write enough data
+                   into it to cause a flush. However, if we *do* write
+                   "too much", then we could end up with transient
+                   buckets which would suck. This works for now, but is
+                   a bit shaky if changes are made to some of the
+                   buffering sizes. Let's do an assert to prevent
+                   potential future problems... */
+                AP_DEBUG_ASSERT(AP_MIN_BYTES_TO_WRITE <=
+                                APR_BUCKET_BUFF_SIZE);
+                apr_brigade_write(tmpbb, NULL, NULL, str, n);
+            }
+            apr_brigade_destroy(bb);
+            bb = tmpbb;
+        }
     }
     return ap_pass_brigade(f->next, bb);
 }

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...