httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Baffled by the negotation fix...
Date Sat, 02 Mar 2002 05:26:03 GMT
On Fri, Mar 01, 2002 at 09:15:46PM -0800, Ryan Bloom wrote:
> 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.

We're essentially creating a new request here.  I'm not sure why
you think we have to preseve the old protocol filters.  They simply
aren't valid anymore.  They are for the old request - we want a *new*
instance of these filters.  The old request filters aren't valid for
this type of sub-request - the contexts shouldn't be valid.  The
only filters with a valid context are the connection-filters.

> > 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.

How do you know which filters to add?  There are number of places
in the HTTP modules where they manually add CONTENT_LENGTH and
HTTP_HEADER.  My point is just to remove all of the duplicate code
and allow modules to reset the filters.  I can't believe that this
will cause the server to be that much slower.  By making it a hook,
you abstract out the protocol - only the protocol engine knows
which filters are required.  -- justin

View raw message