In this issue

The next beta release will be called 1.3b5. There will be no 1.3b4. This is because a package for 1.3b4 was created, but then a bug was found which needed to be fixed before the beta was released. If it was fixed and called 1.3b4 again there would have been two different versions of Apache with the same version number, which would create problems with bug reports. So the version number is increased. The release of 1.3b5 is expected in the near future.

Apache Site: www.apache.org
Release: 1.2.5 (Released 5^th January 1998) (local download sites)
Beta: 1.3b3 (Released 20^th November 1997) (local download sites)

• HTTP/1.1 chunked responses could become corrupted in some circumstances.

Apache 1.2.5 is the current stable release. Users of Apache 1.2.4 and earlier should upgrade to this version since it fixes a number of bugs and potential security problems. The next major release will be 1.3. A beta test release of 1.3 is available now for both Unix and Windows 95/NT systems.

These bugs have been found and fixed in 1.3b5.

Because of the major differences between Windows and Unix, these are separated into bugs which affect Windows systems only, and other bugs (which may affect Windows as well). Unix users can ignore the bugs listed in the Windows section.

Windows-specific Bugs

• Multiple concurrent access to the same CGI program can cause Apache to hang after a while. This seems to be an issue with the Microsoft compiler's C runtime library.
• A CGI program with no extension could not be executed because Windows needs an extension. Fixed by appended "." to the filename, if it does not already contain a "." character.

Other Bugs

• According to HTTP/1.1, encodings x-gzip and gzip are equivalent, as are x-compress and compress. So Apache will now ignore any leading x- when comparing encodings. However some browsers do not treat them as equivalent, so Apache ensures that it returns Content-Encoding header contains the same format that the browser requested on it's Accept-Encoding header.
• The "send body lost connection" warning message has been changed to "client stopped connection before send body completed" to try and make it more obvious that this is a client or network problem, not a problem in Apache (other similar messages such as "request lost connection" have also been changed).
• HTTP/1.1 chunked responses could become corrupted in some circumstances.
• MiNT port updated.

Patches for bugs in Apache 1.2.5 may be made available in the apply_to_1.2.5 directory on the Apache site (this directory may not exist if no patches are available). Some new features and other unofficial patches are available in the 1.2 patches directory (these may not apply cleanly to 1.2.5). For details of all previously reported bugs, see the Apache bug database and known bugs pages. Many common configuration questions are answered in the Apache FAQ.

Development has slowed down to prepare for the release of Apache 1.3. During the beta release cycle Apache is in a "feature freeze" where no major new features will be added.

When Apache sends a file from the file system, it has to read the file and send it out a bit at a time. Apache is optimised to do this as fast and efficiently as possible, and where possible use the Unix mmap() facility which "maps" the contents of the file onto a memory location, to avoid having to read the file which would involve copying the contents between buffers.

Even better performance can be obtained by opening commonly requested files when Apache starts, so that they are already available in mapped memory when a request comes in. An experimental module, mod_mmap_static, works like this. It adds a directive, mmapfile, which is given a list of files to load at startup. Note that if the file is changed on the disk, Apache will need to be restarted (via a USR1 or HUP signal) to get the new contents mapped into memory.

Because this module is experimental at the moment, it has been placed in a new modules/experimental directory.

The next generation of the Apache web server will be called Apache 2.0. This will contain some major changes to the way the server works. This article summarises the current ideas for Apache 2.0.

Everything in this article is based on things that are being actively discussed at the moment, and for which there is some degree of interest amongst the Apache developers. However of course nothing should be assumed at this stage about what will finally make it into Apache 2.0. Also other new features may be implemented, especially for Apache NT where work is still needed to make it integrate better into the NT environment.

Apache 1.3 is now in a beta test phase. When the tests are finished, the final release will superceed the current stable release on the 1.2.* branch (currently 1.2.5, but at least one more release is planned). Once 1.3 is finished, the Apache developers will start work on the implementation of the next major version, Apache 2.0. If bugs are found with the final release of 1.3 there may be updates, starting at 1.3.1, or possibly even a 1.4, but these will be based on the 1.3 code.

The major changes being discussed for Apache 2.0 are:

This may boost performance by allowing a single process to handle multiple requests, switching between threads to handle each request. Switching threads may use less resources than switching between processes as currently happens on Unix systems. In particular, memory is shared between threads so Apache will not need as much memory to serve the same number of requests. On the downside, using threads means that if the processing of one request dies (say, due to an error in a module) it will terminate all other threads in the same process. The implementation of multithreading will be based on the "process model" (see below).

Apache NT is already multithreaded, but the code to implement it is separate from the Unix code. In 2.0 the code would be merged, with an "abstraction" layer used to make the same code work on both Unix and NT. This is also part of the new "process model".

Filtering will allow a module to parse the output of another module. For example, it might be possible to get the includes (SSI) module to parse the output of a CGI script for SSI commands. This is one example of the way that a general purpose "layered IO" system could be used. This system would let modules process the response as it is sent back to the client.

The multithreading ability, above, is one example of a process model. Another example is the current method on Unix, where Apache creates a number of processes and each process handles requests in sequence. In Apache 2.0 other models might be available as well, all implemented in such a way that the same core code works on all models and on both NT and Unix.

One other process model which will probably be implemented is where each thread handles multiple requests at the same time. This is done by using "asynchronous I/O" (on Unix) or "overlapped I/O" (on NT). This eliminates the overhead of switching between threads.

A replacement for the current Configure script is being investigated. The GNU "autoconf" suite of programs can be used to configure software for various platforms. The advantage of autoconf is that it probes the system to find out what facilities are available and to check that they work correctly. At the moment Configure has a mixture of hard-coded definitions for platforms plus some tests for specific libraries. Autoconf may make it easier for Apache to work on platforms which are not currently supported. On the downside, the overhead of autoconf may make it more difficult to port Apache to systems which are not supported by autoconf or are very non-standard.

Some major changes to the Apache API have been proposed. These are subject to a lot of discussion, because of the effect that they may have on modules written for Apache 1.3 and earlier. In the past, the API has tended to change regularly, and this has caused extra work for module authors. The intention with 2.0 is to make an API that can be stabalised to encourage people to develop Apache modules, both as source and binary files.

The two main areas that the API covers are:

• The "phase" model, and how modules express an interest in a particular phase. It is probable that several new phases will be added and that modules call functions to hook into phases, rather then using the current static module structure. Changes to the way modules hook into phases are needed to support layered-IO, amongst other things.
• The helper functions made available by the Apache core to modules, such as functions to send out HTTP response or to manipulate table structures. These will probably be renamed to avoid clashes with functions in third-party libraries.

The intention is to make sure that the new API is fully documented to make writing modules easier. There may also be a backward-compatability mode (or module) to help make Apache 1.3 and earlier modules work with Apache 2.0. However even with complete backward compatability, modules may need to be updated to work properly in a multithreaded server.

The configuration language used in httpd.conf, .htacces files, and so on, may be changed for 2.0. This is because of some limitations and ambiguities in the current language. For example at the moment it is not obvious from the language how directives given outside <VirtualHost> sections applies to the same directive given inside a <VirtualHost> (it depends on the directive).

Apache 2.0 may be written in C++, making use of object inheritence to implement modules.