Forum Moderators: phranque

Message Too Old, No Replies

.htaccess help

htaccess

         

buildersweb

11:00 am on Apr 13, 2010 (gmt 0)

10+ Year Member



Hi i have basic knowledge of .htaccess and i have a problem that might be simple to solve.

I want to redirect www.mysite1 to www.mysite2 but i wanted to do a 1:1 301 redirect ....

So i made the following to htaccess of mysite1 :
redirect 301 / [mysite2.com...]

and at site mysite1.com htaccess .. I tried to make a 1:1 redirect from all urls coming from mysite2.com

But i had a problem with some urls so i desided to go back to htaccess of mysite1.com to build the urls there and redirect them at mysite2.com.

For example i wanted something like this :
mysite1.com/events/dfdfdf-dfdf-aaaa-sssss.htm?print=1&tmpl=component 

to be redirected to:
mysite2.com/events/month/


Without "dfdfdf-dfdf-aaaa-sssss.htm?print=1&tmpl=component"

Actually i want every url inside mysite1.com/events/....*
to be redirected to mysite2.com/events/month/


How can i do that ? I need a little guide....

Thanks






jdMorgan

5:39 pm on Apr 13, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The Redirect directive uses prefix-matching. You specify the prefix you want to match -- in your example above, that was "/", meaning "redirect all paths that start with a slash." Notice how the "Redirect" directive took the part of the URL-path that you *did not* specify, and re-appended it to the new URL you provided, giving you the one-to-one correspondence you wanted.

Now take a look at the RedirectMatch directive, also in Apache mod_alias. RedirectMatch uses regular-expressions pattern-matching. It can add or remove URL-path-parts at the end (as you wish), at the beginning, or even in the middle. This is the directive you will need to use to accomplish redirects that *are not* one-to-one.

You can also use RedirectMatch for one-to-one redirects, but you must match (specify) the part of the requested URL-path that you want copied, and you must use a "back-reference" in the new URL to indicate where you want the copied path inserted. For example,
 Redirect 301 / http://example.com/ 

and
 RedirectMatch 301 ^/(.*)$ http://example.com/$1 

are completely equivalent.

The regular expressions pattern ".*" means "match any number of any characters, including blank," and the $1 says, "put whatever matched the first parenthesized pattern into the new URL here." Note that by using multiple parenthesized subpatterns and back-references, it is possible to "take stuff out of" or "add stuff in the middle of" your old URLs.

Regular expressions has many other matching capabilities as well, allowing you to *fully* define *exactly* which URL-paths you want to redirect, and (therefore) those that you don't want to redirect as well. It takes quite a bit of time to get really good and comfortable with regex, but it is a very worthwhile investment because regular expressions are used/supported in all modern scripting languages, e.g. PHP, PERL, C, , JavaScript, etc. And they are supported because they are *extremely* useful and precise.

A note for new regex users: If you find yourself always using ".*" subpatterns, you have missed out on the potential power and much-improved efficiency possible by using *specific* subpatterns. Multiple ".*" subpatterns in a regular-expressions pattern are a definite no-no, as they lead to extremely slow and inefficient processing. Use specific positive- and negative-match subpatterns instead. (An example is the "match anything but a period" subpattern shown in my rule immediately below.)

So a RedirectMatch for your example might be:

RedirectMatch 301 ^/events/[^.]+\.htm$ http://example.com/

But note that RedirectMatch cannot see the query string data appended to your requested URL-path. If you need to manipulate the query string, use mod_rewrite instead.

And more complication: You can also use mod_rewrite to do your redirects. In fact, if you use mod_rewrite for any purpose -- external client redirects, internal filepath rewrites, or proxy through-puts, then you should use it for all of these, and not use mod_alias (Redirect or RedirectMatch) at all.

This has to do with being able to specify which directives in your .htaccess file are to execute first; Only the directives belonging to the same Apache module will be executed in the order that they appear in your file. It is important to realize that .htaccess is not a sequential "program," but rather a list of directives -- often handled by different Apache modules. Each of those modules 'reads' .htaccess and 'executes' only those directives that it understands. But you cannot control the order in which each Apache module takes its turn from within your .htaccess file. This can only be done on Apache1.x servers by modifying the module load order in the server config files. On Apache2.x, the execution order is controlled by some 'internal priority scheme.'

The end result is that if you mix directives from different Apache modules, there is no way to know what order they will execute in. You can determine that by testing today, but a server upgrade or a move to a new host might break your code tomorrow.

Therefore, it's a good idea to use mod_rewrite for all functions if you use it for any functions, and to not use a mixture of mod_rewrite and mod_alias directives.

In mod_rewrite-speak, the one-to-one redirect looks like this:

# Typical "set-up" directives for mod_rewrite
Options +FollowSymLinks -Indexes -MultiViews
RewriteEngine on
#
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]

and an example NON one-to-one redirect for your example problem (without repeating the set-up part) would be

RewriteRule ^events/[^.]+\.htm$ http://example.com/? [R=301,L]

Note that the "set-up" directives shown are typical. They are only required once in your .htaccess file. SOme hosts may not allow all of those Options settings, or may not allow any of them. However, since this varies by host, you have to test this yourself. Those Options settings are the ones I recommend for general use.

By all means, if you have not read through the mod_alias and mod_rewrite documentation at apache.org, take the time to do so. This may save you hours of frustration and/or years of less-than-optimal search engine ranking by helping you to understand how these directives are supposed to work. Also take advantage of the resources in our Apache Forum Charter and our Apache Forum Library. Remember that .htaccess is a server configuration file, and should not be modified without full understanding of the effects -- on the server, on the "Web site," and in search results.

Finally, once you have got your redirects to the point where they appear to work. Don't call it good and move on until you have thoroughly-tested them using a good server headers checker like the "Live HTTP Headers" add-on for Firefox and other Mozilla-based browsers. Make very sure that your request for an old URL is redirected to the final, correct, and canonical new URL with one single 301-Moved Permanently redirect. If that's not the case, then you've got some more work to do... :)

Jim