超文本传输协议HTTP11RFC 2616中文版 中Word文档格式.docx

1、注意:服务器,缓存,或者客户端的实现者可能会面对设计上的判断,而这些判断没有显示 地在此规范里讨论。如果一个判断可能会影响语义透明性,那么实现者应该能维持语义透明 性,除非一个仔细的完整的分析能说明打破透明性的好处。13.1.1缓存正确性（Cache Correctness一个正确的缓存必须能用最新的响应来响应请求,此响应当在下面的条件满足时才适合此请 求（见 13.2.5, 13.2.6,和 13.12此缓存响应已被检测与假设通过源服务器重验证后源服务器返回的响应相等价。此缓存响应是足够保鲜 （fresh的 （见 13.2节 。 缺省的情况下, 这意味着此响应必须满足客 户端, 源服务器,

2、和缓存的最严格的保鲜要求 （见 14.9节 ; 如果源服务器指定了保鲜寿命, 这说明它是源服务器自己的保鲜要求。由于客户端和源服务器的最严格的保鲜要求,如果一个缓存的响应不是足够保鲜的,那么在 仔细考虑的情况下,缓存可能仍然返回此缓存的响应通过合适的 Warning 头域（见 13.1.5和 14.46节 ,除非此响应被阻止（例如:通过” no-store ” cache-directive ,或者通过 一个” no-cache ” cache-request-directive ;见 14.9节 。此缓存响应是一个 304（没有被改变 , 305（代理重定向 ,或 错误（4xx 或者 5xx

3、 响应消 息。如果缓存不能同源服务器通信,那么一个正确的缓存应该用它缓存的响应去响应请求,如果 此缓存的响应能正确的服务于请求;如果不能服务器于此请求,那么缓存必须能返回一个错 误或警告指示存在通信失败。如果缓存从服务器端接收到一个响应（或者是一个完整的响应,或者一个 304（没有被改变 的响应 , 此响应应该是正常情况下要发送到请求的客户端的, 并且此响应并不是新鲜的, 那 么此缓存应该把此响应转发给请求客户端不需要添加一个新的 Warning 头域（但是没有移去 已经存在的 Warning 头域 。缓存并不是简单的因为传输中响应变得陈旧而尝试去重验证响 应;这可能会导致一个无限的循环。用户

4、代理接收一个陈旧的没有 Warning 头域的响应应该 提示用户一个警告信息。13.1.2警告信息（Warnings 无论何时,缓存返回一个响应,此响应既不是第一手的 （first-hand也不是足够保鲜（在 13.1.1节的条件 2 ,那么缓存必须利用一个 Warning 常用头域来警告产生的效果。 Warning 头域和当前定义的警告在 14.46节里描述。这些警告允许客户端去采取合适的动作。警告可能被用于其他的目的,和缓存相关的目的和其他的目的。警告和错误状态码的区别在 于是否是真正的失败。警告被赋予三位数字 warn-codes 。 第一个数字指明:警告是否必须或不必须从缓存项里删除,

5、 在一个成功的重验证之后。1xx 警告描述了响应的保鲜或重验证状态信息,并且这些信息应该在一个成功的重验证之后 删除。 1xx 警告码可能是由缓存产生的,当缓存验证一个缓存项时。此警告码不能被客户端 产生。2xx 警告描述了实体主体或实体头域的某些方面的信息,这些信息不能被重验证修改,并且 这些信息不能在一个成功重验证之后被删除。见 14.46节关于警告码的定义。HTTP/1.0缓存将缓存所有响应中的警告,并且不会删除第一类警告。穿过 HTTP/1.0缓存响 应中的警告会携带一个额外的 warning-date 域,这是为了防止将来的 HTTP/1.1接收端信任 一个错误的缓存警告。警告同样携

