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
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
Bugs fixed in next release:
Compilation problem on QNX (redefinition of
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
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.
Better Auto-detection of Linux Systems
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
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.
Graceful Restarts Work with Scoreboard File
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
For example, to set your compiled in server root to
/etc/httpd, you would updated the
EXTRA_CFLAGS in in Configuration to
The new things which can be configured like this are:
The default server root (the directory containing your
"conf" and "logs" directories), which can be set by the -d
flag to httpd
The location of the httpd.conf file, which can be set by
the -f flag to httpd
The PATH environment variable value passed on to CGI
programs (defaults to a common selection of bin
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
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
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.