On Thu, Oct 12, 2000 at 06:46:23AM -0700, rbb@covalent.net wrote:
> On Thu, 12 Oct 2000 rbb@covalent.net wrote:
> > On Wed, 11 Oct 2000, Greg Stein wrote:
> >
> > > On Wed, Oct 11, 2000 at 10:08:29PM -0700, rbb@covalent.net wrote:
> >
> > > > Another thing I should clear up here. ap_get_client_block doesn't need
to
> > > > store it's data in a private bucket_brigade. It should ALWAYS return
> > > > whatever data it can to the caller, because that is the way modules expect
> > > > it to work.
> > >
> > > But what happens if the brigade contains more than the caller asked for?
> > > ap_get_client_block() must store that somewhere.
> > >
> > > Where does it store the unread input?
> >
> > Currently, it falls on the ground, which is wrong, you are correct. But,
> > this can't go at the connection level, because we are really far above the
> > connection level when we are in ap_get_client_block. This needs to be in
> > the request_rec.
>
> Whoops, I screwed this up. My fault. ap_get_client_block never gets more
> data than it asked for, thus it doesn't need to store any, ever.
You didn't screw it up... I did :-) Here I am talking about passing around
a parameter saying "no more than this", yet I ask about unread input.
hehe...
I see two changes pending, at least:
1) Add an apr_size_t to the (input) filter function prototype
2) General policy for input filters is to return *no more* than requested.
If they have any excess, then it must be stored in their ctx somehow.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
|