In this issue

Release: 1.1.1
Beta: None
Bugs reported in 1.1.1:

• Apache 1.1.1 binary for SunOS 4.1.3 is corrupt on www.apache.org

• Previously allowed non-numeric port numbers on Port directive
• Previously allowed directives with on/off argument to have arguments other than "on" or "off"
• Dead children can be left in scoreboard (see Under Development)

The following items are under development for the next release of Apache.

When a browser has a file in its cache, it does not bother getting it from the server unless it has changed. It does this by sending a conditional request, telling the server to only send the data if it has been modified since the time that the browser last obtained it. If it has not changed on the server, the server responds with a 304 status, meaning "use local copy".

Responses can also contain a definite time when the document will expire, in the Expires HTTP header. There are some cases where the expiry time of a document might change, even if the document itself has not changed. So a 304 status message can include an updated expires time, which the browser should use to replace the expires time in it's cached copy of the file. Currently Apache does not send out the expires header on 304 status, which is required by HTTP/1.1. The problem with not sending out the expires header is that the browser still keeps the old expiry time, so it thinks the document has expired straight away. This will be fixed in the next release.

The problem which caused this bug to be noticed, however, is not fixed by it. There seems to be a bug in the Netscape Navigator browser which can cause it to continuously request the same document. This affects looping animated GIF images which were originally sent with an expires header. Whenever the animation restarts, Navigator checks to see if the GIF is out of date, by sending a conditional request for the GIF. If it is not out of date, the server will respond with a 304 status. Even if this response includes a new expiry date, Navigator ignores it, and thinks that the GIF is out-of-date, so every time it loops it performs another conditional request. Server administrators who see continuous repeated requests for an animated GIF which returns a 304 status might be being hit by this browser bug. A work-around at the moment is to not send expires headers with animated GIFs.

When the Redirect directive is used to redirect incoming requests to a new URL or site, the query string arguments on the incoming request are not passed on. For example, if the redirect is

  Redirect /foo http://www.two.com/bar

and the request is for /foo/index.html, the redirect is correctly pointed to /bar/index.html at www.two.com. However if the request is for /foo/index.cgi?sort=date, the redirect will be to /bar/index.cgi. The query string arguments (the ? and following text) are not passed on. Similarly, any internal target (given by a # in the incoming URL) is not passed on. Finally, if the request was for a POST method, the redirect will be via the GET method.

All this is the standard behaviour of the Redirect directive. However, a future release of Apache might offer a way to pass on the query string and target information to the destination URL.

There have been occasional reports that child processes can die, but the scoreboard still lists them as active. The exact cause of this is not yet known, but it might be an operating system error, since Apache is careful to always acknowledge when its children die, and cleans up the scoreboard. The problem, reported on some IRIX, Solaris 2 and BSDI systems, seems to be that the operating system does not pass the information about the death of a child to the parent process. There is a work around, which is to get the parent process to explicitly check the status of the child processes every so often. The next Apache release will have code which does this.

The next version of Apache will support negotiation based on languages, using the method given in the HTTP/1.1 specification. However, there is a problem with implementing this exactly as given in the specification.

Languages are specified by a language tag such as en or de. In addition, variations of languages can be given by adding a suffix, for example, US and UK English can be specified as en-US and en-GB respectively. The problem is that if a user specifies their language preference as one of these types, the server will think it is different to any other variations of English, and indeed, different from plain 'en' as well. So, if an English speaker in the US configures their browser to prefer 'en-US', they will never be sent text marked as being in 'en' or 'en-GB'. Since most sites using language negotiation will tend to use just the short forms (en, de and so on) this will lead to the user not getting the information they want.

The real solution is to ensure that users select the appropriate language preference, presumably by sufficiently clear instructions in the browser's language selection options. As a work-around, Apache will be updated so that a preference for en-US will match both en and en-GB, but only if no version exists in en-US itself.