In this issue

A new Apache beta is now available. This is called beta 10 (Apache 1.2b10) and was released on Wednesday 30th April. This version should be more robust in the face of error conditions, because of updates to the way it handles timeouts, signals and errors from network operations.

There are some noticable changes, such as properly working graceful restarts, re-ordered default modules and use of shared memory on Linux 2.x. There are also a number of bug fixes, including fixed CGI command line arguments, sending CGI a SIGPIPE on write errors, various suEXEC fixes, better logging of bad requests, work-around for the Netscape Navigator header-size bug and preserving query string across redirect. Full list of changes is available in the src/CHANGES file in the distribution.

The previous public beta release was beta 8. Beta 9 was prepared and just about to be released when a bug was found. Although it was not announced it was available for download for a short period, and to prevent any confusion the beta number was bumped to 10 for the actual release after the bug was fixed.

Release: 1.1.3 (Released 14th January 1997)
Beta: 1.2b10 (Released 30th April 1997)

Bugs fixed in 1.2b10:

• If an error occurs while sending a response, Apache continued to send the data.
• Fix for scripts not receiving a SIGPIPE if the user disconnects while that script is sending output.
• Command line arguments passed to CGI programs (from the query string) were sometimes incorrect.
• Default virtual hosts for a particular port (e.g. <VirtualHost _default_:8080>) were not working.

Bugs fixed in next release:

• Compilation problem on QNX (redefinition of signal).
• If a script which has already read POST or PUT data fails and is redirected to an error script Apache would block trying to read the request data again.

Patches to Apache 1.2b10 bugs may be available in the 1.2b10 patches directory on the Apache site. At time of writing there are no patches and this directory does not exist.

For details of all previously reported bugs, see the Apache bug database.

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 now expected in May.

There has recently been some confusion over the configuration to use on Linux systems. Most systems include support for shared memory, and this can be used for the Apache "scoreboard" instead of using a file, and this gives is a performance boost. So in 1.2b8 the use of shared memory on Linux was made the default. However there are some systems which apparently do not support shared memory, so this caused a number of bug reports. This situation appears to be that Linux 2 kernels always included shared memory, while it was a (kernel) compile-time option in 1 series kernels (and may not have been completely reliable). To try to make things work out-of-the-box on most systems, Apache now compiles to use shared memory on Linux 2 (or higher), and to use a file on Linux 1.

If you are using Linux 1, you can still compile Apache to use shared memory by added -DHAVE_SHMGET on in the EXTRA_CFLAGS line in Configuration. The LINUX_TWEAK rule reported previously in Apache Week has been removed.

The new implementation of graceful restarts now works on systems using a scoreboard file. The code to read and write scoreboard files has also been tidied up to make it work better if an error or signal occurs while in the process of doing a scoreboard file update. There is still a risk of scoreboard file corruption (although much less than before), so whereever possible shared memory should be used instead (it is the default on most systems).

If you have your server root somewhere other than the default /usr/local/etc/httpd, you probably start Apache with a -f or -d flag. Alternatively you can compile your server root into Apache by modifying the definition of HTTP_ROOT in conf.h. But if you do this you'll need to make this change every time you upgrade to a new version of Apache. In 1.2b10 you can configure the server root, and a few other things, in the Configuration file -- without having to alter any Apache source code files. This keeps your local modification entierly within the Configuration file.

For example, to set your compiled in server root to /etc/httpd, you would updated the EXTRA_CFLAGS in in Configuration to say

  EXTRA_CFLAGS=-HTTPD_ROOT="/etc/httpd"

The new things which can be configured like this are:

• HTTP_ROOT
  The default server root (the directory containing your "conf" and "logs" directories), which can be set by the -d flag to httpd
• SERVER_CONFIG_FILE
  The location of the httpd.conf file, which can be set by the -f flag to httpd
• DEFAULT_PATH
  The PATH environment variable value passed on to CGI programs (defaults to a common selection of bin directories)
• SHELL_PATH
  The full path of the shell to use when running sub-programs (defaults to /bin/sh on Unix and cmd on OS/2)

Some existing CGI scripts fail to work with Apache 1.2 because of a change introduced before 1.2b1 was released. While CGI programs can be updated to work with Apache 1.2 using a simple work-around, Apache may be modified to revert to the old behaviour in the next release.

The problem is the value of the PATH_INFO environment variable when the CGI script being called is defined in a ScriptAlias directive, rather than on the request URI. In this case, there can be path info data on the ScriptAlias directive, as well as on the requested URI. In Apache 1.1 and before, Apache passed in all the path info, from both sources, but in 1.2 it only passes the path info from the request URI.

For example, if the configuration includes

  ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/wrapper/param1/

then a request for the URI /cgi-bin/script.cgi/param2 gets handled by the script /usr/local/etc/httpd/cgi-bin/wrapper (if it exists). In Apache prior to 1.2 (as weel as NCSA and CERN servers), the PATH_INFO environment variable would be set to contain /param1/script.cgi/param2. This lets the script see both the path_info from the ScriptAlias and the path_info from the request URI. In 1.2 this was updated so that the value of PATH_INFO would be /param2, i.e. just the path_info from the request URI.

The CGI specification does not cover this situation, so either could be correct. However that change has made some CGI scripts fail to work, since they relied on the old definition of PATH_INFO. To make them work, a new environment variable, FILEPATH_INFO was added to Apache in December. This variable has the "old" value of PATH_INFO (as used in Apache 1.1, NCSA and CERN). Scripts which need the old usage should use FILEPATH_INFO if it exists, otherwise use PATH_INFO. But of course this requires scripts to be updated to work with Apache 1.2, if they are called via a ScriptAlias which includes path info.

It has not yet been decided if Apache will revert to the behavior compatible with Apache 1.1, NCSA and CERN, or whether programs will be required to check FILEPATH_INFO as well.

Mixed press this week for Apache. A review of web servers in the US Network World online magazine (Network World Fusion) found Apache's only advantages was the availability of source code, and apart from that all the other servers reviewed could "meet or beat" Apache. On the other hand, Sun World Online reports that Apache (and Unix) is the most popular Internet server platform by far.

The Network World review compared Netscape Enterprise, WebSite Professional and Microsoft IIS on Windows NT, WebSTAR on Macintosh and Apache on Unix (the Unix variant was not given). The only aspects really compared were management and content management. While performance was mentioned, it was only in the context of the management tools (where, incidently, they found that Windows NT is best for performance management). They did not appear to test the actual performance of the servers, however. The use of programming APIs was examined as a method of getting better performance. But scripting or embedded languages (such as perl, python and php) we not covered, despite their potential for higher performance (especially with the option of loading scripts at server start-up, rather than on-the-fly, as in mod_perl).

The review preferred programs with provide offer a broad range of in-built features, which works against Apache which fits the Unix philosophy of allowing administrators to add components as and when necessary (for example, Apache was critised for not automatically rotating log files). Of course irrespective of the conclusion of rreviews, Apache is still by far the most widely used Internet server, and 400,000 users cannot all be wrong. The article is available from Network World Fusion as document ID 1431, after free registration.

Sun World Online (May 1997) asks Who's really winning the browser and Web server wars? Of course, on the server side it is Apache, while for browsers it is Netscape. They also noted that at least two-thirds of Internet Web servers are still on Unix.