Avoiding A Loop During IP Change

[cooldogs]

I'm somewhat new to .htaccess and ModRewrite rules.

I have a client using WebSite Tonight through GoDaddy, in a few days we will be switching his domain from that particular server to a new dedicated IP that will be all his.

I'm assuming the step is to have the new site waiting at the dedicated IP (and it is) and then request that GoDaddy redirect the domain to the new IP

The way the new IP is set up it could be indexed by the search engines on it's own, something I do not want to have happen, i.e., xx.xx.x.#*$! would be in the index as would domain.com - a canonical issue.

Anyway to avoid this I've been using noindex on the pages under construction at the new IP. But I want the no index gone from them of course before the domain is pointed at the new IP.

My strategy is to have an .htaccess file waiting on the new IP that redirects any requests for the ip url to the www.domain.com url. So when the site propogates the double indexing won't be a problem.

All this said what will be waiting on the new IP server while the site goes through propogation is ...

RewriteEngine On
RewriteCond %{HTTP_HOST} ^xx\.xx\.x\.#*$! [nc,or]
RewriteRule (.*) [domainname.com...] [R=301,L]

Right now it works fine, if someone approaches the new IP via using the IP number as the url it redirects them to the "old design" at domain.com on the web site tonight server since that is where the domain.com currently "resides".

What I'm concerned about, is, can this cause a loop of any kind once the site starts to propogate and the domain is pointed from the old server to the other new one.

I'm a good web "designer" but not the most technical person in the world so please forgive me for my lack of knowledge on this.

Any help would be much appreciated. Thank you.

[jdMorgan]

That should be fine.

If you have any trouble while testing, you might have to add

DirectoryIndex index.html

at the top of your .htaccess file. But it is extremely likely that this has already been done at the server config level as part of the standard server configuration.

The only thing you might be embarrassed about in the future is calling the code we've discussed here a "big .htaccess file." I just finished editing one for another site that was 104kB in size -- Now that's gettin' a mite bit big, if'n you were to ask me... ;)

Jim

[g1smd]

I think the biggest I generally see is about 80KB - and half of that is stuff for blocking malicious bots.

[cooldogs]

Can't the, dare I say it, "big" ones, slow down the time it takes the site to load. With all the page name changes added mine is a mere 6K right now.

[g1smd]

It can have a performance effect if you are serving thousands of pages per minute.

It can have a performance effect if all of your rules are badly coded with multiple

(.*)

patterns to match.

For most sites, you are unlikely to see much effect - but do try to make each rule as efficient as possible.

For instance, a few weeks ago, jd demonstrated a rule using multiple

(.*)

patterns that meant the server had to make several thousand checks to get a match, whereas a more targeted pattern reduced that to a few dozen checks.

So, it isn't the number of rules per se, but the way they are coded.

In particular, make the left side of the rule as specific as possible so if it doesn't apply to the URL being tested, that is found out very quickly. If you have to use

(.*)

on the left, add a RewriteCond that will select out when it needs to match and when it does not - be as specific as possible.

I didn't know this for a long time -- but the order of processing is this:
- look at the left side of the RewriteRule (and maybe abort)
- look at any RewriteCond lines (and maybe abort)
- process the right side of the RewriteRule.

I had always assumed the RewriteCond information was processed first, and therefore a lot of code I wrote a few years ago is not all that good.