> > 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.
Was that the one about returning a 302 to the client? No way. If every time we do a multiviews or a mod_dir request we have to send a 302 to the client, we will cut our throughput horribly. You are actually talking about making most of the requests we serve require two requests. Think about it, the most common request people make to a web server is http://www.example.com/.; To make that request return a 302 EVERY time is just wrong. Plus, the protocol filters are already working. Please re-read this patch, it didn't add the protocol filters, it just changed how we insert filters. In reality, this patch is only broken because of the way we use our filter list. Ryan
