精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
锐英源精品开源心得，转载请注明：“锐英源www.wisestudy.cn，孙老师作品，电话13803810136。需要全文内容也请联系孙老师。
The following sections give brief descriptions of each of the phases and their purposes. 以下部分提供了每一个阶段的简短描述和他们的用途。
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 例子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.
URI转换阶段通常用于一个URI转换成文件系统位置,或进入另一个URI。转换可能并不精确，这是因为其在过程中的早期位置,但无论如何这就是它的。
Example modules that use this phase: 模块使用这个阶段示例:
· mod_alias
· mod_rewrite
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 阶段。
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.
自由访问控制依赖于用户提供的凭证来响应弹出用户名/密码对话框，当服务器告诉它所请求的资源限制时浏览器将呈现上述对话框。用户提供的凭证和Apache定义的任何类型数据库里的应用程序资源数据进行比较；2者匹配意味着身份验证成功和可以继续访问检查。
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.
注意：这些用户凭据可能以纯文本的形式在网络传送，这种情况还不少;即，他们不是所有的都加密。这使得他们容易被截获和窃取。此外,大多数(如果不是全部的话)的Web服务器现在—包括Apache——不要从特定的来源限制连续身份验证失败数量,所以黑客很容易在一个Web服务器中发起字典攻击。
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的数据库作为一个特定群体的一部分，等等。
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.
称为访问检查阶段，这一任务是检查请求，客户端接头的特征，等等，并作出关于该请求是否应被拒绝的决定。因为没有自由支配凭证检查——甚至没有处理程序在这个阶段可以返回一个“未经授权的”状态,结果重试;只有OK或HTTP_FORBIDDEN是合适的。
Example module that uses this phase:,使用这一阶段的示例模块:
· mod_access
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).
这是指任何用户提供的凭据在服务器数据库中查找和验证阶段。在这个阶段的处理程序通常的反应是正常（即凭证有效），拒绝（这意味着处理器是没有资格来判断），或HTTP_UNAUTHORIZED（意思是有一些错误的凭据，如密码不匹配或完全无效的用户名)。
This phase will not be invoked unless there is a Require directive in the current scope (see the main Apache documentation for details).
这一阶段将不会被调用，除非在当前范围要求指令（详见Apache主文档）。
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.
一旦客户的凭证已经被证明是正确的,下一步就是,看看他们的被请求的资源访问列表。在Apache术语中,身份验证和授权阶段通常结合,但不一定;不同的资源可能有不同的访问列表,但共享相同的用户列表。
The usual returns from a handler in this phase are OK (access granted), DECLINED (not qualified), or HTTP_UNAUTHORIZED (try again with different credentials).
通常在这个阶段返回从一个处理程序是OK(访问授予),DECLINED(不合格),或HTTP_UNAUTHORIZED(再次尝试不同的凭证)。
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).
这个阶段给模块机会检查请求和资源的属性，并做出有关的资源的类型的注释。通常处理程序的响应是OK(r->content_type等其他适当地更新)和DECLINED(通常是因为一些其他模块已经完成了工作)。
Example modules that use this phase:使用这个阶段的示例模块:
· mod_mime
· mod_mime_magic
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
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:这个阶段的示例模块: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.
模块和Apache主核心代码之间的二进制兼容性是使用MODULE_MAGIC_NUMBER来衡量。这是在Apache头文件中定义和自动包含在模块结构当模块被编译为恒定值。随着API发展,MMN增加了Apache开发团队,取决于早期版本的变化的兼容性。
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).
这种机制有许多缺点,但它至少可以防止模块不当使用API例程，语义发生了变化,或者从调用例程可能不可用(如果核心代码的价值大于模块)。
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 模块代码编写应该是模块化的,线程安全的,并注册清理