What’s New in Apache 2.2

More than ten years after the debut of the Apache HTTP Server, and after a number of years of maintaining the status quo, the latest version of the world’s most popular Web server contains many exciting new developments, with even more novelties promised in coming releases.

More than ten years after the debut of the "i">Apache HTTP Server, and after a number of years of
maintaining the status quo, the latest version of the world’s
most popular Web server contains many exciting new developments. If
you run Apache, it’s time to upgrade to "i">Apache 2.2.

If you install Apache 2.2, you’ll quickly discover that
Apache configuration has changed. The single, monolithic
configuration file, httpd.conf, has been
augmented with several smaller, special-purpose configuration
files. The primary file is still named "i">httpd.conf. The smaller files, used for less common
configuration options, can be found in the subdirectory

To enable a feature found in one of the “extra”
files, simply un-comment the corresponding "c">Include line in httpd.conf. For
example, to enable the user home directory feature, elide the
# (octothorpe) from its "c">Include line:

# User home directories
Include conf/extra/httpd-userdir.conf

# Include conf/extra/httpd_manual.conf

Similarly, to make the Apache HTTP Server documentation
accessible via the URL class="story_link">http://your.server.com/manual/, un-comment
the last line above.

None of the “extra” configuration files implement
new features. Instead, the modularization of the formerly-sprawling
Apache configuration file is intended to make setup, modification,
and ongoing maintenance easier.

Of course, if you’ve been using Apache for a number of
years, you may find the new scheme harder to navigate. Here’s
a quick tip: To find a particular parameter among the myriad of
configuration files, use grep –ir in
conf/. For instance, the command…

