Basic concepts

We begin with an overview of the basic concepts behind the API, and how they are manifested in the code.

Handlers, Modules, and Requests

Apache breaks down request handling into a series of steps, more or less the same way the Netscape server API does (although this API has a few more stages than NetSite does, as hooks for stuff I thought might be useful in the future). These are:

• URI -> Filename translation
• Auth ID checking [is the user who they say they are?]
• Auth access checking [is the user authorizedhere?]
• Access checking other than auth
• Determining MIME type of the object requested
• 'Fixups' -- there aren't any of these yet, but the phase is intended as a hook for possible extensions likeSetEnv, which don't really fit well elsewhere.
• Actually sending a response back to the client.
• Logging the request

These phases are handled by looking at each of a succession ofmodules, looking to see if each of them has a handler for the phase, and attempting invoking it if so. The handler can typically do one of three things:

• Handlethe request, and indicate that it has done so by returning the magic constantOK.
• Declineto handle the request, by returning the magic integer constantDECLINED. In this case, the server behaves in all respects as if the handler simply hadn't been there.
• Signal an error, by returning one of the HTTP error codes. This terminates normal handling of the request, although an ErrorDocument may be invoked to try to mop up, and it will be logged in any case.

Most phases are terminated by the first module that handles them; however, for logging, 'fixups', and non-access authentication checking, all handlers always run (barring an error). Also, the response phase is unique in that modules may declare multiple handlers for it, via a dispatch table keyed on the MIME type of the requested object. Modules may declare a response-phase handler which can handleanyrequest, by giving it the key*/*(i.e., a wildcard MIME type specification). However, wildcard handlers are only invoked if the server has already tried and failed to find a more specific response handler for the MIME type of the requested object (either none existed, or they all declined).

The handlers themselves are functions of one argument (arequest_recstructure. vide infra), which returns an integer, as above.

A brief tour of a module

At this point, we need to explain the structure of a module. Our candidate will be one of the messier ones, the CGI module -- this handles both CGI scripts and theScriptAliasconfig file command. It's actually a great deal more complicated than most modules, but if we're going to have only one example, it might as well be the one with its fingers in every place.

Let's begin with handlers. In order to handle the CGI scripts, the module declares a response handler for them. Because ofScriptAlias, it also has handlers for the name translation phase (to recognizeScriptAliased URIs), the type-checking phase (anyScriptAliased request is typed as a CGI script).

The module needs to maintain some per (virtual) server information, namely, theScriptAliases in effect; the module structure therefore contains pointers to a functions which builds these structures, and to another which combines two of them (in case the main server and a virtual server both haveScriptAliases declared).

Finally, this module contains code to handle theScriptAliascommand itself. This particular module only declares one command, but there could be more, so modules havecommand tableswhich declare their commands, and describe where they are permitted, and how they are to be invoked.

A final note on the declared types of the arguments of some of these commands: apoolis a pointer to aresource poolstructure; these are used by the server to keep track of the memory which has been allocated, files opened,etc., either to service a particular request, or to handle the process of configuring itself. That way, when the request is over (or, for the configuration pool, when the server is restarting), the memory can be freed, and the files closed,en masse, without anyone having to write explicit code to track them all down and dispose of them. Also, acmd_parmsstructure contains various information about the config file being read, and other status information, which is sometimes of use to the function which processes a config-file command (such asScriptAlias). With no further ado, the module itself:

STANDARD_MODULE_STUFF, NULL, /* initializer */ NULL, /* dir config creator */ NULL, /* dir merger */ make_cgi_server_config, /* server config */ merge_cgi_server_config, /* merge server config */ cgi_cmds, /* command table */ cgi_handlers, /* handlers */ translate_scriptalias, /* filename translation */ NULL, /* check_user_id */ NULL, /* check auth */ NULL, /* check access */ type_scriptalias, /* type_checker */ NULL, /* fixups */ NULL, /* logger */ NULL /* header parser */ };

How handlers work

The sole argument to handlers is arequest_recstructure. This structure describes a particular request which has been made to the server, on behalf of a client. In most cases, each connection to the client generates only onerequest_recstructure.

A brief tour of the request_rec

request_reccontains pointers to a resource pool which will be cleared when the server is finished handling the request; to structures containing per-server and per-connection information, and most importantly, information on the request itself.

The most important such information is a small set of character strings describing attributes of the object being requested, including its URI, filename, content-type and content-encoding (these being filled in by the translation and type-check handlers which handle the request, respectively).

