In this issue

Release: 1.1.3 (Released 14th January 1997)
Beta: 1.2b4 (Released 31st December 1996)

• If MinSpareServers is not given it defaults to 5, even if MaxSpareServers is set to less than 5.
• The RLimit* directives are ignoring any second argument.
• On some recent operating systems, the error_log will contain messages about "accept" failing which are not errors.
• If a child process cannot be created, Apache does not notice and the scoreboard slot will stay in "Server Starting" status.
• 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 work.
• 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 executable code.

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:

• 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 this.

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 state.

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.