Customising server configuration at hostingbay.com.au

I'd noticed a few annoying quirks with my former hosting service, here's some of them, along with my solutions (when I've found them). This isn't any official help guide, just what I've observed to work with my own website.

No charset headers served with pages

It's a mandatory requirement that pages correctly identify what character set encoding is used with them, so that the browser can properly display the pages. It can guess what to do without the information, but can guess very wrongly at times.

In the absence of proper HTTP headers to identify the charset, you can write the information into a meta statement on each HTML page. But that's a hassle, has its own problems, and you can only do it with HTML files (e.g. plain text files would be served unidentified).

You can do the job properly by adding the following kind of directive to a .htaccess file in the appropriate directory (the server www root directory, or any sub-directories that use different encoding schemes), like this:

AddDefaultCharset us-ascii

Naturally, the charset that you specify must be the correct one—the one that you're actually using. Specifing the wrong one is even worse than not specifying anything at all. And specifying one with HTTP headers, but using a different one in the page, and trying to specify the one that you actually used with a meta statement in the HTML will not work.

For very plain typing us-ascii ought to be sufficient (typing that uses only the symbols displayed on the US IBM style keyboards), and only if you're actually using ASCII when you're creating the file. But if you've used any fancy characters on a Windows machine you'll probably need to specify windows-1252. Other computer systems probably use iso-8859-1 or utf-8.

No expiry headers are served with files

This can cause a problem for caching, as some things may decide to cache them indefinitely (meaning that changes to your pages don't get noticed on subsequent visits), others may decide never to cache them (meaning that each visit to a page, including navigating through the site in a single session, will refetch every file as it goes along, wasting your bandwidth).

Unfortunately the Apache module for setting expiry headers wasn't compiled into the server when I wanted to set them, so I had to pressure the host to do that for me on one website that I had hosted with them, and ended up having to have my site relocated to another server because they wouldn't install the module on it. I shouldn't have had to do that, they're a normal and expected aspect to web serving, and they should have already been a part of the webserver. Once I had the module available to me, the following set of rules in a .htaccess; file allowed me to set expiry headers on my pages:

ExpiresActive On

      ExpiresDefault "access plus 1 day"

      ExpiresByType image/gif "access plus 3 days"

      ExpiresByType image/jpeg "access plus 2 weeks"

      ExpiresByType image/png "access plus 3 days"

      ExpiresByType text/css "access plus 2 days"

      ExpiresByType text/html "access plus 2 days"

      ExpiresByType text/plain "access plus 2 days"

      ExpiresByType audio/x-pn-realaudio "access plus 6 months"

Notes:

If you don't have the module available to you, you'll get a server 500 error while trying to access anything on your site. So you'll have to abandon trying to set expiry headers, or pressure the host to provide you with the tools that are necessary for proper webserving.
The values that I've picked suit my purposes, the likelihood of someone revisting my pages within a certain time (how much caching helps or hinders them), how often I'm likely to modify pages, how rarely I'm likely to modify images, etc.

The hostname changes with some redirects

I advertised my (old) website as evpc.biz, rather than www.evpc.biz, as it's shorter (less to type, and it fits easier into printed material that doesn't have a lot of free space. Unfortunately, if someone types in an URI that should end with at trailing slash but don't type the slash, the server's configuration redirects them to the www. prefixed hostname with a trailing slash, rather than just appending the trailing slash and leaving the hostname at whatever it already was.

e.g. Asking for http://evpc.biz/computing doesn't redirect them to http://evpc.biz/computing/, as it should, but redirects them to: http://www.evpc.biz/computing/

This can happen if they type in an URI, or they follow a link on another page that someone else badly typed. While not a major disaster, it causes an inefficiency for caching (pages get cached twice by proxies, at each address), and confuses visitors and people linking to your website as to what address they should be using.

Unfortunately you don't have access to the configuration files to fix this problem properly (an educated guess is that it's due to the UseCanonicalName directive being set on along with the ServerName directive being set to the domain name prefixed by www.). But you can fix that with some rewriting rules written into a .htaccess file in your www root directory like this:

RewriteEngine On

      RewriteCond %{HTTP_HOST} ^www\.evpc\.biz$ [NC]

      RewriteRule ^(.*)$ http://evpc.biz/$1 [R=301,L]

Breaking that down into what's done by each line:

The rewriting engine is turned on.
It checks for requested hostnames of www.evpc.biz or WWW.EVPC.BIZ; (the ^ caret symbol means starting with, the backslashes prepending the dots escape them so that they're treated as dots rather than regex wildcards, the $ means ending with, and the [NC] means not case-sensitive).
It rewrites the URI, and redirects the browser to request the rewritten URI.

The ^(.*)$ wildcard operates on the hostname in the requested URI. The requested hostname (including the http:// protocol prefix) is stripped off the request and replaced with http://evpc.biz/, and the remainder of the URI (if there is any) is placed where the $1 variable is.

So a http://www.evpc.biz/computing/ request gets split into http://www.evpc.biz and /computing/, then the first part gets replaced with http://evpc.biz/ and the second part put onto the end of it.

The redirect specifies that this is a permanent condition (i.e. don't use the old URI ever again), with the R=301 flag. And the L flag indicates that this is the last rule related to this task.

Now the hostname will remain consistent (all requests with what you consider to be the wrong fully-qualified domain name will be redirected to what you want). Incidentally, you should be able to use the same notion in reverse (to ensure than your site is always referred to with the www. sub-domain prefix), like this:

RewriteEngine On

      RewriteCond %{HTTP_HOST} ^evpc\.biz$ [NC]

      RewriteRule ^(.*)$ http://www.evpc.biz/$1 [R=301,L]

Naturally, evpc and biz text in these example rules are only appropriate to my (old) website.