Other commonly used data items are tables giving the MIME headers on the client's original request, MIME headers to be sent back with the response (which modules can add to at will), and environment variables for any subprocesses which are spawned off in the course of servicing the request. These tables are manipulated using theap_table_getandap_table_setroutines.

Finally, there are pointers to two data structures which, in turn, point to per-module configuration structures. Specifically, these hold pointers to the data structures which the module has built to describe the way it has been configured to operate in a given directory (via.htaccessfiles orsections), for private data it has built in the course of servicing the request (so modules' handlers for one phase can pass 'notes' to their handlers for other phases). There is another such configuration vector in theserver_recdata structure pointed to by therequest_rec, which contains per (virtual) server configuration data.

Here is an abridged declaration, giving the fields most commonly used:

char *args; /* QUERY_ARGS, if any */ struct stat finfo; /* Set by server core; * st_mode set to zero if no such file */

int header_only; /* HEAD request, as opposed to GET */ char *protocol; /* Protocol, as given to us, or HTTP/0.9 */ char *method; /* GET, HEAD, POST,etc.*/ int method_number; /* M_GET, M_POST,etc.*/

void *per_dir_config; /* Options set in config files,etc.*/ void *request_config; /* Notes on *this* request */

Where request_rec structures come from

Mostrequest_recstructures are built by reading an HTTP request from a client, and filling in the fields. However, there are a few exceptions:

• If the request is to an imagemap, a type map (i.e., a*.varfile), or a CGI script which returned a local 'Location:', then the resource which the user requested is going to be ultimately located by some URI other than what the client originally supplied. In this case, the server does aninternal redirect, constructing a newrequest_recfor the new URI, and processing it almost exactly as if the client had requested the new URI directly.
• If some handler signaled an error, and anErrorDocumentis in scope, the same internal redirect machinery comes into play.

• Finally, a handler occasionally needs to investigate 'what would happen if' some other request were run. For instance, the directory indexing module needs to know what MIME type would be assigned to a request for each directory entry, in order to figure out what icon to use.

  Such handlers can construct asub-request, using the functionsap_sub_req_lookup_file,ap_sub_req_lookup_uri, andap_sub_req_method_uri; these construct a newrequest_recstructure and processes it as you would expect, up to but not including the point of actually sending a response. (These functions skip over the access checks if the sub-request is for a file in the same directory as the original request).

  (Server-side includes work by building sub-requests and then actually invoking the response handler for them, via the functionap_run_sub_req).

Handling requests, declining, and returning error codes

As discussed above, each handler, when invoked to handle a particularrequest_rec, has to return anintto indicate what happened. That can either be

• OK-- the request was handled successfully. This may or may not terminate the phase.
• DECLINED-- no erroneous condition exists, but the module declines to handle the phase; the server tries to find another.
• an HTTP error code, which aborts handling of the request.

Note that if the error code returned isREDIRECT, then the module should put aLocationin the request'sheaders_out, to indicate where the client should be redirectedto.

Special considerations for response handlers

Handlers for most phases do their work by simply setting a few fields in therequest_recstructure (or, in the case of access checkers, simply by returning the correct error code). However, response handlers have to actually send a request back to the client.

They should begin by sending an HTTP response header, using the functionap_send_http_header. (You don't have to do anything special to skip sending the header for HTTP/0.9 requests; the function figures out on its own that it shouldn't do anything). If the request is markedheader_only, that's all they should do; they should return after that, without attempting any further output.

Otherwise, they should produce a request body which responds to the client as appropriate. The primitives for this areap_rputcandap_rprintf, for internally generated output, andap_send_fd, to copy the contents of someFILE *straight to the client.

At this point, you should more or less understand the following piece of code, which is the handler which handlesGETrequests which have no more specific handler; it also shows how conditionalGETs can be handled, if it's desirable to do so in a particular response handler --ap_set_last_modifiedchecks against theIf-modified-sincevalue supplied by the client, if any, and returns an appropriate code (which will, if nonzero, be USE_LOCAL_COPY). No similar considerations apply forap_set_content_length, but it returns an error code for symmetry.

Finally, if all of this is too much of a challenge, there are a few ways out of it. First off, as shown above, a response handler which has not yet produced any output can simply return an error code, in which case the server will automatically produce an error response. Secondly, it can punt to some other handler by invokingap_internal_redirect, which is how the internal redirection machinery discussed above is invoked. A response handler which has internally redirected should always returnOK.

(Invokingap_internal_redirectfrom handlers which arenotresponse handlers will lead to serious confusion).

Special considerations for authentication handlers

Stuff that should be discussed here in detail:

• Authentication-phase handlers not invoked unless auth is configured for the directory.
• Common auth configuration stored in the core per-dir configuration; it has accessorsap_auth_type,ap_auth_name, andap_requires.
• Common routines, to handle the protocol end of things, at least for HTTP basic authentication (ap_get_basic_auth_pw, which sets theconnection->userstructure field automatically, andap_note_basic_auth_failure, which arranges for the properWWW-Authenticate:header to be sent back).

Special considerations for logging handlers

When a request has internally redirected, there is the question of what to log. Apache handles this by bundling the entire chain of redirects into a list ofrequest_recstructures which are threaded through ther->prevandr->nextpointers. Therequest_recwhich is passed to the logging handlers in such cases is the one which was originally built for the initial request from the client; note that thebytes_sentfield will only be correct in the last request in the chain (the one for which a response was actually sent).

Resource allocation and resource pools

One of the problems of writing and designing a server-pool server is that of preventing leakage, that is, allocating resources (memory, open files,etc.), without subsequently releasing them. The resource pool machinery is designed to make it easy to prevent this from happening, by allowing resource to be allocated in such a way that they areautomaticallyreleased when the server is done with them.

The way this works is as follows: the memory which is allocated, file opened,etc., to deal with a particular request are tied to aresource poolwhich is allocated for the request. The pool is a data structure which itself tracks the resources in question.

When the request has been processed, the pool iscleared. At that point, all the memory associated with it is released for reuse, all files associated with it are closed, and any other clean-up functions which are associated with the pool are run. When this is over, we can be confident that all the resource tied to the pool have been released, and that none of them have leaked.

Server restarts, and allocation of memory and resources for per-server configuration, are handled in a similar way. There is aconfiguration pool, which keeps track of resources which were allocated while reading the server configuration files, and handling the commands therein (for instance, the memory that was allocated for per-server module configuration, log files and other files that were opened, and so forth). When the server restarts, and has to reread the configuration files, the configuration pool is cleared, and so the memory and file descriptors which were taken up by reading them the last time are made available for reuse.

It should be noted that use of the pool machinery isn't generally obligatory, except for situations like logging handlers, where you really need to register cleanups to make sure that the log file gets closed when the server restarts (this is most easily done by using the functionap_pfopen, which also arranges for the underlying file descriptor to be closed before any child processes, such as for CGI scripts, areexeced), or in case you are using the timeout machinery (which isn't yet even documented here). However, there are two benefits to using it: resources allocated to a pool never leak (even if you allocate a scratch string, and just forget about it); also, for memory allocation,ap_pallocis generally faster thanmalloc.

