In this issue
The current stable version of Apache is now 1.2.4. The last
generally available release was 1.2.1. The latest version
fixes a number of bugs in 1.2.1 and works around a problem in
Solaris 2.5.1 which meant it could fail after a HUP.
The next released version was going to be 1.2.2 but this had
a last minute change after the version number had already
been set, so the release was incremented to 1.2.3. This was
actually released earlier this week on Tuesday 19th August.
Unfortunately a bug was found (see below) which affected the
proxy module. A new version was created, called 1.2.4, which
incorporated a fix for this bug and a small outstanding
change to the configuration for AIX 4.2 systems. Version
1.2.4 is now the current release of Apache.
Anyone running 1.2.1 or earlier is recommended to upgrade to
1.2.4. If you are using the proxy module with 1.2.3 you
should also upgrade to 1.2.4.
The Apache versions 1.2.* are maintenance releases of Apache
1.2 and do not include any new features. New features are
being added to Apache 1.3 which will be available for beta in
the near future. There is already an alpha of 1.3 available
which is primarily intended for testing on Windows 95 and
Windows NT systems.
Release: 1.2.4 (Released 22nd August 1997) (local download
Bugs in 1.2.3 fixed in 1.2.4:
Alpha: 1.3a1 (Released 23rd July 1997) (local download
The proxy sends on the full URI (for example,
http://www.apache.org/) to the origin server, instead of
just the URI path (e.g. /).
Does not compile on AIX 4.2 because of a missing library.
Patches to Apache 1.2 bugs will be made available in the apply
to 1.2.4 directory on the Apache site. Some new features
and other unofficial patches are available in the 1.2
patches directory. For details of all previously reported
bugs, see the Apache bug database and
Bugs page. Many common configuration questions are
answered in the Apache FAQ.
Unique Request Identifiers
Apache 1.3 will come with a new module which can create a
unique identifier for every request. This identifier can be
used in log files or passed on to SSI or CGI programs. It
could be used to match up the actions of (for example) a CGI
program with the logged request, to match up log records from
different files, or be passed back into subsequent requests
via URLs to maintain a form of state.
The module is called mod_unique_id and is not
enabled by default. The unique identifier it creates for each
request is stored in the environment variable
UNIQUE_ID which can be logged and which will be
passed on to any sub-processes. Note that the unique
identifier is not a number - it can consist numbers, letters
and the characters "@" and "-". These characters where chosen
to make it safe to use in URLs.
Caching Negotiated Responses
The negotiation module can be used to auto-select between
various versions of the same resource. For example, if a gif,
jpeg and png version of a picture are available, a request
for the picture without any extension can automatically pick
the best one based on the browser's ability. (In theory at
least - in practice many browsers do not send the correct
Since the result of the request can be one of three different
files, Apache sends back header information to ensure that
the client does not cache the response. This is to prevent,
for example, a proxy caching the response then sending it out
to clients who should get a different version of the file.
This is the correct behaviour for negotiation with HTTP/1.0
clients (HTTP/1.1 includes ways to allow for caching of
negotiated responses, and Apache fully implements HTTP/1.1,
so none of this section applies to HTTP/1.1 requests).
However many sites use the negotiation module to allow
requests to be made without the file extension. For example,
if the file index.html exists and negotiation is turned on, a
request for "index" will get the "index.html" file. This is
very useful since at any time the index.html file can be
replaced with one in a different format - say a cgi called
index.cgi or a parsed file called index.shtml - without
affecting the URLs that people are already using. But there
is a problem - the responses in this case are not cached, for
the reasons given above, even though since there is only a
single file to return it is quite safe to allow clients to
cache the response.
Apache 1.3 will probably be updated to allow negotiated
responses to be cached where there is only one choice
There have been a number of changes recently to streamline
the way Apache sends out simple (static) pages. Changes here
can have a significant impact on heavily loaded sites which
serve lots of (often small) static files. The aim is two
reduce the number of operating system calls to a minimum,
since they tend to add a large overhead to any process.
Apache 1.3 will be able to serve a page in 22 system calls
with the latest set of performance changes. For comparison, a
request for a static page in 1.2 requires 44 system calls.
This change basically removes the overhead required to set
and clear timeouts while handling a request. The child
process normally has to set a timeout using the alarm()
system call in case (for example) reading the request takes
too long. In Apache 1.3 the checking for timeouts is
performed by the parent process, not the child. What happens
is the child notes its current state in the shared
"scoreboard" every time the state changes. The parent process
checks the state of every child every second and any which
have been in a particular state too long get sent an ALARM
signal. So the timeouts remain exactly as they were before
but the child has to do much less work. The "scoreboard" is
an area of shared memory which all child processes and the
parent process have access to.
Include Configuration Files
A possible enhancement in Apache 1.3 will be the ability to
include directives from additional configuration files, as
well as the standard httpd.conf and optional srm.conf and
Module API: New Phase
A new phase has been added to the Apache module API for
version 1.3. This is called the "post read request" phase and
is called immediately after the request has been read (and
during an internal redirect). It is not run when doing a
sub-request lookup. This phase is intended for modules which
need to perform processing after the request has been
received but before anything else is done, for example,
setting environment variables based on the request contents.
Module authors may also remember that the "init module" phase
gets run twice at startup. From 1.3 onwards the init module
phase will only get called once at startup, after the error
log files have been opened.
The World Wide Web Consortium (W3C), which oversees the
evolution of Web standards, now uses Apache at its main site