httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: HTTP Input header filter
Date Thu, 06 Feb 2003 14:07:46 GMT
Justin Erenkrantz wrote:
> --On Wednesday, February 5, 2003 4:32 PM -0500 Bill Stoddard 
> <> wrote:
>> 1. Installing this filter for the duration of a connection. It is
>> still a protocol filter, but it lasts for the duration of the
>> connection. In order to handle pipelined connections, an
> Hmm.  I'm wondering if we're mis-understanding something here
> My understanding based on this comment is that this filter will actually 
> read the request line as well as the headers and body.  But, that's not 
> what ap_http_filter is for - it only deals with reading the body of the 
> request.  Why are we altering that?  (Why not two filters?)
Because a header parsing filter needs to know when one request ends and 
another request begins. ap_http_filter knows how to do this. An http 
header filter would have to replicate much of this logic. There are 
other mechanisms we can use to deal with this: replicate ap_http_filter 
logic in the header parser filter, create a new API to push bytes back 
to the core_input_filter when the header parser filter reads too many 
bytes and variations.

> If you do mean that all of the HTTP logic will be moving into this 
> filter, a potential concern with this will be how to deal with protocol 
> upgrades in the middle of a connection.
> I know that there are plans to utilize the Upgrade header via a 
> waka-like protocol or a TLS upgrade.  So, we should be able to replace 
> the HTTP protocol handling on a per-request basis.  Making 
> ap_http_filter span connections may make that unnecessarily hard. 

> ap_http_filter was previously a connection filter, but it became way too 
> complicated as it tried to handle what state it was in.  The code became 
> impossible to deal with, so it was refactored.
The filter will remain a 'protocol' filter, but it will stay installed 
the duration of the connection. The new ap_http_filter will not be 
appreciably more complex than the current one (I hope :-)

> I guess I'd like to see justification why the core component of a 
> request should not be request-centric.  -- justin

Two words, pipelined requests.

I'll try to get my thoughts translated into working code which should 
help us explore some of the tradeoffs.


View raw message