Forum Moderators: phranque

Message Too Old, No Replies

mod rewrite: redirect by cname and language

         

KieserFiller

6:54 pm on Mar 24, 2010 (gmt 0)

10+ Year Member



Hi,
I'm tinkering around with this one for several hours now...

What I try to accomplish is, to redirect
[xrms.mydomain.com...]
to [mydomain.com...] for our xrms users

and set up an language redirection by browsers preffered setting.for the main website. this is the my .htaccess so far:


RewriteEngine On
Options FollowSymLinks

RewriteCond %{REQUEST_URI} ^/?$ [NC]
RewriteCond %{HTTP_HOST} ^xrms\..*$ [NC]
RewriteRule (.*) https://mydomain\.com/xrms [R,L]

RewriteCond %{REQUEST_URI} ^/?$ [NC]
RewriteCond %{HTTP:Accept-Language} (de) [NC]
RewriteRule ^(.*)$ https://www\.mydomain\.com/concrete_de/news [R,L]

RewriteCond %{REQUEST_URI} ^/?$ [NC]
RewriteCond %{HTTP:Accept-Language} (pl) [NC]
RewriteRule ^(.*)$ https://www\.mydomain\.com/concrete_pl/news [R,L]

RewriteCond %{REQUEST_URI} ^/? [NC]
RewriteRule ^(.*)$ https://www\.mydomain\.com/concrete_en/news [R,L]

As you see, the user shoul be forwarded to /xrms if domain begins with xrms.*. If not, the language handling comes into place:
move to german site if german is supported, polish site if polish is supported or default finally to english site.

BUT: that doesn't work, thats why I'm hoping for some hints from you..

without the first rule, the language handling works fine.
without the language-rules, the first one works fine, too.

but together they don't.
xrms.mydomain.com is handled by the other rules while it should not, and I am redirected to their destinies.

Any idea on this?

jdMorgan

2:04 pm on Mar 26, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Because these are redirects, each HTTP request will have to be completely-handled "all at once". Otherwise, the client will be redirected by one of your rules, issue a new HTTP request, and then get redirected by one of the other rules:

RewriteEngine On
Options FollowSymLinks
#
# Redirect xrms subdomain requests to example.com/xrms subdirectory
RewriteCond %{HTTP_HOST} ^xrms\.example.\com [NC]
RewriteRule ^$ https://example\.com/xrms [R=301,L]
#
# Redirect requests for "home page" in non-blank, non-xrms domains with
# Accept-Language=de to https://www\.example\.com/concrete_de/news
RewriteCond %{HTTP_HOST} !^(xrms\.example.\com)?$ [NC]
RewriteCond %{HTTP:Accept-Language} ^([^,;]+[,;])*\ ?de([\-,;]|$) [NC]
RewriteRule ^$ https://www\.example\.com/concrete_de/news [R=301,L]
#
# Redirect requests for "home page" in non-blank, non-xrms domains with
# Accept-Language=pl to https://www\.example\.com/concrete_pl/news
RewriteCond %{HTTP_HOST} !^(xrms\.example.\com)?$ [NC]
RewriteCond %{HTTP:Accept-Language} ^([^,;]+[,;])*\ ?pl([\-,;]|$) [NC]
RewriteRule ^$ https://www\.example\.com/concrete_pl/news [R=301,L]
#
# Redirect requests for "home page" in non-blank, non-xrms domains with
# Accept-Language [b]not=[/b] de or pl to https://www\.example\.com/concrete_en/news
RewriteCond %{HTTP_HOST} !^(xrms\.example.\com)?$ [NC]
RewriteCond %{HTTP:Accept-Language} !^([^,;]+[,;])*\ ?(de|pl)([\-,;]|$) [NC]
RewriteRule ^$ https://www\.example\.com/concrete_en/news [R=301,L]
#
# (New) Default hostname canonicalization rule: Redirect non-blank, non-xrms, non-www hostname
# requests to same URL-path on www.example.com host using originally-requested protocol
RewriteCond %{HTTP_HOST} !^((xrms|www)\.example\.com)?$
RewriteCond %{SERVER_PORT}s ^(443(s)|[0-9]+s)$
RewriteRule ^(.*)$ http%2://www.example.com/$1 [R=301,L]

Now, each rule is 'fully-qualified' and no unexpected 'secondary' redirects should occur.

Note also the much-more-specific Accept-Language patterns, intended to prevent unexpected matches on regional language options, for example, "at-de"

You may wish to change or expand the new, final, default hostname canonicalization rule, since I do not know exactly what you would want to do with requests that are not for xrms.example.com, www.example.com, or a blank hostname. As an example, I opted to redirect these to the same URL-path as requested and using the same HTTP/HTTPS protocol as requested, but on the www.example.com host.

The handling of blank hostnames is required if your server might receive a true HTTP/1.0 request; HTTP/1.0 requests do not contain a "Host" header, and the %{HTTP_HOST} variable will therefore be blank. It is important to handle this case --although very rare-- because if it is not handled properly (as shown), the result can be an 'infinite' redirection loop which can over-load your server.

You may also wish to consider the issue of HTTPS/SSL performance. It is not likely that *all* of your site needs to be secured with HTTPS/SSL, and using SSL for all requests is comparatively slow. Generally, HTTPS is only needed for "subscribe", "login", "my account", and "checkout" functions, and not for the whole site.

Jim