In this issue

1.0.5 is the current stable public release (it is 1.0.3 plus a security 'fix'). The beta test version, 1.1b, is still at version 2.

All versions: Apache fails to restart

In some circumstances, the Apache parent process dies when being sent a HUP (restart) signal. It leaves the children around, so cannot be restarted until they have died (or been killed). The code which handles signals has been updated to fix this problem in the next beta release.

Proxy module

The proxy module is still very experimental, and a number of bugs and problems have been reported. There will probably be a major clean-up or rewrite of the proxy module in the future. For now, bugs with the proxy module are taking a lower priority to other bugs, so use the proxy module at your own risk.

ASIS local redirects

If an ASIS document (a document containing all its own headers, see mod_asis) contains a Location: header, Apache passes it on "as is" (which is the reason for using asis documents after all). However this can lead to non-fully qualified Location: headers being returned. While the asis document author could be required to put only full URLs here, it would be nice if Apache could intercept the Location: header and if it is a local, relative URL, process it immediately. Apache will now do this from the next version.

Content Negotiation

There has been some discussion of how the content negotiation features in Apache can be modified to both meet the requirements of HTTP 1.1, and to provide reasonable defaults for current browsers. Content negotiation is where the browser can ask for particular representations of data, often giving some sort of desirability for each. For example, a browser might prefer to receive JPEG images, but it can also handle GIF, so it would ask for JPEG with a higher desirability than GIF. So the browser might send an "Accept:" header like this:

Accept: image/gif:q=0.5, image/jpeg:q=0.9

This request JPEGs with preference of 90%, and GIF with a preference of 50% (the q= part on the request gives a measure of desirability of the content type, in the range 0.000 to 1.000). If neither are available, an error should be returned. However, most browsers prefer something rather than nothing, so they routinely add a wildcard request of */* (meaning any type) as well. The problem is often they give all these requests the same quality value, so the server might return inappropriate content types. The trick is for Apache to treat wildcard requests as having a lower priority than exact requests (unless the browser does actually send a quality level with the wildcard, of course).

Error Document Return Codes

Using the ErrorDocument directive, you can get Apache to execute a script when an error occurs, instead of providing a default message. This can be used (for example) to give a more friendly error message, or maybe to jump direct to an approximate URL matching or even to the correct URL. When it does this, Apache retains the same error code that would have been returned, and returns that with the script's output, unless overridden by the script.

For example, if you have ErrorDocument for 403 errors (Forbidden) pointing to a script the output of the ErrorDocument script would be sent with a 403 status to the client. The browser should then display the following text but some, such as Internet Explorer, pop-up a dialog box instead. The only way to get IE to display the HTML page would be to send it with a status 200 instead of status 403. The CGI script can do this by outputting a "Status: 200" header. However, should the result of a bad request really be a valid document, which can then be cached? This depends how you view what ErrorDocument is doing: on the one hand, it is intercepting an error and providing a customised error message (in which case the status shouldn't be changed), but on the other hand, it could be regarded as intercepting an error at the server and returning the correct page instead (in which case it should return a 200 OK status).

Since either of these interpretations could be ok, depending on what the site administrator is trying to acheive, Apache lets you chose. With no Status: header, it will return the error status, or you can specify Status: 200 to return an OK status.

HTTP 1.1

Apache plans to support the new features of HTTP 1.1 soon after they are fully specified. A minimal set of requirements to comply with 1.1 at present is:

• Receive chunked POST and PUT submissions
• Require a 1.1 request to have a Host: header
• Support If-Unmodified-Since: header
• Send a Vary: header with negotiated documents

Major changes, such as byte ranges, entity tags and persistant connections (the new version of keep-alives) will definitely have to wait wait until after the specification is finalised. In the meantime, Apache version 1.1 is HTTP/1.0 compliant, and the next version (probably Apache 1.2) will start to offer features from HTTP/1.1.

mod_rewrite

The URL re-writing module, mod_rewrite, has a home page.

Back to the 1.0 API

The module API in the beta versions of 1.1 has a number of changes from that distributed with previous versions of Apache. These means that modules might not compile straight away with 1.1 beta. While the API changes are intended to provide better facilities such as buffered IO and to allow for future features such as byte ranges, the released version of 1.1 should implement the 1.0 API as well, to allow old modules to compile.

A paper on the Design considerations for the Apache Server API was presented at the WWW5 Conference in Paris by the API author, Robert S Thau. The paper explains why the API is designed as it was, compares it to alternative extension implementations, and reviews some of the ways in which it could be improved. It does not describe the API itself in detail.

Apache vs. NCSA and Netsite: Apache features in a comparative review of three Web servers in Sun World Online (May 1996). As they say " ... if you're willing to invest a little time and want excellent support from the best minds in the industry, Apache is the clear winner ". This article also links to useful sidebars on "server maintenance rules of thumb" and "tips for Web servers".