©
This document usesPHP Chinese website manualRelease
Warning - this is a first (fast) draft that needs further revision!
Several changes in Apache 2.0 affect the internal request processing mechanics. Module authors need to be aware of these changes so they may take advantage of the optimizations and security enhancements.
The first major change is to the subrequest and redirect mechanisms. There were a number of different code paths in Apache 1.3 to attempt to optimize subrequest or redirect behavior. As patches were introduced to 2.0, these optimizations (and the server behavior) were quickly broken due to this duplication of code. All duplicate code has been folded back intoap_process_request_internal()to prevent the code from falling out of sync again.
This means that much of the existing code was 'unoptimized'. It is the Apache HTTP Project's first goal to create a robust and correct implementation of the HTTP server RFC. Additional goals include security, scalability and optimization. New methods were sought to optimize the server (beyond the performance of Apache 1.3) without introducing fragile or insecure code.
All requests pass throughap_process_request_internal()inrequest.c, including subrequests and redirects. If a module doesn't pass generated requests through this code, the author is cautioned that the module may be broken by future changes to request processing.
To streamline requests, the module author can take advantage of the hooks offered to drop out of the request cycle early, or to bypass core Apache hooks which are irrelevant (and costly in terms of CPU.)
The request'sparsed_uripath is unescaped, once and only once, at the beginning of internal request processing.
This step is bypassed if the proxyreq flag is set, or theparsed_uri.pathelement is unset. The module has no further control of this one-time unescape operation, either failing to unescape or multiply unescaping the URL leads to security reprecussions.
All/../和/./elements are removed byap_getparents(). This helps to ensure the path is (nearly) absolute before the request processing continues.
This step cannot be bypassed.
Every request is subject to anap_location_walk()call. This ensures that
Modules can determine the file name, or alter the given URI in this step. For example,mod_vhost_aliaswill translate the URI's path into the configured virtual host,mod_aliaswill translate the path to an alias path, and if the request falls back on the core, theDocumentRootis prepended to the request resource.
If all modulesDECLINEthis phase, an error 500 is returned to the browser, and a "couldn't translate name" error is logged automatically.
After the file or correct URI was determined, the appropriate per-dir configurations are merged together. For example,mod_proxycompares and merges the appropriateTRACErequest, the core handles the request and returnsDONE. If no module answers this hook withOK或DONE, the core will run the request filename against the
Every request is hardened by a secondap_location_walk()call. This reassures that a translated request is still subjected to the configuredlocation_walkabove, so this step is almost always very efficient unless the translated URI mapped to a substantially different path or Virtual Host.
The main request then parses the client's headers. This prepares the remaining request processing steps to better serve the client's request.
Needs Documentation. Code is:
switch (ap_satisfies(r)) { case SATISFY_ALL: case SATISFY_NOSPEC: if ((access_status = ap_run_access_checker(r)) != 0) { return decl_die(access_status, "check access", r); } if (ap_some_auth_required(r)) { if (((access_status = ap_run_check_user_id(r)) != 0) || !ap_auth_type(r)) { return decl_die(access_status, ap_auth_type(r) ? "check user. No user file?" : "perform authentication. AuthType not set!", r); } if (((access_status = ap_run_auth_checker(r)) != 0) || !ap_auth_type(r)) { return decl_die(access_status, ap_auth_type(r) ? "check access. No groups file?" : "perform authentication. AuthType not set!", r); } } break; case SATISFY_ANY: if (((access_status = ap_run_access_checker(r)) != 0)) { if (!ap_some_auth_required(r)) { return decl_die(access_status, "check access", r); } if (((access_status = ap_run_check_user_id(r)) != 0) || !ap_auth_type(r)) { return decl_die(access_status, ap_auth_type(r) ? "check user. No user file?" : "perform authentication. AuthType not set!", r); } if (((access_status = ap_run_auth_checker(r)) != 0) || !ap_auth_type(r)) { return decl_die(access_status, ap_auth_type(r) ? "check access. No groups file?" : "perform authentication. AuthType not set!", r); } } break; }
The modules have an opportunity to test the URI or filename against the target resource, and set mime information for the request. Bothmod_mime和mod_mime_magicuse this phase to compare the file name or contents against the administrator's configuration and set the content type, language, character set and request handler. Some modules may set up their filters or other request handling parameters at this time.
If all modulesDECLINEthis phase, an error 500 is returned to the browser, and a "couldn't find types" error is logged automatically.
Many modules are 'trounced' by some phase above. The fixups phase is used by modules to 'reassert' their ownership or force the request's fields to their appropriate values. It isn't always the cleanest mechanism, but occasionally it's the only option.
This phase isnotpart of the processing inap_process_request_internal(). Many modules prepare one or more subrequests prior to creating any content at all. After the core, or a module callsap_process_request_internal()it then callsap_invoke_handler()to generate the request.
Modules that transform the content in some way can insert their values and override existing filters, such that if the user configured a more advanced filter out-of-order, then the module can move its order as need be. There is no result code, so actions in this hook better be trusted to always succeed.
The module finally has a chance to serve the request in its handler hook. Note that not every prepared request is sent to the handler hook. Many modules, such asmod_autoindex, will create subrequests for a given URI, and then never serve the subrequest, but simply lists it for the user. Remember not to put required teardown from the hooks above into this module, but register pool cleanups against the request pool to free resources as required.