The --enable-module option of Apache 1.3 and the --enable-modules option of Apache 2 have in common two special arguments that allow you to specify a larger group of modules without listing them explicitly:

• most expands the default list to include a larger selection of the modules available.

• all goes further and builds all modules that aren’t experimental or otherwise treated specially.

Tables 3-2 and 3-3 contrast the modules that are built at the default, most, and all levels, for Apache 1.3 and Apache 2, respectively. Each column adds to the previous one, so the All column contains only those modules that are additional to most. The Explicitly Enabled column details all modules that aren’t included unless explicitly enabled, along with a subheading detailing why.

Some experimental modules are likely to be added to the list of All modules at some point in the future; in Apache 2 this includes mod_file_cache, mod_proxy, and mod_cache. These modules have been listed under Additional rather than Experimental in the Explicitly Enabled column to differentiate them from truly experimental or demonstration modules such as mod_example, which should never be encountered in a production-server environment.

Table 3-2 is the list for Apache 1.3.

Table 3-3. Apache 2 Included Modules (Continued)  

Default	Most	All	Explicitly Enabled
mod_env	mod_rewrite		mod_ldap
mod_http			mod_auth_ldap
mod_imap			mod_logio
mod_include			mod_proxy
mod_log_config			mod_proxy_connect
mod_mime			mod_proxy_ftp
mod_negotiation			mod_proxy_http
mod_setenvif			mod_ssl
mod_so			mod_suexec
mod_status			Example and Experimental:
mod_userdir			mod_bucketeer
			mod_case_filter
			mod_case_filter_in
			mod_echo
			mod_example
			mod_optional_hook_export
			mod_optional_hook_import
			mod_optional_fn_import
			mod_optional_fn_export

Either mod_cgid or mod_cgi is built automatically depending on whether the chosen MPM is threaded. Modules shown indented depend on the module before them; that is, mod_mem_cache requires mod_cache.mod_logio requires mod_log_config.mod_deflate and mod_ssl require external libraries to be built; mod_file_cache, mod_cache, and mod_proxy may migrate to the all list in time. mod_http provides basic HTTP support; it may be removed for those intending to use Apache as a framework for a generic protocol server, but should be kept in general use.

Options concatenate so you can specify both general and specific options together to get the mix of modules you want with the minimum of effort. For example, in Apache 1.3, you can specify this:

[1.3] $ ./configure --enable-module=most --enable-module=rewrite
[1.3] $ ./configure --enable-module=all --disable-module=rewrite --disable-module=so

or in Apache 2, you can specify this:

[2.0] $ ./configure --enable-modules=most --enable-rewrite
[2.0] $ ./configure --enable-modules=all --disable-rewrite --disable-so

Deciding what to include and exclude is made simpler if you choose to build a dynamic server because, as I mentioned earlier, you can simply choose to build all the modules and sort them out later. Once the server is installed, you can then comment out the directives in the configuration for the modules you don’t want. This only breaks down if a module can’t be built dynamically or you want to explicitly disable mod_so (because by definition it can’t be dynamic and load itself ). If you change your mind later, you just uncomment the relevant directives and restart Apache.

Building Apache as a purely dynamic server is almost as simple as building it as a static server, though the options again differ between Apache 1.3 and Apache 2. The approach taken also differs subtly. In Apache 1.3, you have to both enable a module and specify that it’s to be built dynamically; neither implies the other, so if you specify that a module is dynamic without also enabling it, it won’t get built. In Apache 2, if you ask for it to be built dynamically, it’ll also automatically be enabled, which is more reasonable.

The option to create modules dynamically in Apache 1.3 is --enable-shared. This takes the name of a module as an argument or the special value max, which takes the list of enabled modules and makes dynamic any of those modules that are capable of being loaded dynamically. The following is fairly typical of how the majority of Apache 1.3 servers are built:

[1.3] $ ./configure --enable-module=all --enable-shared=max

You could also have used most or left out the --enable-module option if you wanted fewer modules compiled. max operates on the result of the combination of all the --enable-module options you specify; it doesn’t imply a particular set of modules in and of itself.

Apache 2 does away with separate options and instead provides a single combined option, --enable-mods-shared, which both enables and makes dynamic the module or list of modules you specify. As with --enable-modules, you can also specify most or all. The equivalent to the previous command in Apache 2 is this:

[2.0] $ ./configure --enable-mods-shared=all

More interestingly, you can also keep Apache a primarily static server but make one or two modules dynamic, or vice versa, so you can have the best of both worlds. This allows you to take advantage of the slightly increased performance benefits of binding a module statically into the server but at the same time keeping optional features external to the server so that they can be removed to make Apache more lightweight without it.

For example, mod_rewrite is very powerful, but it’s large, so if you’re not sure whether you’ll actually be using it, you can only make it dynamic with this (depending on what else you’ve enabled):

[1.3] $ ./configure --enable-module=all --enable-shared=rewrite
[1.3] $ ./configure --enable-module=most
        --enable-module=rewrite --enable-shared=rewrite

You don’t need to enable mod_rewrite explicitly in the first example because it’s covered by all. Otherwise, you need to add an --enable-module=rewrite as well. Apache 1.3 doesn’t build it by default.

The equivalent for Apache 2 is this:

[2.0] $ ./configure --enable-modules=all --enable-mods-shared=rewrite,...
[2.0] $ ./configure --enable-modules=most --enable-mods-shared=rewrite,...

Interestingly, you can also make a module shared by giving the --enable option the value shared, so you could also have said this:

[2.0] $ ./configure --enable-modules=all --enable-rewrite=shared ...

Even if you choose to build Apache statically, you can still include the mod_so module to allow dynamically loaded modules to be added to the server later. In Apache 1.3 you do this by enabling all modules (which includes mod_so), making any module dynamic, or explicitly add mod_so with this:

[1.3] $ ./configure --enable-module=so ...

Conversely, Apache 2 automatically includes mod_so even in a fully static server. If you don’t want it, you must explicitly disable it using any of these:

[2.0] $ ./configure --disable-so ...
[2.0] $ ./configure --enable-so=no ...
[2.0] $ ./configure --disable-module=so,... ...

Alternatively, you can build a mostly dynamic server with one or two modules built statically. It’s rare that you wouldn’t want mod_access or mod_mime not built into the server, so you can make them static with this:

[1.3] $ ./configure --enable-module=all --enable-shared=all --disable-shared=access
             --disable-shared=mime

To do the same for Apache 2, you make use of the last argument you can give to an --enable option: static. This is the only way to reverse the status of a module from dynamic back to built-in because there are no such options as --disable-mods-shared or --enable-mods-static in Apache 2 (at least not currently):

[2.0] $ ./configure --enable-modules=all --enable-access=static
                  --enable-mime=static

When Apache is built from this configuration, it automatically inserts the directives to load dynamic modules, saving you the trouble of doing it yourself. It is, therefore, convenient to build modules even if you don’t really need them. You can comment out the enabling directives and uncomment them later should you change your mind.