|Your Daily Source for Apache News and Information|
|Breaking News||Preferences||Contribute||Triggers||Link Us||Search||About|
This is the second of a three-article series on SSI. In the first article, we talked about how to enable SSI on your server and passed on some very basic examples. In this article, there will be more examples, and we'll talk about some somewhat more involved things that you might want to do with SSI. In the final article, we'll talk about the more advanced features of Apache SSI, including conditional statements.
In the last article, we mentioned that you could use SSI to inform the user when the document was most recently modified. However, the actual method for doing that was left somewhat in question. The following code, placed in your HTML document, will put such a time stamp on your page. Of course, you will have to have SSI correctly enabled, as discussed in the last article.
<!--#config timefmt="%A %B %d, %Y" --> This file last modified <!--#flastmod file="ssi.shtml" -->
Of course, you will need to replace the
ssi.shtml with the actual name of the file that you're referring to. This can be inconvenient if you're just looking for a generic piece of code that you can paste into any file, so you probably want to use the
LAST_MODIFIED variable instead:
<!--#config timefmt="%D" --> This file last modified <!--#echo var="LAST_MODIFIED" -->
For more details on the
timefmt format, go to your favorite search site and look for
ctime. The syntax is the same.
If you are managing any site that is more than a few pages, you may find that making changes to all those pages can be a real pain, particularly if you are trying to maintain some kind of standard look across all those pages.
Using an include file for a header and/or a footer can reduce the burden of these updates. You just have to make one footer file, and then include it into each page with the
include SSI command. The
include element can determine what file to include with either the
file attribute, or the
vitrual attribute. The
file attribute is a file path, relative to the current directory. That means that it cannot be an absolute file path (starting with /), nor can it contain ../ as part of that path. The
virtual attribute is probably more useful, and should specify a URL relative to the document being served. It can start with a /, but must be on the same server as the file being served.
<!--#include virtual="/footer.html" -->
I'll frequently combine the last two things, putting a
LAST_MODIFIED directive inside a footer file to be included. SSI directives can be contained in the included file, and includes can be nested - that is, the included file can include another file, and so on.
In addition to being able to
config the time format, you can also
config two other things.
Usually, when something goes wrong with your SSI directive, you get the message
[an error occurred while processing this directive]
If you want to change that message to something else, you can do so with the
errmsg attribute to the
<!--#config errmsg="[It appears that you don't know how to use SSI]" -->
Hopefully, end users will never see this message, because you will have resolved all the problems with your SSI directives before your site goes live. (Right?)
And you can
config the format in which file sizes are returned with the
sizefmt attribute. You can specify
bytes for a full count in bytes, or
abbrev for an abbreviated number in Kb or Mb, as appropriate.
I expect that I'll have an article some time in the coming months about using SSI with small CGI programs. For now, here's something else that you can do with the
exec element. You can actually have SSI execute a command using the shell (
/bin/sh, to be precise--or the DOS shell, if you're on Win32). The following, for example will give you a directory listing.
<pre> <!--#exec cmd="ls" --> </pre>
or, on Windows
<pre> <!--#exec cmd="dir" --> </pre>
You might notice some strange formatting with this directive on Windows, because the output from
dir contains the string "<
dir>" in it, which confuses browsers.
Note that this feature is exceedingly dangerous, as it will execute whatever code happens to be embedded in the
exec tag. If you have any situation where users can edit content on your web pages, such as with a guestbook, for example, make sure that you have this feature disabled. You can allow SSI, but not the
exec feature, with the
IncludesNOEXEC argument to the
In the next column, I'll talk about some of the more advanced features of SSI, in particular, the flow-control feature (conditional statements) and using variables.
Rich Bowen is the Director of Web Application Development at The Creative Group and the author of Apache Server Unleashed.
|About Triggers||Media Kit||Security||Triggers||Login|
All times are recorded in UTC.
Linux is a trademark of Linus Torvalds.
Powered by Linux 2.4, Apache 1.3, and PHP 4