Most of this text is concerned with elaborate ways of creating dynamic pages through Perl scripts, PHP scripts, Java servlets and Java Server Pages. The basic Apache setup provides support for CGI programs (based on Perl scripts and alternatives), and for the fairly limited ‘server-side includes’ (SSI) mechanism. The relevant modules (mod_env, mod_cgi and mod_include) are included in the default Apache build. It is best to limit the number of directories that contain executable code that can generate dynamic pages. The default configuration, as specified in the httpd.conf file, permits CGI programs only in the /local/apache/cgi-bin directory, and there are no directories that allow for SSI files. These defaults are likely to be too restrictive. If you want to relax the constraints a little, you can add extra Directory directives to the main httpd.conf file. These extra Directory directives must contain control options that permit execution of CGI scripts in a directory or SSI processing of files from a directory. Server-side includes are flagged by special tags in an HTML file, tags such as:

<!--#flastmod ... -->
   <!--#include ... --->
   <!--#exec ... --->

Apache must read the files, check the HTML, and find and process the SSI tags. This adds significantly to the cost of normal retrieval of an HTML file. It is best to use a distinct file extension to flag those files for which SSI processing is required. The conventional extension is .shtml; the server has to be configured to handle such files appropriately. The httpd.conf configuration file will need to include the directives:

AddType text/html .shtml
 AddHandler server-parsed .shtml

The first directive sets the content type that is to be used in the HTTP header when the texts of the processed files are returned to the client. The second directive enables the actual parsing by the web server. SSI tags like flastmod or size are harmless, as is the inclusion of other HTML files via the include tag. The execution of code, as allowed by an exec tag or by an include tag specifying output from a CGI-script, can be risky. The code may be any shell script; if your site is not properly secured, there are ways that hackers can change the script that will be executed from an SSI file. The Apache options that permit the use of SSI do allow you to distinguish between simple uses and uses that involve execution of code. If you want to allow files in a directory to be SSI-parsed, you will need a Directory directive that identifies the directory and the level of use that you permit:

<Directory /local/apache/htdocs/allow_SSI_here>
   Options +Includes
   ...
 </Directory>
 or
 <Directory /local/apache/htdocs/allow_SSI_here>
 Options +IncludesNOEXEC
 ...
 </Directory>

As an example of server-side includes, you could create a simple counter for use in a web page (this script is for Linux or Unix). This would involve a shell script such as the following:

Val=`cat counter`
   NewVal=`expr $Val + 1`
   echo $NewVal > counter
 echo $NewVal

This code would have to be saved in a file Count.sh; the file would have to be made executable, and a file for the counter would have to be created with a data line with the initial value 0. The counter could then be invoked from HTML code in a .shtml file as follows:

...
   <hr>
   This page has been accessed
   <!--#exec cmd "Count.sh" -->
   times.

(All the files would need to be in the same directory.) The httpd.conf file contains a ScriptAlias directive that identifies the location of your default cgi-bin directory. A ScriptAlias directive also arranges that Apache will treat all files in the specified directory as executables, so Apache will try to fork-exec these files rather than simply return them to the client. If you want CGI programs in other directories, you will need to use a file extension that will identify the CGI programs:

AddHandler cgi-script .cgi

You might want to use .cgi for compiled C/C++ programs and .pl for Perl scripts, in which case you could have:

AddHandler cgi-script .cgi .pl

You will also need Directory directives that identify those directories that may contain executable scripts, for example:

<Directory /local/apache/htdocs/filesAndCGIs>
   Options +ExecCGI
 </Directory>

Apache should then run any .cgi files in this directory (and .pl files if you specified both). The web server has to launch a new process for a CGI program (or for an SSI exec tag). The new process is created via fork then exec calls on Linux/Unix. The new process inherits the same user-id and group-id as the creating process; consequently, it will normally have user-id ‘nobody’. Often you will want these processes to run with different user-ids. One approach relies on a set-user-id file system. The Apache system incorporates a safer mechanism via its SUExec extensions. The SUExec mechanism imposes a series of safety checks before it changes the user-id associated with a child CGI process. These checks are intended to prevent anyone from sneakily getting a program to run with user-id = "root", and to avoid running any script or executable that might have been changed by someone other than official owner. You have to be a system’s administrator with root access to set up the SUExec extensions. If you run your own Linux system, you could try this as an advanced exercise in Apache administration.

ForWindows users, installation of Apache is trivial. You download your Apache as an compressed executable archive file (from http://httpd.apache.org/). This file can be run; it will create the Apache server and its required files, and add shortcuts to your Start menu. Typically, your Apache will be installed in C:\Program Files\Apache Group\Apache. This directory has subdirectories \bin (execu

s and scripts), \conf (configuration files), \logs (log files), \cgi-bin (standard directory for your CGI programs) and \htdocs (the standard directory for documents). The htdocs directory should contain several example files, but the cgi-bin directory will probably be empty. You are likely to have to make one change to the \conf\httpd.conf file; this file can be opened with any text editor. The file probably does not have a value specified for the ServerName parameter; you may need to define something like ServerName localhost (or maybe ServerName 127.0.0.1). (If nothing is defined, Apache will try to find a DNS server that can tell it the correct server name based on your machine’s IP address and the DNS records; this attempt will fail if you are not linked to a DNS server, so Apache won’t start.) After editing httpd.conf, your basic Windows Apache should be ready to run. You can start it from the Start menu, and then start a browser and use this browser to connect to your localhost server.

Linux/Unix users have rather more work to do, but benefit by getting a better understanding of the Apache system. Linux/Unix users will need about 20 Mbyte of disk space for a final Apache deployment directory (/local/apache), and rather more space for a directory where Apache is compiled and linked (/home/me/apache_1.3.27). You download a tar.gzip version of the server (1.3.27 or higher); decompress (gunzip) this archive, and extract the files (tar -xf ...). This process should create a subdirectory apache_1.3.27 in your home directory. This is effectively your master copy. Much of the material from this directory will be duplicated in your final deployment directory. The apache directory contains bin, cgi-bin, conf, htdocs, icons, logs, src and other subdirectories. The cgi-bin subdirectory contains a few small example programs using shell scripting and Perl. The htdocs directory contains a number of examples, including one used to illustrate content negotiation based on a client’s language preferences. It also contains the Apache documentation in the /manual subdirectory.