Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Fri, 10 Aug 2001 09:46:09 -0700 (PDT)
From: Doug MacEachern <dougm@covalent.net>
To: Ryan Bloom <rbb@covalent.net>
cc: new-httpd@apache.org
Subject: Re: are we ready to roll? - POST thru' mod_ssl
In-Reply-To: <0108092042510E.09485@koj.rkbloom.net>
Message-ID: <Pine.LNX.4.21.0108100911300.26753-100000@mako.covalent.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

forget my bandaid, like i said, i know it isn't right.  here's what things
look like when apr_brigade_partition is called:

without-ssl:
(gdb) dump_brigade b
dump of brigade 0x8243dac
   0: bucket=HEAP(0x834b398), length=0, data=0x834b3b8
   1: bucket=SOCKET(0x82f0838), length=-1, data=0x8243a7c

with-ssl:
(gdb) dump_brigade b
dump of brigade 0x84e28dc
   0: bucket=POOL(0x84f24e0), length=0, data=0x84f2500

so with this brigade, apr_brigade_partition returns APR_EINVAL, but we
can't just return that value because there is more data down the chain.
my bandaid was trying to keep things not just from crashing, but to
trigger an ap_get_brigade call so ap_get_client_block actually gets some
data.  the brigade above is what was already in ctx->b after reading the
headers.

now once ap_get_brigade is triggered, we get a bucket with the post data:
(gdb) dump_brigade ctx->b
dump of brigade 0x84e2b14
   0: bucket=POOL(0x8284c20), length=10, data=0x8281fa0

in which case apr_brigade_partition does this:
        if (point == e->length) {
            *after_point = APR_BUCKET_NEXT(e);
            return APR_SUCCESS;

but there is only one bucket in the brigade, so APR_BUCKET_NEXT is bogus
and things go boom.