当前位置:锐英源 / 英语翻译 / Apache / Apeche请求处理阶段
Java 安卓移动开发
Java Web开发
Q Q:396806883



The following sections give brief descriptions of each of the phases and their purposes. 以下部分提供了每一个阶段的简短描述和他们的用途。

Post-read Phase Post-read 阶段

This phase is the first, and begins as soon as the server has read the request header from the client. Modules typically use this phase to make notes or decisions about the request (such as by setting environment variables).


Examples 例子
· mod_setenvif

URI Translation Phase URI转换阶段

The URI translation phase is typically used to translate a URI into a filesystem location, or possibly into another URI. This is not always appropriate due to its early position in the process, but that’s what it’s for anyway.


Example modules that use this phase: 模块使用这个阶段示例:
· mod_alias
· mod_rewrite

Header Field Parsing 包头字段解析

The header field parsing phase is called third in the sequence, and was originally intended to be used to make notes or decisions about the contents of the request header. Unfortunately, this phase turns out to occur too late for some things, so many of the modules that hooked into it in the past now hook into the post-read phase instead.

头字段解析阶段被称为序列中的第三,本来用于做出关于请求头的内容笔记或决定。不幸的是,这个阶段在处理某些事情时被证明太晚了,所以过去本阶段开发的许多模块现在钩到Post-read 阶段。

Security Callbacks 安全回调

The next three callbacks have to do with applying security restrictions, and their interactions are often a source of confusion. The next few paragraphs explain their roles in generic detail (if there is such a thing). If you feel comfortable with the terms mandatory access control, discretionary access control, authentication, and authorisation, go ahead and skip ahead.


Understanding Web-based access control 理解网络访问控制
‘Authentication’ and ‘authorisation’ frequently get confused. Authentication is the process of proving an association or identity between an agent (the end-user in our case) and a defined degree of trust. It’s essentially making someone show an ID card and prove that it’s hers. Authorisation, which comes after authentication, is the process of matching up this proven identity with a set of access rights. It’s quite possible for the authentication step to be passed, but to find the user isn’t authorised to access something.


There are two ways in which Apache can do authentication. In common security parlance, they’re called discretionary and nondiscretionary access control, depending upon whether the information supplied (called the credentials) is at the discretion of the user trying to gain access. A good way to think about it is that authentication is controlled by what you know, what you have, what you are, or some combination of these.

Apache有两种方法可以做认证。在共同安全的说法,他们称自由裁量和不可任意支配的访问控制,取决于提供的信息是否(称为凭证)为用户试图访问信息的钥匙。好的身份验证方法是由what you know, what you have, what you are或这些信息中的一些组合控制。

Nondiscretionary mechanisms rely on aspects of the request that are fundamental and unchangeable, like the IP address. A client system can’t change its IP address, or the server wouldn’t be able to reach it through the net. A door lock that decided whether or not to let you in based on your DNA would be nondiscretionary in nature; you can’t change your genes. This is a ‘what you are’ system.

非自由裁量机制依赖于那些基本的,不可改变的要求,如IP地址的各个方面。客户端系统不能改变其IP地址,或者服务器可能无法通过网络到达。一个门锁,决定是否让你根据你的DNA在自然界中不可任意支配的,你不能改变你的基因。这是一个“what you are”系统。

Discretionary mechanisms rely on something the user provides, such as a username and password. To use the door lock idea again, a combination lock is a ‘what you know’ type, and a regular key lock is a ‘what you have’ type. The problems with these are that multiple people can be privy to the secret for ‘what you know’ systems, and someone could steal (or make a copy of) the key for a ‘what you have’ lock.

自由裁量机制依赖于用户提供的东西,比如用户名和密码。要再次使用门锁的想法,一个密码锁是一个'what you know“类型,一个普通钥匙锁是”what you have"类型。很多人的问题,这些都是可以参与的“what you know”系统中的秘密,有人可能偷(或复制)关键的‘what you have’锁。

The nondiscretionary controls in Apache are based on the client's IP address or domain/host name. Access can be explicitly allowed or denied on an address-by-address basis, or by CIDR or subnet address, or by name. In the case of controls that use host or domain names, Apache does what's called a double-reverse lookup, which means that it translates the user-agent's IP address into a name, and then translates that name back into a set of addresses again. If the original address is in the final list, it's considered valid and the allow or deny rule is put into effect; otherwise, the client doesn't match the condition and the server treats it as not being in the claimed domain at all.

在Apache中的自由裁量非控制是基于客户端的IP地址或域名/主机名。访问可以明确允许或地址按地址基础上予以否认,或CIDR VS子网地址或名称。在使用主机名或域名控制的情况下,,Apache所谓的双左查找,这意味着它将用户代理的IP地址转换为一个名称,然后将这个名字再回一组地址。如果原始地址是在最后的列表,它被认为是有效的;否则,服务器端不匹配条件并且服务器将其视为不是在所要求的领域。

Discretionary access controls depend upon the credentials supplied by the user in response to the pop-up username/password dialogue box the browser presents when the server tells it the requested resource has restrictions. The credentials the user supplies are compared against whatever databases have been defined to Apache as being applicable for the resource; a match on both means authentication has succeeded and the processing can proceed to access checking.


Note: These user credentials are transmitted over the net in what amounts to plaintext; i.e., they're not encrypted at all. This makes them easy to intercept and steal. In addition, most (if not all) Web servers out there now – including Apache – don't put any restrictions on the number of consecutive authentication failures from a particular source, so a cracker can easily bang away at a Web server with a dictionary attack.


The access checking mechanisms in Apache are quite simple: they merely specify what combination of successfully authenticated credentials are allowed access – all others are denied. These combinations can be specific usernames, any valid username, and valid username that is Apache's databases as being part of a particular group, and so on.

