About Server Side Includes

If you've ever tried to look after a large or complicated web site, you'll have an idea of just how easy it is to lose track of changes you've made when updating your site. Changing even a single link that appears in your main navigation area can be such a nightmare and very long winded. Sure you can use the extended find and replace of some tools or editor, but how can you be sure that it will replace all the links? What happens if you only want some of them changed?

A few site owners get around this by having menu pages that they use in a navigation frame of some sort. While this can certainly make it much easier to maintain the site, it can also put limitations on the design in that the menu would have to be called in a frame if it was to be shown in the same window as the rest of the site.

The best of both Worlds

This is where Server Side Includes (SSI) can help. They allow web site owners to keep their menu in a single file and have it displayed on a page without the need of a frame. All it takes is a single line of code to put the entire contents of one a file into another, which makes it possible to change all the pages of a site by editing a single file.

SSI can do more than just inserting fragments of HTML code into your pages, it can enter the results of scripts (for example a page counter) or give you the current time, tell you when a page was last updated or report back to the user the browser they are using. eXtended Server Side Includes (XSSI) can do even more, allowing you to set conditions to include different files, lets say for menus, depending on what browser you are using for example. Unfortunately XSSI is only limited to servers running Apache 1.2 or higher, and only then if they have been configured to do so.

Including files

It has to be said that you cannot just add a standard SSI command into your web page and expect it to work. SSI commands will only work on a server that will support them, and even then the server needs to know to expect them. Although it is possible for SSIs to be used in a normal HTML page (i.e. a page with a .html extension), a server configured this way will be slower as it will parse all HTML files for SSIs. It is much more common to have the server look for SSIs in files ending in .shtml, that way it doesn't waste time looking through normal html files for commands that just aren't there. More often than not, you will have to rename the pages using SSIs on your site to end in .shtml before you can get them to work.

SSIs can look rather like a HTML comment to anyone that is familiar with HTML but not SSI. Indeed, they have probably adopted this comment like syntax so that when servers did not understand the command and thus just left the command in the page, it would not interfere with the overall look of the page because the browser would treat it like an ordinary comment. Below is an example of what is probably the most common and widely supported of the SSI commands - the virtual include.

<!--#include virtual="menu.html" -->

The result of such a command would take the contents of the file menu.html (which in this case would be expected to be found in the same directory) and insert it at the point indicated by the comment. If the file was not found, it would print a message saying that there was an error, but it would still print out the rest of the original page.

All SSI commands have to start with <!--#. This lets any SSI aware server that a command follows. The command that follows immediately after the #, but before the next space, gives the server more information about that it is expected to do before it parses the rest of the page. In this case we want to include another file. The attribute of the command passes in the various files or arguments needed to complete the task, and as we want to include a file, the file location is passed to the virtual attribute.

The SSI include command can take one of two attributes.

  • virtual - passes a relative URL to be parsed by the server (i.e. it must not contain the http:// or domain part of the address). If you pass a URL that begins with a slash (/) then it will be relative to your home directory, otherwise it is relative to the current directory of the file.
  • file - allows you to specify the path to a file but is more limited than virtual because the file you want to include can only be in the current directory or the directories below that of the current file. virtual should be the preferred method of including files.