* "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > This is my final plea to kill fast_internal_redirect. > > Jeff Trawick recently noted that the change to mod_dir means > that a request for / (translated to /index.foo) means that > /index.foo can't be manipulated by mod_rewrite. If they choose > to manipulate the request, they must do so at the '/' phase. > > This was *always* true for / where it translated to /index.html.en. > Since 1.3, mod_negotiation+mod_rewrite would perform a fast > internal redirect (from / to /index.html) to index.html.en w/o > a chance for rewrite or any other module to interceed.
Not exactly that way, see below. > I believe, having fixed much of fast_internal_redirect, that we > made a bad call ever adopting this for mod_negotiation. The problem is *only* mod_dir in this case, because it went from handler to fixup (after mod_rewrite) + used the fast redirect in 2.0. mod_negotiation was never a problem, because it catches up much earlier (translate_name) and so is influencable by mod_rewrite like any other request. (RewriteRules in server context just should LA-U: anyway, and fixup (RewriteRules in .htaccess) comes later anyway). Actually, I feel, you're breaking configs out there if you change that behaviour of mod_negotiation (in the stable branches). > I propose to fix, unwinding this fix to 2.0, then 1.3. Although > we can't eliminate this entry point from 1.3 or 2.0, we can at > least stop using it internally within our own modules. > > Comments before I proceed on 2.1? IMHO the fix would be to just revert the mod_dir behaviour of 2.0 back to the 1.3 one - hook into the handler and do a normal internal redirect. Perhaps we should additional move the fast_internal_redirect function to mod_negotiation itself and mark it deprecated in 2.0. nd
