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=44020>. 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=44020 Summary: Absolute paths in the target of Redirect directives in server config context are mishandled Product: Apache httpd-2 Version: 2.2.6 Platform: PC OS/Version: Linux Status: NEW Keywords: PatchAvailable Severity: minor Priority: P2 Component: mod_alias AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] It seems that when a Redirect directive with an absolute path as target, like in the configuration below, is specified in server config context, no scheme or hostname will get prefixed to the absolute path for matching requests, which is not according to the documentation of the Redirect directive: "The new URL should be an absolute URL beginning with a scheme and hostname, but a URL-path beginning with a slash may also be used, in which case the scheme and hostname of the current server will be added." And, this also differs from how Redirect directives with absolute path targets are handled, for example, in directory context, which is in line with the documentation, it seems. To demonstrate the problem, consider the following configuration: Redirect /test/source1 /test/dest <Directory /var/www/test> Redirect /test/source2 /test/dest </Directory> With the above configuration, the command curl --include http://localhost/test/source1/ gives the following output: HTTP/1.1 302 Found Date: Mon, 03 Dec 2007 22:04:32 GMT Server: Apache/2.2.6 (Debian) PHP/5.2.4-2 with Suhosin-Patch Location: /test/dest/ Content-Length: 300 Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="/test/dest/">here</a>.</p> <hr> <address>Apache/2.2.6 (Debian) PHP/5.2.4-2 with Suhosin-Patch Server at localhost Port 80</address> </body></html> While the command curl --include http://localhost/test/source2/ gives this output: HTTP/1.1 302 Found Date: Mon, 03 Dec 2007 22:04:44 GMT Server: Apache/2.2.6 (Debian) PHP/5.2.4-2 with Suhosin-Patch Location: http://localhost/test/dest/ Content-Length: 316 Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://localhost/test/dest/";>here</a>.</p> <hr> <address>Apache/2.2.6 (Debian) PHP/5.2.4-2 with Suhosin-Patch Server at localhost Port 80</address> </body></html> Note how the Location header in the HTTP response differ in the output of the two commands. I believe the cause for this discrepancy is in the function translate_alias_redir in file mod_alias.c, which seems to process redirections (as well as aliases) specified in server config context, while the function fixup_redir seems to process redirections specified in directory context. Note how the blocks of the if statements which test for redirection (with condition ap_is_HTTP_REDIRECT(status)) differ. I think these should be almost, if not completely, the same, and I'll also attach a patch suggesting this. Since the patch simply makes the two if statements identical, a change not directly related, is also introduced, meaning that a query string following a '?' in the URL is also handled the same way in both contexts. While this also seems reasonable, I think, I have not much experience with Apache internals, so the patch is merely a suggestion, of course. Note, I use the version of Apache packaged by Debian, but the source file mod_alias.c, which I think contains the cause of the problem, has not been modified by Debian, as far as I can see. -- 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]
