dynamic domains

[killer7]

First off, I'd like to thank everyone here. Many of google searches have landed me here when trying to figure something out.

Now, I've got a strange issue. I'm attempting to do dynamic subdomains, and that works without much issue.

When redirecting from test.example.com, it should serve files from example.com/test/ which works. What the problem is that referenced links, such as href=/members/, will use test.example.com/test/members/, which works, but defeats the purpose. I've been fighting with this for a couple days and it's almost as if the rules that I KNOW should match don't. It's confusing the daylights out of me.

Here's what I have that's working:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.example.com
RewriteCond %{HTTP_HOST} ([^.]+)\.example.com
RewriteRule ^(.*)$ /home/username/public_html/es/%1/$1 [L]

Any ideas?

Thanks =]

[jdMorgan]

Nothing wrong with your rule, unless you're having a looping problems... Where is this code located?

I'd guess you've got some other 'agent' -- another rule or a script for example, that is invoking an external redirect, since your rule can't change the URL (it's an internal rewrite, not a redirect), and since you clearly showed a server-relative link in the href above.

As such, I'd suggest installing the "Live HTTP Headers" add-on for Firefox/Mozilla browsers, and using it to find out 'when' the subdomain-subdirectory is being exposed as a URL. Based on when this is occurring, you can narrow down what code might be responsible for it.

Also, just a comment: It's unusual to see (or to have to use) a long filepath like the one you've got in your RewriteRule's substitution path above. You might want to check your DocumentRoot setting, as it looks like it may be pointed 'too high' in the server filepath. Most of the time, for example, it's not necessary to include "/public_html" ot anything above that in RewriteRules because DocumentRoot is already defined as/at /public_html.

Jim

[killer7]

Thanks for the help jd,
The sub domain directory is exposed in links, such as when the link contains code such as <a href="/members/">Members</a>, then it will use test.example.com/test/members

I'll check through the other htaccess file higher up, but changes I made in it did not seem to have an effect.

[jdMorgan]

Links on pages define URLs. Clients (e.g. browsers or robots) resolve page-relative and domain-relative links to the 'absolute' URLs needed to make an HTTP request. Then your internal rewrites in mod_rewrite resolve the requested hostname and URL-path to a filepath, or --in the absence of an applicable RewriteRule-- the server resolves them by default to DocumentRoot+requested-URL-path.

So the links on your pages must be <a href="/path-below-/members"> only; Since this is a server- or domain-relative link, and the current page is in the membername subdomain, the rewrite of <username>.example.com to /test/username should still 'point' the requested URL to the proper subdirectory.

That is, as far as the member is concerned, the only information needed in the URL is his subdomain, the domain and the requested page or object; the membername should not be included in links.

It's also probably a good time to point out another potential problem before you get in too deep: When doing something like this, it's a good idea to put all "user" subdomains into a subfolder themselves -- That is, don't put the subdoamin-subdirectories in root.

If you do, you end up with one or two problems: If your code is in .htaccess, then in order to prevent rewrite looping, you'll have to check for each subdomain-subdirectory-name explicitly, the rule will need a RewriteCond to exclude each subdomain-subdirectory so that it won't be rewritten recursively, and this can easily become a maintenance nightmare.

And there's another problem no matter where you put your rewrite code: If you put all subdomain-subdirectories in root, then no other directory in root can have the same name as a user or you'll have 'naming collisions'. Your user-signup-and-directory-creation script will have to check each username against a current list of all existing directories.

So the bottom line is that I strongly recommend that you put all username-subdomain-subdirectories into a subdirectory below root, and call it by some short-but-unique name like "usrdirs". In this way, rewrite-loop checking and prospective-username checking will be simplified; loop prevention can be easily done simply by excluding any path in that unique subdirectory, and when vetting a new username, your script need only check for pre-existing subdirectories in that unique subdirectory. I bring this up because the fact that you're (apparently) currently testing in a "/test" subdirectory is likely masking both aspects of this problem.

Jim

[killer7]

Jim,
That's partially the issue.

I want to rewrite the URL to not contain the user dir.

Such as,
[user.example.com...] (How I want it to work, currently works fine)

