Forum Moderators: phranque

Message Too Old, No Replies

multiple domains, mod rewrite and return header

         

nmjudy

11:21 am on Aug 24, 2004 (gmt 0)

10+ Year Member



I'm confused. I setup a website under 1 domain with a static IP with my hosting provider. I then parked 2 additional domains at this domain (through cpanel). It's my understanding, that I should only promote one of those domains and have the other 2 redirect to the promoted domain in the event that the other 2 got indexed (avoiding duplicate content).

I created my first mod rewrite like this.
Options +FollowSymLinks
RewriteEngine on

RewriteCond %{HTTP_HOST} ^(www\.)?domain1\.com$ [NC]
RewriteRule ^(.*)$ [promoteddomain.com...] [R=301,L]

RewriteCond %{HTTP_HOST} ^(www\.)?domain2\.net$ [NC]
RewriteRule ^(.*)$ [promoteddomain.com...] [R=301,L]

RewriteCond %{HTTP_HOST} ^(www\.)?promoteddomain\.com$ [NC]
RewriteRule ^(.*)$ [promoteddomain.com...] [R=301,L]

Now when you type any combination of the 3 domains into the address bar (with or without the 'www.'- they get redirected to www.promoteddomain.com.

However, using a header checker tool I get the following information:
HTTP/1.1 200 OK
Cache-Control: cache
Connection: close
Date: Tue, 24 Aug 2004 11:12:26 GMT
Pragma: no-cache
Server: Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4

Shouldn't I be getting a 301 redirect? I spoke to my hosting provider and this is the response I got which makes no sense to me for what I want to accomplish:

"The 301 status code is shown in the header only when the requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. In your case all the domains domain1.com, domain2.net, and promoteddomain.com have the same Ip since they are in the same server. So, the status code will be 200 OK itself. When the server checks, all the requests are going to the same IP and it will not be able to distinguish between these main domain and parked domains. That's why it returns the 200 status.

You can see a 301 status if you moved a domain permanently to another server and give a redirection to the new domain in the new server. Moreover this status code depends on the method used to send the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD."

jdMorgan

1:47 pm on Aug 24, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Well, they did an admirable job of responding -- their reply shows that they did do a bit of research, and I'm actually quite impressed. But there is an error in their response here:

"When the server checks, all the requests are going to the same IP and it will not be able to distinguish between these main domain and parked domains."

This is precisely what checking server variable %{HTTP_HOST} accomplishes; it allows mod_rewrite to determine the server name that was requested by HTTP/1.1 clients and above. This information is passed in the HTTP request header, and is therefore visible to mod_rewrite.

I see two problems with the code. First, you don't need the "(www\.)?" in the third ruleset at all, and including it may cause "redirection looping" problems, because it can rewrite the desired domain to itself. Use:


RewriteCond %{HTTP_HOST} ^promoteddomain\.com [NC]
RewriteRule ^(.*)$ http://www.promoteddomain.com/$1 [R=301,L]

instead.

Second, all three rules have an end-anchor on the HTTP_HOST pattern, which can cause problems if the client or an intervening caching proxy appends a port number. So I'd suggest dropping the end-anchor "$" to avoid this:


RewriteCond %{HTTP_HOST} ^(www\.)?domain1\.co[b]m[/b] [NC]
RewriteRule ^(.*)$ http://www.promoteddomain.com/$1 [R=301,L]

Now, it will accept "www.domain1.com:80" if it is requested.
An alternative would be to use a pattern of ...domain\.com(:[0-9]{1,5})? [NC]

It may be that neither of these tweaks fixes your problem. In that case, it may be that some other factor is preventing mod_rewrite from being invoked. If the server AllowOverride setting does not allow you to control FileInfo or Options, for example, then mod_rewrite can't run.

Jim

nmjudy

6:39 pm on Aug 24, 2004 (gmt 0)

10+ Year Member



Thanks for the info! I changed my .htaccess file to be as follows as per your recommendations:

Options +FollowSymLinks
RewriteEngine on

RewriteCond %{HTTP_HOST} ^(www\.)?domain1\.com [NC]
RewriteRule ^(.*)$ [promoteddomain.com...] [R=301,L]

RewriteCond %{HTTP_HOST} ^(www\.)?domain2\.net [NC]
RewriteRule ^(.*)$ [promoteddomain.com...] [R=301,L]

RewriteCond %{HTTP_HOST} ^promoteddomain\.com [NC]
RewriteRule ^(.*)$ [promoteddomain.com...] [R=301,L]

Everything appears to redirect in the browser correctly. However, using one header checker tool I get the following information:
HTTP/1.1 200 OK
Cache-Control: cache
Connection: close
Date: Tue, 24 Aug 2004 11:12:26 GMT
Pragma: no-cache
Server: Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4

While doing further research, I stumbled across webmasterworld's header checker tools and got this:
HTTP/1.1 301 Moved Permanently

Date: Tue, 24 Aug 2004 18:22:19 GMT
Server: Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.8 FrontPage/5.0.2.2634a mod_ssl/2.8.18 OpenSSL/0.9.7a
Location: [promoteddomain.com...]
Connection: close
Content-Type: text/html; charset=iso-8859-1

I then checked the raw log files and they look like this:

68.42.39.184 - - [24/Aug/2004:06:57:01 -0400] "GET / HTTP/1.1" 301 251 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
68.42.39.184 - - [24/Aug/2004:06:57:02 -0400] "GET / HTTP/1.1" 200 24411 "-""Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
68.42.39.184 - - [24/Aug/2004:06:58:09 -0400] "GET / HTTP/1.1" 301 251 "-""Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
68.42.39.184 - - [24/Aug/2004:06:58:10 -0400] "GET / HTTP/1.1" 200 24351 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"

Looks like it's working to me (I try to say with utmost confidence) - So I don't know why my hosting service said 200 OK or why the other tool is giving false information.

What's your opinion? Do you think that it's setup correctly? Or do you think something still isn't correct?

jdMorgan

7:04 pm on Aug 24, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Their header checker may be set up to automatically follow redirects, which is what would happen here. I'd trust Brett's WebmasterWorld code, though; it does not follow redirects unless you tell it to do so (there are various versions, and you may not have seen this option, but it will not follow redirects by default).

For a third opinion, try WannaBrowser (do a search) -- It's a free service.

Jim

nmjudy

7:41 pm on Aug 24, 2004 (gmt 0)

10+ Year Member



Third opinion (wannabrowser) looks good to me - saying 301 redirect for all domains with and without 'www' to www.promoteddomain.com.

Thank you for your guidance!

jdMorgan

8:10 pm on Aug 24, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Good news!

Now let's make it faster:


Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^((www\.)?domain1\.com¦(www\.)?domain2\.net¦promoteddomain\.com) [NC]
RewriteRule ^(.*)$ http://www.promoteddomain.com/$1 [R=301,L]

You'll have to edit the broken pipe "¦" characters, and change them back to solid pipe characters -- posting on this board changes them.

Another way to do this, if you want to redirect all alternate domains to the main domain is:


Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^www\.promoteddomain\.com
RewriteRule ^(.*)$ http://www.promoteddomain.com/$1 [R=301,L]

This redirects all requested domains that are not blank and are *NOT* www.promoteddomain.com to www.promoteddomain.com. It's handy when you have a lot of alternate domains and want to redirect all of them to the main one. The 'not blank' check is needed to prevent problems with true HTTP/1.0 clients, which do not provide the HTTP_HOST header for the server to check.

Jim