I did too, and this is what happened.
The 4U shared hosting plan I was on with Tera-Byte in 2006 left acres of unused disk space. As for bandwidth, iansharpe.com was but a gushing stream in the bottom of a deep, wide riverbed.
I was working on an e-commerce venture selling premium-quality sable brushes at www.luxartis.biz. The business has now been sold to another party.
Luxartis needed server-side scripting and a database. PHP and MySQL were what I was most familiar with. I didn't expect hordes of visitors to start with.
What could be more natural, then, than to host it alongside iansharpe.com 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 are 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, chosen for no better reason than I'd heard it is a reasonable outfit and the price looked good. GoDaddy has been fine and subsequently used for more registrations.
To begin with, I set luxartis.biz to forward to its subdomain. Doing this alone 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, nearly obsolete for the purpose of search engine indexing, but even so, sometimes it is used, and other meta tags are still useful.
GoDaddy enables 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. Even so, 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 is a commercial operation. Penny-pinching sub-optimal kludges acceptable on a personal site may lose business when image, visitor flow and usability assume prime importance.
What I really need 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 Tera-Byte hosting plan. One IP address is all you get. If I rent a whole or virtual server from Tera-Byte, I can buy pairs of additional IP addresses for it. But I don'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, the 4U 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 Tera-Byte's techies deliberately barred this too, or could it be turned on if I asked nicely?
Time to fire off a support request to Tera-Byte. I thought I knew the answer but had to ask anyway.
I'll give Tera-Byte its due. Tech support questions have always been answered quickly and competently, even at weekends. That doesn't mean I'm always going to like the answers.
The official word was that this feature was unsupported in my hosting plan.
That was the end of the road for the clean co-hosting with Tera-Byte. 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 I shop round, it's more than I'm paying now and I'd be responsible for server administration at a level I don'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 in May 2006, so I needed decent hosting. I had also decided that I shouldn't be wasting time on nasty workarounds.
BlueHost does an attractively priced package that allows unlimited domains on one plan with plenty of bandwidth and disk capacity.
This is exactly what I need. Plus, it has other useful features that Tera-Byte was still not offering in early 2007. For example, cron jobs give 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 sitation 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.