Bugs reported in 1.1.1:
Bugs fixed in next release:
Apache 1.1.1 binary for SunOS 4.1.3 is corrupt on
Previously allowed non-numeric port numbers on Port
Previously allowed directives with on/off argument to have
arguments other than "on" or "off"
Dead children can be left in scoreboard (see Under
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
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
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
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.