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.