httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 06:16:40 GMT
On Wed, Oct 11, 2000 at 09:27:52PM -0700, wrote:
> > Don't you want to hold onto remaining buckets between invocations?
> > Here is the set of changes I was soon to commit to get POSTs working
> > again :) 
> No, there is no reason to keep c->remaining intact between
> invocations.  The whole point of c->remaining is to say "grab no more than
> this much data from the bucket brigade and return it to me."  Once we have
> returned that much data, the remaining field is invalid.

But how does this work in the presence of chunking?

Let's presume that the input-chunking-filter sits above http_filter. To read
a chunk from the body, it must do a getline(). Then, it must read N bytes of
data. Then, it will do a getline() again.

c->remaining does not signal "end of request", but just "end of read".
Another flag must be used to signal end-of-request (as I stated in my
commentary email).

Hmm... also, it sounds like we ought to have a utility function that reads a
line of text from a brigade. That can be used by the header-reading code,
and by the chunk-handling code.

> > Index: main/http_protocol.c
> > ===================================================================
> > RCS file: /home/cvspublic/apache-2.0/src/main/http_protocol.c,v
> > retrieving revision 1.160
> > diff -u -r1.160 http_protocol.c
> > --- main/http_protocol.c        2000/10/12 02:54:38     1.160
> > +++ main/http_protocol.c        2000/10/12 04:18:32
> > @@ -2398,10 +2398,23 @@
> >      apr_status_t rv;
> >      apr_int32_t timeout;
> >  
> > +    if (!r->connection->input_data) {
> > +        /* XXX used only by ap_get_client_block(), lifetime is request;
> > +         * move from c to r and fix the pool
> > +         */
> > +        r->connection->input_data = ap_brigade_create(r->connection->pool);
> > +    }
> I stopped using r->connection->input_data, because it isn't this filter's
> to use.  In fact, this can actually go away now.  The whole point of this
> brigade, was to give the core filter a place to store information.  It is
> incorrect for any filter to have access to a brigade in the conn_rec.

Right. It would store the brigade in its ctx, right?

Hmm. I guess it could also "pass everything it has" on up the chain. No
reason for it to keep pieces... oh wait. When it hits the end of a request,
it must hold the remaining data for the next request.

IOW, yes: http_filter does need the ctx, and it would store a brigade of
unused input there. (unused because it belongs to the next request, or to
the next chunk)


Greg Stein,

View raw message