Note: The original version of this article was written some time ago. I don't know if roadblocks I encountered with the hosting company I was using then still apply, so I have anonymised that aspect of the content. Some of the things below may be outdated, or less complete than they were.
I was working on the launch of an e-commerce venture, Luxartis.biz (since be sold to another party). The site needed server-side scripting and a database. PHP and MySQL were what I was most familiar with at the time. I didn't expect hordes of visitors to start with.
The hosting plan for iansharpe.com had all the needed server features and my personal site only used a fraction of the space and bandwidth allowances. What could be more natural, then, than to host my new venture alongside it and call on some of that unused horsepower?
Easy! There are several ways to do it. One of them had to work...
I went all around the houses before realising that no matter how good the headline figures are for a hosting plan, there may be serious but less obvious limits to what you can do.
Initially, I put Luxartis in a subdomain to keep it physically separate from iansharpe.com. This took a few moments to set up in my site administrator control panel. Luxartis then resided at luxartis.iansharpe.com (though it isn't there now).
The luxartis.biz domain was registered with GoDaddy
To begin with, I set luxartis.biz to forward to the subdomain. Doing this meant that entering www.luxartis.biz automatically redirected the visitor from GoDaddy to the Luxartis home page, but the address bar then showed luxartis.iansharpe.com.
I wanted the paid-for URL displayed, so I turned on masking.
Also known as cloaking, masking causes the domain registrar to create a page for you on its own site. This has very little on it except for a frame. When a visitor enters your domain address, they get the container page hosted by the registrar. The frame pulls in content from your web site. URL and content appear to be married but in reality two web servers are working in tandem.
It's a flawed marriage. For instance, no matter which page is viewed, only the bare domain name is displayed in the address bar. This may or may not affect the ability to bookmark a specific page. It depends on the browser.
I don't know the full effect on search engine spiders, but I can't believe it never has adverse consequences.
Furthermore, the header tags on the real page do not become the meta tags for the framing page. The 'keywords' meta tag is reputedly just about obsolete for the purpose of search engine indexing. But even so, sometimes it is used and other meta tags still have value.
GoDaddy enabled me to create 'title' and 'keywords' meta tags for the framing page, but that's one setting for the whole site, not a custom setting per target page.
Some registrars offer other systems, such as automatic HTTP redirects. Nevertheless, I preferred to stay away from workarounds.
In addition to the disadvantages mentioned so far, there is the matter of speed. With forwarding, there are always two web servers involved: the registrar's and yours. At busy times, this is bound to introduce extra delays loading pages.
Luxartis was a commercial operation. Penny-pinching sub-optimal kludges acceptable on a hobby site may lose business when image, visitor flow and usability assume prime importance.
What I really needed is requests for Luxartis pages to be sent directly to my server.
If I set the new domain to point to the IP address of iansharpe.com, Luxartis visitors got iansharpe.com content, but with www.luxartis.biz in their address bars.
So the next option I looked at was to have a second IP address assigned to my site. Sometimes it is possible to assign a subdomain its own IP address. This could be a unique target for luxartis.biz.
Only, it wasn't an option on my hosting plan. One IP address is all you got. If I rented a whole or virtual server from the same company, I could buy pairs of additional IP addresses for it. But I didn't need the resources, expense or admin overhead of a dedicated server. Not only that, but the extra addresses cost almost as much as separate cheap hosting.
Moving on, I investigated what the Apache web server has to offer. Virtual hosts seemed to be the answer. Apache can be set up to run multiple sites on one IP address. Requests for content from different sites are distinguished by the target domain names supplied by the browser. This will fail with old browsers that don't supply the required information, but modern ones do.
Once again, I had a potentially good solution.
Only, my hosting plan didn't give access to the Apache configuration file.
Next port of call was Apache's .htaccess files. Even I am allowed to tinker with these.
Provided Apache's rewrite engine module, mod_rewrite, is available, .htaccess allows you to intercept incoming requests and modify them in various ways before the server retrieves and transmits the content.
One of the techniques that .htaccess makes possible is to redirect a request to another file, possibly located in another directory or on another site.
Again, this looked like a good way forward. I could put an .htaccess file in the root of iansharpe.com, trap requests for luxartis.biz, and redirect them to files in the Luxartis subdomain.
This is where the real head banging began. The .htaccess file is incredibly flexible. As is noted in many other places, the price of flexibility is complexity.
Mod_rewrite makes use of regular expression matching, and while I am familiar with regex, I don't use it every day.
For this reason, I put my inability to get .htaccess working quite as I wanted down to my own mistakes. In fact, I had run up against another hidden barrier.
I fairly quickly had .htaccess working to the point where the redirections were being performed, giving me two web sites running on one hosting plan:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^.*luxartis\.biz$ [NC]
RewriteRule ^.*$ http://luxartis.iansharpe.com [R=301,NC]
The only problem was, the Luxartis subdomain was appearing in the address bar. The point of this adventure was to prevent that.
The mod-rewrite documentation is dense, and the various tutorials I found either regurgitate it without much tenderising, or are very skimpy, or manage a pointless combination of both faults. Why do these people bother?
I kept bouncing back to the official manual. On the umpteenth skim-through, the penny dropped.
I had discovered elsewhere that redirections which report code 302 to the browser are undesirable. This code signifies that the requested page has moved temporarily, and search engines tend to ignore such pages. What's needed is a code 301 redirection, indicating that a resource has moved permanently. This is much more acceptable.
If you don't add parameters to your RewriteRule lines in .htaccess, you're probably defaulting to 302 rewrites. If this isn't what you want, you can append the [R=301] flag to change the return code.
Reviewing that portion of the mod_rewrite documentation, I noticed that it refers to external rewrites. Elsewhere, it mentions internal rewrites. Suddenly, I realised that external rewrites 301 and 302 tell the browser about the redirection, causing the re-written address to load into the address bar. An internal redirection should do the job invisibly.
Internal redirects are forced with the [P] flag and require Apache's mod_proxy module to be present.
Guess what? The [P] flag did nothing more than generate server errors. Had the hosting company's techies deliberately barred this too, or could it be turned on if I asked nicely?
Time to fire off a support request. I thought I knew the answer but had to ask anyway.
The official word was that this feature was unsupported in my hosting plan.
That was the end of the quest for clean co-hosting with that company. My choices seemed to be as follows:
Otherwise, I could be looking at a VPS or VDS (virtual private/dedicated server), which works like having a server all to yourself, but it is virtualised: it runs in parallel with several others on the same hardware.
VPS/VDS is a stepping stone between cheap shared hosting and an expensive fully dedicated server. The downside is that, while not too pricey if you shop round, it cost more than I was paying for shared hosting and I'd be responsible for server administration at a level I didn't want to make time for.
So that's where I was during development of the Luxartis site.
Version 1 of the Luxartis site was ready to go live so I needed decent hosting. I had also decided that I shouldn't be wasting time on nasty workarounds.
Bluehost did, and still does, an attractively priced package that allows unlimited domains on one plan with plenty of bandwidth and disk capacity.
This is exactly what I needed. Plus, it has other useful features such as cron jobs, giving the ability to run admin scripts at scheduled times.
I chose Bluehost after reading many good things written by its customers. My experience of its service and server performance has been good, so a year after hosting Luxartis, I moved iansharpe.com and some other sites there too.
A useful tip if you choose Bluehost or a similar deal elsewhere: at the time of writing, the company offers a free domain name with new accounts. Use it to create an umbrella site that does nothing but host your other domains. The name doesn't matter because nobody is going to visit the parent site, but make sure it does not detract from the image and tone you wish to maintain for your public-facing domains.
An otherwise useless umbrella domain enables you to add or remove sites without running into the tricky situation where you want to close or sell the principal domain associated with the account. It is possible, but it means wiping all your sites and associated databases, waiting for tech support to link your account to another domain, then you have to restore everything.
If you sign up with Bluehost through that link, I get a worthwhile affiliate commission. Note that it's a non-Microsoft shop so is unsuitable if you want ASP or SQL Server rather than equivalents such as PHP and MySQL.