Forum Moderators: phranque

Message Too Old, No Replies

301 redirect exposes script variables, breaks URLs

         

jcmoon

9:48 pm on Apr 3, 2006 (gmt 0)

10+ Year Member



I suppose I'm doing something wrong, as I'm getting results I just don't expect.

I changed URL patterns, so to ensure that the old URL's work (and that bots understand the transition to the new ones), I'm setting up 301 permanent redirects from the old URL's to the new ones.

No problem there, right? Well, all of these URL's are also mod-rewritten, with elements of the URL turned into parameters passed into scripts, which in turn query a database.

So here's what I expect, for the sake of example:

OLD URL: www.example.com/var1__var2-blah-blah.shtml
gets redirected to
NEW URL: www.example.com/var1--var2-blah-blah.shtml
(both cases mod-rewritten to /cgi-bin/script_a.cgi?pone=var1&ptwo=var2)

So I set up some redirects, as follows:

redirect 301 /var1__var2-blah-blah.shtml http://www.example.com/var1--var2-blah-blah.shtml

And now, when I go to the old URL above, instead of sending me to the new URL as I like, it sends me to this:

www.example.com/var1--var2-blah-blah.shtml?pone=var1&ptwo=var2

This isn't the URL I use in my site, and if nothing else might lead to duplicate-content, and thus supplemental (!), issues, so I've got to do something different ... I think.

Am I doing something wrong? Or, is this normal, and I'm overreacting?

(PM me for actual URL's instead of examples)

(as a second question ... can you do pattern-matching in 301 redirects? i.e. the (.*) which becomes $1 etc ... I'd rathern not have to create 500 rules for 301 redirects if I don't have to)

jdMorgan

1:44 am on Apr 4, 2006 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Can't tell, since there's no code to look at, but the problem is likely that your rewrites are running before your redirects, this exposing the internal script path to the client. To avoid this:

1) Do not mix mod_alias directives (e.g. Redirect, RedirectMatch) with mod_rewrite directives -- use mod_rewrite only.
2) Use the [L] flag on your RewriteRules, except in the (usually rare) cases where you know you don't want it.
3) Place the redirects before the rewrites in your .htaccess or httpd.conf file.

Jim

jcmoon

9:15 pm on Apr 5, 2006 (gmt 0)

10+ Year Member



Sage advice. I did have a few RewriteRule's appearing before my redirect 301's. Those have been moved. Helpfully, I'm not using mod_alias directives, so that won't be an issue (unless the redirect 301's count). Also, I do have [L] after all of my RewriteRule's.

So it would seem that things are as they should be. Hoever, I still see the same issue coming up. To give you some applicable code, these are adapted from two lines in my .htaccess file:

redirect 301 /some-directory-name/unique.shtml http://www.example.com/some_directory-name/unique.shtml

followed later on by

RewriteRule ^(.*)-name/(.*).shtml$ /cgi-bin/script.cgi?var1=p&var2=$1&var3=$2 [L]

Have I done something wrong? This all seems legit to me.

jdMorgan

10:00 pm on Apr 5, 2006 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



> I'm not using mod_alias directives,
See Apache mod_alias [httpd.apache.org].

> RewriteRule's appearing before my redirect 301's. Those have been moved.

From another post today:

Apache directives are not executed strictly in the order that you specify. They are executed in module order. For example, all mod_alias directives will execute, then all mod_proxy diretives will execute, and then all mod_rewrite directives will execute (Each module parses the config files and executes the directives that it recognizes).

That's just an example -- the modules will execute in the reverse order the they are loaded (by LoadModule) on Apache 1.x, and in the order determined by Apache 2.x priority scheme. This can have various unexpected results.

Another possibility is that your server defines the canonical domain differently from your desired domain redirect and UscCanonicalName is set to 'on'. In that case, directory URLs requested without trailing slashes may end up exposing internal rewrites.

Jim