APACHE学习笔记(二) Hooks
时间：2007-05-10 来源：Givemefive
The usual hooks for processing a request in Apache 2.0 are described next.
post_read_request—This is the first hook available to modules in normal request processing. It is available to modules that need to hook very early into processing a request.
translate_name—Apache maps the request URL to the filesystem. A module can insert a hook here to substitute its own logic—for example, mod_alias.
map_to_storage—Since the URL has been mapped to the filesystem, we are now <Directory> and <Files>in a position to apply per-directory configuration ( sections and their variants, including any relevant .htaccess files if enabled). This hook enables Apache to determine the configuration options that apply to this request. It applies normal configuration directives for all active modules, so few modules should ever need to apply hooks here. The only standard module to do so is mod_proxy.
header_parser—This hook inspects the request headers. It is rarely used, as modules can perform that task at any point in the request processing, and they usually do so within the context of another hook.mod_setenvif is a standard module that uses a header_parser to set internal environment variables according to the request headers.
access_checker—Apache checks whether access to the requested resource is permitted according to the server configuration (httpd.conf). A module can add to or replace Apache’s standard logic, which implements the Allow/Deny From directives in mod_access (httpd 1.x and 2.0) or mod_authz_host (httpd 2.2).
check_user_id—If any authentication method is in use, Apache will apply the relevant authentication and set the username field r->user. A module may implement an authentication method with this hook.
auth_checker—This hook checks whether the requested operation is permitted to the authenticated user.
type_checker—This hook applies rules related to the MIME type (where applicable) of the requested resource, and determines the content handler to use (if not already set). Standard modules implementing this hook include mod_negotiation(selection of a resource based on HTTP content negotiation) and mod_mime (setting the MIME type and handler information according to standard configuration directives and conventions such as filename “extensions”).
fixups—This general-purpose hook enables modules to run any necessary processing after the preceding hooks but before the content generator. Like post_read_request, it is something of a catch-all, and is one of the most commonly used hooks.
handler—This is the content generator hook. It is responsible for sending an appropriate response to the client. If there are input data, the handler is also responsible for reading them. Unlike the other hooks, where zero or many functions may be involved in processing a request, every request is processed by exactly one handler.
log_transaction—This hook logs the transaction after the response has been returned to the client. A module may modify or replace Apache’s standard logging.
post_read_request—This is the first hook available to modules in normal request processing. It is available to modules that need to hook very early into processing a request.
translate_name—Apache maps the request URL to the filesystem. A module can insert a hook here to substitute its own logic—for example, mod_alias.
map_to_storage—Since the URL has been mapped to the filesystem, we are now <Directory> and <Files>in a position to apply per-directory configuration ( sections and their variants, including any relevant .htaccess files if enabled). This hook enables Apache to determine the configuration options that apply to this request. It applies normal configuration directives for all active modules, so few modules should ever need to apply hooks here. The only standard module to do so is mod_proxy.
header_parser—This hook inspects the request headers. It is rarely used, as modules can perform that task at any point in the request processing, and they usually do so within the context of another hook.mod_setenvif is a standard module that uses a header_parser to set internal environment variables according to the request headers.
access_checker—Apache checks whether access to the requested resource is permitted according to the server configuration (httpd.conf). A module can add to or replace Apache’s standard logic, which implements the Allow/Deny From directives in mod_access (httpd 1.x and 2.0) or mod_authz_host (httpd 2.2).
check_user_id—If any authentication method is in use, Apache will apply the relevant authentication and set the username field r->user. A module may implement an authentication method with this hook.
auth_checker—This hook checks whether the requested operation is permitted to the authenticated user.
type_checker—This hook applies rules related to the MIME type (where applicable) of the requested resource, and determines the content handler to use (if not already set). Standard modules implementing this hook include mod_negotiation(selection of a resource based on HTTP content negotiation) and mod_mime (setting the MIME type and handler information according to standard configuration directives and conventions such as filename “extensions”).
fixups—This general-purpose hook enables modules to run any necessary processing after the preceding hooks but before the content generator. Like post_read_request, it is something of a catch-all, and is one of the most commonly used hooks.
handler—This is the content generator hook. It is responsible for sending an appropriate response to the client. If there are input data, the handler is also responsible for reading them. Unlike the other hooks, where zero or many functions may be involved in processing a request, every request is processed by exactly one handler.
log_transaction—This hook logs the transaction after the response has been returned to the client. A module may modify or replace Apache’s standard logging.
相关阅读 更多 +
