.htaccess root redirect - need help please.

can't get root redirection working

[humbucker]

Hi, I really need your help please.
Here is my problem :

I'm desperately trying to make a redirection from

http://www.mydomaine.com
&
http://mydomain.com
to: http://www.mydomaine.com/blog
BUT
I got several other registered url that redirect to dedicated subfolders contained in this domain webspace,
(example : http://www.web2.com redirects to http://www.mydomain.com/web2)

When my htaccess is working for the first part of my question, it always fail with the others domains,
can someone please help

Thanks thanks a lot !

[edited by: jdMorgan at 10:27 pm (utc) on Oct. 18, 2008]
[edit reason] de-linked URLs [/edit]

[jdMorgan]

Please post your best-effort code as a basis for discussion.

Also, can you tell us why you would want to *redirect* from mydomaine/ to mydomaine/blog, instead of simply serving the content for the URL mydomain/ from the filepath /blog ? By this I mean that there is no reason that the users or search engines would know or care that content for mydomaine/ was stored in mydomaine/blog, and so there is no reason to tell them that it is. Instead, simply *rewrite* from mydomaine/ to /blog, and the clients don't need to know about this filespace mapping inside the server, any more than they need to know about the other domains that mentioned mapping into their own subdirectories.

Jim

[humbucker]

Hi Jim,

Here is what I'm using right now :

RedirectMatch permanent ^/$ http://www.mydomain.com/blog/

This code works when I'm typing http://www.mydomain.com only, not when I'm typing http://mydomain.com (first problem)

To answer you, I want to use this redirection not to move all the files I've created with database and so on in my /blog folder.

The webspace connected to this general domain in fact stores a lot of other websites files, that's why i'm embarassed with this redirection problem. All the other domains url now also redirect to mydomain/blog, I assume they do that because they go into the htaccess file and dont maybe find exceptions.
i'm sorry I'm not that good in english, nor in htaccess.

Thanks for your help.

[edited by: jdMorgan at 10:29 pm (utc) on Oct. 18, 2008]
[edit reason] de-linked URLs [/edit]

[jdMorgan]

You'll need to use mod_rewrite instead of mod_alias, and check the HTTP_HOST header using a RewriteCond. If it indicates that the requested domain starts with mydomain, www.mydomain, or mydomaine, or if it ends with a "." or a port number, then *externally redirect* to www.mydomaine.

Next, look at the HTTP_HOST header again. Verify that it is www.mydomaine. If so, and the requested URL-path *does not* start with /blog, then *internally rewrite* to /blog, retaining whatever additional URL-path-parts the client asked for.

Jim

[g1smd]

That is certainly the best way to tackle things; a couple of redirects and a rewrite.

Someone else had an almost identical question in the last few weeks here, and I believe that thread has a whole load of code in it as a basis to get started.

[encyclo]

That is certainly the best way to tackle things

Is it? If I understand the problem correctly, the aim is to redirect one page, specifically the root index page, to one particular subdirectory, this without affecting any other subdirectory which may also function as a document root for another domain.

If this is an accurate description of the scenario, then I don't think using mod_rewrite is the simplest solution. A simpler and more robust solution would to be to have an index.php in the document root which includes the following:

<?php 
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.example.com/blog/");
?>

[jdMorgan]

A major part of the question here is whether a redirect is needed, or just a simple rewrite, so that content requested from mydomaine/ is served from the server path /blog/.

I'm wondering why you think the PHP solution is "more robust" as well, since it depends on loading and executing an additional interpreter -- and not a small one, either. That's quite an additional dependency to introduce into a conventionally-assessed "robustness" analysis.

Jim

[encyclo]

A mod_rewrite solution would be invoked (assessed) for every HTTP request across multiple domains (due to the document roots for other domains reside within subdirectories of the main domain). The PHP interpreter would only be invoked in one specific instance (a request for the index of the main domain), not in any other scenario. Assuming the site is dynamic anyway (most blogs are), I don't think the use of PHP is an exaggeration in this context. Whether it is more efficient in terms of server load I cannot say.

When discussing robustness, one of my pet hates is the "stacking" of document roots where either subdomains or addon domains have their document root within a subdirectory or another domain. This always complicates the use of mod_rewrite as the .htaccess for the main domain affects those domains/subdomains in the subdirectories. Changing this setup will help the "robustness" as the complexity of any rewrites is usually reduced.

I think it's fair to suggest that the question should not always be how to use mod_rewrite to achieve a goal, but to ask whether mod_rewrite is always the solution. Not every problem is a nail to be hit with the mod_rewrite hammer. :)

[jdMorgan]

When discussing robustness, one of my pet hates is the "stacking" of document roots where either subdomains or addon domains have their document root within a subdirectory or another domain. This always complicates the use of mod_rewrite as the .htaccess for the main domain affects those domains/subdomains in the subdirectories.

The most usual case is that the add-ons are either rewritten or have their DocumentRoot set to the subdirectory in the main domain's filespace by code at the server config level (httpd.conf, conf.d, etc.). In this case, there is no complication of .htaccess code due to the add-ons, because the main domain's root .htaccess file isn't accessed when an add-on is requested.

It's possible --and yet to be fully-determined-- if this is the case in the OP's server set-up.

I think it's fair to suggest that the question should not always be how to use mod_rewrite to achieve a goal...

True enough, but the mod_alias won't work regardless of the add-on-domain-to-filespace mapping, because the mod_alias Redirect directives cannot explicitly stop recursion, and cannot do an internal rewrite. So I suggested mod_rewrite to replace mod_alias -- and not to say that you couldn't do this with PHP, or PERL, etc. I will say, however, that I prefer to use the smallest hammer possible... ;)

Jim

[edited by: jdMorgan at 2:13 am (utc) on Oct. 19, 2008]

[g1smd]

*** This always complicates the use of mod_rewrite as the .htaccess for the main domain affects those domains/subdomains in the subdirectories. ***

The main operation of the sub-folder is mapped to another domain with its own .htaccess file, so the .htaccess in the server _public_html or _www root folder only comes into play if the sub-folder is being referenced by the "wrong" domain name. None of the other sub-folders are affected by this.

[humbucker]

I must say what I'm reading seem very technical to me, and to be honnest mod_rewrite, mod-alias is really...hum..unknown to me, so I'm sorry first to declare I'm lost, I'm also really grateful to find some many people willing to help.
What I'm trying to find is the best solution for robots, page rank, and so on ...
The php thing seems good, but in my mind, what I know about .htaccess is that it was a clearer way to operate, right ?

[humbucker]

I should be clearer sorry...if I'm using the php syntax given above, what will google robots read and display in the search result. Do you know ?
Can I put some "title" and "meta" rags in the index.php file ? and how ?

Many thanks

[jdMorgan]

The PHP code above generates a 301-Moved Permanently server response, and that is what browsers and robots will see. They will replace the URL that they originally asked for with the URL provided in the "Location:" header, and issue a second HTTP request for that URL. As long as this 301-redirect is in place, the new URL will be used for display in search results.

However, you should take steps to get rid of any links pointing to the old/wrong URL, because it will avoid the search engines and visitors having to be redirected. View the redirect as a "tidy-up" and not as a "cure." If you cannot get all Web sites which point to the wrong URL to correct their links, then the 301 will need to remain in place forever.

There is no way to put HTML elements such as <title> into a server response header. But it doesn't matter because even if you could, they wouldn't be used anyway; The <title> and everything else will be taken from the new URL instead.

Jim