We begin here by describing how memory is allocated to pools, and then discuss how other resources are tracked by the resource pool machinery.

Allocation of memory in pools

Memory is allocated to pools by calling the functionap_palloc, which takes two arguments, one being a pointer to a resource pool structure, and the other being the amount of memory to allocate (inchars). Within handlers for handling requests, the most common way of getting a resource pool structure is by looking at thepoolslot of the relevantrequest_rec; hence the repeated appearance of the following idiom in module code:

Note thatthere is noap_pfree--ap_palloced memory is freed only when the associated resource pool is cleared. This means thatap_pallocdoes not have to do as much accounting asmalloc(); all it does in the typical case is to round up the size, bump a pointer, and do a range check.

(It also raises the possibility that heavy use ofap_palloccould cause a server process to grow excessively large. There are two ways to deal with this, which are dealt with below; briefly, you can usemalloc, and try to be sure that all of the memory gets explicitlyfreed, or you can allocate a sub-pool of the main pool, allocate your memory in the sub-pool, and clear it out periodically. The latter technique is discussed in the section on sub-pools below, and is used in the directory-indexing code, in order to avoid excessive storage allocation when listing directories with thousands of files).

Allocating initialized memory

There are functions which allocate initialized memory, and are frequently useful. The functionap_pcallochas the same interface asap_palloc, but clears out the memory it allocates before it returns it. The functionap_pstrduptakes a resource pool and achar *as arguments, and allocates memory for a copy of the string the pointer points to, returning a pointer to the copy. Finallyap_pstrcatis a varargs-style function, which takes a pointer to a resource pool, and at least twochar *arguments, the last of which must beNULL. It allocates enough memory to fit copies of each of the strings, as a unit; for instance:

