Hey,

Anyone a guru with .htaccess geotargeting?

I'm trying to force anyone from say Australia to a domain, lets say www.mySiteForAussies.com. Also, if you visit a www.mySite.com.au, I'd like to force them to www.mySiteForAussies.com as well.

So I have the following....

Options +FollowSymLinks

GeoIPEnable On
GeoIPDBFile "/usr/local/share/GeoIP/GeoIP.dat"­

RewriteEngine on

RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^AU [OR]
RewriteCond %{HTTP_HOST} ^www.mySite.com.au [NC]
RewriteRule ^(.*)$ www.mySiteForAussies.com/$1 [L,R=301]

Now, this works. Kind of. My problem is that if they are at www.mySite.com.au/page.html, they get redirected to www.mySiteForAussies.com. They lose the page.html.

Anyone know what I'm doing wrong?

Mute writes...

[L,R=301]

Humour me and swap these flags around

[R=301,L]

or just remove them entirely.

If that doesn't work, I have no idea what's wrong as your rewrite rules look correct.

Removed it entirely and still does the same thing. I thought my code looked pretty tight too but am struggling here....

Mute writes...

Removed it entirely

Oops, I just meant remove the [R] flag. You definitely want to keep the [L], especially if there's more to the .htaccess file.

Tried removing just the [R=301] and leaving the [L] but still have the same problem.

Any other ideas?

Mute writes...

Any other ideas?

Is that your entire .htaccess file? If not, post up the whole thing (masking domain names if you must).

That's the entire .htaccess file.

Ok, so let's start simple. Try this as an .htaccess file (substituting your domain names in and just for argument's sake, keeping them all lowercase)

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.domain\.com\.au [NC]
RewriteRule ^(.*)$ http://www.domainforaussies.com/$1­ [R=301, L]

Are either of the domains using SSL / https?

Happy Noodle Boy writes...

Ok, so let's start simple. Try this as an .htaccess file (substituting your domain names in and just for argument's sake, keeping them all lowercase)

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.domain\.com\.au [NC]
RewriteRule ^(.*)$ www.domainforaussies.com/$1 [R=301, L]

Are either of the domains using SSL / https?

Nope, no SSL or https.

And tried the .htaccess as above but no dice either. Hmmm....

what about this :

Options +FollowSymLinks

GeoIPEnable On
GeoIPDBFile "/usr/local/share/GeoIP/GeoIP.dat"­

RewriteEngine on
RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^AU$
RewriteRule ^(.*)$ www.mySiteForAussies.com$1 [L]

Nope, that didn't work either Penguin. Starting to wonder if it's my server or something rather then the code. Although I've used Rewrite before and had no troubles....

Are you sure the second site isn't doing a redirect of its own? You'll need to trace the requests from the client side. I recommend the Firefox Live HTTP Headers plugin.

If you have full server access, you might also want to try turning up the debug level. See the RewriteLog and RewriteLogLevel directives in the Apache documentation.

Finally, you could also try breaking the problem down. Happy Noodle Boy's test shows that its not the GeoIP stuff causing the problem. How "simple" can you get the .htaccess file and still show the problem?

For instance, what about this:

RewriteEngine on
RewriteRule ^/(x)$ http://www.mySiteForAussies.com/$1­

Ahh, mod_rewrite and its irregular expressions. I've used it twice, and both times I only made it work by accident.

Make sure the AllowOverride option is set to All for that host.

Penguin writes...

Make sure the AllowOverride option is set to All for that host.

He'd be getting 500 Internal Server Errors if the right Options and Overrides weren't set and besides, mod_rewrite only requires the FileInfo override.

OK, after a bit more testing I've found out that it's passing the querystring but not the file or directory.

So if I go to www.mySite.com.au/page.html?id=7 I'll get redirected to www.mySiteForAussies.com/?id=7

EDIT: Actually, scrap that. I'd left off the $1 so that's why it wasn't passing the file name. It doesn't seem to pass directories properly though.

Mute writes...

EDIT: Actually, scrap that. I'd left off the $1 so that's why it wasn't passing the file name. It doesn't seem to pass directories properly though.

Ah...

Is this .htaccess file in the top level of your site, or in a subdirectory?

mod_rewrite removes the directory in which the .htaccess file lives before matching (more specifically, the URL-path corresponding with that directory). It only gets re-added back on with internal redirect. You're using an external redirect (you have to, since you're going to a different site), so the directory does not get added on -- it can't know "where" in the URL to add it on.

Foonly writes...

Is this .htaccess file in the top level of your site, or in a subdirectory?

It's in a subdirectory.

So, are you saying it's not possible for me to do what I'm trying to do with a directory.

So, to recap....

