To understand mod_perl, you should understand how
request processing works within Apache. When Apache receives a
request, it processes it in 11 phases. For every phase, a standard
default handler is supplied by Apache. You can also write your own
Perl handlers for each phase; they will override or extend the
default behavior. The 11 phases (illustrated in Figure 1-4) are:
Figure 1-4. Apache 1.3 request processing phases
This phase occurs when the server has
read all the incoming request's data and parsed the
HTTP header. Usually, this stage is used to perform something that
should be done once per request, as early as possible.
Modules' authors usually use this phase to
initialize per-request data to be used in subsequent phases.
- URI translation
In this phase, the requested URI is
translated to the name of a physical file or the name of a virtual
document that will be created on the fly. Apache performs the
translation based on configuration directives such as
ScriptAlias. This translation can be completely
modified by modules such as mod_rewrite, which
register themselves with Apache to be invoked in this phase of the
- Header parsing
During this phase, you can examine and
modify the request headers and take a special action if
needed—e.g., blocking unwanted agents as early as possible.
- Access control
This phase allows the server owner to
restrict access to specific resources based on various rules, such as
the client's IP address or the day of week.
you want to make sure that a user
really is who he claims to be. To verify his identity, challenge him
with a question that only he can answer. Generally, the question is a
login name and password, but it can be any other challenge that
allows you to distinguish between users.
The service might have various restricted
areas, and you might want to allow the user to access some of these
areas. Once a user has passed the authentication process, it is easy
to check whether a specific location can be accessed by that user.
- MIME type checking
Apache handles requests for different types
of files in different ways. For static HTML files, the content is
simply sent directly to the client from the filesystem. For CGI
scripts, the processing is done by mod_cgi, while for mod_perl
programs, the processing is done by mod_perl and the appropriate Perl
handler. During this phase, Apache actually decides on which method
to use, basing its choice on various things such as configuration
directives, the filename's extension, or an analysis
of its content. When the choice has been made, Apache selects the
appropriate content handler, which will be used in the next phase.
This phase is provided to allow
last-minute adjustments to the environment and the request record
before the actual work in the content handler starts.
This is the phase where most of the work
happens. First, the handler that generates the response (a content
handler) sends a set of HTTP headers to the client. These headers
include the Content-type header, which is either
picked by the MIME-type-checking phase or provided dynamically by a
program. Then the actual content is generated and sent to the client.
The content generation might entail reading a simple file (in the
case of static files) or performing a complex database query and
HTML-ifying the results (in the case of the dynamic content that
mod_perl handlers provide).
This is where mod_cgi, Apache::Registry, and other
content handlers run.
By default, a single line describing
every request is logged into a flat file. Using the configuration
directives, you can specify which bits of information should be
logged and where. This phase lets you hook custom logging
handlers—for example, logging into a relational database or
sending log information to a dedicated master machine that collects
the logs from many different hosts.
At the end of each request, the
modules that participated in one or more previous phases are allowed
to perform various cleanups, such as ensuring that the resources that
were locked but not freed are released (e.g., a process aborted by a
user who pressed the Stop button), deleting temporary files, and so
Each module registers its cleanup code, either in its source code or
as a separate configuration entry.
At almost every phase, if there is an error and the request is
aborted, Apache returns an error code to the client using the default
error handler (or a custom one, if provided).