在Apache中的访问检查机制是相当简单:他们只是指定哪些成功验证的凭据组合被允许访问 - 所有其他被拒绝。这些组合可以是特定的用户名,任何有效的用户名和有效的用户名是Apache的数据库作为一个特定群体的一部分,等等。

Security: Access 安全:访问

Called the access checking phase, this one is tasked with examining the characteristics of the request, the client connexion, and so on, and making a decision about whether the request should be denied or not. Since no discretionary credentials are examined – or even available – no handler in this phase can return an unauthorised’ status which results in a retry; only OK or HTTP_FORBIDDEN are appropriate.


Example module that uses this phase:,使用这一阶段的示例模块:
· mod_access

Security: Authentication 安全:身份验证

This is the phase at which any user-supplied credentials are looked up in a server database and verified. The usual responses for a handler in this phase are OK (meaning the credentials are valid), DECLINED (meaning the handler isn’t qualified to judge), or HTTP_UNAUTHORIZED (meaning that there’s something wrong with the credentials, such as a password mismatch or a completely invalid username).


This phase will not be invoked unless there is a Require directive in the current scope (see the main Apache documentation for details).


Security: Authorisation 安全:授权

Once the client’s credentials have been verified as being correct, the next step is to see if they’re in the access list for the resource being requested. In Apache terms, the authentication and authorisation phases are typically tightly bound, but that’s not necessarily so; different resources may have different access lists, but share the same user list.


The usual returns from a handler in this phase are OK (access granted), DECLINED (not qualified), or HTTP_UNAUTHORIZED (try again with different credentials).


Type Checking/Setting 类型检查/设置

This phase gives modules a chance to examine the attributes of the request and the resource and make notesabout the type of resource. The usual responses from a handler are OK (with r->content_type et aliabeing updated appropriately) and DECLINED (usually because some other module has already done the work).


Example modules that use this phase:使用这个阶段的示例模块:
· mod_mime
· mod_mime_magic

Fixups 修正

This phase is the last one before the server actually starts sending content back to client, so it’s the last opportunity modules have to made any tweaks or changes (hence the name of the phase).这一阶段是服务器实际上开始发送内容返回到客户端前的最后阶段,这是模块必须做出任何调整或变更名称(因此阶段)的最后一次机会。

Example modules that use this phase:使用这个阶段的示例模块:

· mod_env

Content Handling 内容处理

This is the real workhorse phase; it’s the one that actually gets the resource content to the client. Content generation and transmission is considerably more involved than the other phases, so it’s no wonder that not very many actually contribute to this phase.


Content handling may involve actual content generation, as is done by mod_example, mod_info, and mod_status, or it may involve transforming some existing content before transmission, such as is done by mod_include and mod_php3. 内容处理可能涉及实际的内容生成,通过mod_example mod_info,mod_status,或者它在传输之前可能需要改变现有的一些内容,如通过mod_include mod_php3。

Only one content hander can be invoked for Apache 1.3; this means that there’s no easy way, for instance, to have the output from a CGI script (handled by mod_cgi) parsed by mod_include for server-side include directives. 只有一个内容处理器可以被Apache1.3调用; 这意味着,没有简单的方法,例如,有从由mod_include负责对服务器端解析包括指示CGI脚本(由mod_cgi一样处理)的输出。

Any failure in processing at this or any earlier phase will result in the request being aborted by the Apache core code. 由Apache导致的任何处理故障或早期阶段的核心代码将被中止请求。

Example modules that hook into this phase:这个阶段的示例模块:
· mod_include
· mod_cgi
· mod_php3
· mod_info
· mod_status

Logging 日志记录

This phase is invoked after the content has been sent to the client; this is where all the statistics collected during the request processing may be recorded and/or analysed. Any error during this phase is non-fatal, since the request has already been completed as far as the client is concerned.

Example modules that use this phase:使用这个阶段的示例模块:
· mod_log_config
· mod_log_referer
· mod_log_agent


Binary compatibility between modules and the main Apache core code is measured using a concept called the MODULE_MAGIC_NUMBER. This is a constant value that is defined in the Apache header files and automatically included in the module structure when a module is compiled. As the API grows and evolves, the MMN is incremented by the Apache development team, depending upon the compatibility of the change with earlier versions.


At run time, the core code examines the value stored in the module structure and compares it to the value with which the core code was built. If they’re identical, or indicate compatibility, operation proceeds normally. Otherwise, the core will refuse to include the module in its list and will emit an error message. 在运行时,核心代码检查的值存储在模块结构和与值进行比较的核心代码。如果它们是相同的,或显示兼容性,操作收益正常。否则,将拒绝包括列表的核心模块,并将发出一个错误消息。

This mechanism has many shortcomings, but it at least keeps modules from improperly using API routines whose semantics have changed, or from calling routines that may not be available (if the core code’s value is older than the module’s).


Notes about Module Processing 有关模块处理的注意事项
Here are some final notes about common problems and questions about module writing: 以下是有关的常见问题和有关模块的写作问题,一些最后的注意事项:
· The request_rec is the only currently-supported way of passing information from phase to phase request_rec是唯一支持从第一阶段传递信息到目前阶段的方式
· Modules cannot assume the same child will handle two consecutive requests from the same client 处理连续两个来自相同客户端的请求,模块将不能假设相同的子类
· Module code should always be written to be modular, thread-safe, and register cleanups 模块代码编写应该是模块化的,线程安全的,并注册清理

版权所有 Copyright(c)2004-2015 锐英源软件
公司注册号:410105000449586 豫ICP备08007559号 最佳分辨率 1024*768