> 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
