Release: 1.2 (Released 5th June 1997) (local download
Bugs in 1.2:
There can be problems using SSI documents under suEXEC when
the SSI includes another SSI in a different directory and
also executes a command.
Mod_imap can get into a loop if the map file includes a
relative URL which would exist above the document root.
Patches to Apache 1.2 bugs will be made available in the 1.2
patches directory on the Apache site. This directory also
includes some minor new features which did not make it into
the 1.2 release. For details of all previously reported bugs,
see the Apache bug
database and Known
Bugs page. Many common configuration questions are
answered in the Apache FAQ.
There are now three areas of Apache development:
Core Apache development - new features
Porting - developing a version to run on Windows NT and 95
GUI - developing a user interface to configure Apache from
The current state of the source is that the modifications
required to make Apache work on Windows systems have be
incorporated into the main source code. This now incorporates
multithreading which is necessary for Apache to work on Windows
(since Windows does not support the standard Unix methods for
creating multiple processes and shared file and socket
descriptors). In the 1.3 release Apache will only be
multithreaded on Windows systems, with full multithreading for
all systems becoming available in the next release (probably
Meanwhile the development of a GUI configuration interface is
at a very early stage of planning.
The way that virtual hosts are configured and used within
Apache can be confusing. Both name-based and IP-based hosts
are configured using the <VirtualHost>
directive, and all appear at the top level of the
configuration file. When a request comes in Apache tries to
find a virtual host to handle it from all the hosts defined,
and if none are found for that host, the "main server" part
of the configuration file is used instead (i.e. the
directives outside all <VirtualHost>
The configuration syntax and internal code will probably be
updated in Apache 2.0 to make it clearer how Apache should
really select a virtual host. For example, a name based
virtual host should be selected based on the IP address that
the request arrives on, to prevent a connection on a one IP
address from jumping across to using a name which is assigned
to a different IP. The use of the "main server" will probably
also be tidied up, possibly with an option to disable this
server and use a default virtual host instead.
Apache comes with a module, mod_dld, which was designed to
allow modules to be dynamically loaded. This allows the
server to load modules without recompiling. Unfortunately
mod_dld has not been maintained recently and only works with
some operating systems (since dynamic loading is very
operating system dependent). Now there is some interest in
allowing dynamic loading on various systems, and possible
methods are being examined, including used "shared libraries"
to hold modules.
Apache for Windows NT and 95 may also allow dynamic loading
of modules, although probably not in the initial release.
Under Windows, dynamic modules are usually referred to as
"dynamic link libraries" or "DLL"'s. A future version of
Apache may allow you to obtain modules as DLLs and easily
configure the server to load them.
The integration of support for Windows 95 and NT systems
requires some changes to the module API. The most important
change is that Apache on Windows is multithreaded, so modules
need to be "thread safe". This also applies to any libraries
which are linked into the module). Most modules should be
okay, but since in the future Apache will be multithreaded on
Unix as well module authors should try and ensure that their
modules are thread-safe as soon as possible. For example, the
use of global variables or static variables may not be
thread-safe if the variables are updated in the module.
There is also a specific API change. The API functions
spawn_child and spawn_child_err
gets called with an argument which is a function to execute
in a spawned child process. Under Unix this child function
would normally do an exec() and exit if the exec
failed. Now the child function should instead return the
value -1 if the exec() fails. This is required for
compatibility with Windows systems which do not have a a fork
system call and instead have to spawn() a child
process then return -1 if the spawn failed.