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...@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-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
