Some minor enhancements have also been added to the programs that support the Apache httpd server. The first, the addition of a new command line option to httpd, should simplify the debugging of module availability. It was always possible to list the modules built into the httpd runtime using the -l command line option, for example:
$ httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c
But this lists only those built into the binary; dynamically loaded modules (DSOs) were not listed. You could usually determine whether a module was loaded if it added directives to the configuration file by listing supported directives with the -L command-line option, but it wasn’t foolproof.
The new -M command line option lists all of the modules, those statically linked into the httpd server and those shared and loaded according to the configuration. The module type (static or shared) is also displayed:
httpd -M Loaded Modules: core_module (static) mpm_prefork_module (static) http_module (static) so_module (static) authn_anon_module (shared) env_module (shared) expires_module (shared) headers_module (shared) mime_module (shared) negotiation_module (shared) setenvif_module (shared) log_config_module (shared) logio_module (shared) cgi_module (shared) alias_module (shared) rewrite_module (shared) userdir_module (shared) info_module (shared) status_module (shared) actions_module (shared) autoindex_module (shared) dir_module (shared) ext_filter_module (shared) deflate_module (shared) include_module (shared) Syntax OK
This is much more useful as a way of identifying problems with modules and the availability of individual directives.
The prefork, worker, and event MPMs now allow the httpd server to be shut down gracefully, enabling requests to be serviced before shutting down the server completely. You can also specify a timeout period in the configuration through the GracefulShutdownTimeout period directive after which the server will shutdown regardless of the status of any existing requests.
Should I Upgrade Now or Wait?
The common dilemma of choosing whether to upgrade to the new version or to stay with the current version and installation remains.
On the one hand, Apache 2.2.0 is merely an additional release of an already stable and well-tested edition of the Apache httpd project. The first official version of the Apache 2.0 branch, v2.0.35, was released in April 2002. Despite a number of bugs and fixes there have been no major show-stoppers for the Apache 2.0 series. So in theory, version 2.2.0 is actually an updated version of a stable and well-tested release.
However, the change in the authorization modules may make some nervous about using the v2.2.0 without further testing. Certainly, the configuration changes mean you should do some of your own testing on a staging server before using Apache 2.2.0 in a production environment — especially if your Web sites rely heavily on Apache-driven authentication and authorization.
If you use custom developed modules with your Apache installation, then you should also be careful of migrating to the new version immediately. The changes to the regular expression engine and API will require some redevelopment. If your modules use SQL interfaces to MySQL or other databases, then you should use the new mod_dvd interface in preference to your own custom-driven solution. Note again, however, that this only affects modules using this technique, not dynamically driven applications.
Therefore, the current choices are:
- Apache 2.0.55 is the latest stable release before 2.2.0.
- Apache 2.2.0 is the latest formal release if you want to stay on the bleeding edge.
- Apache 1.3.34 is the latest Apache 1.x release.