Request Processing Model

For our purposes, the most interesting thing that we have to know about Apache is how it deals with client requests. With this knowledge we can adjust the server to our needs.

As was said in Chapter 2, HTTP is a TCP-based, application-level protocol. TCP, in turn, is a connection-oriented, transport-level protocol. This means that the communicating parties have to establish a network connection before any application-level data can be sent. The communicating parties thus first setup a TCP connection, send and receive HTTP data, and subsequently close the connection.

The request-processing model in Apache also reflects this scheme. What is important, however, is that Apache further splits the three main phases (connect, transmit, disconnect) into smaller ones. The need for having more specialized phases comes from using HTTP, in which we can distinguish many stages of request processing. Such HTTP-related stages include, for instance, client authentication, request verification and classification, and so on. In Apache terminology, each stage is called a ``hook.'' In general, a hook represents a certain class of operations that have to be performed on the request.

The number and type of hooks that process a given request depend on the request itself. Although there exists a default hook sequence, followed by typical HTTP requests, it does not have to be used each time a request is received. Since it is Apache that passes requests between different hooks, it can also modify the default sequence, depending on the status codes returned by the hooks executed so far. In this way, the server can omit some of the hooks, or use some special, normally untouched ones (see Figure 3.1).

Figure 3.1: Each request can be processed by a different sequence of hooks

Each hook can be associated with one or more so-called ``hook functions.'' Apache calls these functions each time a request is passed to the hook. For each hook it is also defined, how they should be called. Two ways are possible: either all the hook functions are called, or they are called sequentially until one of them reports to have handled the request (see Figure 3.2). In case none of the functions can deal with the request, an error occurs. This mechanism allows us to modify the behavior of the whole server: all we have to do is define custom hook functions and associate them with the appropriate hooks. The latter operation is called ``registration.''

Figure 3.2: Each hook decides how its hook functions are called