httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: How to achieve zero-copy when reading request headers?
Date Sun, 30 Jun 2002 06:57:51 GMT
On Sat, Jun 29, 2002 at 07:34:57PM -0700, Brian Pane wrote:
> I'd like to streamline this processing so that ap_read_request()
> can do something like this:
> 
>   - get the input brigade from the input filter stack
>   - loop through the brigade and parse the HTTP header
>     - Note: in the common case, the whole header will
>       be in the first bucket
>   - split the bucket where the request header ends,
>     remove the bucket(s) containing the header from
>     the brigade, and hand the remainder of the brigade
>     back to the filter stack
>   - Then use the bytes in the header bucket(s) as a
>     read-write copy of the request.  (In the case where
>     the whole request header is in one bucket, we could
>     achieve zero-copy input for all the header fields
>     by null-terminating them in place and storing those
>     strings in r->headers_in, as long as we ensure that
>     the data lasts for the lifetime of the request.)
> 
> 
> What's the best way to do this?  Turn the reading of the
> request header into an input filter?  Or something more like
> the current implementation, but with an AP_MODE_SPECULATIVE
> read from the input filter stack to let ap_read_request()
> peek at the entire request?  Or something else entirely?

Point #3 (splitting and handing the remainder back) is the
biggest problem.  We're not going to be handing data back
down the filter chain (this is one of the few things that
I believe that gstein, rbb, and I actually agree on in the
filters).

Reading the headers as an input filter could be too late for 
request processing as that could be done as late as the handlers.
We have to have this information *before* any request processing
occurs.

Perhaps doing a way to split a brigade in the core input filter
with a CRLFCRLF instead of a simple CRLF will allow us to get
back a brigade which represents the entire MIME headers.  That
should solve most of our problems.

I'd look at apr_brigade_split_line and add a variation that does
CRLFCRLF and see how that works performance-wise.  You'll get a
brigade back that should represent all of the headers.  (This may
mean adding a special input mode to the filters, but I think I can
live with this - AP_MODE_GETMIMEHEADERS or something like that.
And this means that ssl's input filter would need to be adapted
to handle this as well - urgh.)

My $.02.  -- justin

Mime
View raw message