Server Side Includes (SSI)

As you gain experience with HTML, you will discover directives that allow you to instruct the web server to perform more advanced actions with your files. For example, you might want to print a message at the bottom or the top of your page indicating when it was last modified.

To get the system to do this, you need to include a directive specifying that action. Such a directive is in the form of a "Server-Side Include" command. This document explains how to use some of these commands.

  1. The CS Department's web servers support all of Apache's Server-Side Include commands.
  2. The most popular commands are listed below and described more fully later in this section.
    #exec cgi
    #exec cmd
  3. The server looks for SSI commands within ".html" and ".shtml" files only. Traditionally, SSI commands are in files with the ".shtml" extension, but this is not a requirement.
  4. SSI commands are embedded within an HTML comment.
    <!--#include file = "filename" --> 

    Be sure to leave one or more spaces before the closing "-->" to prevent it from being mistaken for part of the parameter value. It is also a good idea to enclose the parameter value within quotation marks.
  5. " #flastmod" provides a simple mechanism to show the date and time that a particular web page was updated. It is normally used with the name of the current web page as a file argument. For example the Last Modified information that appears at the bottom of this web page was produced by:
    <BR>Last Modified:
    <!--#flastmod file="ssi.html" -->
    The path to the file argument is relative to the directory containing the current page.
  6. "#include" works like a C/C++ include statement and inserts the contents of another file or URL into the current web page.
    <!--#include file="path_to_file" -->
    <!--#include virtual="URL_to_file" -->
    The path to a file is always relative to the directory containing the current page. It cannot contain a backwards reference "../".
    The URL is relative to the current page unless it begins with a slash "/", in which case it may be any URL on this server. It may also specify a query string to be passed to the included page.

    Included files are not scanned for Server-Side Includes.
  7. " #exec cgi" and "#exec cmd" are used to run a Perl script or any executable program or script respectively. The standard output stream (stdout) from your command or program is inserted into the current web page, at the point where the "#exec" SSI command was found. "#exec cmd" is more robust and is the preferred form of this SSI command.
    <!--#exec cmd="./MyProgram optional-arguments" -->
    < !--#exec cmd="/bin/date +%d/%m/%Y" --> 

    • There is no default path available to this command so a full execution path must be specified.
    • The first example runs an executable called "MyProgram" that is located in the same directory as the current web page. This file can be any type of executable, i.e. a Perl or Shell script, or a compiled program.
    • The second example executes the system date command and formats the current date as 09/07/2004 .
    • The command is executed using the same user ID and group ID as the Web Server. Currently, both of these ID's are the name "nobody".

      This is an especially bad option - see the notes in the testing section, dealing with testing this type of executable. The comments under SSI executables that run as the web server's user ID are only a slight exaggeration. You are strongly encouraged to make all SSI executables run under your own user ID. This is known as running a program setuid.

      See the man page perlsec which describes how to write a simple C program that can act as a setuid wrapper for Perl. A very simple modification to this code can make it act as a setuid wrapper for shell scripts or even system programs.
    • Since this SSI command is often used to produce a Hit Counter or an Access Log, any file(s) that it writes to must be writable by the Web Server. The safest method of doing this is to "chmod 4755 program_name", which makes your program run setuid, under your user ID. However, this is not permitted for Script files. For Script's (including Perl Scripts) you could use "chmod 666" for the data file(s) that the Script will write to. This is extremely dangerous, it allows anyone to write to your files! See the previous note about creating a setuid wrapper.
  8. Be sure to read the Testing section !

Go to and search for a version of the manual that matches our web servers. You can determine the current version by logging in to Hercules and using "apachectl -v".