httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [PATCH] Move http header parsing into the http_input_filter
Date Thu, 27 Feb 2003 00:58:30 GMT
--On Tuesday, February 25, 2003 8:09 PM -0500 Bill Stoddard 
<bill@wstoddard.com> wrote:

> Ok, I know what I was thinking. Check out tmp_bb in ap_read_request
> in protocol.c (unpatched version). We create tmp_bb, do
> read_request_line, ap_get_mime_headers then destroy tmp_bb.  My
> patch does essentially the same thing.  If there is a request body
> to read, whoeever needs to read it will create a new brigade. In
> this regard, my patch does not create any new bogosity. (and no, we
> do not throw away the first read).

No, it's not the same thing.  One is: 'read the request line and 
headers using this temporary brigade,' the other is: 'read part of 
the input body into this brigade - oh, by the way, feel free to read 
the headers and status while you are at it, and, oh, don't feel that 
I require any data.'

As I've said before, the patch uses ap_get_brigade only as a way to 
drive the input filters before we are ready to read the body.  To me, 
it indicates a strong disconnect with how the filters are designed. 
Filters are meant to be called asynchronously as needed (pulled), but 
the request parsing must happen synchronously and at a specific point 
in time.

I don't fully understand why the status and header parsing must 
belong in an input filter (hammer, meet balloon).  I think the patch 
could be rewritten removing the context of an input filter and still 
see significant performance benefits.  At the time the request is 
read, there should be no other input filters, so I don't believe 
there would be significant overhead to not being an input filter.  -- 
justin

Mime
View raw message