Apache HTTP Server Version 2.2
This document describes some of the major changes between the 2.0 and 2.2 versions of the Apache HTTP Server. For new features since version 1.3, see the 2.0 new features document.
mod_authn_aliasmodule can greatly simplify certain authentication configurations. See module name changes, and the developer changes for more information about how these changes affects users and module writers.
mod_mem_cachehave undergone a lot of changes, and are now considered production-quality.
htcachecleanhas been introduced to clean up
eventMPMs now allow
httpdto be shutdown gracefully via the
GracefulShutdownTimeoutdirective has been added to specify an optional timeout, after which
httpdwill terminate regardless of the status of any requests being served.
mod_proxy_balancermodule provides load balancing services for
mod_proxy. The new
mod_proxy_ajpmodule adds support for the
Apache JServ Protocol version 1.3used by Apache Tomcat.
httpdcan be configured to use a system installation of PCRE by passing the
--with-pcreflag to configure.
mod_filterintroduces dynamic configuration to the output filter chain. It enables filters to be conditionally inserted, based on any Request or Response header or environment variable, and dispenses with the more problematic dependencies and ordering problems in the 2.0 architecture.
httpdis now built with support for files larger than 2GB on modern 32-bit Unix systems. Support for handling >2GB request bodies has also been added.
eventMPM uses a separate thread to handle Keep Alive requests and accepting connections. Keep Alive requests have traditionally required httpd to dedicate a worker to handle it. This dedicated worker could not be used again until the Keep Alive timeout was reached.
mod_dbd, together with the
framework, brings direct SQL support to modules that need it.
Supports connection pooling in threaded MPMs.
mod_authis now split into
mod_auth_dbmis now called
mod_accesshas been renamed
mod_authz_host. There is also a new
mod_authn_aliasmodule for simplifying certain authentication configurations.
mod_auth_ldapmodule to the 2.2
Authn/Authzframework. New features include using LDAP attribute values and complicated search filters in the
?configargument which will show the configuration directives as parsed by Apache, including their file name and line number. The module also shows the order of all request hooks and additional build information, similar to
mod_imaphas been renamed to
mod_imagemapto avoid user confusion.
-Mhas been added that lists all modules that are loaded based on the current configuration. Unlike the
-loption, this list includes DSOs loaded via
APR-Util. For details, see the APR Website.
mod_auth_*-> Modules that implement an HTTP authentication mechanism
mod_authn_*-> Modules that provide a backend authentication provider
mod_authz_*-> Modules that implement authorization (or access)
mod_authnz_*-> Module that implements both authentication & authorization
ap_log_cerrorhas been added to log errors that occur with the client's connection. When logged, the message includes the client IP address.
test_confighas been added to aid modules that want to execute special code only when the user passes
ThreadStackSizehas been added to set the stack size on all threaded MPMs. This is required for some third-party modules on platforms with small default thread stack size.
mod_filter, using the
pcreposix.hheader is no longer available; it is replaced by the new
ap_regex.hheader. The POSIX.2
regex.himplementation exposed by the old header is now available under the
ap_regex.h. Calls to
regexecand so on can be replaced by calls to
With Apache 1.x and 2.0, modules requiring an SQL backend had to take responsibility for managing it themselves. Apart from reinventing the wheel, this can be very inefficient, for example when several modules each maintain their own connections.
Apache 2.1 and later provides the
ap_dbd API for
managing database connections (including optimised strategies
for threaded and unthreaded MPMs), while APR 1.2 and later provides
apr_dbd API for interacting with the database.
New modules SHOULD now use these APIs for all SQL database operations. Existing applications SHOULD be upgraded to use it where feasible, either transparently or as a recommended option to their users.