In this issue

Release: 1.1.1
Beta: None
Bugs reported in 1.1.1:

• Core dump when CGI returns a status code that Apache does not understand (see below)
• A few HTTP compliance issues (see below)
• Custom error responses not cacheable (see below)

• Warnings on Irix 6.2
• Bug opening the error log when called by a module (pfopen)

The following items are under development and may be included in the next release of Apache. See our Apache 1.2 Sneak Preview for other new features in the next release.

The name of the cookies module has been the cause of some confusion. Contrary to popular belief, it does not enable Apache to use cookies, and it is not required in order for CGIs to set and get cookies. What the module does is allow users to be tracked through a site, by creating a log which is sometimes called a 'click-trail'. This provides a more accurate picture of what individual users access on the site than provided by the standard access log.

Because this module is designed for user tracking, in the next release it will be called mod_usertrack. It is an optional module that is not compiled in by default.

Also in the next release, the module itself will be considerably simplified. All the code which does the actual logging has been removed. Instead, the server administration can create a cookie log using the CustomLog directive (which is part of the configurable log module, which is a default part of Apache). The cookie information can be accessed by the new %{...}n option, as "%{cookie}n".

For backwards compatibility, the configurable log module understands the old CookieLog directive, but this is deprecated.

CGI scripts can return a status value to be used in the HTTP response, if the default (200 OK) is not suitable. For example, a script could return Status: 304 to indicate that no body is being transmitted. However, if the status number is not one that Apache understands, the server will core dump and not return any data. Apache in fact does not know all the HTTP/1.0 status values, so valid Status: lines from CGI scripts, such as Status: 204, will cause a core dump. Apache will be modified to handle this more gracefully, by returning a 500 status instead. Also, Apache will probably be updated to know about all the codes defined in HTTP/1.0 and 1.1

The next Apache release will include a -h command line flag. When given, this makes Apache list all the directives it understands. This can be useful to see what modules are compiled in. This output has been extended to also show what overrides each directive needs in order to be valid.

A few problems have been noticed with Apache's HTTP compliance. These are relatively minor. They are:

• Last-Modified: could return a time in the future if the file's date is in the future.
• If the If-Modified-Since: time was invalid, it was being used anyway instead of being ignored.
• The If-Modified-Since: header was being processed even for HEAD requests
• Some whitespace in the request line was not being ignored.

All these will be fixed in the next release.

Any response can currently be marked by Apache or by a module as being non-cacheable. This is done, for example, on documents returned with error statuses. Internally, each request has a no_cache flag associated with it. If set, this flag has two effects:

• Firstly, it prevents Apache from returning a "Not Modified" status. This means that the client will always get a response body.
• Secondly, it makes Apache add headers to the response which tell caches that this response is not cacheable.

There are some case where only one effect is needed. For example, an error document script which sends a 200 (OK) response should not return a "Not Modified" status. However, it can allow the response to be marked as cacheable. The Apache code has been updated to distinguish between these two effects: the no_cache flag indicates whether the response can be cached, and a new no_local_copy flag to specify that a "Not Modified" response is not allowed for this request.

Some versions of the phf CGI program are insecure, and should not be compiled or installed in a CGI directory. This program, originally part of the NCSA HTTPd and also distributed with Apache up to version 1.0.3, contains security problems that are being actively exploited on the Internet. If phf is installed and runnable on a web site, it lets anyone execute commands on the server. (This insecurity does not exist in the version of phf distributed with Apache 1.0.5).

The phf program with Apache 1.0.5 and earlier versions was distributed in the cgi-src directory, and needed active effort to both compile it and place it in the cgi-bin directory. The security problem in inherent to the CGI code in phf, and is not related to the server used.

The security problem actually exists in the file cgi-src/util.c, also distributed with Apache up to 1.0.5 (insecure in versions up to 1.0.3). This file provides some utility functions for CGI programs written in C. Any programs linked with this file might be insecure, unless the Apache 1.0.5 version is used. A patch to fix util.c is available from CERT. It should be applied immediately to util.c from Apache 1.0.3 or earlier, and any programs which use util.c recompiled.

Attempts are being made to exploit the phf security holes at present. Server administrators can look for attempted accesses to /cgi-bin/phf in their log files. On most sites, which do not have /cgi-bin/phf, these accesses will return a 404 Not Found status and there is no security risk. The log messages may be used, however, to try and identify the people trying to execute commands on the server.

Stronghold, the commercial version of Apache-SSL, is now available outside the US and Canada. As previously reported (see Apache & Secure Transactions feature), strong encryption cannot be exported from the US and Canada. The encryption parts of Stronghold have now been developed outside the US, so they can be exported to most countries. Inside the US and Canada, Stronghold is available from C2Net. In the rest of the World, Stronghold is available from UK Web. Stronghold is based on Apache-SSL, the free patches available from AL Digital.

Apache is now distributed as part of the Apple's MkLinux implementation on Power PC, according to an Apple Press Release.

An article in ComputerWorld called Beware Freeware, Managers Say covers the reasons why corporate information systems departments do not use free software such as Apache.

Finally, a market share survey of information systems managers by ComputerWorld does not mention Apache at all. The survey lists servers by vendor, including NCSA. However Apache does not have an organisation behind it.