httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Baffled by the negotation fix...
Date Sat, 02 Mar 2002 19:38:45 GMT

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



Mime
View raw message