httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: Baffled by the negotation fix...
Date Sat, 02 Mar 2002 05:15:46 GMT
> On Fri, Mar 01, 2002 at 04:50:16PM -0800, Ryan Bloom wrote:
> > I don't understand how this is working.  The original code from Will
> > came from a discussion that he and I had over the phone.  My
question is
> > how were the protocol specific filters removed in this case?
> >
> > Oh, damn, the problem is that these filters are request specific
> > of connection specific.  What we really need, is a filter type that
> > request specific, but that isn't specifically tied to the request.
> > Basically another field in the request_rec, which would store all
> > all HTTP_HEADER filters.  That way, they wouldn't be lost for
> > sub-requests and internal redirects.
> Yes, but the concept of the protocol is intertwined with the concept
> of a request.  A request should be one "transaction" of a protocol
> interaction.  A protocol filter shouldn't survive successive
> iterations of a "request" - we saw that didn't work for HTTP.

You are thinking of this wrong.  Filters that are stored on 
r->protocol_filters wouldn't survive a single request, they would be
required for the lifetime of the request.  The idea is that anything
that lives in r->output_filters would be allowed to be removed by the
server code at will.  Anything on r->protocol_filters would be static
for the lifetime
of a request, and c->output_filters survives a request.

> What's wrong with a simple hook that lets the protocol engines add
> filters to a request?  -- justin

Because the more hooks we add, the more complex it is to write a module,
and the slower the server actually goes.  Also, why should this be a
hook?  There are a set of filters that absolutely must survive for the
lifetime of a request and no longer.  Those are protocol filters, and
they shouldn't be treated equivalently to content filters.


View raw message