Introduction to Apache Modules

One of Apache's greatest strengths is its modular structure. All configuration directives are part of one module or another, and while in earlier versions of Apache these modules were all painstakingly turned on or off at compile time, nowadays almost all modules are available as dynamic shared objects (DSOs) and can simply be loaded at runtime.

Built-in Modules

To see which modules are compiled statically into Apache, use httpd -l:

# httpd -l Compiled-in modules:   http_core.c   mod_so.c suexec: disabled; invalid wrapper /usr/local/sbin/suexec

This means that the directives in the Core module and the mod_so module are the only ones guaranteed to be available. The Core module provides access to the most fundamental directives without which Apache could not run at all; mod_so enables DSO support, which makes it possible to load all the approximately 32 further modules that ship with Apache, as well as any additional modules that you might choose to install.

Note

Ignore the note about suexec; this is a utility that allows Apache to run in a setuid wrapper, executing requests as a specified user (usually different for every virtual host). The suexec wrapper isn't installed by default; you can read more about it at http://httpd.apache.org/docs/1.3/suexec.html. Also, in Chapter 30, "Network Security," we cover CGIwrap, a more versatile alternative to suexec.

Note that Apache 2.x may not display the line about suexec, and its list of DSOs is significantly different.

Dynamically Loaded Modules

Dynamic modules are functional libraries that can be added to or removed from the Apache server at the time you run it, instead of having to be compiled into the httpd binary. These modules (also known as DSOs, or Dynamic Sharable Objects) allow you to trim down the size of your running httpd processes by eliminating modules you don't need. This can easily be done at runtime by commenting out the unnecessary modules from httpd.conf. If you decide later that you need the functionality in a certain module, just reenable it and restart Apache. A complete listing of all the Apache modules and which directives are part of each module can be found at http://httpd.apache.org/docs/1.3/mod/.

To enable a module, you need both the LoadModule directive (which dynamically links the module into the httpd process) and the AddModule directive (which enables the module's directives in the correct order for further use in the configuration file). If you look in httpd.conf, you'll find LoadModule and AddModule directives for all the bundled Apache modules, which are installed into /usr/local/libexec/apache. Something to note about LoadModule is that each LoadModule directive is processed inline before proceeding, so the order in which the modules are specified matters. If a module depends on another module already being linked in, the dependency must be invoked first. The default configuration has all this correctly handled for you.

Note

AddModule directives are not required in Apache 2.x.

Third-Party Modules

The real strength of Apache's modular structure comes with third-party modules. These modules are linked in at runtime with the rest of the available Apache modules, providing additional functionality and configuration directivesusually to give Apache the ability to process certain kinds of server-side content more efficiently. One popular module is mod_perl, which embeds a Perl interpreter into Apache, greatly speeding up Perl CGI scripts by obviating the need for Apache to start up a subshell process and execute the CGI program within it with every request (you learn more about mod perl in an upcoming subsection of this chapter). Another is mod_php4, a module that gives Apache the ability to parse and serve dynamic PHP pages (the UNIX analog of Microsoft's ASP technology). More than 100 third-party Apache modules are available in the ports collection in /usr/ports/www; they're the ones beginning with mod_.

Building Modules with apxs

Early in the development of the first third-party modules, when DSO support was experimental at best, compiling a third-party module meant having the Apache source available, tweaking the build configuration files in both the Apache source and the module's source, and cross-compiling them into a single, hybrid binary. Although this was technically a "modular" approach (which is to say that it was better than having to patch the code manually into the Apache source itself), it still wasn't what anyone would call easy to handle. It still involved building a new executable each time a new version of either Apache or the module became available, and it still involved a fair amount of code hackery to get it to work.

Enter apxs, the Apache Extension tool. This support program, residing in /usr/local/sbin, is built along with Apache to take advantage of the already compiled binary's DSO support (the statically compiled mod_so module) to provide a self-contained build framework that's fully aware of all the capabilities of your httpd binary. You no longer have to have the Apache source code around in order to build third-party modules; apxs compiles and converts modules in raw source form or already compiled objects into .so objects that can be loaded into Apache with the LoadModule directive, along with the rest.

You will most likely never need to use apxs directly; it's a compile-time tool used transparently by the build tools in the ports collection. All you have to do to build a third-party module, just as with any other port, is to go into the module's directory in /usr/ports/www and type make. apxs does the rest. If a new version of Apache is released, it can be built and installed on its own, and third-party modules will continue to work. Likewise, if a module is updated, you can simply rebuild and reinstall it. This is true modularity at its best.

More information on apxs, if you're interested, can be found in the man apxs page.

mod_perl

One of the most popular third-party modules is mod_perl. Although Perl is still the most popular choice for CGI programming (which we'll discuss shortly), executing Perl scripts means a fair amount of overhead for Apache. When an HTTP request is made for a Perl CGI program, Apache must start a shell process and run the script within it, feeding the results back to the client.

With mod_perl, a Perl interpreter is built directly into Apache. Specialized directives define certain file types as executable Perl scripts that Apache can execute itself; further, each Perl script that Apache executes is held in compiled form in memory for later use. This eliminates the startup overhead usually associated with CGI execution, making the response of server-side programs a great deal faster.

More information on mod_perl is available at http://perl.apache.org.

mod_python

In keeping with the rise of Python as the likeliest inheritor of Perl's crown as the server-side programming language of choice in the future, mod_python provides the same kind of benefit to Apache for Python that mod_perl does for Perl. The Python interpreter is made directly available to the Apache executable, allowing Apache to run Python programs without any of the execution overhead of doing it through CGI.

The mod_python home page is at http://www.modpython.org.

mod_php

PHP, the wildly popular dynamic page-generation tool for UNIX, is made a part of Apache through the mod_php4 and mod_php5 modules. The directives enabled by this module family let Apache serve .php files completely natively, executing their embedded scripting functionality to generate the final form of a page before sending it to the client. When you build and install mod_php4, your httpd.conf file is automatically updated to provide support for the .php and .phps file types.

More information on PHP and mod_php4 can be found at http://www.php.net.

mod_ruby

This module does for the Ruby language what mod_perl and mod_python do for Perl and Python, making the startup of Ruby CGI scripts much faster. This is especially important considering the growing popularity of web application architectures such as Ruby on Rails (http://www.rubyonrails.org), which is gaining in momentum as a competitor to other web application frameworks and technologies.

A great many more modules are available, providing Apache with enough expanded functionality to keep you busy for a long time. Apache's modularity has only fairly recently become completely entrenched, and the widespread availability of standardized third-party modules, coupled with the FreeBSD ports collection, makes for an unprecedented new era in extensible HTTP server administration.

Note

Some third-party modules, useful though they might be, are only available for Apache 1.3, and not for Apache 2.x. Still others come in two flavors, one for each version of Apache; these can be identified by the "2" suffix on their names and the fact that they occur in pairs (for example, mod_log_sql and mod_log_sql2). Be sure to choose the right module for your version of Apacheand the right version of Apache for the modules you want to use!