Server Side Includes (SSI) are a method of integrating directives or commands into HTML documents. The directives should be placed inside an HTML comment field. When a client asks a properly configured Web server to send it a document that contains Server Side Includes, the Web server processes the directives and includes their output in what is sent to the client.

Two brief examples:

#include virtual="standard-page-footer.html"
#exec cgi="generate-page-footer.pl"

A set of tokens in an html file, used stitch various pieces data into the file when accessed (such as the time, a filesize, the results of a script, et cetera).

The available tags are:
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.
Server side includes (commonly known by their abbreviation SSI) are one of the dirty hacks committed by the NCSA httpd team, inherited by Apache.

They provide very useful functionality but do so without any concern for safety.

With SSIs you basically have holes in your code (usually, but not necessarily, HTML text) that may be filled with arbitrary text at runtime. The holes may appear in arbitrary places within your text: this already makes it hard to guarantee syntactically well-formed output. With the exec or cgi directives, the range of possible resulting content isn't even predictable from the text of the directive: it entirely depends on what the called executable happens to do.

So while SSI allows HTML to be composed from smaller pieces, and to be shared between documents, it doesn't really support doing this in a structured way. A better approach would allow static syntax checking of the output formats. It must be said that HTML doesn't really lend itself well to this kind of composition.

This is one of the reasons XML is fundamentally superior. With XML you can share and combine document fragments in a controlled way.

Log in or registerto write something here or to contact authors.