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 08:34:53 GMT
On Sun, Jun 30, 2002 at 01:02:38AM -0700, Brian Pane wrote:
> It will happen long before then: ap_read_request() causes a read
> on the input filter chain at the start of the request processing.

We can't insert this filter until after we've read the request
line.  (see below)

> > 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.
> 
> Unfortunately, the header won't necessarily end with CRLFCRLF.
> HTTP/0.9...

Yeah, it will.  We don't call ap_get_mime_headers() when we're
assbackwards.  =)

That said, I think you are meaning to read the request line and
the headers at the same time.  I think we'll always have to read
the request line on its own.  We can potentially optimize reading
the request headers in a manner as you've described though.  But,
I'd prefer that we kept the current model and read the request
line on its own.

> stack in ap_read_request() (and remove once we've parsed the
> request header): let this filter do the scanning for the various
> forms of HTTP header, remove the header from the brigade, and
> leave the rest of the brigade for subsequent input filters to
> handle.

It'd have to be a connection-level filter to ensure that we don't
lose pipelined-requests since we read too much.  But, since we are
a connection-level filter, that means you don't have access to
the request.  So, you'd have to split it out into two filters:

- One connection-level filter that will split on a CRLFCRLF and
stash the rest away for the next read on this connection.
- One request-level filter that will expect a CRLFCRLF-segmented
brigade and process the headers and then get out of the way.

Still sounds like an AP_MODE_GETLINES to me.  =)  This *might*
be a better approach than jerry-rigging this new filter mode
into ssl and core input filter.  Perhaps we should have done
the same with AP_MODE_GETLINE (at the cost of an extra brigade
per request though)?  -- justin

Mime
View raw message