not, [user.example.com...] (this is what relative links are causing. I need to rewrite the url to exclude the /user/ sub director, it's redundant to have in the URL and is causing other problems.)

[jdMorgan]

As above, you cannot use mod_rewrite to 'change' a URL defined on a Web page. You must change the link on the Web page itself. Once that is done, and that URL is requested by the client, mod_rewrite can then be used to 'deliver' that URL request to the proper filepath in the server.

Jim

[killer7]

I'll rephrase.

I need links that link to:
[user.example.com...]

to redirect to
[user.example.com...]

(The whole directory of the sub domain, the above is just an example obviously.)

This seems very simple to me, just that none of my code's rules will match. I feel rather stupid the more I look at it.

[jdMorgan]

Let me ask directly, then: Where are these

links that link to:
[user.example.com...] located? On your own site?

If so, then you must change those links in the HTML of your site's pages.

Only after that is done can mod_rewrite be of any assistance to you. Mod_rewrite affects incoming URL requests; It cannot change the HTML on your pages, and it cannot "change a bad URL" once that URL has been requested from your server -- at that point it is too late.

Jim

[killer7]

Jim,
Yes those are on my site. The whole plan was to have it setup so that all sub directories were accessible as sub-domains.

(ie. test.example.com -> example.com/test)
I needed the relative links (which link as example.com/test/linkedpage) to rewrite to test.example.com/linkedpage

I was hoping that maybe I just didn't know something but it's seeming rather impossible to me. As you can tell, htaccess isn't my strongest point.

Thanks for all the help! =]

[jdMorgan]

Right, you must change the links on your pages to the '<a href="http://test.example.com/">' format first, and then mod_rewrite can help you... Rewriting requests for URLs of the form test.example.com to the server filepath example.com/test is trivial, but it's only the second part of the process; What you put on your HTML page defines the URL, and nothing inside the server can change it once it's been defined.

Again, mod_rewrite is doing a requested-URL-to-internal-server-filepath translation function, not a "change the text on all of my pages" function. In fact, mod_rewrite runs as soon as the client request is received by your server, and finishes running before any of your content is served or any of your scripts are executed.

If that's not clear, then perhaps it is a misunderstanding of *what* is being rewritten: It is the server filepath associated with a requested URL that is being rewritten (changed), and not any of your on-page content or links. mod_rewrite might well have been called
"mod_change_the_filepath_to_serve_content_from_a_non-default_server_filepath" if it were not for the fact that it also does several other functions.

In a nutshell, here's how it must work:
1) Change the HTML code on your page to link to "test.example.com/" (or change the script that generates your HTML page)
2) Visitor clicks on that "test.example.com/" link
3) Server receives client browser request for "test.example.com/"
4) Server invokes mod_rewrite, which detects the request for the "test" subdomain
5) Mod_rewrite internally rewrites that URL request, changing the filepath to point to files in the "/test" subdirectory instead of in the root directory.
6) Server serves the requested content from the /test subdirectory.
6) Visitor sees content from a file in the /test subdirectory in response to his request for the "test" subdomain URL.

The mod_rewrite rule itself is trivial; It is only a problem of understanding how it works -- and how a URL is defined by a link on a page, and not by anything inside the server.

Once the on-page link has been changed and the internal rewrite rule has been implemented, there is an optional third step which can be taken to speed up search engines' correction of any old links listed in search results. But it's no use even discussing that until the other two steps are implemented and tested.

Jim

[killer7]

Jim,
Here's a quick question for you if you have a second.

Would it be possible to re-write request as a redirect?
ie.
request for example.com/test to be redirected to test.example.com? And for something like example.com/test/somedir to redirect to test.example.com/somedir?

Just wondering if this could be done at all. I understand how mod_rewrite works, just not so much how to use it.

I'm not trying to change links on the page. Just trying to make them work by re-writing them.

[jdMorgan]

Last post: Mod_rewrite cannot change the links on your pages.

You must change the links on your pages by editing the database URL entries, by editing the script that produces your HTML pages, or if they are static HTML pages, by editing the pages themselves. Any attempt to try to avoid this by using some rewriting or redirecting 'trick' is going to fail, either technically or because it will nuke your search engine rankings, server stats, and site performance. If there were an easy way to do this I would tell you, but frankly, I'm not going to risk my reputation by giving bad advice.

You're dealing with the technicalities of the HTTP protocol, server-side coding, and search engine ranking here, and unfortunately, they do not correspond with how you 'wish' things worked.

Sorry to be blunt, but really, this thread with its current focus is no longer likely to be productive.

If you can't find a good way to modify your database or script to produce correct URLs in your links, then look into using a 'filter' on Apache to 'edit' your pages on the fly (as they are being served). You will need to be hosted on an Apache 2.x server and you will very likely need better than run-of-the-mill hosting to do this without dragging down your site's performance. Check with your host to be sure that you will be allowed to use this Apache facility before investing any hope in it.

Jim

[killer7]

Thanks Jim,
I just try to pick people's brains from time to time.

I appreciate your time. And the great help this site is.

[jdMorgan]

Well, I hate to see a project fail due to mis-communication or lack of effective communication, but without a confirmation of exactly where and when the "/members" filepath is being exposed in the URL, it's impossible to make any further suggestions.

I still suggest investigating this using an HTTP headers checker as previously outlined above; You can't fix a problem if you don't know exactly what the problem is.

Jim