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:19:11 GMT
On Wed, Oct 11, 2000 at 09:30:59PM -0700, wrote:
> On Wed, 11 Oct 2000 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.
> Oh, if we didn't return that much data, the http_filter really shouldn't
> know or care about that.  It is up to ap_get_client_block to inform
> http_filter how much data it wants next time.  The reason for this, is
> that ap_get_client_block doesn't just use the content-length to determine
> how much to grab, it also uses the size of the buffer passed into the
> function.

Good call. And chunking uses the marker, and the "figure out where the end
of the request" code uses that marker.

IMO, it would make more sense to pass this value to the filter function,
instead of storing it off to the side in the conn_rec.

Consider: ap_get_client_block() is going to read from an *arbitrary* filter.
Is *that* filter supposed to look at c->remaining? Or is that value only for
the http_filter?

Let's just add an apr_size_t as a param to the input filter to say "give me
no more than <this> amount of data."  (it is legal to return less)


Greg Stein,

View raw message