httpd-dev mailing list archives

> 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