httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject core_input_filter design (was: Re: cvs commit: ...)
Date Tue, 10 Oct 2000 06:04:44 GMT
On Mon, Oct 09, 2000 at 10:04:11PM -0700, wrote:
> > core_input_filter() was broken for the reasons stated...  Let's move
> > forward.
> > 
> > I'm trying to understand why is it so important that the code to
> > ensure that we have a LF lives in core_input_filter().  It seems that
> > we already have enough code that knows what a header line looks like
> > (http_filter(), and getline() to a lesser extent).  
> > 
> > Why not have http_filter() ask for another brigade if it doesn't get
> > enough data back?  Otherwise, core_input_filter() is going to have to
> > know whether it is in header mode or body mode.
> For the same reason that you want a buffering filter.  Think of it this
> way.  Win95/98 and BeOS send one char at a time, which then create single
> character bucket brigades in the input filter.  If http_filter does the
> buffering, then we end up with a minimum of 14 single character
> bucket_brigades.  That is unacceptable.

That is arguable. It is entirely possible that the next level up wants
"whatever is available". For example, what if we are reading the body and
trying to consume it as it arrives?

Concrete example: a client issues all of the headers for a PUT. It includes
the "Expect: 100-continue" header. The client then *pauses*. The server is
required to parse the headers, check whether everything is okay, prep for
the reception of data, then *SEND* a "100 Continue" status to the client.
Once the client receives that, it will begin sending the body of the

If the core_input_filter tries to be too smart, then it could end up
blocking or looping on the input without passing the headers up. Or it will
block the upwards flow of content in the previous example (consume as it

The logic about processing the incoming data (into headers vs body) belongs
up in the http_filter.

> This needs to work very much like
> bgets used to.

bgets was used only during header processing. core_input_filter is used for
both headers and body. You *cannot* read until an LF is found. It may never

> There were bugs in the code you removed, but fixing them
> was the correct solution, not removing them.  The first way to fix it, was
> to add a maximum number of characters.  The second, was to check for the
> socket being closed.

No. The correct answer is to deliver what was found and let the protocol
level (http_filter) decide whether it needs more, and how to buffer it.


Greg Stein,

View raw message