returns a pointer to 8 bytes worth of memory, initialized to"foo/bar".

Commonly-used pools in the Apache Web server

A pool is really defined by its lifetime more than anything else. There are some static pools in http_main which are passed to various non-http_main functions as arguments at opportune times. Here they are:

permanent_pool

never passed to anything else, this is the ancestor of all pools

pconf

• subpool of permanent_pool
• created at the beginning of a config "cycle"; exists until the server is terminated or restarts; passed to all config-time routines, either via cmd->pool, or as the "pool *p" argument on those which don't take pools
• passed to the module init() functions

ptemp

• sorry I lie, this pool isn't called this currently in 1.3, I renamed it this in my pthreads development. I'm referring to the use of ptrans in the parent... contrast this with the later definition of ptrans in the child.
• subpool of permanent_pool
• created at the beginning of a config "cycle"; exists until the end of config parsing; passed to config-time routinesviacmd->temp_pool. Somewhat of a "bastard child" because it isn't available everywhere. Used for temporary scratch space which may be needed by some config routines but which is deleted at the end of config.

pchild

• subpool of permanent_pool
• created when a child is spawned (or a thread is created); lives until that child (thread) is destroyed
• passed to the module child_init functions
• destruction happens right after the child_exit functions are called... (which may explain why I think child_exit is redundant and unneeded)

ptrans

• should be a subpool of pchild, but currently is a subpool of permanent_pool, see above
• cleared by the child before going into the accept() loop to receive a connection
• used as connection->pool

r->pool

• for the main request this is a subpool of connection->pool; for subrequests it is a subpool of the parent request's pool.
• exists until the end of the request (i.e., ap_destroy_sub_req, or in child_main after process_request has finished)
• note that r itself is allocated from r->pool;i.e., r->pool is first created and then r is the first thing palloc()d from it

For almost everything folks do,r->poolis the pool to use. But you can see how other lifetimes, such as pchild, are useful to some modules... such as modules that need to open a database connection once per child, and wish to clean it up when the child dies.

You can also see how some bugs have manifested themself, such as settingconnection->userto a value fromr->pool-- in this case connection exists for the lifetime ofptrans, which is longer thanr->pool(especially ifr->poolis a subrequest!). So the correct thing to do is to allocate fromconnection->pool.

And there was another interesting bug inmod_include/mod_cgi. You'll see in those that they do this test to decide if they should user->poolorr->main->pool. In this case the resource that they are registering for cleanup is a child process. If it were registered inr->pool, then the code wouldwait()for the child when the subrequest finishes. Withmod_includethis could be any old#include, and the delay can be up to 3 seconds... and happened quite frequently. Instead the subprocess is registered inr->main->poolwhich causes it to be cleaned up when the entire request is done --i.e., after the output has been sent to the client and logging has happened.

Tracking open files, etc.

As indicated above, resource pools are also used to track other sorts of resources besides memory. The most common are open files. The routine which is typically used for this isap_pfopen, which takes a resource pool and two strings as arguments; the strings are the same as the typical arguments tofopen, 例如，

There is also aap_popenfroutine, which parallels the lower-levelopensystem call. Both of these routines arrange for the file to be closed when the resource pool in question is cleared.

Unlike the case for memory, therearefunctions to close files allocated withap_pfopen, andap_popenf, namelyap_pfcloseandap_pclosef. (This is because, on many systems, the number of files which a single process can have open is quite limited). It is important to use these functions to close files allocated withap_pfopenandap_popenf, since to do otherwise could cause fatal errors on systems such as Linux, which react badly if the sameFILE*is closed more than once.

(Using theclosefunctions is not mandatory, since the file will eventually be closed regardless, but you should consider it in cases where your module is opening, or could open, a lot of files).

Other sorts of resources -- cleanup functions

More text goes here. Describe the the cleanup primitives in terms of which the file stuff is implemented; also,spawn_process.

Pool cleanups live untilclear_pool()is called:clear_pool(a)recursively callsdestroy_pool()on all subpools ofa; then calls all the cleanups fora; then releases all the memory fora.destroy_pool(a)callsclear_pool(a)and then releases the pool structure itself.i.e.,clear_pool(a)doesn't deletea, it just frees up all the resources and you can start using it again immediately.

Fine control -- creating and dealing with sub-pools, with a note on sub-requests

