Return-Path: 
 <dev-return-21270-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 57847 invoked by uid 500); 24 Sep 2001 08:28:34 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
list-post: <mailto:dev@httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 57836 invoked from network); 24 Sep 2001 08:28:33 -0000
X-Authentication-Warning: kurgan.lyra.org: gstein set sender to
 gstein@lyra.org using -f
Date: Mon, 24 Sep 2001 01:32:02 -0700
From: Greg Stein <gstein@lyra.org>
To: dev@httpd.apache.org, rbb@covalent.net,
        Justin Erenkrantz <jerenkrantz@ebuilt.com>
Subject: Re: [PATCH] Take 2 of the http filter rewrite
Message-ID: <20010924013201.C4050@lyra.org>
References: <20010923185819.M6756@ebuilt.com>
 <20010924033401.6918F46DFC@koj.rkbloom.net> <20010923212215.N6756@ebuilt.com>
 <20010924043531.E761E46DFD@koj.rkbloom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20010924043531.E761E46DFD@koj.rkbloom.net>;
 from rbb@covalent.net on Sun, Sep 23, 2001 at 09:35:31PM -0700
X-URL: http://www.lyra.org/greg/
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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/