Re: mod_rewrite Redirection ignoring the explicite code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux