DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40373>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40373 ------- Additional Comments From [EMAIL PROTECTED] 2006-08-31 19:02 ------- I think the actually rewriting process is correct, but the internal redirect goes some way wrong: I've done some debugging using ap_log_rerror to see when which hook gets active and what are the values of r->uri and r->filename. I think I found the dilemma: mod_rewrite sets r->handler to 'redirect-handler' in the fixup_hook. Now mod_rewrite has an other hook called 'handler_redirect' (APR_HOOK_MIDDLE) which finally calls ap_internal_redirect(). But interestingly this hook is registered as APR_HOOK_MIDDLE, but fuxup hooks registered as APR_HOOK_LAST (such as mod_rewrite's mime hook or mod_dir's fixup_dir) are being processed before the handler_redirect hook runs. I attached a portion of my error log showing the order of processing. The processing of mod_rewrite's hook_mimetype is useless here, because the request won't be served, the mime-type is lost with the internal redirect (bug 36590, fix: using ap_internal_redirect_handler() if the H flag is used and we need an internal redirect [I don't know if this will preserve the mime-type/T flag, too].) So from how it currently works - I can't see a reason why mod_rewrite's fixup hook doesn't call ap_internal_redirect() directly, because any past processing after hook_fixup seems to be useless to me. And I don't know how a fix of bug 36590 could break many existing cases, because the defined handler will never run/mime-type never set to something which is served. An other case came just into my mind: mod_rewrite sets r->handler to be redirect-handler. Now, if we're using the new H flag we're overriding this handler with sthg. other in the hook_mimetype and an the internal redirect won't take place any more, resulting in a 404, because 'redirect:/url/path' cannot be found. The hook "handler_redirect" seems to run after the fixup hook_mimetype. I don't know if this is just an issue with my built... may be someone can try to reproduce this. Actually, the rewrite log entry "[INTERNAL REDIRECT]" is wrong, because at this state only r->handler is set. Yes, if mod_rewrite sets r->handler to be 'redirect-handler' the module leaves r->uri with the value created by ap_process_request_internal and below from core while r->filename has 'redirect:(url-path)'. Copying the url-path from r->filename back to r->uri ("updating r->uri") won't be a solution because this is also a dirty fix which would cause the same problem in an other case. (rewriting /abc to /foo/bar, r->uri would be updated now to /foo/bar, mod_dir acts and would 301' to /foo/bar/ before the internal redirect takes place. So there is no chance due to the missing internal redirect processing to match e.g. now in per-server context against /foo/bar and rewrite it to /index.php?args=/foo/bar). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
