In this example, the defaults for htdocs and its subdirectories are set to allow clients to view the contents of a directory (as a page with a list of files, or something prettier), enable support for content negotiation, and permit the use of Unix inter-directory links. The next subdirective, AllowOverride, makes provision for overriding .htaccess files in subdirectories. The options here allow you to specify that nothing be changed (as in the example with AllowOverride None), or that anything be changed (AllowOverride Any). You can be more discriminating and authorize changes on access controls (AllowOverride Limit for IP based controls) or authorization (AllowOverride AuthConfig), as well as more subtle things like specifying that a directory’s contents should be handled in different ways with respect to language preferences. You should avoid changes to the AllowOverride setting. The final options in the example simply specify that by default all the files that you put in your htdocs directory and subdirectories are intended for general web access. These defaults can be replaced by other controls that you specify for particular directories. The next few elements in the httpd.conf file define options relating to files in user directories, set default values for the names of control and index files, and define the files and formats used for logging. A ScriptAlias directive is then used to define the standard cgi-bin directory, and another Directory directive group sets the access permissions for this directory. The next part of the file contains data used to generate HTML pages with fancy listings of directories (listings that incorporate little GIF images that distinguish subdirectories and different types of files). The following part of the configuration file has data relating to support for different file types and data used to support content negotiation by natural language type. The first directives are AddEncoding directives; these allow Apache to recognize files with .gz extensions as possibly deserving special handling. The files are returned with special HTTP content-type headers that identify the data as compressed files; some browsers can automatically decompress such files. The next part will have many AddLanguage and AddCharset directives; these are part of the ‘multiview’ support for content negotiation. The AddLanguage codes supply language-specific file extensions:

AddLanguage da .dk
   AddLanguage nl .nl
   AddLanguage fr .fr
   AddLanguage de .de

The same language codes are used by browsers and are specified in the HTTP request header as language preferences. In your browser, you can specify several languages and give them an order of preference. If, for example, Apache receives a request for the index.html resource in a directory that supports MultiViews (as specified by an Options directive that applies to that directory) and there is no index.html file, it will look for a file index.html.xx where the xx code best matches the language preferences in the request. If you look in your /local/ apache/htdocs directory, you should find a series of such files – index.html.de, index.html.en, index.html.fr, index.html.es – these are the different versions of the Apache welcome page for different European languages. (If you want to have a default file that can be returned when no preferred language version is available, you can have a version index.html.html.) You can even allow for dialects. Your browser probably has the preference options English- US, and English-United Kingdom (with codes en-us and en-gb). You can add some extra AddLanguage directives that map these dialect preferences to specialized file extensions:

AddLanguage en-us .yank
   AddLanguage en-gb .limey

The next part of the configuration file will have AddType directives for some extra mime types, and then AddHandler directives. The AddHandler directives specify special handling for files with the given extensions. If you included the appropriate modules, your Apache should have built-in handlers for CGI scripts, image map files, parsing of serverside includes, and generating server info and status. If you combine a Perl interpreter or PHP interpreter into your Apache, you will also have handlers for these. The directives in this part of the file include:

#AddHandler cgi-script .cgi
   #AddType text/html .shtml
   #AddHandler server-parsed .shtml

You will need to uncomment the first directive if you wish to allow CGI programs in directories other than just the cgi-bin directory. You will need to uncomment the other two directives if you wish to experiment with server-side includes. The next part of the file will include a Location directive:

#<Location /server-status>
   # SetHandler server-status
   # Order deny, allow
   # Deny from all
   # Allow from .your_domain.com
 #</Location>

(There is a similar commented-out server-info part.) These relate to support for the server monitoring facilities that might be needed by a webmaster.When enabled, these are accessed using URLs, e.g. http://localhost:8080/server-status. In this case, the URL does not define a path to a file resource; it is interpreted differently. These Location directives specify how such URL requests should be handled. You should uncomment these directives, and edit the Allow subdirective to reference a domain from where you wish to read the server data. The final part of the configuration file contains options for Apaches that are acting as proxy servers, and options supporting ‘virtual hosts’. If you are able to set up a DNS server, then it is worth playing with the virtual host controls. Virtual hosts allow your Apache to pretend to be several different machines – provided all the machine names are properly registered with the Domain Name Services. This is particularly useful for small Internet Service Providers who host sites for a few customers. Instead of URLs like http://www.small-isp.com.bv/~fashionshop and http://www.small-isp.com.bv/ ~sportshop, the clients can have URLs like http://www.fashion.com.bv/ and http:// www.sportshop.com.bv/. These all map to the same server, but (provided clients are using HTTP/1.1) the server can differentiate between the requests and really make it appear that there are multiple separate servers supporting the different clients. These features are documented at http://httpd.apache.org/docs/vhosts/index.html.

