The HTTP protocol, which is used to retrieve documents (usually web pages) from the internet for display in a web browser, provides a number of standard error codes to indicate conditions or status relative to the process. The most widely known of these is the notorious code 404 - “File not found.” This error may occur for a number of reasons, but most commonly it indicates a broken link. Perhaps there is a typographical error in your html, or maybe the document was moved to a new location without the needed changes made to the referring link. What happens at this point is that the web browser asking for the missing document receives a special error message web page instead. This page is usually provided by the server, but may in some instances be generated by the browser. The error page may be rather generic, or it may be customized for the originating site.

Good question! Generally, the error pages provided by the server are adequate. On that basis, changing them isn't really required. However, such messages also tend to be dull and often rather cryptic. So, you might decide to create customized error messages for a variety of reasons.

For example:

• You may wish to create an error page which retains the look and feel of your own site. This may increase the comfort level of your viewers, since they won't necessarily feel like they have suddenly been whisked away from what they were viewing into some mysterious la-la land they'll have to crawl back from. Here is an example: Google's 404 page
• Since the error may have been caused by a fault in your site, you might want to direct the viewer to contact you about it, so that you can fix the problem.
• You may want to provide the viewer with additional information designed to help them resolve the issue themselves. This is useful if the problem is caused not by your site but by some mistake the user made in entering the URL, for example: Here is an example of that.
• And let's face it - most error pages are pretty dull. The 404 page in particular can be frustrating. So much so, in fact, that people have even written spiteful songs about it!

Now that you've decided you want to create a custom error page, you probably want to know how to do it. In fact, on SDF this turns out to be fairly easy. There are two basic steps involved:

1. Create the custom error pages that you want displayed.
2. Create (or modify) the file .htaccess in the root of your html directory structure.

Creating the custom error page itself is just like creating any other web page. Thus, it is somewhat beyond the scope of this article, as really you can do what you like. But if you are short of ideas, check out this site.

The key to making your custom error page work is in correctly informing the Apache web server that you have created a custom document and precisely indicating where that document is located. This is accomplished through an entry in the “.htaccess” file.

For the purposes of this discussion, we'll assume you already have your website set up. The root folder of your html directory structure is where you need to create “.htaccess,” or modify it if it already exists. If you are logged into an SDF shell account, you can generally get to this folder by entering this command:

cd ~/html

If you are using SDF's vhost services, you need to change to the directory for the website you are updating – it's probably a subdirectory of the html directory. Once in the folder, you can create or edit the file by entering:

pico .htaccess

Of course, while pico is the editor I like to use, you have your choice of several others and should feel free to use the one you like. You can also create or edit the file on your own system and upload it to SDF just as you would any other web document.

With the Apache web server, as used on SDF, “.htaccess” provides “a way to make configuration changes on a per-directory basis.” The complete use of this file is way beyond the scope of this article, but more information is available here.

In our scenario, you are probably creating a new file, so you'll be starting with a blank slate. You will need to create one line for each error page that you define. To indicate to the server that you want to use your own code 404 message, you'll need to add a line that is similar to this one:

.htaccess (vanity domain)

ErrorDocument 404 /404.html

“ErrorDocument” indicates that you are defining your own, “404” is the error code you are taking responsibility for, and /404.html is the name and location of your custom error document. Please note that the “/” in front of the file name indicates that 404.html may be found in the www root directory of the site that the server is masquerading as (a concept known as DOCUMENT_ROOT). Because the same physical computer might handle requests for multiple host names, the DOCUMENT_ROOT will be different for each SDF user's vanity domain. Whenever the original request makes use of a vanity domain, say, altego.freeshell.org, the custom error document in the html subdirectory of altego's $HOME will be loaded with the syntax above.

Some SDF users prefer to have their sites accessible via tilde-style URLs, like http://sdf.org/~altego . In this case the DOCUMENT_ROOT is no longer pointed at altego's html directory, but instead to the root html directory for SDF as a whole. Hence the location of the custom error page must be modified like so:

.htaccess (tilde-style URL)

ErrorDocument 404 /~altego/404.html

If you want the same custom error page to show up regardless of whether the visitor types the vanity domain or the tilde-style URL, it becomes much more difficult for a single .htaccess file to do the job. (RewriteRule directives prefaced by conditions on HTTP_HOST are the most obvious mechanism, but they have to be constructed very carefully in order to play nice with the UserDir settings in httpd.conf. Detailed instructions are beyond the scope of this tutorial.) Choosing just one of the above syntaxes for ~/html/.htaccess will send half your visitors to another nonexistent URL, accompanied by a warning from the SDF server about errors encountered when processing .htaccess!

Here are two possible ways to let your visitors use either style of URL, and still get your customized error page if they make a typo. They both involve duplication of the hosted content and (possibly manual) sync jobs. (To avoid these complications you might choose to: (a) disable the tilde-style URL — mkhomepg -d will remove or insert your $LOGNAME in the UserDir enabled … directive near the end of httpd.conf, (b) pare down the folder of the less-popular URL to a simple index.html that performs a redirect, or (c) try to hack together a workable combination of RewriteCond and RewriteRule directives that plays nicely with the UserDir settings in httpd.conf.)

• Option 1: Delete the public_html symlink created by mkhomepg -d, and make an actual folder of that name in your home directory. Give it and its parent directory loose enough permissions (go+rx should suffice) that the Apache “tilde user” can navigate to it. Periodically synchronize between public_html and html all content EXCEPT the .htaccess file, and make sure each folder's .htaccess gives the correct location relative to the DOCUMENT_ROOT (~/html/.htaccess contains ErrorDocument 404 /404.html, while ~/public_html/.htaccess looks like ErrorDocument 404 /~altego/404.html).
• Option 2: Upgrade your membership to MetaARPA and toggle vanity domain hosting to the MetaArray. The tilde-style URL will still resolve to the cluster, where ErrorDocument 404 /~altego/404.html will continue to work as before. The vanity domain will resolve to mab, where your content must be uploaded again into the appropriate directory, and the htaccess file modified to read ErrorDocument 404 /404.html. With MetaARPA membership you can set up a cronjob to keep the contents of your two html directories (cluster and MetaArray) in sync.

If you place the document in a subdirectory off your html root, you need to indicate that path in “.htaccess”. If you are creating custom pages for additional codes, simply add the appropriate lines in “.htaccess”.

After making your changes, it may be a good idea to reset the permissions on your website by entering the command:

mkhomepg -p

And that is pretty much all there is to it!

http://sdf.org/?tutorials/errorpage - traditional link (using RCS)