httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44020] New: - Absolute paths in the target of Redirect directives in server config context are mishandled
Date Tue, 04 Dec 2007 18:44:35 GMT
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: bugs@httpd.apache.org
        ReportedBy: haastord@online.no


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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message