Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 10 Oct 2000 06:42:51 -0700 (PDT)
From: rbb@covalent.net
To: new-httpd@apache.org
Subject: Re: input filter commentary
In-Reply-To: <20001009235525.G9396@lyra.org>
Message-ID: <Pine.LNX.4.21.0010100635340.18833-100000@koj>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 9 Oct 2000, Greg Stein wrote:

> With this back and forth about the input filtering, I decided to take a
> little closer look into it. Ooh, my eyes still hurt.
> 
> *) each call into core_input_filter() allocates an 8k block on the
>    connection pool. Needless to say, this doesn't scale for shit.
>    [ more on this below ]

This is easy to explain.  I wrote the code in ten minutes, and just wanted
it to work.  Just fix it, a static buffer from the pool that is saved in
the ctx will work just fine for this.

> *) chunked input is broken. the http_filter uses conn->remaining as a "flag"
>    to determine whether it is reading headers or the body. This is *very*
>    poor from a readability/maintainability standpoint. A flag in the CTX
>    would be much better.
>    
>    Further, conn->remaining never becomes non-zero when chunked input
>    arrives at the server. Therefore, http_filter continues to do CR/LF
>    translation on the body(!). Not to mention screwing up where it thinks it
>    is in the input handling. Some kind of input state (machine) should be
>    present.

conn->remaining works as far as it goes, and it begins to mimic what the
request_rec has now.  I did it because I was told we didn't have input
filtering until we could filter the body.  Well, we can.  The problem is,
that we basically have to re-write Apache's protocol handling to deal
cleanly with input filtering.  I have it on my list to get chunking
working again, but since I just did the hack last week, I haven't gotten
to it yet.

> *) http_filter cannot guarantee that it is returning a full line for
>    getline(). Thus, getline() must have a loop to fetch data. It scans
>    through the data looking for the LF (and could then do the CR/LF munging
>    for getline callers), so it is unclear why http_filter is doing the
>    munging.
Bug.

> Ideally, we should have a SOCKET bucket (unless a FILE/PIPE bucket could do
> the trick). These buckets are designed to spin off HEAP buckets as they are
> read, which matches up with the suggestion above. Also, a SOCKET bucket
> would completely toss the core_input_filter -- we could just initialize
> conn->input_data with a brigade with the socket bucket in it.
> 
> This splits the input handling into the appropriate levels:
> 
> *) core_input_filter simply talks to the network to fetch data
> 
> *) http_filter steps through a state machine to read HTTP requests
> 
> *) getline/get_client_block read/parses data from the request and returns it
>    in the appropriate form to the caller.

This is a good idea.  I wouldn't use a FILE/PIPE bucket, because then we
get back to having problems on platforms where a file/pipe is not the same
as a socket.  I will implement the socket bucket today, and we can give
this a try.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------