httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: HTTP Input header filter
Date Wed, 05 Feb 2003 22:57:01 GMT
--On Wednesday, February 5, 2003 4:32 PM -0500 Bill Stoddard 
<bill@wstoddard.com> 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?)

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.

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

Mime
View raw message