At the end of last month's article, I announced that the Apache Group was ready to release the first Beta of Apache 2.0. If you have been watching the news coming from the Apache Group, you have probably noticed that the beta has not been released yet. This month, I will discuss why the first beta was not released, what has changed since last month, and our current plans for the first beta.

What went wrong

While waiting for mod_include, we also discovered that piped logs, notably reliable piped logs, had a major problem. We were checking to determine if the pipe between Apache and the logging program was still writable. If not, Apache assumed the logging process had died, and restarted it. The problem is that operating systems will report that the pipe is unwritable in multiple situations, and only one of those is that the process has actually stopped reading. For example, we were seeing Apache stop and restart the logging process if the pipe was full. This means that when the piped log process is at its busiest, Apache was stopping and restarting the logging process.

What has changed

mod_include

For example, all of the SuExec logic was duplicated between both modules, as was the RLIMIT logic. This problem became even bigger in Apache 2.0, because there are two CGI modules, mod_cgi and mod_cgid. This means that the same logic is in three places instead of just two. This also creates a configuration problem. Many web sites refuse to allow CGI scripts, because they pose a potential security whole. The same site may want to provide SSIs for simple dynamic sites. Those sites obviously do not include mod_cgi in their installation, but by adding mod_include it is possible to execute CGI scripts if the configuration isn't correct.

This problem is solved by having mod_include implement only the bare minimum of SSI tags. Mod_include also implements a hook to allow other modules to extend its abilities. For example, in Apache 2.0 mod_include does not implement the perl tag. If mod_perl wishes to implement this tag, then it is free to do so. In the near future, mod_include will also stop implementing the CGI tag, as that tag will move to mod_cgi and mod_cgid. This will remove the possibility that a site that doesn't want CGI scripts will accidentally enable them with Server Side Includes. If mod_cgi is not included in the server, then all CGI abilities will be removed.

Modules are able to extend mod_include's abilities by calling ap_register_include_handler. This function accepts a character string, which represents the tag that mod_include is looking for, and a function that implements the tag. Mod_include reads the input passed to it, and parses it searching for the "<!-- " tag that indicates the beginning of an SSI element. It then parses that SSI element to find the actual SSI tag. Once that tag is found, it calls the function that has been registered for that tag. This allows mod_include to implement only the bare minimum, while allowing for a very powerful parsing language. This also allows the Apache developers to combine all of the common code to a single location, making Apache easier to maintain in the future.

Reliable Piped logs

This problem has been solved by not restarting the logging process if the pipe becomes unwritable. The Apache developers decided that if the logging program actually stops responding, then the administrator will need to be responsible for restarting the server, and thus the logging program. The reliable piped logs will still restart the logging process if the program dies for some unexpected reason. The only change to reliable piped logs, is that we no longer try to detect a logging program that has just stopped responding.

Source Code Re-Organized

The new layout also introduces a new Apache Portable Run-time project, apr-util.This is a set of utilities that the Apache developers believe are useful outside of a web server. These functions are portable to every platform that Apache 2.0 runs on, but they are not portability issues. Functions in this library do not abstract out operating system issues, rather they implement useful functions that many different types of programs may find useful. For example, the buckets functions that help to implement filtering are in this library.

Re-organizing the source tree has required the Apache developers to delay the beta for a few weeks, so that all of the problems could be worked out of this tree before we tried to release a working server based on it. One alpha release, alpha 9, has already been released based on this tree, which has allowed the developers to find most, if not all, of the issues related to the new source tree. The current Apache 2.0 development tree is no longer stored in the apache-2.0 CVS repository. That repository is the old 2.0 tree, the new tree is stored in httpd-2.0. The instructions for checking out the current Apache 2.0 development tree can be found at the Apache development site.

Where are we going from here

There are a couple of other issues that the Apache developers will need to resolved before Apache 2.0 can be released as a beta, but the developers are confident that those can be resolved before the 22nd. If the beta does not roll on the 22nd, then you can be sure that the developers will be working hard to get it out the door as soon as they can. However, the Apache developers are very strong believers that we can not release Apache 2.0 before it is ready. Doing so would be a disservice to the people who entrust their web sites to Apache.

Related Stories:
Apache 2.0 alpha 9 Released(Dec 13, 2000)
Writing Input Filters for Apache 2.0(Nov 22, 2000)
Building and Installing Apache 2.0(Jul 26, 2000)
An Introduction to Apache 2.0(May 28, 2000)