Re: svn commit: r490142 - /httpd/httpd/trunk/modules/mappers/mod_alias.c
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): Servername localhost Redirect /zw /blub 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 302 Found Found The document has moved here. 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
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
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
