At 11:54 AM 3/3/2002, you wrote: >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.
Justin, yes - it adds complexity. But we can't simply 'abort processing' to speed things up. Perhaps we need to do so, as well, but I'm simply responding to 'this is bogus'. Perhaps it is. However, again consider mod_dir. We have a request. It asks for a dir. We find the dir, and look at DirectoryIndex. We look for the first item, 'index.php'. Nope, no php, destroy that subrequest. We look for 'index.html'. We find that file. In checking for that file, we have run through the process_request cycle. What you are asking is that we re-invoke the entire process_request cycle. That is doable, but it will be costly. And -that- cost, the cycles to completely repeat process_request() for index.html, is why I changed my focus from throwing this code path away, to making this code path work correctly, if it is at all possible or realistic. Rbb's derivative of your fix of my patch identified and solved the filters problem. It helped Ryan notice that we were -really- messed up on r->connection->output_filters never growing any connection filters added to r->output_filters. That was bogus, I'm glad to see it now fixed. There should be no problem 'appropriating' the connection+protocol filters from the subreq->main request and using them to serve the subreq as the top level request. If you see such an issue, please, raise it. Bill
