httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 13:51:26 GMT
On 12 Oct 2000, Jeff Trawick wrote:

> writes:
> > > 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.
> I wasn't talking about c->remaining...  I was talking about any extra
> data delivered by http_filter().

But that's just it.  The lower filters aren't by definition allowed to
return any more data than they are asked for.  Greg is right about not
using c->remaining for this, it should be a parameter to the filter

> I realize that ap_get_client_block() *tries* to get http_filter() not
> to deliver any more data than can be stored in the handler's buffer,
> using the following line:

It's more than trying, it is a requirement that the lower filters pay
attention to this.

>     len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
> But a filter can sit between ap_get_client_block() and http_filter(),
> such that the number of bytes delivered to ap_get_client_block() isn't
> so close to the number of bytes shipped on the wire.  Consider a
> gunzip-type transformation.

This is why the value should be a parameter, not a field in the
conn_rec.  Also, -1 should be a special value that says give me everything
you have, I'll deal with it myself.

They design set out above should solve all of the problems outlined in
these e-mails.  I'll implement as soon as I get into the office.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message