httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: [PATCH] Take 2 of the http filter rewrite
Date Mon, 24 Sep 2001 19:27:21 GMT
On Mon, Sep 24, 2001 at 03:14:22PM -0400, Cliff Woolley wrote:
> On Mon, 24 Sep 2001, Justin Erenkrantz wrote:
> > The brigades should not be returning more data than is asked for
> > ever.
> Right.  But the only increment the API allows to ask for are one whole
> bucket's worth at a time.

util_filter's ap_get_brigade takes in the length to read.  The
translation from httpd->apr_util in the core filter loses this 
distinction.  The core filter should be splitting the buckets and 
only returning the requested amount to HTTP_IN (and it'd have to 
handle the 0 case when we want to read a line).  Since the
core is inherently connection-based, I see no reason why the
buffering can't be done there.  Currently, it passes the
socket bucket up the chain.

> > What happens then is that we now enter a condition where the
> > caller may not be able to handle the data (i.e. I only wanted 10
> > bytes you gave me 8192, oops).
> The filters should be able to handle this.  Like I said before, if you
> want 10 bytes, fine... just do this:
> if (apr_bucket_split(b, 10) == APR_ENOTIMPL) {
>     /* bucket cannot be split natively */
>     apr_bucket_read(b,str,&len,APR_BLOCK_READ); /* check for errors */
>     apr_bucket_split(b, 10);                    /* check for errors */
> }
> apr_bucket_read(b,str,&len,block);              /* check for errors */
> I guarantee you len will come back as 10 every time, because b is now 10
> bytes and b->next is all the rest.

The problem is that HTTP_IN has the socket bucket to begin with (which 
has -1 length - i.e. indeterminate).  In order to properly handle a 
request-centric HTTP filter, that filter must not get the -1 bucket.
It must be hidden by the core filter.  

(This is the way I see it...)  -- justin

View raw message