In this issue

Apache Site: www.apache.org
Release: 1.2.4 (Released 22nd August 1997) (local download sites)
Beta: None
Alpha: 1.3a1 (Released 23rd July 1997) (local download sites)

Bugs fixed in 1.3:

• Added support for ReliantUNIX

Apache 1.2.4 is the current stable release. Users of Apache 1.2.3 and earlier should upgrade to this version. The next release will be 1.3. The first beta of 1.3 will be available shortly. An alpha test release of 1.3 is available now for compilation and testing on Windows 95 and NT systems.

Patches for bugs in Apache 1.2.4 may be made available in the apply to 1.2.4 directory on the Apache site. Some new features and other unofficial patches are available in the 1.2 patches directory. For details of all previously reported bugs, see the Apache bug database and known bugs pages. Also many common configuration questions are answered in the Apache FAQ.

The module which is used to authenticate users against an mSQL database will no longer be distributed as part of Apache. This is because there are many other databases now available and supporting just one in the distribution is not appropriate. Modules for authentication against various databases are available from the module registry.

Installing Apache on Unix is not as easy as it could be. For a start, there is no "make install" capability, so files have to be moved around by hand (or in the traditional NCSA method of installation, run from the same directory where Apache is compiled). Also the distributed configuration files need editing by hand to insert the correct directories and paths such as ServerRoot, DocumentRoot and <Directory> sections.

From 1.3 onwards, this will be simplified. There will be a "make install" facility which will create the correct directory tree, install httpd, and put the correct paths into the configuration files. Of course the configuration files should still be edited by hand to customise for the site and to ensure that directory restrictions apply to the correct directories.

Under Windows there is already a "make install" equivalent for use with source distributions (actually "nmake -f makefile.nt installr"). Future releases will also be available in binary (pre-compiled) form with a complete GUI installation process.

Here are a selection of configuration errors and problems which have been reported as bugs in Apache recently. In many of these cases (as with many bug reports) the problems come from incorrect configuration of Apache or CGI scripts, rather than the Apache code.

A typical way to limit resources to particular clients or users is to use a <Limit> section, such as this

  <Limit GET POST>
  ...
  access restriction directives such as require or allow
  ...
  </Limit>

The effect of the <Limit> section is to limit the restriction to only the listed methods - GET and POST in this example. This means that other methods, such as PUT, are not subject to the restriction. This can be a security problem. The correct solution is to remove the <Limit> and </Limit> lines, which will make the restriction apply to all request methods.

Note that while GET, POST and PUT are the commonly used methods today (along with HEAD which is treated like GET within Apache) other methods can be defined and used at any time. The above example configuration would allow these additional methods through as well. This is particularly important if the restricted area includes CGI scripts which do not bother to check the method with which they are called.

CGI scripts should check the request method which they were invoked with. For example, if a CGI script is expected to be called by the GET method, it should check that the REQUEST_METHOD environment variable contains the word "GET" or "HEAD" and if not return an appropriate error status (such as 501 Method not implemented). If this is not done, the script could be invoked with other methods and either send the wrong data (e.g. invoked with POST and sent data by standard input), or access restrictions could be evaded as in the previous section.

CGIs should also check for the HEAD method, and if so do not need to output the body of the response, only the headers. However if the CGI does output the body, Apache will ignore it and only send the headers to the client. The request method names are case sensitive, so the method "get" is not the same as the method "GET" (the latter being the only one which is currently defined by HTTP).

The allow and deny directives are used to restrict access by the caller's hostname or IP address. When using hostnames, the text given on these directives matches the end of the callers hostname. So for example, the lines

  order deny,allow
  deny from all
  allow from apache.org

would allow requests from apache.org as expected, but also allow from www.apache.org and all other hosts with *.apache.org addresses. It would even allow access to people from domains unrelated to apache.org, such as otherapache.org. This may not be obvious from the directive, which appears to just restrict the host "apache.org". At the present time there is no way to specify that just the hostname "apache.org" should be restricted, and not its sub-domains. But it is possible to prevent domains such as otherapache.org by using

  allow from .apache.org

Of course if a restriction to a single host is required it can be implemented by listing the full IP address or addresses of the host instead of the hostname. Using IP addresses also reduces the number of DNS lookups performed so should be more efficient.

Apache works fine on systems that mount disks via NFS. However there are some files which Apache uses which should not be stored on NFS mounts. The most important is the "lock file" which is used by Apache to efficiently let multiple processes access the same network socket. This default location for this file is the "logs" directory under the server root, unless changed by the LockFile directive. If the server root or the logs directory is NFS mounted, the location of the lock file must be changed. A directory such as /tmp or /var/tmp is often a good location. This lock file should not be NFS mounted because many implementations of NFS do not lock files properly.

While the lock file is the only file which should never be stored on a NFS mounted disk, for best performance other files which are heavily used by Apache should also be local rather than remote. For example, the log files (usually stored in the logs directory under the server root) are best stored on a local disk. Also the files accessed by browsers (under the document root and often from home directories) should be local for the better performance.

Apache is used in an operating system comparison to find the best OS to use as a web server. The article OS Holy Wars in Internet Week (1 Sept 1997) compares BSDI, FreeBSD, RedHat Linux and Windows NT. All apart from the latter used Apache as the web server during the tests. They report that Linux (with Apache) had the best performance and "soundly licked" the other systems, although the tests are slightly limited because they did not tune any operating systems except when the load tests generated errors.

Refreshingly this article treats free operating systems and software on an equal basis as commercial software and gives a good review of the history and on-going development of FreeBSD and Linux.