6、带一个警告文本。此文本可能是任何合适的自然语义（可能基于客户端请求的 Accept 头域 ,同时包含一个可选择的关于何种字符集被使用的声明。多个警告可能会绑定一个响应 （或者被源服务器或者被一个缓存发送的 , 这包括多个警告可 以共用一个警告码。例如,服务器可能会以英语和法语提供相同的警告。当多个警告绑定一个响应时, 有时候不可能把所有的警告都展示给客户。 HTTP 版本不能指定 一个严格的优先值去决定警告的优先和顺序显示,但是可以探索一些方法。13.1.3缓存控制机制 （Cache-control MechanismHTTP/1.1基本的缓存机制（服务器指定过期时间和验证器对缓存是隐含的指令

7、。某些情况 下, 服务器或客户端可能需要给 HTTP 缓存提供显示的指令。 我们利用 Cache-Control 头域为 此目的。Cache-Control 头域允许客户端或服务器在请求或响应里传输多个指令。这些指令常常覆盖 缺省的缓存算法。作为一个常用规则,如果头域值中存在一个明显的冲突,那么最具严格解 释的头域值会被应用 （也就是说, 能保留语义透明性的值 。 然而, 一些情况下, cache-control 指令被显示地指定用来削弱语义透明性的相似性（例如, ” max-stale ” 或者 “ public ” 。 Cache-control 指令在 14.9节被描述。13.1.4显示

8、的用户代理警告（Explicit User Agent Warnings很多用户代理允许用户覆盖基本缓存机制。例如,用户代理可能允许用户指定缓存实体（即 使实体明显是陈旧的从来不要被验证。或者,用户代理可能习惯于给任何请求加上 “ Cache-Control :max-stale=3600” 。用户代理不能缺省的执行不透明行为,或者不能缺省 的执行导致非正常的无效率的缓存行为,但是可能被显示地设置去这样做通过一个显示的用 户动作。如果用户已经覆盖基本的缓存机制,那么用户代理应该给用户指示何时显示不能满足服务器 透明要求的信息 （特别地, 如果显示的实体被认为是陈旧的 。 因为此协议通常允许用户

9、代理 去判定响应是否是陈旧或不是陈旧的,所以此指示只需要当实际发生时显示。此指示不必是 对话框;它应该是一个图标（例如,一个正在腐烂的鱼或者一些其他的指示器。如果用户以一种方式已经覆盖了缓存机制,这种方式可能不正常地减少缓存效率,那么用户 代理应该继续指示用户的状态（例如,通过一个图片显示以便用户不能不注意地消费过度 的资源或者忍受过度的延迟。13.1.5规则和警告的例外情况在某些情况下, 缓存的操作者应该设置缓存返回陈旧的响应, 即使此响应没有被客户端请求。 这个判定本来不应该轻易决定,但是由于某些原因可能会这样做,特别是当缓存和源服务器 连接不好时。无能何时当缓存会返回一个陈旧的响应时,缓

10、存必须给此响应做个标记（利用 Warning 头域 ,因为这样能使客户端提示用户响应是陈旧的。用户代理照样能采取步骤去获得第一手的或保鲜的响应。由于这个原因,如果客户端显示地 请求第一手的或保鲜的响应,缓存就不能返回一个陈旧的响应,除非由于技术或策略方面的 原因。13.1.6由客户控制的行为（Client-controlled Behavior当源服务器是过期信息得主要来源时,有时候客户端可能需要控制缓存去判定是否返回一个 缓存响应而不需要缓存通过服务器验证它。客户端通过利用一些 Cache-Control 头域来达到 此目的。客户端的请求可能会指定自己愿意接受一个没有验证的响应的最大的年龄（

11、age ;指定 0值 会强迫缓存重验证所有的响应。客户端照样会指定在响应过期前的最小保持时间。这些选项 增加了对缓存行为的限制,同时这样做并不能进一步地放松缓存语义透明的近似。客户端可能照样会指定它会接受陈旧响应直到陈旧数达到最大数量。 这放松了对缓存的限制, 同时这可能违反了源服务器指定对语义透明性的限制,但是这可能支持无连接的操作或者高 获得性当连接不好时。13.2 过期模型 （Expiration Model13.2.1 服务器指定模型（Server-Specified ExpiratiionHTTP 缓存会工作的很好, 这是因为缓存能完全地避免客户端对源服务器的请求。 避免对源服 务器

