The problem here is that we are getting some zero-length buckets at the head

of our brigade - which are in isolation okay.  In this situation, they
must be removed by the call to APR_BRIGADE_NORMALIZE.

The way we partition the buckets means that we will never remove the
zero-length bucket from the head - causing an infinite loop.  We read only
a single bucket now - previously partition with the blocking reads would
read multiple buckets - but it forced having a defined length which we
agreed was bogus.

Therefore, if we have a zero-length bucket at the head, we would then try
to partition and split at the zero-point of the brigade.  That combination
doesn't actually remove the zero-length bucket - it is still there - causing
an infinite loop because we'll never go past the zero-length bucket.

This call was originally present in core_input_filter.  I think it might
be better to fix partition/split/etc to eliminate a zero-length bucket
and skip it.  But, I'm not 100% sure that needs to happen.

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

diff --git a/server/core.c b/server/core.c
index 50f9d05a3a69fef3784525f35f457dd5f0e7ae5c..cddac0942fd6935f683b9132b28f6a148750aaf9 100644 (file)
--- a/server/core.c
+++ b/server/core.c
@@ -2780,6 +2780,9 @@ static int core_input_filter(ap_filter_t *f, apr_bucket_brigade *b, ap_input_mod
         APR_BRIGADE_INSERT_TAIL(ctx->b, e);
     }
 
+    /* ### This is bad. */
+    APR_BRIGADE_NORMALIZE(ctx->b);
+
     /* ### AP_MODE_PEEK is a horrific name for this mode because we also
      * eat any CRLFs that we see.  That's not the obvious intention of
      * this mode.  Determine whether anyone actually uses this or not. */