BTW, after reading this note again, this also solves another problem we have. The filter type right now is AP_HTTP_HEADER_FTYPE, and there is a comment that the name sucks. The correct name is AP_PROTOCOL_FTYPE, which denotes exactly what we are trying to do with this filter type.
Ryan > > Justin Erenkrantz wrote: > > > > > > A protocol filter shouldn't survive successive > > > iterations of a "request" > > > > Even if in the same "connection"? That doesn't seem quite right to me... > > I'm confused as well :/ > > We originally wrote the protocol filters to be connection based, but that > had some drawbacks that people were unwilling to live with, and it made > writing input filters very complex. Today, the filters that implement the > protocol are request based. The problem is the definition of the request. > My opinion is that a request is the time from when a user sends the GET > line to the time that the response is sent back. Justin (please correct > me if I am wrong) believes that the request is the lifetime of the > request_rec in the code. The problem is that the request_rec can be > modified by causing an internal redirect or a sub_request. > > My argument is simple: > > There are three lifetimes for filters that are attached to a communication > stream: > > 1) Resource lifetime > 2) Protocol lifetime > 3) Connection lifetime > > If you look at this, the lifetimes make sense for all protocols, and they > flow from shortest to longest-lived. The problem is that our protocol > abstraction isn't complete, and never has been. Most protocols actually > have a layer between the request and the connection, usually tied to a > user's login/logout. That is the protocol layer. Every protocol module > that I have ever seen actually implements that structure, and jerry-rigs > getting it into the server. That would be the structure that should keep > the protocol-lifetime filters. However, Apache doesn't have that > structure by default, because HTTP doesn't require it. In HTTP, the > protocol-lifetime is equivalent to the lifetime of a single request. > > The problem we have is that we have tied our protocol filters to the > lifetime of a resource, or a single request_rec in the server. I am > stating that I believe that the correct way to fix this is to split the > protocol and resource filters into two pointers. The resource-lifetime > filters are ignored on sub_request and internal redirects. The protocol > filters are by definition carried over from one request to the next, until > the request (from the user's perspective) is finished. > > In fact, the more I think about this, the more convinced I am that I am > correct. Think about it this way. The HTTP_HEADER filter defines how we > read a request from the network. That essentially defines the HTTP > version that we are using for this request. That HTTP version is the same > regardless of how many times we redirect internally or create > sub_requests. That is why the HTTP_HEADER filter should be tied to a > special pointer in the request_rec, and not just thrown in with things > like the mod_include filter, which is tied to a particular resource. > > Ryan
