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 05:44:11 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

We aren't creating a new request.  The fact that we are simply copying
the features of the request_rec to another request proves that this
isn't a new request.

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

That is BS.  Those filters are completely valid.  We are talking about
moving them from the original request to the redirected request, just
like we move other stuff.  The protocol level filters are just as valid
as the connection filters, the only real problem is that we don't have a
structure that sits between the request and the connection.  If we did,
those filters would go there. 

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

Have you tried to write a module recently Justin?  I am constantly
trying to explain to people what each hook does.  Adding another hook is
a PITA for module authors, and I am against adding hooks that are
absolutely not necessary.  As for which filters to add, any filter that
has an AP_HTTP_HEADER_TYPE type would be static for the request.

The abstraction still exists, it is just that it is done with filter
type instead of a hook.  It still removes all of the duplicate code.  It
also makes the filter categories mean something other than just the
order of the filter.  The lifetime of the filter is the tied directly to
the type of the filter.

Ryan



Mime
View raw message