In this issue

Another beta version of 1.2 was made available this week. This follows on from beta 4. Beta 5 was never released (it was all ready for a release when a silly bug in a recent patch was noticed).

Beta 6 has a number of important improvements over previous releases of 1.2. Anyone running any beta version should upgrade to 1.2b6. The main changes in beta 6 are various changes to reduce the "FIN_WAIT_2" problem, protection against the sort of problem which caused the recent potential security hole in mod_cookies, and various improvements and fixes for suexec. More documentation on the FIN_WAIT_2 problem is available on the Apache site, including fixes and workarounds for several server operating systems. Apache now also takes more care to log errors closing connections so that problems can be identified easier.

In issue 47 we reported a bug that was causing bytes to be lost when using keep alive (persistent) connections. This was been documented on the W3 site. It now appears that this problem is caused by a bug in the latest version of the 'libwww' library from W3.

Release: 1.1.3 (Released 14th January 1997)
Beta: 1.2b6 (Released 26th January 1997)

• Bug passing query string arguments when using suexec

• Spaces between co-ordinates in imap files are invalid (e.g. "300, 300" cannot be used)
• OS specific fixes for A/UX, NeXT
• suexec programs no longer have to be world executable, and other suexec fixes
• Speeded up transfers which using keep alives
• Fixed potential core dumps on HP/UX 10.10

• Compilation errors on NeXT
• mod_rewrite problems
• Corrupt mod_info output
• FTP proxy bug on Linux
• Connection is closed after a 304 status is returned, even if it could have been kept alive.
• Only using a single argument to RLimit* directives can cause core dumps

Patches to fix some of these bugs are available in the 1.2b6 patches directory on the Apache site.

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.

In another move towards making Apache 1.2 even more compatible with NCSA 1.5, the syntax of the keepalive directives have been updated. The existing syntax will continue to work as well. Previously the KeepAlive directive took an argument which was the maximum number of requests to allow on a single connection. If it was set to 0, keep alives were disabled. Now it can be given as either "On" or "Off", to turn keep alives on and off respectively. If a number if used, 0 means off and any other number means on (this value of the number is ignored).. If set to On, the number of requests allowed on each connection can be controlled by the new MaxKeepAliveRequests. This is the value previously set by KeepAlive, with the change that if this is set to 0 there is no limit to the number of requests allowed on each connection. The default is 100 (previous versions of Apache provided a default value of 5).

This is in 1.2b6 currently available for download.

A new feature has been submitted which will allow for conditional logging. This could be used to create custom log files which better emulate the agent and referrer logs.

The new HTTP/1.1 protocol caused some confusion amongst browser, server and proxy authors over what version number should be used on responses. The problem has been that if a HTTP/1.1 server (such as Apache 1.2) receives a request marked as coming from a HTTP/1.0 client, should the response be marked as HTTP/1.0 or HTTP/1.1? The intention of the HTTP/1.1 specification is that the response should indicate the version of protocol which the server uses, not the version of the request. So a HTTP/1.1 compliant server should always respond with a HTTP/1.1 response. This confusion led to the incorrect behaviour of the AOL proxies last year, as reported in issue 46.

A new Internet Draft is under development to explain more clearly how version numbers should be used in HTTP responses. It does not modify the existing HTTP specifications (RFC1945 and RFC2068), but should be used as the definitive guide if there is any ambiguity in those documents.