You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ni...@apache.org on 2006/12/25 13:06:33 UTC
svn commit: r490142 - /httpd/httpd/trunk/modules/mappers/mod_alias.c
Author: niq
Date: Mon Dec 25 04:06:33 2006
New Revision: 490142
URL: http://svn.apache.org/viewvc?view=rev&rev=490142
Log:
PR#35314: Enable path components in Redirect
Modified:
httpd/httpd/trunk/modules/mappers/mod_alias.c
Modified: httpd/httpd/trunk/modules/mappers/mod_alias.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_alias.c?view=diff&rev=490142&r1=490141&r2=490142
==============================================================================
--- httpd/httpd/trunk/modules/mappers/mod_alias.c (original)
+++ httpd/httpd/trunk/modules/mappers/mod_alias.c Mon Dec 25 04:06:33 2006
@@ -204,7 +204,10 @@
if (ap_is_HTTP_REDIRECT(status)) {
if (!url)
return "URL to redirect to is missing";
- if (!use_regex && !ap_is_url(url))
+ /* PR#35314: we can allow path components here;
+ * they get correctly resolved to full URLs.
+ */
+ if (!use_regex && !ap_is_url(url) && (url[0] != '/'))
return "Redirect to non-URL";
}
else {
Re: svn commit: r490142 - /httpd/httpd/trunk/modules/mappers/mod_alias.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/26/2006 03:49 AM, Nick Kew wrote:
> On 25 Dec 2006, at 22:59, Ruediger Pluem wrote:
>
>>
>>> - if (!use_regex && !ap_is_url(url))
>>> + /* PR#35314: we can allow path components here;
>>> + * they get correctly resolved to full URLs.
>>
>>
>> Where? A quick check shows that the resulting Location header has no
>> scheme and host in front.
>> AFAICT this violates 14.30 of RFC2616 as the value of a Location
>> header must be an absoluteURI
>> or better absolute-URI as defined in 4.3 of RFC3986.
>
>
> What kind of a quick check? I ran a case with leading slash, both from
> httpd.conf and .htaccess, expecting to see broken Location headers which
That was the same I did, but with different results (see below).
> I was then going to fix at the point where they're generated (which can't
> be at config-time because we don't always have a server name at
> that point). But it returned full, valid and correct Location headers
> to the client without me doing anything. Hence the trivial change
> and comment.
That is very strange. See the results below I got from the following
configuration (trunk, r490277):
<virtualhost 127.0.0.1:80>
Servername localhost
Redirect /zw /blub
</virtualhost>
telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET /zw HTTP/1.0
HTTP/1.1 302 Found
Date: Tue, 26 Dec 2006 10:23:33 GMT
Server: Apache/2.3.0-dev (Unix) DAV/2 mod_ssl/2.3.0-dev OpenSSL/0.9.6g
Location: /blub
Content-Length: 189
Connection: close
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="/blub">here</a>.</p>
</body></html>
Connection closed by foreign host.
So I get an invalid Location header, plus I am not sure which part of the code
should transform this in an absolute-URI
Regards
Rüdiger
Re: svn commit: r490142 - /httpd/httpd/trunk/modules/mappers/mod_alias.c
Posted by Nick Kew <ni...@webthing.com>.
On 25 Dec 2006, at 22:59, Ruediger Pluem wrote:
>
>> - if (!use_regex && !ap_is_url(url))
>> + /* PR#35314: we can allow path components here;
>> + * they get correctly resolved to full URLs.
>
> Where? A quick check shows that the resulting Location header has
> no scheme and host in front.
> AFAICT this violates 14.30 of RFC2616 as the value of a Location
> header must be an absoluteURI
> or better absolute-URI as defined in 4.3 of RFC3986.
What kind of a quick check? I ran a case with leading slash, both from
httpd.conf and .htaccess, expecting to see broken Location headers which
I was then going to fix at the point where they're generated (which
can't
be at config-time because we don't always have a server name at
that point). But it returned full, valid and correct Location headers
to the client without me doing anything. Hence the trivial change
and comment.
> Of course you can already create invalid Location headers with
> RedirectMatch. So it might make
> sense to check the validity of a Location header after applying a
> Redirect(Match) to a request
> to ensure that it results in an absolute-URI and maybe fix it if it
> does not seem to be one.
I guessed a fix for that was responsible for the correct headers I saw.
--
Nick Kew
Re: svn commit: r490142 - /httpd/httpd/trunk/modules/mappers/mod_alias.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/25/2006 01:06 PM, wrote:
> Author: niq
> Date: Mon Dec 25 04:06:33 2006
> New Revision: 490142
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=490142
> Log:
> PR#35314: Enable path components in Redirect
>
> Modified:
> httpd/httpd/trunk/modules/mappers/mod_alias.c
>
> Modified: httpd/httpd/trunk/modules/mappers/mod_alias.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_alias.c?view=diff&rev=490142&r1=490141&r2=490142
> ==============================================================================
> --- httpd/httpd/trunk/modules/mappers/mod_alias.c (original)
> +++ httpd/httpd/trunk/modules/mappers/mod_alias.c Mon Dec 25 04:06:33 2006
> @@ -204,7 +204,10 @@
> if (ap_is_HTTP_REDIRECT(status)) {
> if (!url)
> return "URL to redirect to is missing";
> - if (!use_regex && !ap_is_url(url))
> + /* PR#35314: we can allow path components here;
> + * they get correctly resolved to full URLs.
Where? A quick check shows that the resulting Location header has no scheme and host in front.
AFAICT this violates 14.30 of RFC2616 as the value of a Location header must be an absoluteURI
or better absolute-URI as defined in 4.3 of RFC3986.
Of course you can already create invalid Location headers with RedirectMatch. So it might make
sense to check the validity of a Location header after applying a Redirect(Match) to a request
to ensure that it results in an absolute-URI and maybe fix it if it does not seem to be one.
Regards
Rüdiger