Apache 2.0 Beta Delayed
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 wrongAll of the Apache 2.0 alphas have suffered from one problem, mod_include didn't work. Obviously this is a major problem, many web sites rely on Server Side Includes to create dynamic web pages. In Apache 1.3 this module was implemented as a handler, meaning that SSIs had to be stored on disk. With Apache 2.0, it makes more sense to implement mod_include as a filter, this allows SSIs to be implemented as files on disk, the output from CGI scripts, or as the output from any other module. However, re-writing mod_include as a filter turned out to be a non-trivial problem. After weeks of work, mod_include has been completed, and it now works as a filter. Last month it looked like 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's article discusses why the first beta was not released, what has changed since last month, and our current plans for the first beta.
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_includeBecause the Apache Group had to wait to release the first beta, we decided to make some major improvements in the interim. The first major improvement was to mod_include. In Apache 1.3 if somebody wanted to add an SSI tag to mod_include they had to actually modify the module directly. This was most obvious for two tags in mod_include, the PERL tag, and the CGI tag. The PERL tag was a hack to allow PERL code inside of Server Side Includes. The biggest problem with this hack, is that it was only available if you also had mod_perl installed. This meant that the features available in mod_include relied on mod_perl, but that link was not obvious. The CGI tag is meant to allow a Server Side Include to specify a CGI script to run. The problem with this is that it requires duplicating a lot of logic between mod_include and mod_cgi.
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.