In this issue

Release: 1.2 (Released 5th June 1997) (local download sites)
Beta: None

• 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 a browser

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 2.0).

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> sections).

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.