httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Input Filtering and Pushback.
Date Tue, 08 Jan 2002 00:03:31 GMT
[ I'm still trying to catch up on several weeks of email... just a quick
  note on something here... ]

On Mon, Dec 31, 2001 at 10:02:41AM -0800, Ryan Bloom wrote:
> On Monday 31 December 2001 02:40 am, Justin Erenkrantz wrote:
> > I think the best strategy would be to introduce a new input filter
> > mode (call it PEEK and rename the current PEEK mode to EATCRLF) that 
> I would recommend not re-using the PEEK mode, because that will
> cause confusion to people who have written input filters already.

Regardless, the existing PEEK ought to be renamed EATCRLF. Or even tossed
entirely somehow.

> > 5. Run through all buckets in the brigade and read/copy into
> >    the caller's buffer.  (What happened to zero-copy?)
> We don't do zero-copy on input.  The real benefit to zero-copy
> is on output, because the data tends to be larger.

There *should* be a benefit on input, too. Think about a PUT of a gigabyte
file that you want to dump onto the disk. In the best of all worlds, this
would map into a sendfile() from the socket to a file descriptor.

> > 10. Call ap_get_brigade with PEEK.
> >    - Should this PEEK call block?  Is that an option that the
> >      caller to ap_get_brigade specifies?  I think ap_getline
> >      would indeed want it to be a blocking PEEK.
> If we are going to conitnue to extend input filtering, we should
> probably split the mode from the blocking.

Absolutely agree.

Whether you have two parameters, or a single param with bitfields... *shrug*
IMO, I like two params.


Greg Stein,

View raw message