httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Br├Ąckelmann <>
Subject [users@httpd] mod_rewrite Redirection ignoring the explicite code
Date Thu, 06 May 2010 21:43:28 GMT
Please Cc me on every reply.  I'm subscribed to the allow post list, but
I am not subscribed to receive list posts. Can't stand yet another
mailing list at this point. ;)

Yes, I know mod_rewrite is voodoo. ;)  Anyway, here's a (somewhat)
stripped down example of a case I really don't understand what's going
on, and why. I left in some of the juicy bits, which are necessary in
the full code for features. Any explanation or insight greatly

Oh, and if there's a better place to go I didn't find, please don't
hesitate to slap me.

So here's the deal. The full code is supposed to do some redirection of
moved legacy sub-domains (not included in the example) and directories.
Preserving the request URI in the absence of a trailing slash of the
target (which explains the env var), or just to the new domain with a
trailing slash. But that's pretty irrelevant with the stripped down
example. ;)

Use a txt rewrite map for easier reproduction.

  $ cat

Extract the leading part of the REQUEST_URI. Look it up in our legacy
map, and if and only if it is defined in the map, go on and rewrite the
URL with the corresponding URI.

  RewriteMap   legacy  txt:/path/to/

  RewriteCond  %{REQUEST_URI}    ^(/[^/]+)(.*)
  RewriteCond  ${legacy:%1}      !=""
  RewriteRule  ^                 ${legacy:%1}      [E=req:%2]

So at this time, a request for /foo is rewritten with the example URI.

Remember, the mod_rewrite magic is supposed to distinguish between
redirect URIs with or without a trailing slash, so I need more rules.

  RewriteRule  ^http://.+/$      -                 [R=301,L]  # 302, WTF!?

Using this rule, I do get the desired redirect with the correct
Location, alas a  302 Found  temporary redirect. Why? I mean, sure,
using the dash as a substitution results in no substitution being
performed. But that's OK, isn't it? The URL already is the correct, full
target URI at this point, so just force the external redirection and
stop processing.

It does stop here. It does not process subsequent rules. But it ignores
my explicit 301 return code and instead returns 302. Huh!?

  RewriteRule  ^(http://.+/)$    $1                [R=301,L]

Using this rule, *instead* of the previous one, works -- and returns a
301 Moved Permanently  as I asked for. The only difference being a
(rather pointless and less easy to the eye) substitution of the current
URL with the very same URL.

Is this a bug, some missing or unclear documentation, or am I just being
an idiot? :)

Both rules do stop processing, both rules do redirect. Only, the first
variant ignores the explicit return code...


Oh, right!  Apache HTTP 2.2.9, Debian Lenny

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:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message