Typically, you'd use a server-side include to un-clutter your web source files, and to make them generally more readable and updatable. They are used to perform operations in the parsing phase of website delivery, like cutting and pasting information from one file into another as it is being sent to a client. More advanced server-side include functions have been superceded today by perl, vbscript, jscript, or whatever your scripting host of choice is.

The layout of most common web pages today are very complex, and hard to look at (or at least eyeball), without some sort of aid. Server-side includes typically help you to make code more manageable, and compact, while encouraging basic code reuse principles A good example of a server-side include would be the menu for a website. This would be something that individual pages would not need in their main code for each page. Using these, you can create a web page "template" of sort with which to more easily manipulate large blocks of text. Server-side includes were the first in a series of web page programmatic improvements to get to where we are today in the functional web.

Typically, you must denote a page to the web server as being server-parsed. The most typical extensions for a server-side include parsed web page are .shtm, and .shtml. In Apache, you would set these up by putting the following lines in your conf (/etc/httpd/conf/httpd.conf on my apache dev system) file if it is not there already:

AddType text/html .shtml
AddHandler server-parsed .shtml

This will tell Apache that your file is server-parsed first, and to read it before it outputs it.

For an IIS system, you would typically, use Internet Services Manager to accomplish this. In ISM, there is a listing of file types that it should parse before outputting to the connected client. In IIS 5.0, .asp, .htm, and all the other associated files types are parsed by default (because IIS performs caching of code, so it makes sense anyway). Either way the effect is about the same.

A typical Server-Side Include looks something like:

<!-- #include file="filename.asp" --> or
<!-- #include virtual="filename.asp" -->

Notice that it is contained in an HTML comment. This is the structure of the SSI directive (as the commands are called). The above two are the most common that you will see these days; the only difference in the above include directives is how to treat the path algorithm between the two (ShadowNode explains them all above, in his WU).

A final note that should be mentioned about the #include directive is that you should always register the type of your include file with the web server as a parsed file, or already used a parsed extension, that way it cannot be called directly. (This was a problem with IIS 4.0, however .inc is parsed by default on 5.0; Microsoft issued a security bulletin on this) If I have a library file is named mylib.inc, and .inc is not registered with IIS or Apache, it will dump the file (and all the back end code) out, and the world will see your source code and internal structure, something that can be potentially damaging to a web site. Be careful with these server-side includes. They can be quite a powerful and timesaving tool, if used correcly, and knowledgably.