httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] Take 2 of the http filter rewrite
Date Mon, 24 Sep 2001 08:32:02 GMT
On Sun, Sep 23, 2001 at 09:35:31PM -0700, Ryan Bloom wrote:
> On Sunday 23 September 2001 09:22 pm, Justin Erenkrantz wrote:
> > On Sun, Sep 23, 2001 at 08:34:00PM -0700, Ryan Bloom wrote:
>...
> I don't see this at all.  It is not possible to specify how much is read from the
> socket itself.  I just read through the bucket_socket code, and we always
> try to read APR_BUCKET_BUFF_SIZE.  This seems to mean that we are
> going to read more from the socket than we should, and the second request
> will be lost.

Ryan's quite right.

>...
> > register a cleanup with the request pool that setasides everything
> > that was read but not processed (i.e. all buckets except for the
> > socket) to now live as long as the connection pool.  The question
> > now becomes how do we retrieve this data back.  My first guess would
> > be to store it via a pool userdata option, but maybe we could shove
> > it back down into the core (which definitely breaks some abstractions).
> > So, I think I'm leaning towards the userdata - use "HTTP-IN-<tid>"
> > to specify the uniqueness should work.

Eww. No... just move the filter back to the connection and you're fine. We
can make it a request filter later on.

> No.  I fought against this VERY strenuously last time, and I will fight it again.

Me, too :-)

> This is why it needs to be a connection filter.  To keep the abstraction valid,
> the data being read from the socket is stored in the filter's context, the same
> way it is for the output filters.

For now, yes: a connection filter is appropriate. Later, when we can
guarantee that the request-level filter will never read past the end of the
request (i.e. it never requests more from the lower-level input filter),
then we can move it to a request filter (which, as I mentioned before has
interesting properties).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message