SECANDO LAS FIGURAS.

Before moving on to discuss how a module hooks itself into any of the stages of processing a request/data, we should pause to clear up a matter that often causes confusion—namely, the order of processing.

2.7 Request Processing in Apache 49

9. http://apache.webthing.com/mod_proxy_html/

10. http://www.outoforder.cc/projects/apache/mod_transform 11. http://apache.webthing.com/xmlns.html

12. http://modsecurity.org/ 13. http://apache.webthing.com/

The request processing axis is straightforward, with phases happening strictly in order. But confusion arises in the data axis. For maximum efficiency, this axis is pipelined, so the content generator and filters do not run in a deterministic order. For example, you cannot in general set something in an input filter and expect it to apply in the generator or output filters.

The order of processing centers on the content generator, which is responsible for pulling data from the input filter stack and pushing data onto the output filters (where applicable, in both cases). When a generator or filter needs to set something affecting the request as a whole, it must do so before passing any data down the chain (generator and output filters) or before returning data to the caller (input filters).

2.7.6 Processing Hooks

Now that we have an overview of request processing in Apache, we can show how a module hooks into it to play a part.

The Apache module structure declares several (optional) data and function mem- bers:

module AP_MODULE_DECLARE_DATA my_module = {

STANDARD20_MODULE_STUFF, /* macro to ensure version consistency */ my_dir_conf, /* create per-directory configuration record */ my_dir_merge, /* merge per-directory configuration records */ my_server_conf, /* create per-server configuration record */ my_server_merge, /* merge per-server configuration records */ my_cmds, /* configuration directives */

my_hooks /* register modules functions with the core */ };

The configuration directives are presented as an array; the remaining module entries are functions. The relevant function for the module to create request processing hooks is the final member:

static void my_hooks(apr_pool_t *pool) {

/* create request processing hooks as required */ }

Which hooks we need to create here depend on which part or parts of the request our module is interested in. For example, a module that implements a content gen- erator (handler) will need a handler hook, looking something like this:

ap_hook_handler(my_handler, NULL, NULL, APR_HOOK_MIDDLE) ;

Now my_handler will be called when a request reaches the content generation

phase. Hooks for other request phases are similar.

The following prototype applies to a handler for any of these phases:

static int my_handler(request_rec *r) { /* do something with the request */ }

Details and implementation of this prototype are discussed in Chapters 5 and 6.

2.8 Summary

This basic introduction to the Apache platform and architecture sets the scene for the following chapters. We have now looked at the following aspects of Apache:

• The Apache architecture, and its relationship to the operating system • The roles of the principal components: MPMs, APR, and modules • The separation of tasks into initialization and operation

• The fundamental Apache objects and (briefly) the API header files • Configuration basics

• The request processing cycle • The data axis and filter architecture

Nothing in this general overview is specific to C programming, so Chapter 2 should be equally relevant to scripting languages. Together with the next two chap- ters (on the APR and programming techniques, respectively), it provides the essen- tial basis for understanding the core information and advanced topics covered in Chapters 5–11. In those chapters, the concepts introduced here are examined in more detail, and demonstrated in the context of developing real applications.

The Apache Portable Runtime (APR) and Utilities (APR-UTILS or APU) are a pair of libraries used by the Apache httpd, but autonomously developed and main-

tained within the ASF. Although many core developers are involved in both httpd

(the webserver) and APR, the projects are separate. These libraries provide core functions that are not specific to webserving but are also useful in more general applications.

Apart from the webserver, the best-known APR application is Subversion, a revision and change control management system. Another is Site Valet, a suite of software for QA and accessibility audit on the Web; Site Valet was developed by this book’s author.

This chapter discusses the APR as it applies to Apache modules. It does not go into subjects such as application initialization, which are necessary but are handled internally by the Apache core code. For developers working outside the webserver

3

53

The Apache Portable

context, this usage is documented clearly within APR itself, and it is covered in the tutorial at http://dev.ariel-networks.com/apr/apr-tutorial/html/ apr-tutorial.html.

3.1 APR

The main purpose of APR is to provide a portable, platform-independent layer for applications. Functions such as filesystem access, network programming, process and thread management, and shared memory are supported in a low-level, cross- platform library. Apache modules that use exclusively APR instead of native system functions are portable across platforms and can expect to compile cleanly—or at worst with a trivial amount of tidying up—on all platforms supported by Apache. Each APR module comprises an application programming interface (API) shared between all platforms, together with implementations of the functions defined in the API. The implementations are often wholly or partly platform-specific, although this issue is of no concern to applications.

At the core of APR is Apache’s resource management (pools), which are discussed in more detail later in this chapter. Table 3-1 provides a full list of the APR modules.

TABLE 3-1 APR Modules

Name Purpose

apr_allocator Used internally for memory allocation

apr_atomic Atomic operations

apr_dso Dynamic loading of code (.so/.dll)

apr_env Reading/setting environment variables

apr_errno Defines error conditions and macros

apr_file_info Properties of filesystem objects and paths

apr_file_io Filesystem I/O

apr_fnmatch Filesystem pattern matching

apr_general Initialization/termination; useful macros