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
