Hmm. I'm wondering if we're mis-understanding something here.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
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