If Apache and Perl are not already installed on your system, download and install these systems. Windows users have the choice of installing the complete Cygwin system or just the Apache for Windows system and ActivePerl. Cygwin gives Windows users a Unix shell and comes complete with versions of Apache and a Perl. Apache forWindows and up-to-date Apaches for Linux/ Unix can be obtained from the Apache site. The Windows version of a Perl interpreter recommended for the exercises is that available for download. This download is a self-installing archive; by default, it will install a Perl system in C:\Perl. The following practical configuration exercise requires that you create subdirectories of Apache’s htdocs directory with differing permissions. Some directories are to allow CGI scripts or SSI files. Other directories are to allow experimentation with access controls, adding support for server information, and possibly trying to use content negotiation. The exercise involves changing the httpd.conf configuration file. Each time you change this file, you should check that your revised version is legal; there is a configtest option for the apachectl script that verifies your configuration file. A couple of parts of this exercise may prove impractical in your environment. For example, the testing of IP address-based access restrictions requires that you leave your server running, and connected live to the Internet, while you go and login on some other system from where you can try to submit requests; this may be hard to organize. Another problem might be using server-side includes to execute shell scripts; these will not work in a purely Windows environment. The examples assume that your Apache root directory is /local/apache; you should modify directory names as necessary.

(1) Configure your Apache:

Unix/Linux/Cygwin users should be able to use the configure script provided with Apache:

Use the --help option to determine defaults.

Pick a directory where your installed Apache is to be located.

Run the .configure script giving it arguments identifying the installation directory, enabling support for server-status and server-info options, and removing one of the lesser used default options, such as imap.

Run make and make install to build and install your Apache. Windows Apache users should simply edit the httpd.conf file, enabling the load modules for status information etc. (and setting a ServerName if this is variable is unset in the file and there is no DNS service available on a local network containing your machine).

(2) Test run your Apache (Unix/Linux/Cygwin installations use the apachectl control script, apachectl -start; Windows users have an option in the Start menu. Run a browser pointing at http://localhost:8080/ (or just http://localhost/ for a Windows configurations); if ‘localhost’ does not work, try specifying 127.0.0.1. By default, your Apache should return a welcome page identifying itself as an Apache server and pointing out that if this page is received it means that the webmaster (you) has not fully configured the web site. (The default setup has the Apache root directory supporting multiviews; if a client browser is configured with language preferences, this welcome page is returned in the closest match available from the set of pages provided by Apache.)

If you don’t get a welcome page, go back and repeat stage 1, and do it right. Note that default welcome pages, such as those provided by Apache and by IIS, have been exploited by hackers. Minor wording changes in the welcome page are sufficient to identify the particular version of the software installed on a server host machine; hacker manuals list the weaknesses of the different versions. Hackers run searches on Google, HotBot, AltaVista etc. looking for sites with these welcome pages (indicating a machine on the Internet that has a web server that has started by default, possibly without the machine’s owner even being aware that the server program exists). Once identified, these machines are usurped. Close down your Apache server.

(3) Remove the Apache-supplied contents of the /local/apache/htdocs directory and all its subdirectories. Create the following subdirectories in htdocs: multiv, progs, over, access.

multiv

This directory will be used for pages that illustrate support for content negotiation. It will containmultiple copies of the same resource; selections are on the basis of language codes.

progs

This directory will contain some content files and a CGI program (i.e. a CGI program located in a directory other than the standard cgi-bin).

over

A Directory directive in your httpd.conf file should permit this directory to have a .htaccess file that will override default access controls and execution options. The directory will contain files that use server-side includes. Access is limited to members of a subgroup of the users that you have defined in a password file.

access

This directory will contain resources with controlled access based on a combination of IP address and password checking.

(4) Create a subdirectory for password and group files in your /local/apache directory. Use Apache’s password utility program to create a password file with names and passwords for half a dozen users. Create a groups file with two groups containing distinct subsets of your users. Password and groups files should have names starting with .ht (so that the httpd.conf file directive denying access applies to these files). Alternatively, learn how to use the dbm module and the Apache supplied support program that places usernames and passwords in a dbm database.

(5) Create the following content files, form files, and CGI programs:

Welcome.html in htdocs: this should be a simple ‘Welcome to my Apache’ page.

Form and CGI program in htdocs and cgi-bin; install some data entry forms in / local/apache/htdocs and matching CGI programs in /local/apache/cgi-bin. Initial example programs should be in C/C++; later examples will use Perl. The little C++ framework that is used in those examples can be used to build new CGI programs. Alternatively, you can obtain the W3C approved C code library and implement a CGI program using this code.