On rare occasions, too-free use ofap_palloc()and the associated primitives may result in undesirably profligate resource allocation. You can deal with such a case by creating asub-pool, allocating within the sub-pool rather than the main pool, and clearing or destroying the sub-pool, which releases the resources which were associated with it. (This reallyisa rare situation; the only case in which it comes up in the standard module set is in case of listing directories, and then only withverylarge directories. Unnecessary use of the primitives discussed here can hair up your code quite a bit, with very little gain).

The primitive for creating a sub-pool isap_make_sub_pool, which takes another pool (the parent pool) as an argument. When the main pool is cleared, the sub-pool will be destroyed. The sub-pool may also be cleared or destroyed at any time, by calling the functionsap_clear_poolandap_destroy_pool, respectively. (The difference is thatap_clear_poolfrees resources associated with the pool, whileap_destroy_poolalso deallocates the pool itself. In the former case, you can allocate new resources within the pool, and clear it again, and so forth; in the latter case, it is simply gone).

One final note -- sub-requests have their own resource pools, which are sub-pools of the resource pool for the main request. The polite way to reclaim the resources associated with a sub request which you have allocated (using theap_sub_req_...functions) isap_destroy_sub_req, which frees the resource pool. Before calling this function, be sure to copy anything that you care about which might be allocated in the sub-request's resource pool into someplace a little less volatile (for instance, the filename in itsrequest_recstructure).

