Release: 1.1.3 (Released 14th January 1997)
Bugs reported in 1.2b4:
Beta: 1.2b4 (Released 31st December 1996)
Bugs in 1.2b4 fixed in next release:
If MinSpareServers is not given it defaults to
5, even if MaxSpareServers is set to less than
The RLimit* directives are ignoring any second
On some recent operating systems, the error_log will
contain messages about "accept" failing which are not
If a child process cannot be created, Apache does not
notice and the scoreboard slot will stay in "Server
PATH_INFO not available to server-side included scripts.
Proxy module can send headers as part of the message body
for nph scripts.
POST to a directory index CGI (e.g. index.cgi) did not
If ErrorDocument was given a string ending
with a double-quote, the trailing quote was not displayed.
Configuration updates for OSF, SCO3.
Last issue, we said that users of 1.1.2 do not have to
upgrade if they managed to get 1.1.2 to compile in their
system. This is not correct. Apache 1.1.2 causes problems
when the URL refers to a CGI script and includes some
PATH_INFO. You should upgrade to 1.1.3.
Apache is currently in a 'beta release' cycle. This is where
it is made available prior to full release for testing by
anyone interested. Normally during the beta cycle no new
major features will be added. The full release of Apache 1.2
is expected in February.
The fastCGI module (mod_fastcgi.c) will no longer be
distributed with Apache. The latest versions of this module
are available from the fastCGI site.
Recently Apache 1.1.3 was released to address a couple of
security-related bugs. While the most important bug (the
cookies one) is very difficult to exploit (and there is no
evidence that any has managed to exploit it), it is possible
that other similar bugs could exist in the code. Because of
these, the entire code is being updated to prevent this sort
of bug from ever producing a potential security hole again.
The problem in the cookies bug was that Apache used a fixed
length string to hold data which it received from the network
(in the case of the cookies module, the data was an Internet
hostname). It is possible to write text longer than the
buffer allows, which would cause extra data to get corrupted.
Normally the only affect this would have is possible
corruption of the Apache program in memory (no security
risk). However if a cracker knows what system the server is
running on and knows a lot about the internal structure of
Apache and the data structures on the operating system, they
might be able to overwrite the data with executable code, and
manage to get this code executed. In the worst case, this may
give them access to the server system as the user that Apache
runs as (normally 'nobody' or a normal user, not the
root user). This whole sequence is very difficult, but not
impossible, to exploit. In the case of the cookies module,
the cracker would have to arrange to be connecting from a
hostname containing exactly the right combination of data and
Even through the risk posed by this bug and other similar
ones is small, Apache will be updated to prevent any
potential security holes of this sort occurring in future.
This will be done by never allowing more data than a string
can contain being written to that string, using special
functions which limit string sizes.
There seem to be a couple of problems related to closing
connections in the Apache 1.2 betas. Neither seem to be
directly related to Apache, but are caused a combination of
operating system bugs, client software bugs and changes to
Apache which have made the existing problems more noticeable.
The problems are:
These problems, while related to specific operating systems and
clients, have prompted a detailed analysis of the way Apache
handles closing connections. Some minor bugs in this code have
been fixed. The next beta release of Apache will address both
these problems. Below is a more detailed explanation of both
Connections can fall into a FIN_WAIT_2 state, where
they stay forever until they use of all the connection
resources of the server.
The last part of the response can be lost
FIN_WAIT_2 is the final stage of closing a TCP connection.
Any connections in this state (as seen by
netstat command) are almost completely closed:
they are just waiting for the final acknowledgment of the
close from the client. If this never arrives, the connection
will probably stay in this state forever. Unlike most other
TCP connection states, the TCP specifications do not
recommend a timeout for this state, although some recent
operating systems do implement a timeout. Note that it is
normal to see connections in FIN_WAIT_2 state, and it is not
unreasonable to expect some connections to stay in this state
forever (e.g. if the client was switched off at the wrong
time). The problem is when the number of connections in this
state keeps increasing.
It is thought that this state is being seem more now due to a
particular combination of client operating system and
browser, probably Windows on a PC.
It has also been noticed that the last part of the response
can get lost (i.e. the client never shows it). This is seen
when the server is running on certain operating systems, or
when the client is sending a large request (e.g. a POST or
PUT) which the server has refused.
The cause (and fix) for both of these problems relates to how
Apache closes connections. In the 1.1.1 and 1.1.3 servers,
Apache closes the connection as soon as it has finished
sending data. This can cause two problems: firstly, some
(buggy) operating systems did not flush out any unsent data
on that connection before doing the close, and secondly if
the client is still sending the request (for example, PUT
data or when using a persistent connection) it would cause an
immediate connection closedown which means the client might
not receive the last set of data sent. So both of these can
cause the lost data problem.
To get around the lost data problem, the code was updated to
close the connection for sending only, while still reading
(and ignoring) any more received data until the client closed
the connection at its end. This relies on the client actually
closing its end of the connection properly - on clients which
don't, the FIN_WAIT_2 problem is seen. The way that Apache
holds the connection open like this is referred to as a
"lingering close". This should be done by simply setting an
operating system option for that connection, and letting the
OS take care of it. However many OSes have problems with
lingering close, so Apache 1.2 includes its own code to do
A possible work around is to remove this additional
code. This can be done by adding -DNO_LINGCLOSE to the
EXTRA_CFLAGS in Configuration and rebuilding
Apache. Some users have noticed that this considerably
reduces the number of connections falling into FIN_WAIT_2
During the analysis of the way TCP connections close, it was
noticed that this lingering close code was being called more
times than necessary, on already closed or aborted
connections or after a timeout. This has been fixed.