12、请求的主要机制是服务器将来会提供一个显示过期时间（explicit expiration time , 此显示过期时间用来指示响应可能会满足后续的请求。也就是说,客户端请求响应时,缓存 能返回一个保鲜（fresh 的响应而不需要从源服务器那里获得。我们希望服务器给响应设置显示过期时间（explicit expiration time ,服务器相信在过期 时间之前实体不会改变。这能保持语义透明性（译注:语义透明性情况 1.3节里关于“语义 透明”的解释 ,只要服务器对过期时间仔细选择。过期机制只能应用于能从缓存获得的响应,不能应用于客户端请求的第一手（first-hand , 见 1.3节术语的

13、响应。如果源服务器希望强制一个语义透明缓存去验证每个请求,它会使显示过期时间（explicit expiration time 设为过去。这就是说响应总是陈旧的,所以此缓存应该验证此响应当缓存 利用此响应去服务于后续的请求时。见 14.9.4节,有更多强迫重验证的方法如果源服务器希望强迫任何 HTTP/1.1缓存（不管此缓存是怎样设置的去验证每一个请求, 源服务器应该在 Cache-Control 头域里指定 “ must-revalidate ” 缓存控制指令 （见 14.9节 。 源服务器利用 Expires 头域或在 Cache-Control 头域里通过 max-age 缓存控制指令,

14、来指定 显示过期时间（explicit expiration time 。过期时间不能被用于强制客户代理去重新刷新它的显示或重载资源;过期的语义只能应用于缓存机制, 并且这个机制值只需要检测资源的过期状态当请求那个资源的一个新请求发生时。 见 13.13节,关于缓存和历史机制的区别。13.2.2 启发式过期因为源服务器不能总是提供一个显示过期时间（explicit expiration time , HTTP 缓存通 常会设置一个启发式过期时间（heuristic expiration time ,它采用一种算法,此算法利 用其它的值（例如 Last-Modified 时间去估计一个似乎合理的

15、过期时间。 HTTP/1.1规范没 有提供特定的算法,但是的确是加强了对这些算法结果的最坏情况的限制。因为启发式过期 时间可能会对语义透明性妥协,他们本应该被谨慎地使用,并且我们鼓励源服务器尽可能提 供显示过期时间。13.2.3 年龄（Age 计算为了了解缓存项（译注:缓存项是用来响应请求的,它包含缓存的响应实体是否是保鲜的 （fresh , 缓存需要知道其年龄是否已超过保鲜寿命 （freshness lifetime 。 我们在 13.2.4节中讨论如何计算保鲜寿命,本节讨论如何计算响应或缓存项的年龄。在此讨论中我们用“ now ”来表示主机进行计算时时钟的“当前值” 。使用 HTTP 协议

16、的主机, 特别是运行于源服务器和缓存的主机, 应该使用 NTP28 或其他类似协议来将其时钟同步到 一个全球性的精确时间标准上。HTTP1.1协议要求源服务器尽可能在发送每条响应时都附加一个 Date 头域, 要尽可能在每个 响应里给出响应产生的时间（见 14.18节 。我们利用术语“ date_value”去表示 Date 头域 的值,这是一种适合于运算操作的表示方法。当从缓存里获取响应消息时, HTTP/1.1利用 Age 响应头域来传送响应消息的估计年龄。 Age 响应头域值是缓存对响应从产生或被重验证开始到现在的时间估计值。实际上,年龄的值是响应从源服务器途径每一个缓存的逗留时间的总和

17、,再加上响应在网络 路径上传输的时间。我们用“ age_value”来表示 Age 头域的值,这是一种适于算术操作的表示方法。一个响应的年龄 （age可以通过两种完全不同的途径来计算 :如果本地时钟与源服务器时钟同步的相当好,则用 now - date_value ,若结果为负,则取 零。如果途径响应路径（response path的所有缓存均遵循 HTTP1.1协议,则用 age_value。 如果我们有两种独立的方法计算响应的年龄 （译注:注意这里是响应的年龄 , 我们可以合并 二者如下:corrected_received_age = max（now date_value, age_va

