On Sat, 2010-05-08 at 00:15 +0200, Karsten Bräckelmann wrote:
> Thanks Igor and Eric for your help. :) However, I'm not convinced
> that's the cause here. Below is a bare minimum example that shows the
> weird behavior I started with...
Sorry for replying to myself. Below is some more fodder generated by the
rewrite logs.
> "Pattern is [...]. On the first RewriteRule it is applied to the
> URL-path of the request; subsequent patterns are applied to the output
> of the last matched RewriteRule."
> So, here is a *minimal* stripped down example that demonstrates the
> weird behavior I'm asking about.
>
> RewriteRule ^/foo http://example.net/
> RewriteRule ^http:// - [R=301,L]
>
> RewriteRule ^/bar http://example.org/
> RewriteRule ^(http://.*)$ $1 [R=301,L]
>
> Now, "GET /foo HTTP/1.1" redirects to the rewritten URI as expected, but
> it ignores my explicit 301 return code and instead defaults to 302.
>
> HTTP/1.1 302 Found
> Location: http://example.net/
The first logs do show, in contrast to the logs below for the second
case, that using the dash prevents rewriting (as expected), but *also*
prevents the explicit redirect code being applied. :(
(3) applying pattern '^/foo' to uri '/foo'
(2) rewrite '/foo' -> 'http://example.net/'
(2) implicitly forcing redirect (rc=302) with http://example.net/
(3) applying pattern '^http://' to uri 'http://example.net/'
(1) escaping http://example.net/ for redirect
(1) redirect to http://example.net/ [REDIRECT/302]
> The second one, "GET /bar HTTP/1.1", does work exactly as I expected, as
> clearly shown in the result. Also, with the sub-sequent RewriteRules, it
> does match the full URI as substituted before (checked this with another
> debugging rule, appending a path).
>
> HTTP/1.1 301 Moved Permanently
> Location: http://example.org/
The logs for the second case with the no-op substitution-with-self do
show two lines more. Marked. The first is the no-op, the second line
appears to show honoring the desired R=301, unlike in the first case,
which never states "EXplicitly" but only "IMplictly" forcing redirect.
(3) applying pattern '^/bar' to uri '/bar'
(2) rewrite '/bar' -> 'http://example.org/'
(2) implicitly forcing redirect (rc=302) with http://example.org/
(3) applying pattern '^(http://.*)$' to uri 'http://example.org/'
(2) rewrite 'http://example.org/' -> 'http://example.org/' #
(2) explicitly forcing redirect with http://example.org/ #
(1) escaping http://example.org/ for redirect
(1) redirect to http://example.org/ [REDIRECT/301]
> Again, do these results show a bug? Is the dash intended and expected to
> always default to 302, no matter the explicit code given? Or do I still
> not see what is wrong with the rules?
So the question is, whether ignoring the R=301 flag is an *intended*
side-effect of using the dash, or if this actually is a bug. After all,
the dash is documented to perform no substitution, in cases where only
flags need to be applied. Yes, I want that! ;)
"A dash indicates that no substitution should be performed (the
existing path is passed through untouched). This is used when a flag
(see below) needs to be applied without changing the path."
Applying an R=301 flag in my case seems to be the intended use-case for
the dash...
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|