Re: HTTP Input header filter

[Bill Stoddard]

Justin Erenkrantz wrote:

--On Wednesday, February 5, 2003 4:32 PM -0500 Bill Stoddard <[EMAIL PROTECTED]> 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.

Humm...

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.

Bill