18、lue并且只要我们或者有同步的时钟或者响应途径的所有缓存遵循 HTTP/1.1, 我们就能得到一个 可信赖的结果。由于网络附加延时, 一些重要时隙会在服务器产生响应与下一个缓存或客户端接收之间流逝。 如果不经修订,这一延迟会带来不正常的低年龄。由于导致产生年龄值的请求（译注:就是存在 Age 头域的请求是早于年龄值的产生,我们 能校正网络附加延迟通过记录请求产生的时间。然后,当一个年龄值被接收后,它必须被解 释成相对于请求产生的时间,而不是相对响应接收的时间。不管有多少延迟,此算法会导致 稳定的结果。所以,我们计算:corrected_initial_age = corrected_recei

19、ved_age + （now - request_time 这里“ request_time”是请求的发送时间。缓存收到响应时,它计算响应年龄的算法如下:/* age_value* is the value of Age: header received by the cache with this response. * date_value* is the value of the origin servers Date: header* request_time* is the （local time when the cache made the request* that resul

20、ted in this cached response* response_time* is the （local time when the cache received the response* now* is the current （local time*/apparent_age = max（0, response_time - date_value ; /缓存收到响应时响应的 年龄corrected_received_age = max（apparent_age, age_value ;response_delay = response_time - request_time;c

21、orrected_initial_age = corrected_received_age + response_delay;resident_time = now - response_time; /即收到响应到现在的时间间隔current_age = corrected_initial_age + resident_time;缓存项 （cache entry 的 current_age是缓存项从被源服务器最后验证开始到现在的时间间 隔（以秒记加上 corrected_initial_age。当从缓存项里产生一条响应时,缓存必须在响 应里包含一个 Age 头域,它的值应该等于缓存项的 cur

22、rent_age值。Age 头域出现在响应里说明响应不是第一手的（first-hand （译注:第一手的说明,响应是 直接来自于源服务器到达接收端的, 而不是来自于缓存里保存的副本 。 然而相反的情况并不 成立,因为响应里缺少 Age 头域并不能说明响应是第一手的 （fisrt-hand,除非所有请求路 径上的缓存都遵循 HTTP/1.1协议（也就是说,以前 HTTP 版本缓存没有定义 Age 头域 。 13.2.4 过期计算（Expiration Calculations为了确定一条响应是保鲜的 （fresh 还是陈旧的 （stale , 我们需要将其保鲜寿命 （freshness life

23、time 和年龄 （age进行比较。 年龄的计算见 13.2.3节, 本节讲解怎样计算保鲜寿命, 以 及判定一个响应是否已经过期。 在下面的讨论中, 数值可以用任何适于算术操作的形式表示。 我们用术语“ expires_value”来表明 Expires 头域的值。我们用术语“ max_age_value”来 表示 Cache-Control 头域里“ max-age ”控制指令的值（见 14.9.3节 。max-age 指令优于 Expires 头域执行,所以如果 max-age 出现在响应里,那么定义如下: freshness_lifetime = max_age_value否则,若 Ex

24、pires 头域出现在响应里,定义如下:freshness_lifetime = expires_value - date_value注意上述运算不受时钟误差影响,因为所有信息均来自源服务器。如果 Expires , Cache-Control:max-age, 或 Cache-Control:s-maxage （见 14.9.3 均 未在响应中出现,且响应没有包含对缓存的其他控制,那么缓存可以用启发式算法计算保鲜 寿命（freshness lifetime 。缓存器必须对年龄大于 24小时的响应附加 113警告,如果此 响应不带这种警告。而且,如果响应有最后修改时间,启发式过期值应不大于从那