$  grep -ri NameVirtualHost /etc/apache2/conf/*

… recursively searches every entry in "i">/etc/apache2/conf/ for a variation of "c">NameVirtualHost.

Authentication and Authorization

While the reorganization of configuration files is largely
cosmetic, the changes made to authentication and authorization are
very significant. Enhanced security is a major reason to upgrade to

Prior to 2.2, your options for authentication and authorization
were fairly limited. Each authentication module defined both the
authentication type (Basic or "c">Digest) and the mechanism for storing credentials
(username and password) and group information. If you wanted to mix
and match — say, if you wanted to use "c">Digest authentication but store your passwords in
dbm files — there wasn’t a way
to do that. Now, the technique and the mechanism are separate. You
select the AuthType and then select a
provider — a persistent store —
to maintain your user credentials. (This work began in the
2.0.x series, but was withheld until 2.2,
since it’s a significant change that requires administrators
to change syntax.)

If you’re using the most common configuration —
Basic authentication and text password files
— the “old-fashioned” approach works without
changes. However, you should become familiar with the new
configuration syntax, so you can take advantage of its

Consider the following simple examples:

*To use "c">Basic authentication and keep passwords in a text file
generated by htpasswd, try:

<Directory /www/htdocs/private>
    AuthType Basic
    AuthName "Restricted Files"
    # (Following line optional)
    AuthBasicProvider file
    AuthUserFile /usr/local/apache/passwd/passwords
    Require user rbowen

AuthType chooses the technique, while its
complement, AuthBasicProvider, indicates
that passwords are found in a file. The next directive,
AuthUserFile, names the file. (In this
particular case, the AuthBasicProvider line
is optional, since file is the default

*If, on the other hand, you
wanted to store user credentials in a DBM file, you would use the
following configuration:

<Directory /www/htdocs/private>
    AuthType Basic
    AuthName "Restricted Files"
    AuthBasicProvider dbm
    AuthDBMUserFile /usr/local/apache/passwd/passwords.db
    Require user rbowen

As shown, if you choose AuthType Basic,
you must specify an AuthBasicProvider. Of
course, you can change the AuthType to
Digest and name an "c">AuthDigestProvider. The provider can be a "c">file, dbm, "c">ldap, or dbd, to store the
credentials in a file, a DBM database, an LDAP server, or a
database server, respectively.

One huge advantage of this new structure is that a module author
is no longer required to implement HTTP authentication — it
comes for free. All a developer must do is implement the storage
mechanism. As a result, this also means that any authentication
module can be used with either the Basic or
Digest authentication protocol.

Choosing a Provider

The naming convention in Apache 2.2 is that authentication
modules are named mod_authn_…, and
authorization modules are named "i">mod_authz_…. In 2.2, "i">mod_auth_basic and "i">mod_auth_digest realize authentication. As of late-March
2007, mod_authn_file, mod_authn_dbm,
and mod_authnz_ldap
provide authorization. (Because LDAP does both authentication and
authorization, the latter module is named mod_authnz_ldap, and
handles both components.)

* "b">mod_authn_file. With mod_authn_file user credentials are
stored in a text file. The format of the text file is user account
per line in the format "i">username:encpassword, where "c">encpassword is an encrypted
password. Using htpasswd, the password may
be encrypted using MD5, CRYPT, or

To indicate that you wish to use credential information stored
in a text file, use:

AuthBasicProvider file

If you prefer Digest authentication, specify

AuthDigestProvider file

Next, use the AuthUserFile directive to
point to the full path of the password file, as in:

AuthUserFile /var/www/passwords/pass.txt

It’s best to keep your password file outside of your
document directory.

* "b">mod_authn_dbm. If you’d like to store your
credentials in a DBM database, use mod_authn_dbm. Create the DBM
file with the dbmmanage utility, and, as
with mod_authn_file, passwords may be encrypted using any of the
MD5, CRYPT, or SHA algorithms.

You can use a DBM database with either…

AuthBasicProvider dbm


AuthDigestProvider dbm

The location of the dbm file is provided via the "c">AuthDbmUserFile directive:

AuthDbmUserFile /var/www/passwords/pass.dat

Using a DBM database has certain advantages over using a text
file. In particular, it is much faster, since it’s a real
database accessed via indices.

* "b">mod_authn_dbd. The mod_authn_dbd module allows you to
store user credentials in any of several SQL
databases. Credentials can be retrieved by a SQL query specified in
the AuthDBDUserPWQuery directive.
mod_authn_dbd obsoletes a number of third-party modules, such as
mod_auth_mysql, that allow authentication
against databases.

Listing One implements authentication
against a Postgres database. The username
and password are stored in a table called "c">authn; within that table, the password column can be
encrypted by any of the standard authentication modules. The
%s parameter in the query "c">select password from authn where username=%s is replaced
with the username entered in the username/password dialog triggered
by the authentication requirement.

Authentication via a "i">Postgres database

#Use the PostgreSQL driver
DBDriver pgsql

#Connection string: database name and login credentials
DBDParams “dbname=htpasswd user=apache password=xxxxxx”

#Parameters for Connection Pool Management
DBDMin 1
DBDKeep 2
DBDMax 10
DBDExptime 60

#Authentication Section
<Directory /usr/www/myhost/private>
#mod_auth configuration for authn_dbd
AuthType Basic
AuthName “My Server”
AuthBasicProvider dbd

#authz configuration
Require valid-user

#SQL query to verify a user
#(note: DBD drivers recognise both stdio-like %s and native
AuthDBDUserPWQuery “select password from authn where username =

Here’s a clever feature: If you wish to check several
sources, simply provide multiple arguments to the "c">Auth…Provider directive. For example, given this

AuthType basic
AuthBasicProvider dbm file
AuthDBMUserFile /usr/local/apache/passwd/passwords.db
AuthUserFile /usr/local/apache/passwd/passwords
Require user waldo

… if user waldo isn’t able
to authenticate against the DBM, the flat credentials file is
checked next, as specified by the order listed in the "c">AuthBasicProvider option. You can chain as many
providers as you want. But what happens if more than one of your
AuthBasicProviders, say, is of the same
type? Fortunately, that has been planned for, too.

* "b">mod_authn_alias. If you want to authorize against
multiple sources of the same type — say, two LDAP servers
— use mod_authn_alias to create an
alias for each one.

Consider the example in Listing Two. The
configuration checks two LDAP hosts for credentials. The same
technique can be used for authentication methods other than

Use aliases to check more than one provider
of the same type

LoadModule authn_alias_module modules/mod_authn_alias.so

<AuthnProviderAlias ldap ldap-alias1>
AuthLDAPBindDN cn=youruser,o=ctx
AuthLDAPBindPassword yourpassword
AuthLDAPURL ldap://ldap.host/o=ctx

<AuthnProviderAlias ldap ldap-other-alias>
AuthLDAPBindDN cn=yourotheruser,o=dev
AuthLDAPBindPassword yourotherpassword
AuthLDAPURL ldap://other.ldap.host/o=dev?cn

Alias /secure /webpages/secure
<Directory /webpages/secure>
Order deny,allow
Allow from all

AuthBasicProvider ldap-other-alias ldap-alias1

AuthType Basic
AuthName LDAP_Protected_Place
AuthzLDAPAuthoritative off
require valid-user

Consider, for example, this configuration excerpt:

<AuthnProviderAlias file file1>
    AuthUserFile /tmp/user1

<AuthnProviderAlias file file2>
    AuthUserFile /tmp/user2

<Location /x>
    AuthType Basic
    AuthBasicProvider file1 file2
    AuthName "Wooga"

    Require valid-user

This checks two different password files, in turn. If the user
exists in both files, but with an incorrect password in the first
file, the second file is still checked.

* "b">mod_authnz_ldap. While numerous add-on LDAP
authentication modules are available, Apache 2.2 is the first
release to include an LDAP authentication module. mod_authnz_ldap
allows you to authenticate and authorize against any LDAP server,
such as OpenLDAP or "i">Microsoft Active Directory Server.

The example LDAP configuration shown in tandem with
mod_authn_alias demonstrates simple authentication against two LDAP
servers. mod_authnz_ldap also allows you to construct arbitrarily
complex LDAP queries, and allows for a variety of authorization
requirements in addition to valid-user.

Cache Local Content

You may recall that in Apache 1.3 caching
was very tightly tied to proxying. In fact, both features were
implemented in the same module, mod_proxy,
and there wasn’t really any way to use the features
independently. Essentially, caching was an optional feature of

In Apache 2.0, "i">mod_cache was liberated from mod_proxy, and some
features of mod_cache were further divided into sub-modules.
Specifically, the cache storage mechanism was implemented in two
further modules: mod_disk_cache realized a
disk-based storage system, while "i">mod_mem_cache cached data in memory.

In 2.2, this division into submodules is likely to get more use,
because it is better documented and much more stable. In fact, once
you understand some of the things you can gain, you’ll
probably want to start using these features right away. Let’s
take a look.

Because mod_cache and mod_proxy are now distinct, you can use
mod_cache to retain remote (proxied) content and local content as
well. Caching local, dynamic content can greatly improve
performance. For example, if you have dynamically-generated pages
that don’t change very often, cache those. Subsequent page
loads will be faster, and, since the content doesn’t change
very often, you’ll still get the latest content.

Caching can be enabled with a simple configuration like the

CacheRoot /var/cache
CacheEnable disk /

The directory /var/cache (or wherever you
point CacheRoot) needs to exist, and be
writeable by the user defined in Apache’s "c">User directive. The CacheEnable
directive choose a caching scheme and specifies what part of your
URI space you want to be cached. In this example, all requested
URIs (any URI rooted at /) are cached.

Static files don’t particularly benefit from disk-based
caching, since they will have to be retrieved from disk either way.
You can, however, gain performance using the file descriptor cache
implemented by mod_mem_cache. The file
descriptor caches file handles. When a resource is requested, the
file handle is already open, and the contents can be sent directly
to the client. The time savings is significant.

For example, to use the file descriptor cache on image files,
use a configuration like this:

CacheEnable fd /images

Finally, there is a memory-based cache, where the "i">contents of the resource are cached in memory and served

CacheEnable mem /manual

If you wish to combine several of these options, it’s
important to remember the first-match rule: put the most general
directive last:

CacheEnable fd /images
CacheEnable mem /manual
# And everything else ...
CacheEnable disk /

When you cache dynamic content, you must also set an expiry. The
default behavior of a cache is to check the freshness date on the
content, and get a newer version of the content if it’s
expired. However, there are instances when you want to ignore the
expiry and cache the content a little bit longer. This is
particularly the case for content that is dynamic, but seldom

mod_cache provides you some tools to specify how long you want
to cache such content:

CacheIgnoreCacheControl On
CacheDefaultExpire 600

Here, CacheIgnoreCacheControl On ignores
the cache control headers sent by the server; "c">CacheDefaultExpire caches content for ten minutes
regardless of freshness date. Be careful when setting configuration
directives like this. You don’t want to serve stale content
for unacceptably long periods.

Cache Proxied Content

As before, the caching modules can also be used in conjunction
with proxying.

# Cache all proxied http:// requests
CacheEnable disk http://

# Or perhaps just requests to a certain site
CacheEnable disk http://www.apache.org/

# Avoid certain URLs
CacheDisable http://security.update.server/update-list/

# Cache ftp requests
CacheEnable disk ftp://

This can be used in either a forward- or reverse-proxy setup, to
improve performance of proxied content.

It is very important to remember that authenticated content is
never cached, regardless of what directives you have in place.
However, content that has access restrictions in place based on
other things, such as environment variables, or network address,
can be circumvented using proxying and caching. Make sure that you
don’t enable caching of content that you want to restrict
access to, unless you completely understand the conditions under
which it may be accessed.

If, for example, you have content that you’re restricting
access to by IP address, it’s important to understand that
content retrieved from the cache might not be subject to these
restrictions, and so it may be possible to retrieve this content
from arbitrary IP addresses.


In addition to being divided from the caching modules, mod_proxy
has undergone a number of other significant changes in 2.2. Most
important, the proxy features have been split into different
modules to handle the various different protocols. Now, in addition
to mod_proxy, there is also mod_proxy_http,
mod_proxy_ftp, mod_proxy_ajp, mod_proxy_balancer,
mod_proxy_connect. Thus, when you want to
enable proxying, you must enable mod_proxy, as well as the
particular module that handles the protocol or feature you’re
interested in. mod_proxy can also work in conjunction with
mod_cache to cache proxied content, or with "i">mod_ssl to proxy content to an SSL/TLS server, using the
SSLProxy *
directives. (See below.)

A forward proxy connects a client
(typically the browser) to an outbound connection via a proxy
server. Each time the browser makes a request for a URL, it sends
that request not to the target server, but to the proxy server,
which makes the request on behalf of the client and returns the
response to the client. A forward proxy is typically deployed for
security reasons, or for performance reasons. (Or both.)

A forward proxy configuration that permits outbound proxied
connections from your network can be created with this snippet:

ProxyRequests On
ProxyVia On

<Proxy *>
    Order deny,allow
    Deny from all
    Allow from internal.example.com

A reverse proxy “sits” in
front of one or more back-end servers and proxies requests to those
servers. In other words, when a request arrives at the front-end
server, it proxies that request to the server (s) behind it, and
returns the response to the client. Typical uses of a reverse proxy
include exposing web content on servers that are hidden behind a
firewall; providing some type of load balancing among several back
end servers; or providing caching for a slow back-end server. Also,
a reverse proxy server can be used simply to provide access to
multiple servers, all under one server name and/or port number.

A reverse proxy configuration to map requests for a url
/images to the back-end server "i">images.example.com might look like this:

ProxyRequests Off

<Proxy *>
    Order deny,allow
    Allow from all

ProxyPass /images http://images.example.com/images
ProxyPassReverse /foo http://images.example.com/images

No client configuration settints are needed for the reverse
proxy scenario, and the client is completely unaware that the
proxying has happened.


mod_proxy_balancer is an exciting new
module that provides load balancing between multiple back-end
servers. Load balancing has traditionally been associated with
expensive and complex commercial solutions, but this module makes
load balancing simple to configure, and it’s included in the
standard installation of the Apache web server.

For example, the following configuration passes requests for the
URL /test to two back-end servers, and
load-balance requests between these two servers.

<Proxy balancer://mycluster>
ProxyPass /test balancer://mycluster/

The BalancerMember allows for various
configuration settings to be modified per member of the proxy
cluster group. For example, if the second server is twice as
powerful as the first one, you may wish to double the number of
requests that are directed to it:

BalancerMember loadfactor=2

A web-based configuration tool is included with the module, and
is configured using the balancer-manager handler, as shown in the
configuration here:

<Location /balancer-manager>
    SetHandler balancer-manager

The interface provided by this manager is shown in "i">Figure One. Servers in the load balancing cluster can be
dynamically enabled or disabled, and you can adjust load


mod_proxy_ajp gives the 2.2 server a
major new feature: the ability to proxy the Apache
JServ Protocol version 1.3
(AJP) protocol. In the past,
proxy to AJP servers, such as Tomcat, it was
common to use mod_jk or other similar
solutions so that the Apache Web server could sit in front of the
Tomcat server and pass requests through to it. These solutions were
notoriously bad with session management and other things expected
by the servlet engine.

With mod_proxy_ajp, these problems are resolved. Sessions
established to one particular back-end process will be routed back
to that same process the next time, preserving sessions.
Additionally, the web-based management interface allows individual
back-end servers to be enabled and disabled at will, permitting
scheduled maintenance.

The following is an example mod_proxy_ajp configuration:

<Proxy balancer://mycluster>
    BalancerMember ajp:// min=10 max=100 route=node1 loadfactor=1
    BalancerMember ajp:// min=20 max=200 route=node2 loadfactor=2    
ProxyPass /servlets-examples balancer://mycluster/servlets-examples

Requests to the URI servlets-examples are
routed to this proxy cluster, and requests are load-balanced across
that cluster.


mod_dbd, while not particularly useful
all by itself, provides a mechanism for other modules to use SQL
databases. mod_authn_dbd was mentioned above, and is perhaps the
most important example to date of how mod_dbd can be used. Other
modules are sure to follow. The current 2.3
development version, for example, includes an extension to the
RewriteMap directive that enables
RewriteRule s to use SQL queries to
determine their targets.


With the 2.2 release, there is a new program installed in the
bin directory: "i">httxt2dbm. This takes a text file and converts it to a
DBM file usable with the RewriteMap
directive. httxt2dbm. uses the same DBM
library used when Apache was built., which guarantees that
mod_rewrite can read the file without any

The format of the text file is:

pattern1 target1

pattern2 target2

Assuming that you save this file as "i">rules.in, you convert it to a DBM via the command:

$ httxt2dbm -i rules.in -o rules.map

You can then use rules.map in a rewrite
ruleset using the following syntax:

RewriteMap mapname dbm:/www/conf/rules.map

RewriteEngine On
RewriteRule ^/example/(.*) /otherplace/${mapname:$1}

This configuration causes "c">http://servername/example/pattern1 to be rewritten as
http://servername/otherplace/target1 and
http://servername/example/pattern2 to be
rewritten as "c">http://servername/otherplace/target2. The "c">RewriteMap directive creates a function that can be
called in the RewriteRule directive.

This technique is very useful when you have a large number of
one-to-one mappings. Since RewriteMap checks
the map file with each request, you can update the map file without
having to restart your Web server.

With a text-based map file, using a txt:
directive, rewrites take progressively longer as
the file grows larger. With a dbm:
directive, the lookup time scales much better as
the data set grows, since DBM files are indexed databases.

For more information on mod_rewrite, you should consult the
mod_rewrite documentation at "http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html" class=

and the mod_rewrite recipe wiki at "http://rewrite.drbacchus.com/" class=

HTTPD Options

In previous versions of Apache, there was no convenient way to
determine which modules were loaded. httpd
listed all of the statically compiled modules, but
omitted those that were loaded dynamically. 2.2 now has
–M, which lists all modules

/www> sudo ./bin/httpd -M
Loaded Modules:
    core_module (static)
    mpm_prefork_module (static)
    http_module (static)
    so_module (static)
    authn_file_module (shared)
    authn_default_module (shared)
    rewrite_module (shared)
    php5_module (shared)
    authn_alias_module (shared)
Syntax OK

(This information is loaded from the configuration file, rather
than from the currently running httpd
process. That means that if the configuration file has changed
since the server was started, this may not reflect the
configuration that your web server is actually running with.)


A number of smaller, but still significant, changes occurred in
the 2.2.

Version 5.0 of the Perl
Compatible Regular Expression
library is included with
Apache 2.2, and can be used in all directives that use regular
expressions, including the *
directives (AliasMatch,
ProxyMatch, "c">DirectoryMatch, and so on) and mod_rewrite.

mod_filter introduces the
ability to dynamically add and remove filters from the filter
chain, based on the value of any request or response header or
environment variable.

*Large File
The previous 2 GB file size limit has been removed,
allowing you to serve DVD images or other large files from your
server. Additionally, request bodies of more than 2 GB are also

Apache 2.0 introduced the concept of MPMs
(Multi-Processing Modules) that provide alternate ways to handle
multiple incoming connections at one time. The two most popular
MPMs, Prefork and "i">Worker, take two different approaches: the former uses
multiple processes, while the latter uses multiple threads. The
Event MPM is an experimental MPM based on Worker. It solves the
problem of efficient KeepAlive

KeepAlive doesn’t generally live up
to its promise of improved performance, because, prior to the Event
MPM, a child process or thread was dedicated to the "c">KeepAlive connection. Each connection that was in
KeepAlive ensured that the child process or
thread involved was unable to handle any other incoming connections
until the KeepAliveTimeout had expired.

With the Event MPM, a thread is dedicated to handling
Listening sockets, as well as the sockets
that are in KeepAlive state. This frees up
the other threads to work on new requests. The Event MPM is still
experimental, and has a few open issues. However, it is offered as
a glimpse into what will be available in future versions.

mod_ssl now supports TLS upgrade. This
allows an unencrypted connection to be upgraded to a secure
connection. Among other benefits, you may now have multiple SSL
hosts per IP address. Unfortunately, this is not yet widely
supported by browsers, and so is of limited value. However, the
presence of a server implementation should encourage browser
developers to implement this feature.

* "b">mod_info. mod_info has added the "c">?config argument to display the server’s full
configuration, including file names and line numbers. "c">?config displays each configuration directive in effect,
lists which file and line number it was set on, and shows the order
in which directives are applied. You can access mod_info by loading
the URL "c">http://servername/server-info?config. "i">Figure Two shows a sample result.

Additionally, several other similar arguments that were
previously undocumented have been added to the documentation.
?hooks lists hooks and which modules are
attached to those hooks. ?list lists what
modules are enabled, including both statically and
dynamically-loaded modules.

The ?server argument lists base server
settings, including build settings, as shown in "i">Figure Three.

Finally, ? "i">module_name lists just the configuration for that
particular module. For example, the URL "http://localhost/server-info?mod_rewrite.c" class=
just the configuration directives in effect for mod_rewrite.

Moving Ahead

The Apache HTTP Server version 2.2 is a major advancement over
previous versions of the server. The reasons to upgrade greatly
outweight the pain of migration. Taken individually, many of the
new features listed above would justify upgrading, but taken
together, you owe it to your system administrators and your users
to upgrade immediately.

Additional information about the 2.2 version of the server can
be found in the documentation at "http://httpd.apache.org/docs/2.2/" class=
. Quick answers
to your questions may be obtained in the #apache
channel on the irc.freenode.net
IRC network.

For an overview of what has changed between 2.0 and 2.2, look at
the list in the documentation at "http://httpd.apache.org/docs/new_features_2_2.html" class=

Comments on "What’s New in Apache 2.2"


Very useful article. I have been away from the scene and this article gave me a reason to get back to Apache.

The mod_rewrite has always been challenging and I hope Apache 2.2 has made is simple. What is so difficult to think in event paradigm and provide hooks based on that? Apache 2.0 started with that but it needs to be more explicit and made easier. Yes, mod_perl provides that, but even that need to be simplified.

But kudos to all the volunteers who continue to keep Apache the #1 in the game.

Thanks to the author for the lucid examples.



In the example for Reverse Proxy Configuration example:

ProxyRequests Off

Order deny,allow
Allow from all

ProxyPass /images http://images.example.com/images
ProxyPassReverse /foo http://images.example.com/images

The last line should read:

ProxyPass /images http://images.example.com/images
ProxyPassReverse /images http://images.example.com/images




Im still using apache 2.0.5x with php and tomcat, (modjk1, modjk2)and i found so interesting this article particulary with the mod_proxy balancer module…i hope migrate my web servers to this new version…..

Major thankies for the article. Great.

Looking forward to reading more. Great blog article.Really thank you! Much obliged.

I simply could not depart your web site before suggesting that I really loved the usual information a person supply for your guests?
Is going to be back ceaselessly in order to investigate cross-check new posts

Leave a Reply