www.mySite.com.au/page.html --> www.mySiteForAussies.com/page.html

....works perfectly.

But with a dir I get....

www.mySite.com.au/dir/page.html --> www.mySiteForAussies.com/page.html

....passes the filename, but loses the dir.

Mute writes...

....passes the filename, but loses the dir.

Well, the simple way around that is to just put dir in the replacement string:

RewriteRule ^(.*)$ http://www.mySiteForAussies.com/di­ r/$1

Foonly writes...

Well, the simple way around that is to just put dir in the replacement string:

RewriteRule ^(.*)$ www.mySiteForAussies.com/dir/$1

So I'd need to have slightly different .htaccess files for each dir?

Not a big deal, only one dir I'm talking about anyway.

Mute writes...

So I'd need to have slightly different .htaccess files for each dir?

Huh? Now you've got me really confused.

You only need one .htaccess file, at the top level of wherever you want it to be applied. The directory of that .htaccess file is removed from the requests before they're matched by the rules in that .htaccess file.

In other words, if you put the .htaccess file at the very top level of your site (the "document root"), you don't need to do anything funny with the replacement string at all.

Foonly writes...

Huh? Now you've got me really confused.

You only need one .htaccess file, at the top level of wherever you want it to be applied. The directory of that .htaccess file is removed from the requests before they're matched by the rules in that .htaccess file.

In other words, if you put the .htaccess file at the very top level of your site (the "document root"), you don't need to do anything funny with the replacement string at all.

I'm confused too.

I'm currently testing the .htaccess in a dir because I obviously don't want it to be screwing up my live site.

So, for example, I'm using www.mySite.com.au/development and it's redirecting me to www.mySiteForAussies.com

Does that make sense?

You can use the RewriteBase directive whilst developing to let mod_rewrite know where the actual root is.
httpd.apache.org/docs/2....html#rewritebase
Looks like if you use

RewriteBase /
# err, I think I meant
RewriteBase /development

it'll work as expected.

Edit: Just do what the nice Mr Foonly says.

Mute writes...

So, for example, I'm using http://www.mySite.com.au/developme­ nt/ and it's redirecting me to http://www.mySiteForAussies.com/

Does that make sense?

Yes, it does, and that's to be expected. You'd need to add development/ to your replacement string in this case.

OK, I'll try to describe the flow of requests, paths, etc., through Apache:

A request comes in for /foo/bar/baz on the host example.com.

The (virtual-) server for example.com translates /foo/bar/baz into a filesystem path (applying the document root, aliases, and so on), yielding /doc/root/foo/bar/baz.

Say /doc/root/foo/.htaccess exists and contains:

RewriteEngine on
RewriteRule ^(.*)$ http://other.example.com/xyz/$1 [L]

First Apache removes the prefix /doc/root/foo/ from the filesystem path /doc/root/foo/bar/baz (since that's the directory in which the .htaccess file exists). This yields the string bar/baz.

bar/baz matches the rewrite-rule, so Apache swaps it for the replacement string and applies the substitution, giving the URL http://other.example.com/xyz/bar/b­ az. Apache knows this has to be an external redirect (since it starts with http://), so it immediately stops processing and sends back a redirect to the browser.

Things to note:

1. Although the request originally mapped to /doc/root/foo/bar/baz, all of the following (potential) .htaccess files will be processed:

/doc/root/foo/bar/.htaccess
/doc/root/foo/.htaccess
/doc/root/.htaccess
/doc/.htaccess
/.htaccess

(subject to what's been enabled with AllowOverride).

2. When rewrite-rules within an .htaccess file are processed, the directory of the .htaccess file (not the original request) is removed.

3. The directory is not reattached, nor is RewriteBase applied, since the rule resulted in an external redirect.

Happy Noodle Boy writes...

You can use the RewriteBase directive whilst developing to let mod_rewrite know where the actual root is.

I am almost certain RewriteBase is only applied when an internal redirect is performed (it's necessary because an internal redirect needs to start off with a URI-path, and having just done a per-directory rewrite, Apache only has a filesystem path).

Foonly writes...

I am almost certain RewriteBase is only applied when an internal redirect is performed

I believe you're correct. Having never needed to do this sort of external redirect, I wasn't aware or this.
To the OP, ignore my post above and just do as Foonly recommends for your testing. Once you go live, your original .htaccess file should work fine.
On the "testing" note, you should have a testing environment that mimics your production one as closely as possible. This includes directory structure.

Thanks for your help guys.

Works if I use add the directory to the redirects in the development dir.

All is good!

Happy Noodle Boy writes...

On the "testing" note, you should have a testing environment that mimics your production one as closely as possible. This includes directory structure.

Aye we should. We're getting one soon when we upgrade out servers. But till then, stuck with what we've got....