Server-side includes
If you have a website that’s completely static, you’ll see that there are limitations. One of these becomes apparent when your site’s page count reaches a certain limit – changes in your menu take an increasing amount of time to implement. Other problems manifest themselves when you need to vary your content according to a number of variables, such as the browser’s identity or the client’s IP address.

It’s possible to make your site almost completely virtual – database and script-driven using address lines such as ‘…/pagegen?sn=123…’ – but often, this is overkill if you just want to make life easier on a medium-sized site. Server-side includes (SSIs) offer a more secure, intermediate-level way of doing things that eliminates the hassle of manual coding on dozens of pages and makes content more dynamic.

Configuration
SSIs enable you to include static fragments of HTML code and execute scripts and other programs. In Apache’s ‘http.conf’ file, make sure you have the following line unremarked:

 AddModule mod_include.c 

To allow SSIs, the server needs to know how they’re different from normal pages. This is usually achieved using ‘.shtml’ as the extension for the SSI pages, but this has two disadvantages: it tells the user that they’re dynamic, so unwelcome visitors can use this information to more easily overload your server in a Distributed Denial Of Service attack (DDoS), and any pages that link to your dynamic pages will have to be altered so that the link has the ‘.shtml’ extension.

There’s an easier way to do this: simply make the dynamic HTML files executable. If you’re using a GUI, just call up Konqueror, right-click and select Properties | Permissions, then check the ‘exec’ box – this is the so-called ‘XBitHack’. If in ‘httpd.conf’, the lines should look like this:

<IfModule mod_include.c> 

XBitHack on
 
</IfModule>

There are several values for ‘XBitHack’, with ‘off’ being obvious. With it set to ‘on’, any file with the ‘user-execute’ bit set will be treated as a server-parsed HTML file, but if it’s set to ‘full’, the group-execute’ bit is also tested. If this is set, the last-modified date is sent. This enables clients and proxies to cache the result of the request – something you wouldn’t want if you were using a page counter. Windows doesn’t use an ‘exec’ bit in its file metadata, instead relying on file extensions, so Windows users are saddled with using ‘.shtml’.

While we’re looking at the ‘httpd. conf’ file, you can generate variables that, among other things, look at the browser that sent the request. This is especially useful if you’ve found that your HTML doesn’t render properly on some non-compliant browsers. Internet Explorer, to some extent, has its own version of HTML, though it’s not the only one. To generate a variable that your SSIs can look at, in your ‘httpd.conf’ file within section two, insert the following line:

 BrowserMatchNoCase MSIE IE 

This looks for the substring ‘MSIE’ in the user agent string sent to the server and, if it finds it, puts it in the variable ‘IE’. You can, of course, look for any substring for any reason you like: ‘Windows’, ‘Linux’, ‘Gecko’, ‘X11’ and ‘Macintosh’ for example, and place them into any variable you like. These can be looked at by the SSI code, as we’ll discover later.

HTML code
Once the server knows that it has to parse a particular HTML document, it needs to recognise its instructions. This is done using a special tag that the server recognises, which happens to be like a HTML comment:

<!--#echo var=”DATE_LOCAL” -->

This code snippet will look at the variable and replace all the code from the < to the > (inclusive) with the value of the variable ‘DATE_LOCAL’. In the final document sent out over the Internet, none of the SSI code is seen, nor anything that might indicate that it was ever there, thus making it invisible to the end-user. This one happens to be an environment variable, of which there are quite a few, but, if you remember from above, we can also create our own. If we want to have a particular piece of code for certain browsers and have created variables in the ‘httpd.conf’ file as above, we could look for it in the SSI code, like so:

<!--#if expr=”${IE}” --> 

 Explorer specific html
 
 <!--#elif expr=”${NETSC}” -->

 Netscape specific html 

 <!--#else --> 

 compliant html

  <!--#endif -->

In addition to making decisions about which pieces of browser-specific code should appear within a published document, you can include other files that contain code snippets. You can replace the menu in all the existing pages with a piece of code found in another file. Instead of the menu, you would have:

<!--#include file=”menu1.text” --> 
... rest of body text here

where ‘menu1.text’ is the name of a file (you can include the path) that contains the HTML code that replaces the SSI tag. Now, when you create a new page, just use the tag. When you want to change the menu, change ‘menu1.text’ and every page will change simultaneously. Of course, you’re not limited to menus. You can do headers, footers or any other piece of text – from changing email contact details to code that the user never even sees, such as that in forms – it’s like style sheets on steroids!

Perl code
If you’re running ‘mod_perl’, the server keeps Perl running all the time, so that when you need to run a Perl script, the loading delay is nonexistent. This means that if, instead of a static fragment of HTML code, you use some Perl code that generates the HTML, there’s no latency caused by loading Perl each time.

In the menu example above, our ‘menu1.text’ produces some static code that’s incorporated into the final HTML page. While this is neat in that it saves a great deal of time when editing pages, it has the disadvantage that your menu can refer to the current page with a live link – effectively, the user clicks on this and ends up with the same page.

However, using Perl, you can call a program instead of just some static text. You’ll remember from the Perl in HelpDesk Extra in the past that it uses ‘STDOUT’. We can test this from the command line and get the same results as the webserver when it calls it. In the SSI HTML page, we have a line like the following:

<!--#exec cgi=”/cgi-bin/menus/ menuset1.cgi”-->

Note that all your executable code should be in your CGI directory and that people shouldn’t be able to download anything from it – it’s only accessible by the server. If you start putting executables in other directories, you’ll end up in a mess. You should only ever do this if your security is so bad that making other holes doesn’t matter, or if no one visits your site (even on an intranet). In the script, you can see which page called it by looking at the environment:

 my $thispage = $ENV{DOCUMENT_ NAME}; 

Compare this line with the expected input and treat accordingly. The Perl script then assembles the required HTML, including menu expansions.