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.
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), 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”.
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 own site relocated to another server because they wouldn't install the module on it. 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"
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.
I advertised my website as “http://evpc.biz/”, rather than “http://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 your 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]
The rewriting engine is turned on.
It checks for requested hostnames of “www.evpc.biz” or “WWW.EVPC.BIZ” (the “^” 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.
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 website.