25、个时间开始间隔的某个分数。 典型设置为间隔的 10% 。计算响应是否过期非常简单:response_is_fresh = （freshness_lifetime current_age13.2.5澄清过期值（Disambiguation Expiration Values由于过期值很容易被设置,有可能两个缓存会包含同一资源的不同保鲜值。如果客户端执行请求接收到一个非第一手的响应,此响应在此客户端拥有的缓存里仍然是保 鲜的,并且缓存里的缓存项里的 Date 头域的值比此新响应的 Date 头域值要新,那么客户端 应该忽略此响应。如果这样,它可能会重新以“ Cache-Control :max-a

26、ge=0”指令（见 14.9节请求去强制任何中间缓存通过源服务器对其进行检查。如果缓存对有不同验证器 （validator 的同一个表现形式 （representation 有两个保鲜响 应, 那么缓存必须利用 Date 头域值最近的响应。 这种情况可能发生由于缓存会从其他缓存得 到响应,或者由于客户端请求对一个保鲜缓存项的重载或重验证（revalidation 。13.2.6澄清多个响应（Disambiguating Multiple Response因为客户端可能收到经多个路径而来的响应,所以有些响应会经过一些缓存,而其他的响应 会经过其他的缓存,客户端收到响应的顺序可能与源服务器发响应的

27、顺序不同。我们希望客 户端利用最新的响应,即使旧响应仍然是保鲜的。实体标签（entity tag和过期值都不能影响响应的顺序,因为可能会出现晚一点的响应可 能会故意携带过早的过期时间。日期值的精度被规定只有一秒。当客户端试着重新验证一个缓存项的时候 （译注:这里的客户端应该包含一个本地缓存 , 而 且接收到的响应的 Date 头域晚于已存在的缓存项, 那么客户端应该重新进行无条件请求, 并 且包含Cache-Control: max-age=0去强制任何中间缓存通过源服务器来验证（validate 这些中间缓存的副本,或者 no-cache去强制任何中间缓存去从源服务器获得一个新的副本。13.

28、3 验证模型（Validation Model当缓存有一个旧缓存项并且缓存想利用此缓存项来作为客户端请求的响应时,缓存必须首先 通过源服务器（或者可能通过一个有保鲜响应的中间缓存对其进行检验看看此缓存项是否 可用。我们称做“验证（validating ”此缓存项。因为我们不想对完整响应的传输付出太大 代价,而且如果缓存项无效时也不会产生额外的回路（译注:回路的意思,如:从请求到响 应就一条回路 , HTTP1.1协议支持使用条件方法。 .协议支持条件方法的关键特征是围绕“缓存验证器（cache validator ”展开的。当源服务 器产成一个完整响应时,它同时会附加一些验证器给响应,这些验证

29、器和缓存项一起保存。 当客户端（用户代理或缓存服务器对对应有缓存项的资源执行条件请求时,客户端包含一 个相关的验证器（validator 在请求里。服务器（译注:服务器可能是缓存服务器则核对请求里的验证器和当前本地的验证器是否 匹配,如果他们匹配（见 13.3.3 ,则返回一个特定状态码（通常为 304（没有改变 的响 应并且此响应不包含实体主体（entity body 。如果不匹配,服务器就返回完整响应（包含 实体主体 。 这样, 我们就避免了传输完整响应如果验证器匹配, 同时我们也避免了额外的回 路如果验证器不匹配。在 HTTP1.1协议中,一个条件请求和普通的请求差不多,除了条件请求携带一些特殊的头域 （这些头域包含验证器 , 包含这些特殊的头域隐含地表明请求方法 （通常是 GET 方法 为条 件请求方法。协议中包括缓存验证条件的正和负。也就是说请求方法将会执行如果验证器的匹配或不会执 行如果验证器不匹配。缺少验证器的响应可能会被缓存,而且会被缓存用来为请求提供服务直到缓存的副本 过期,除非显示地用缓存控制指令来禁止缓存这样做。然而,缓存不能执行条件方法获取资源如果它没有此资源实体的验证器,那意味着缓存副本将会不可更新在它过期后。13.3.1最后修改日期 （Last-Modified Dates