(Again, under most circumstances, you shouldn't feel obliged to call this function; only 2K of memory or so are allocated for a typical sub request, and it will be freed anyway when the main request pool is cleared. It is only when you are allocating many, many sub-requests for a single main request that you should seriously consider theap_destroy_...functions).

Configuration, commands and the like

One of the design goals for this server was to maintain external compatibility with the NCSA 1.3 server --- that is, to read the same configuration files, to process all the directives therein correctly, and in general to be a drop-in replacement for NCSA. On the other hand, another design goal was to move as much of the server's functionality into modules which have as little as possible to do with the monolithic server core. The only way to reconcile these goals is to move the handling of most commands from the central server into the modules.

However, just giving the modules command tables is not enough to divorce them completely from the server core. The server has to remember the commands in order to act on them later. That involves maintaining data which is private to the modules, and which can be either per-server, or per-directory. Most things are per-directory, including in particular access control and authorization information, but also information on how to determine file types from suffixes, which can be modified byAddTypeandDefaultTypedirectives, and so forth. In general, the governing philosophy is that anything whichcanbe made configurable by directory should be; per-server information is generally used in the standard set of modules for information likeAliases andRedirects which come into play before the request is tied to a particular place in the underlying file system.

Another requirement for emulating the NCSA server is being able to handle the per-directory configuration files, generally called.htaccessfiles, though even in the NCSA server they can contain directives which have nothing at all to do with access control. Accordingly, after URI -> filename translation, but before performing any other phase, the server walks down the directory hierarchy of the underlying filesystem, following the translated pathname, to read any.htaccessfiles which might be present. The information which is read in then has to bemergedwith the applicable information from the server's own config files (either from thesections inaccess.conf, or from defaults insrm.conf, which actually behaves for most purposes almost exactly like).

Finally, after having served a request which involved reading.htaccessfiles, we need to discard the storage allocated for handling them. That is solved the same way it is solved wherever else similar problems come up, by tying those structures to the per-transaction resource pool.

Per-directory configuration structures

Let's look out how all of this plays out inmod_mime.c, which defines the file typing handler which emulates the NCSA server's behavior of determining file types from suffixes. What we'll be looking at, here, is the code which implements theAddTypeandAddEncodingcommands. These commands can appear in.htaccessfiles, so they must be handled in the module's private per-directory data, which in fact, consists of two separate tables for MIME types and encoding information, and is declared as follows:

typedef struct { table *forced_types; /* Additional AddTyped stuff */ table *encoding_types; /* Added with AddEncoding... */ } mime_dir_config;

When the server is reading a configuration file, orsection, which includes one of the MIME module's commands, it needs to create amime_dir_configstructure, so those commands have something to act on. It does this by invoking the function it finds in the module's 'create per-dir config slot', with two arguments: the name of the directory to which this configuration information applies (orNULLforsrm.conf), and a pointer to a resource pool in which the allocation should happen.

(If we are reading a.htaccessfile, that resource pool is the per-request resource pool for the request; otherwise it is a resource pool which is used for configuration data, and cleared on restarts. Either way, it is important for the structure being created to vanish when the pool is cleared, by registering a cleanup on the pool if necessary).

For the MIME module, the per-dir config creation function justap_pallocs the structure above, and a creates a couple of tables to fill it. That looks like this:

Now, suppose we've just read in a.htaccessfile. We already have the per-directory configuration structure for the next directory up in the hierarchy. If the.htaccessfile we just read in didn't have anyAddTypeorAddEncodingcommands, its per-directory config structure for the MIME module is still valid, and we can just use it. Otherwise, we need to merge the two structures somehow.

To do that, the server invokes the module's per-directory config merge function, if one is present. That function takes three arguments: the two structures being merged, and a resource pool in which to allocate the result. For the MIME module, all that needs to be done is overlay the tables from the new per-directory config structure with those from the parent:

As a note -- if there is no per-directory merge function present, the server will just use the subdirectory's configuration info, and ignore the parent's. For some modules, that works just fine (例如，for the includes module, whose per-directory configuration information consists solely of the state of theXBITHACK), and for those modules, you can just not declare one, and leave the corresponding structure slot in the module itselfNULL.

Command handling

Now that we have these structures, we need to be able to figure out how to fill them. That involves processing the actualAddTypeandAddEncodingcommands. To find commands, the server looks in the module's command table. That table contains information on how many arguments the commands take, and in what formats, where it is permitted, and so forth. That information is sufficient to allow the server to invoke most command-handling functions with pre-parsed arguments. Without further ado, let's look at theAddTypecommand handler, which looks like this (theAddEncodingcommand looks basically the same, and won't be shown here):

This command handler is unusually simple. As you can see, it takes four arguments, two of which are pre-parsed arguments, the third being the per-directory configuration structure for the module in question, and the fourth being a pointer to acmd_parmsstructure. That structure contains a bunch of arguments which are frequently of use to some, but not all, commands, including a resource pool (from which memory can be allocated, and to which cleanups should be tied), and the (virtual) server being configured, from which the module's per-server configuration data can be obtained if required.

Another way in which this particular command handler is unusually simple is that there are no error conditions which it can encounter. If there were, it could return an error message instead ofNULL; this causes an error to be printed out on the server'sstderr, followed by a quick exit, if it is in the main config files; for a.htaccessfile, the syntax error is logged in the server error log (along with an indication of where it came from), and the request is bounced with a server error response (HTTP error status, code 500).

The MIME module's command table has entries for these commands, which look like this:

The entries in these tables are:

• The name of the command
• The function which handles it
• a(void *)pointer, which is passed in thecmd_parmsstructure to the command handler --- this is useful in case many similar commands are handled by the same function.
• A bit mask indicating where the command may appear. There are mask bits corresponding to eachAllowOverrideoption, and an additional mask bit,RSRC_CONF, indicating that the command may appear in the server's own config files, butnotin any.htaccessfile.
• A flag indicating how many arguments the command handler wants pre-parsed, and how they should be passed in.TAKE2indicates two pre-parsed arguments. Other options areTAKE1, which indicates one pre-parsed argument,FLAG, which indicates that the argument should beOnorOff, and is passed in as a boolean flag,RAW_ARGS, which causes the server to give the command the raw, unparsed arguments (everything but the command name itself). There is alsoITERATE, which means that the handler looks the same asTAKE1, but that if multiple arguments are present, it should be called multiple times, and finallyITERATE2, which indicates that the command handler looks like aTAKE2, but if more arguments are present, then it should be called multiple times, holding the first argument constant.
• Finally, we have a string which describes the arguments that should be present. If the arguments in the actual config file are not as required, this string will be used to help give a more specific error message. (You can safely leave thisNULL).

Finally, having set this all up, we have to use it. This is ultimately done in the module's handlers, specifically for its file-typing handler, which looks more or less like this; note that the per-directory configuration structure is extracted from therequest_rec's per-directory configuration vector by using theap_get_module_configfunction.

Side notes -- per-server configuration, virtual servers,etc.

The basic ideas behind per-server module configuration are basically the same as those for per-directory configuration; there is a creation function and a merge function, the latter being invoked where a virtual server has partially overridden the base server configuration, and a combined structure must be computed. (As with per-directory configuration, the default if no merge function is specified, and a module is configured in some virtual server, is that the base configuration is simply ignored).

The only substantial difference is that when a command needs to configure the per-server private module data, it needs to go to thecmd_parmsdata to get at it. Here's an example, from the alias module, which also indicates how a syntax error can be returned (note that the per-directory configuration argument to the command handler is declared as a dummy, since the module doesn't actually have per-directory config data):