Apache 2.0 Beta Delayed Page 2

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

The second major change was to fix the reliable piped log problem. In the past, if Apache determined that the pipe was unwritable, then the process was killed and re-spawned. This was meant to ensure that the program was always available to log the output from Apache. The problem is that at times the pipe is reported as being unwritable when it is just full. If the pipe is full, then the logging program should be using all of its resources to read from the pipe and write the logs to disk. If Apache kills the logging program and restarts it, then some of the logs will be lost, and even worse, the logging program will be busy restarting instead of continuing to process the information it has.

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 final major change is that the source code repository has been completely re-vamped. In the past, the Apache developers have tried to provide a single source tree that was also used for binary installations. Apache 2.0's source tree was exactly the same as the 1.3 tree, but that tree doesn't make as much sense. In Apache 1.3 the source tree was geared towards building a web server, but Apache 2.0 is a server framework with an HTTP module. The new source tree emphasizes the new focus of the Apache developers. Although the protocol independence is not perfect yet, the new layout forces the developers to think about that abstraction.

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.

This article was originally published on Dec 20, 2000
Page 2 of 3

Thanks for your registration, follow us on our social networks to keep up-to-date