In this issue

The current stable version of Apache is now 1.2.4. The last generally available release was 1.2.1. The latest version fixes a number of bugs in 1.2.1 and works around a problem in Solaris 2.5.1 which meant it could fail after a HUP.

The next released version was going to be 1.2.2 but this had a last minute change after the version number had already been set, so the release was incremented to 1.2.3. This was actually released earlier this week on Tuesday 19th August. Unfortunately a bug was found (see below) which affected the proxy module. A new version was created, called 1.2.4, which incorporated a fix for this bug and a small outstanding change to the configuration for AIX 4.2 systems. Version 1.2.4 is now the current release of Apache.

Anyone running 1.2.1 or earlier is recommended to upgrade to 1.2.4. If you are using the proxy module with 1.2.3 you should also upgrade to 1.2.4.

The Apache versions 1.2.* are maintenance releases of Apache 1.2 and do not include any new features. New features are being added to Apache 1.3 which will be available for beta in the near future. There is already an alpha of 1.3 available which is primarily intended for testing on Windows 95 and Windows NT systems.

Release: 1.2.4 (Released 22nd August 1997) (local download sites)
Beta: None
Alpha: 1.3a1 (Released 23rd July 1997) (local download sites)

• The proxy sends on the full URI (for example, http://www.apache.org/) to the origin server, instead of just the URI path (e.g. /).
• Does not compile on AIX 4.2 because of a missing library.

Patches to Apache 1.2 bugs will 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 page. Many common configuration questions are answered in the Apache FAQ.

Apache 1.3 will come with a new module which can create a unique identifier for every request. This identifier can be used in log files or passed on to SSI or CGI programs. It could be used to match up the actions of (for example) a CGI program with the logged request, to match up log records from different files, or be passed back into subsequent requests via URLs to maintain a form of state.

The module is called mod_unique_id and is not enabled by default. The unique identifier it creates for each request is stored in the environment variable UNIQUE_ID which can be logged and which will be passed on to any sub-processes. Note that the unique identifier is not a number - it can consist numbers, letters and the characters "@" and "-". These characters where chosen to make it safe to use in URLs.

The negotiation module can be used to auto-select between various versions of the same resource. For example, if a gif, jpeg and png version of a picture are available, a request for the picture without any extension can automatically pick the best one based on the browser's ability. (In theory at least - in practice many browsers do not send the correct information).

Since the result of the request can be one of three different files, Apache sends back header information to ensure that the client does not cache the response. This is to prevent, for example, a proxy caching the response then sending it out to clients who should get a different version of the file. This is the correct behaviour for negotiation with HTTP/1.0 clients (HTTP/1.1 includes ways to allow for caching of negotiated responses, and Apache fully implements HTTP/1.1, so none of this section applies to HTTP/1.1 requests).

However many sites use the negotiation module to allow requests to be made without the file extension. For example, if the file index.html exists and negotiation is turned on, a request for "index" will get the "index.html" file. This is very useful since at any time the index.html file can be replaced with one in a different format - say a cgi called index.cgi or a parsed file called index.shtml - without affecting the URLs that people are already using. But there is a problem - the responses in this case are not cached, for the reasons given above, even though since there is only a single file to return it is quite safe to allow clients to cache the response.

Apache 1.3 will probably be updated to allow negotiated responses to be cached where there is only one choice available.

There have been a number of changes recently to streamline the way Apache sends out simple (static) pages. Changes here can have a significant impact on heavily loaded sites which serve lots of (often small) static files. The aim is two reduce the number of operating system calls to a minimum, since they tend to add a large overhead to any process. Apache 1.3 will be able to serve a page in 22 system calls with the latest set of performance changes. For comparison, a request for a static page in 1.2 requires 44 system calls.

This change basically removes the overhead required to set and clear timeouts while handling a request. The child process normally has to set a timeout using the alarm() system call in case (for example) reading the request takes too long. In Apache 1.3 the checking for timeouts is performed by the parent process, not the child. What happens is the child notes its current state in the shared "scoreboard" every time the state changes. The parent process checks the state of every child every second and any which have been in a particular state too long get sent an ALARM signal. So the timeouts remain exactly as they were before but the child has to do much less work. The "scoreboard" is an area of shared memory which all child processes and the parent process have access to.

A possible enhancement in Apache 1.3 will be the ability to include directives from additional configuration files, as well as the standard httpd.conf and optional srm.conf and access.conf.

A new phase has been added to the Apache module API for version 1.3. This is called the "post read request" phase and is called immediately after the request has been read (and during an internal redirect). It is not run when doing a sub-request lookup. This phase is intended for modules which need to perform processing after the request has been received but before anything else is done, for example, setting environment variables based on the request contents.

Module authors may also remember that the "init module" phase gets run twice at startup. From 1.3 onwards the init module phase will only get called once at startup, after the error log files have been opened.

The World Wide Web Consortium (W3C), which oversees the evolution of Web standards, now uses Apache at its main site