httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: cvs commit: httpd-2.0/server util_filter.c
Date Sun, 03 Mar 2002 17:54:32 GMT
On Sun, Mar 03, 2002 at 08:47:17AM -0800, Ryan Bloom wrote:
> My list insertion code was wrong, which was causing this bug.  Also,
> this patch is required even without the rest of the
> mod_dir/mod_negotiation patch.  We have a bug, it allows a connection
> filter to be added and never called.  Try this:
> 	Crete a request
> 	Add connection filters
> 	Add request filters
> 	Add connection filters
> The second set won't be added.  I am fixing this now, it was a simple
> mistake of where the if was done.

Thanks for figuring out what is wrong.

> Because your suggestion makes it even harder impossible to write
> modules.  Module authors have already told us which filters should
> continue through redirects and sub-requests.  They did that through
> using a different filter type.  Why should they then have to repeat that
> information in a function?
> Hooks are not the solution to every problem.  We already have people
> complaining that there are so many hooks that they don't really know
> what is possible with the server, nor do they know what they have to do
> to make their modules work.  Why would we add more hooks at this point
> when there are other cleaner solutions?

I think you may have missed my message yesterday.  It's not adding a
hook - it's allowing a hook to be able to abort processing of a
request.  That's all.  internal_redirect will take care of
everything.  fast_redirect is bogus because it skips hooks in the
new request.  I believe that is broken behavior.  If we were to
rely on internal_redirect, everything falls into place - without
having to add all of this protocol_filters code that unnecessarily
complicate matters.

And, the hook that I was asking about is already there -
insert_filters.  (I just didn't realize it was there.)  I believe
there is no justification for adding protocol-level filters - as
they merely hide the problem rather than fixing it.  If you
wish to add it, they should be added with a proto_rec as
OtherBill suggested.  And, if you add that, I ask for you to
open 2.1.  -- justin

View raw message