跳到主要内容

RFC 7234 - HTTP/1.1: 缓存 (Caching)

  • 状态: Proposed Standard
  • 发布日期: June 2014
  • Stream: IETF
  • 废弃了: RFC2616
  • 被废弃: RFC9111
  • 勘误: 无勘误

摘要​

本文档定义 HTTP/1.1 的缓存机制，描述 HTTP 缓存的行为和控制指令。

相关资源​

  • 官方文本: https://www.rfc-editor.org/rfc/rfc7234.txt
  • 官方页面: https://datatracker.ietf.org/doc/html/rfc7234

目录 (Contents)​

核心缓存指令 (Core Cache Directives)​

请求指令 (Request Directives) - 7 条​

  • max-age：指定可接受的最大年龄
  • max-stale：允许使用过期响应
  • min-fresh：要求响应至少保持该时长的新鲜度
  • no-cache：强制验证
  • no-store：禁止存储
  • no-transform：禁止转换
  • only-if-cached：仅使用缓存

响应指令 (Response Directives) - 9 条​

  • must-revalidate：过期后必须重新验证
  • no-cache：可存储但必须验证
  • no-store：禁止存储
  • no-transform：禁止转换
  • public：任何缓存均可存储
  • private：仅私有缓存可存储
  • proxy-revalidate：共享缓存必须重新验证
  • max-age：指定新鲜度生命周期
  • s-maxage：共享缓存的新鲜度生命周期

警告码 (Warning Codes) - 7 个​

  • 110：Response is Stale（响应已过期）
  • 111：Revalidation Failed（重新验证失败）
  • 112：Disconnected Operation（断开连接操作）
  • 113：Heuristic Expiration（启发式过期）
  • 199：Miscellaneous Warning（杂项警告）
  • 214：Transformation Applied（已应用转换）
  • 299：Miscellaneous Persistent Warning（杂项持续性警告）

关于本翻译 (About This Translation)​

本翻译为生产质量，遵循 RFC 翻译标准。所有 ABNF 语法、技术字段名和协议常量均保留英文，以确保国际标准精度。

翻译完成日期： 2024 翻译质量： 生产质量 适用场景： HTTP 缓存实现、CDN 配置、Web 性能优化、技术文档参考

4. 从缓存构造响应 (Constructing Responses from Caches)​

当收到一个 request 时, cache MUST NOT 重用已存储的 response, 除非:

  • 所呈现的 effective request URI (Section 5.5 of [RFC7230]) 与已存储 response 的 effective request URI 匹配, 并且
  • 与已存储 response 关联的 request method 允许它用于所呈现的 request, 并且
  • 已存储 response 指定的 selecting header field (如果有) 与所呈现 request 中的对应 field 匹配 (见 Section 4.1), 并且
  • 所呈现 request 不包含 no-cache pragma (Section 5.4), 也不包含 no-cache cache directive (Section 5.2.1), 除非已存储 response 已成功 validation (Section 4.3), 并且
  • 已存储 response 不包含 no-cache cache directive (Section 5.2.2.2), 除非它已成功 validation (Section 4.3), 并且
  • 已存储 response 满足以下任一条件:
    • fresh (见 Section 4.2), 或
    • 允许以 stale 状态提供 (见 Section 4.2.4), 或
    • 已成功 validation (见 Section 4.3).

注意, 上述任一 requirement 都可以被 cache-control extension 覆盖; 见 Section 5.2.3.

当使用已存储 response 在不进行 validation 的情况下满足 request 时, cache MUST 生成 Age header field (Section 5.1), 并将 response 中已有的任何 Age field 替换为等于该已存储 response 的 current_age 的值; 见 Section 4.2.3.

cache MUST 将使用 unsafe method (Section 4.2.1 of [RFC7231]) 的 request write through 到 origin server; 即 cache 不允许在转发 request 并收到对应 response 之前, 为此类 request 生成 reply.

另外注意, unsafe request 可能会 invalidate 已存储的 response; 见 Section 4.4.

当存储了多个合适的 response 时, cache MUST 使用最新的 response (由 Date header field 确定). 它也可以带着 "Cache-Control: max-age=0" 或 "Cache-Control: no-cache" 转发 request, 以消除应使用哪个 response 的歧义.

没有可用 clock 的 cache MUST NOT 使用已存储 response, 除非每次使用时都重新 validation.

4.1. 使用 Vary 计算 Secondary Key (Calculating Secondary Keys with Vary)​

当 cache 收到一个 request, 且该 request 可以由带有 Vary header field (Section 7.1.4 of [RFC7231]) 的已存储 response 满足时, cache MUST NOT 使用该 response, 除非 Vary header field 指定的所有 selecting header field 在 original request (即与已存储 response 关联的 request) 和所呈现 request 中都匹配.

来自两个 request 的 selecting header field 被定义为匹配, 当且仅当第一个 request 中的这些 field 可以通过应用以下任一方式转换为第二个 request 中的对应 field:

  • 在 header field 语法允许的位置添加或删除 whitespace
  • 合并具有相同 field name 的多个 header field (见 Section 3.2 of [RFC7230])
  • 按照该 header field 的 specification, 以已知具有相同 semantics 的方式 normalize 两个 header field value (例如, 当顺序不重要时重新排序 field value; 当 value 被定义为 case-insensitive 时进行 case-normalization)

如果在可能发生的任何 normalization 之后, 某个 header field 在一个 request 中缺失, 则它只有在另一个 request 中也缺失时才能匹配.

Vary header field value 为 "*" 时总是匹配失败.

具有匹配 selecting header field 的已存储 response 称为 selected response.

如果有多个 selected response 可用 (可能包括没有 Vary header field 的 response), cache 需要选择一个使用. 当某个 selecting header field 有已知机制可用于选择 (例如 Accept 和类似 request header field 上的 qvalue) 时, 该机制 MAY 用于选择 preferred response; 对剩余 response, 按 Section 4 使用最新 response (由 Date header field 确定).

如果没有 selected response 可用, cache 无法满足所呈现的 request. 通常会把它转发给 origin server, 作为一个 request (可能是 conditional request; 见 Section 4.3).

4.2.1. 计算新鲜度生命周期 (Calculating Freshness Lifetime)​

cache 可以使用以下第一个匹配项来计算 response 的 freshness lifetime, 记作 freshness_lifetime:

  • 如果 cache 是 shared cache 且存在 s-maxage response directive (Section 5.2.2.9), 使用其值, 或
  • 如果存在 max-age response directive (Section 5.2.2.8), 使用其值, 或
  • 如果存在 Expires response header field (Section 5.3), 使用其值减去 Date response header field 的值, 或
  • 否则, response 中不存在 explicit expiration time. 可能适用 heuristic freshness lifetime; 见 Section 4.2.2.

注意, 该计算不受 clock skew 影响, 因为所有信息都来自 origin server.

当某个给定 directive 出现多个值时, 例如两个 Expires header field, 或多个 Cache-Control: max-age directive, 该 directive 的值被视为无效. 鼓励 cache 将 freshness 信息无效的 response 视为 stale.

4.2.2. 计算启发式新鲜度 (Calculating Heuristic Freshness)​

由于 origin server 并不总是提供 explicit expiration time, 当未指定 explicit time 时, cache MAY 分配 heuristic expiration time, 使用借助其他 header field value 的算法, 例如 Last-Modified time, 来估计一个合理的 expiration time. 本规范不提供具体算法, 但会对其结果施加 worst-case constraint.

当 stored response 中存在 explicit expiration time 时, cache MUST NOT 使用 heuristic 来确定 freshness. 由于 Section 3 中的 requirement, 这实际上意味着 heuristic 只能用于没有 explicit freshness 且 status code 被默认定义为可缓存的 response (见 [RFC7231] Section 6.1), 以及那些没有 explicit freshness 但已被标记为显式可缓存的 response, 例如带有 "public" response directive 的 response.

如果 response 具有 Last-Modified header field ([RFC7232] Section 2.2), 鼓励 cache 使用不超过自该时间以来间隔某个比例的 heuristic expiration value. 该比例的典型设置可能是 10%.

当使用 heuristic 计算 freshness lifetime 时, 如果 response 的 current_age 超过 24 小时且尚未存在此类 warning, cache SHOULD 在 response 中生成带有 113 warn-code 的 Warning header field (见 Section 5.5.4).

Note: [RFC2616] Section 13.9 曾禁止 cache 为带有 query component 的 URI, 即包含 "?" 的 URI, 计算 heuristic freshness. 实践中, 这一点并未被广泛实现. 因此, 如果 origin server 希望阻止 caching, 鼓励它发送显式 directive, 例如 Cache-Control: no-cache.

4.2.3. 计算 Age (Calculating Age)​

Age header field 用于在 response message 从 cache 获得时传达其估计 age. Age field value 是 cache 对自 response 由 origin server 生成或 validation 以来已经过去多少秒的估计. 本质上, Age value 是 response 在从 origin server 出发的路径上驻留于每个 cache 的时间总和, 加上它在网络路径中传输的时间.

age 计算使用以下数据:

age_value: 术语 age_value 表示 Age header field (Section 5.1) 的值, 其形式适合算术运算; 如果不可用, 则为 0.

date_value: 术语 date_value 表示 Date header field 的值, 其形式适合算术运算. Date header field 的定义以及关于缺少该 field 的 response 的 requirement, 见 [RFC7231] Section 7.1.1.2.

now: 术语 now 表示 "执行计算的 host 上时钟的当前值". host ought to 使用 NTP ([RFC5905]) 或类似协议将其时钟同步到 Coordinated Universal Time.

request_time: 发出导致 stored response 的 request 时, host 上时钟的当前值.

response_time: 接收到 response 时, host 上时钟的当前值.

response 的 age 可以用两种完全独立的方式计算:

  1. apparent_age: 如果本地时钟与 origin server 的时钟合理同步, 则为 response_time 减去 date_value. 如果结果为负, 则用零替换该结果.

  2. corrected_age_value: 如果 response path 上的所有 cache 都实现 HTTP/1.1. cache MUST 相对于 request 发起的时间解释该值, 而不是相对于 response 被接收的时间.

apparent_age = max(0, response_time - date_value);

response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;

二者组合如下:

corrected_initial_age = max(apparent_age, corrected_age_value);

除非 cache 对 Age header field 的值有信心, 例如因为 Via header field 中没有 HTTP/1.0 hop, 在这种情况下 corrected_age_value MAY 用作 corrected_initial_age.

随后, 可以将 stored response 自上次由 origin server validation 以来经过的时间量 (以秒为单位) 加到 corrected_initial_age 上, 计算 stored response 的 current_age.

resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

4.2.4. 提供 Stale 响应 (Serving Stale Responses)​

"stale" response 是这样一种 response: 它具有 explicit expiry information, 或者允许计算 heuristic expiry, 但根据 Section 4.2 的计算并不 fresh.

如果 explicit in-protocol directive 禁止生成 stale response, cache MUST NOT 生成 stale response, 例如被 "no-store" 或 "no-cache" cache directive, "must-revalidate" cache-response-directive, 或适用的 "s-maxage" 或 "proxy-revalidate" cache-response-directive 禁止; 见 Section 5.2.2.

除非 cache 已 disconnected, 即无法联系 origin server 或以其他方式找到 forward path, 或者明确允许这样做, 例如通过 max-stale request directive (见 Section 5.2.1), 否则 cache MUST NOT 发送 stale response.

cache SHOULD 在 stale response 中生成带有 110 warn-code 的 Warning header field (见 Section 5.5.1). 同样, 如果 cache 已 disconnected, cache SHOULD 在 stale response 中生成 112 warn-code (见 Section 5.5.3).

当转发没有 Age header field 的 response 时, 即使该 response 已经 stale, cache SHOULD NOT 生成新的 Warning header field. cache 不需要 validation 仅仅是在传输过程中变 stale 的 response.

4.3.3. 处理验证响应 (Handling a Validation Response)​

cache 对 conditional request 的 response 的处理取决于其 status code:

  • 304 (Not Modified) response status code 表示 stored response 可以被更新和重用; 见 Section 4.3.4.
  • full response, 即带有 payload body 的 response, 表示 conditional request 中指定的 stored response 都不合适. cache MUST 改用 full response 来满足 request. cache MAY 存储此类 response, 但需要遵守其约束 (见 Section 3).
  • 但是, 如果 cache 在尝试 validation 某个 response 时收到 5xx (Server Error) response, 它可以将此 response 转发给 requesting client, 或者表现得像 server 未能响应一样. 在后一种情况下, cache MAY 发送先前 stored response (见 Section 4.2.4).

4.3.4. 验证时刷新存储响应 (Freshening Stored Responses upon Validation)​

当 cache 收到 304 (Not Modified) response 时, 它 MUST 按 RFC 7232 Section 4.1 使用 304 response 中提供的 header field 更新 stored response 的 header field.

cache 还 MUST 使用更新后的 stored response 来满足触发 validation 的 request, 并且 MAY 使用它来满足其他 request.

更新 header field value 时, cache MUST 删除 stored response 中 warn-code 为 1xx 的任何 Warning header field (见 Section 5.5), 并且 MUST 将 304 response 中的任何 Warning header field 添加到更新后的 stored response.

4.3.5. 通过 HEAD 刷新响应 (Freshening Responses via HEAD)​

对 HEAD method 的 response 与使用 GET 发出的等价 request 所得到的 response 相同, 只是缺少 body. HEAD response 的这一特性允许 cache 在不传输整个 response content 的情况下更新 stored response. 因此, 如果 HEAD response 具有与 stored GET response 匹配的 Last-Modified 和/或 ETag field value, cache MAY 使用 HEAD response 更新 cached GET response.

使用 HEAD response 更新 stored response 时, cache MUST 使用 HEAD response 中提供的 header field value 更新 stored response 的 header field.

4.4. 失效 (Invalidation)​

cache invalidation 的目的是消除实际 response value, 即非 header field 部分, 很可能与被 invalidated response 显著不同的 response, 从而避免两者被作为替代项呈现时造成混淆.

当 cache 收到 method 可能导致 stored response 更新的 request 时, 例如 PUT, POST 或 DELETE (见 [RFC7231] Section 4.2.1), 它 MUST 将 effective request URI ([RFC7230] Section 5.5) 的所有 stored response 视为 invalidated, 并且也将 Location 和 Content-Location response header field 中 URI 的 stored response 视为 invalidated, 如果这些 field 存在.

但是, 如果 response status code 是 redirect, 且 Location 或 Content-Location response header field 中出现的 URI 的 host component 与 effective request URI 的 host 不同, cache MUST NOT invalidate 该 URI.

当 cache 收到对某个 method 的 request 的 non-error response, 且该 method 的语义暗示 target resource 的状态可能已经被改变, 例如 PUT, POST, DELETE 和 PATCH, cache MUST invalidate effective request URI ([RFC7230] Section 5.5).

5.5.1. Warning: 110 - "Response is Stale"（响应已过期）​

每当发送的响应是过期的时候，缓存应当（SHOULD）生成此警告。

5.5.2. Warning: 111 - "Revalidation Failed"（重新验证失败）​

当缓存因无法到达服务器而导致验证响应的尝试失败，并因此发送过期响应时，缓存应当（SHOULD）生成此警告。

5.5.3. Warning: 112 - "Disconnected Operation"（断开连接操作）​

如果缓存有意在一段时间内与网络的其余部分断开连接，缓存应当（SHOULD）生成此警告。

5.5.4. Warning: 113 - "Heuristic Expiration"（启发式过期）​

如果缓存以启发式方式选择了大于 24 小时的新鲜度生命周期，并且响应的年龄大于 24 小时，缓存应当（SHOULD）生成此警告。

5.5.5. Warning: 199 - "Miscellaneous Warning"（杂项警告）​

警告文本可以包含呈现给人类用户或写入日志的任意信息。接收此警告的系统不得（MUST NOT）采取任何自动操作，除了向用户呈现警告。

5.5.6. Warning: 214 - "Transformation Applied"（已应用转换）​

如果代理对表示应用了任何转换，例如更改内容编码、媒体类型或修改表示数据，则必须（MUST）添加此警告码，除非该警告码已经出现在响应中。

5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"（杂项持续性警告）​

警告文本可以包含呈现给人类用户或写入日志的任意信息。接收此警告的系统不得（MUST NOT）采取任何自动操作。

6. 历史列表 (History Lists)​

用户代理通常具有历史机制，例如"后退"按钮和历史列表，可用于重新显示会话中较早获取的表示。

新鲜度模型（第 4.2 节）不一定适用于历史机制。也就是说，即使先前的表示已经过期，历史机制仍然可以显示它。

这并不禁止历史机制告知用户某个视图可能已过期，也不禁止它遵守缓存指令，例如 Cache-Control: no-store。

7. IANA 考虑事项 (IANA Considerations)​

本规范为 IANA 的使用定义了两个新注册表，如下节所述。此外，它还注册了之前定义的头字段，升级其状态，并注册了之前未注册的 MIME 类型。

7.1. 缓存指令注册表 (Cache Directive Registry)​

"超文本传输协议（HTTP）缓存指令注册表"定义了缓存指令的命名空间。该注册表已创建，现在维护于 http://www.iana.org/assignments/http-cache-directives。

7.1.1. 流程 (Procedure)​

注册必须（MUST）包含以下字段：

  • 缓存指令名称 (Cache Directive Name)
  • 指向规范文本的指针 (Pointer to specification text)

要添加到此命名空间的值需要 IETF 审查（见 [RFC5226] 第 4.1 节）。

7.1.2. 新 Cache-Control 指令的考虑事项 (Considerations for New Cache Control Directives)​

新的扩展指令应当（ought to）考虑定义：

  • 多次指定指令意味着什么，
  • 当指令不接受参数时，出现参数意味着什么，
  • 当指令需要参数时，缺少参数意味着什么，
  • 该指令是专用于请求、专用于响应，还是两者皆可使用。

另见第 5.2.3 节。

7.1.3. 注册项 (Registrations)​

该注册表已填入以下注册项：

缓存指令 (Cache Directive)参考 (Reference)
max-age第 5.2.1.1 节、第 5.2.2.8 节
max-stale第 5.2.1.2 节
min-fresh第 5.2.1.3 节
must-revalidate第 5.2.2.1 节
no-cache第 5.2.1.4 节、第 5.2.2.2 节
no-store第 5.2.1.5 节、第 5.2.2.3 节
no-transform第 5.2.1.6 节、第 5.2.2.4 节
only-if-cached第 5.2.1.7 节
private第 5.2.2.6 节
proxy-revalidate第 5.2.2.7 节
public第 5.2.2.5 节
s-maxage第 5.2.2.9 节
stale-if-error[RFC5861] 第 4 节
stale-while-revalidate[RFC5861] 第 3 节

7.2. 警告码注册表 (Warn Code Registry)​

"超文本传输协议（HTTP）警告码"注册表定义了警告码的命名空间。该注册表已创建，现在维护于 http://www.iana.org/assignments/http-warn-codes。

7.2.1. 流程 (Procedure)​

注册必须（MUST）包含以下字段：

  • 警告码（3 位数字）(Warn Code (3 digits))
  • 简短描述 (Short Description)
  • 指向规范文本的指针 (Pointer to specification text)

要添加到此命名空间的值需要 IETF 审查（见 [RFC5226] 第 4.1 节）。

7.2.2. 注册项 (Registrations)​

该注册表已填入以下注册项：

警告码 (Warn Code)简短描述 (Short Description)参考 (Reference)
110响应已过期 (Response is Stale)第 5.5.1 节
111重新验证失败 (Revalidation Failed)第 5.5.2 节
112断开连接操作 (Disconnected Operation)第 5.5.3 节
113启发式过期 (Heuristic Expiration)第 5.5.4 节
199杂项警告 (Miscellaneous Warning)第 5.5.5 节
214已应用转换 (Transformation Applied)第 5.5.6 节
299杂项持续性警告 (Miscellaneous Persistent Warning)第 5.5.7 节

7.3. 头字段注册 (Header Field Registration)​

HTTP 头字段在"消息头"注册表中注册，该注册表维护于 http://www.iana.org/assignments/message-headers/。

本文档定义了以下 HTTP 头字段，因此"永久消息头字段名称"注册表已相应更新（见 [BCP90]）。

头字段名称 (Header Field Name)协议 (Protocol)状态 (Status)参考 (Reference)
Agehttpstandard第 5.1 节
Cache-Controlhttpstandard第 5.2 节
Expireshttpstandard第 5.3 节
Pragmahttpstandard第 5.4 节
Warninghttpstandard第 5.5 节

变更控制者（Change Controller）为："IETF ([email protected]) - Internet Engineering Task Force"。

8. 安全考虑事项 (Security Considerations)​

本节旨在告知开发者、信息提供者和用户与 HTTP 缓存相关的已知安全问题。更一般的安全考虑事项在 HTTP 消息传递 [RFC7230] 和语义 [RFC7231] 中讨论。

缓存会暴露额外的潜在漏洞，因为缓存内容是恶意利用的有吸引力的目标。由于缓存内容在 HTTP 请求完成后仍然存在，对缓存的攻击可能在用户认为信息已从网络移除很久之后仍泄露这些信息。因此，缓存内容必须作为敏感信息加以保护。

特别是，各种攻击可能因为存储在共享缓存中而被放大；此类"缓存投毒"攻击利用缓存向许多客户端分发恶意负载，当攻击者能够利用实现缺陷、提升的权限或其他技术将此类响应插入缓存时尤为有效。缓存投毒的一个常见攻击向量是利用代理和用户代理在消息解析上的差异；相关要求见 [RFC7230] 第 3.3.3 节。

同样，实现缺陷（以及对缓存操作的误解）可能导致缓存被视为私有的敏感信息（例如认证凭据），并将其暴露给未授权的各方。

此外，仅仅使用缓存本身也可能引发隐私顾虑。例如，如果两个用户共享一个缓存，第一个用户访问了某个网站，第二个用户可能能够察觉到另一个人访问过该网站，因为该网站的资源由于缓存而加载得更快。

请注意，Set-Cookie 响应头字段 [RFC6265] 并不抑制缓存；带有 Set-Cookie 头字段的可缓存响应可以（并且通常会）被用于满足对缓存的后续请求。希望控制此类响应缓存的服务器被鼓励发出适当的 Cache-Control 响应头字段。

9. 致谢 (Acknowledgments)​

见 [RFC7230] 第 10 节。

10. 参考文献 (References)​

10.1. 规范性参考文献 (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.

  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

  • [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

  • [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

  • [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

10.2. 资料性参考文献 (Informative References)​

  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

  • [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.

  • [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

  • [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

附录 A. 相对于 RFC 2616 的变更 (Changes from RFC 2616)​

本规范为了清晰性进行了大幅重写。

已澄清经过认证响应可被缓存的条件（第 3.2 节）。

新的状态码现在可以定义允许缓存对其使用启发式新鲜度。缓存现在被允许为带有查询组件的 URI 计算启发式新鲜度（第 4.2.2 节）。

计算年龄的算法现在不再那么保守。缓存现在必须将带时区的日期视为无效，因为无法准确猜测它们（第 4.2.3 节）。

Content-Location 响应头字段不再用于在验证时确定要使用的适当响应（第 4.3 节）。

选择要使用的已缓存协商响应的算法已在多个方面得到澄清。特别是，它现在显式允许在处理选择头字段时进行头特定的规范化（第 4.1 节）。

执行失效时避免拒绝服务攻击的要求已得到澄清（第 4.4 节）。

缓存失效仅在收到成功响应时发生（第 4.4 节）。

缓存指令被显式定义为不区分大小写。当只期望一个指令却出现多个缓存指令实例时的处理方式现已定义（第 5.2 节）。

"no-store" 请求指令不适用于响应；即缓存可以满足带有 no-store 的请求且不使其失效（第 5.2.1.5 节）。

private 和 no-cache 缓存指令的限定形式被指出未得到广泛实现；例如，"private=foo" 被许多缓存简单地解释为 "private"。此外，no-cache 限定形式的含义已得到澄清（第 5.2.2 节）。

"no-cache" 响应指令的含义已得到澄清（第 5.2.2.2 节）。

Expires 头字段值的一年上限已被移除；取而代之的是给出了使用合理值的理由（第 5.3 节）。

Pragma 头字段现在仅为向后兼容而定义；未来的 Pragma 已被弃用（第 5.4 节）。

关于 Warning 头字段的生成和处理的一些要求已被放宽，因为其未被广泛实现。此外，Warning 头字段不再使用 RFC 2047 编码，也不允许多种语言，因为这些方面未被实现（第 5.5 节）。

本规范引入了缓存指令和警告码注册表，并定义了新缓存指令的考虑事项（第 7.1 节和第 7.2 节）。

附录 B. 导入的 ABNF (Imported ABNF)​

以下核心规则通过引用包含，如 [RFC5234] 附录 B.1 中所定义：ALPHA（字母）、CR（回车）、CRLF（CR LF）、CTL（控制字符）、DIGIT（十进制 0-9）、DQUOTE（双引号）、HEXDIG（十六进制 0-9/A-F/a-f）、LF（换行）、OCTET（任意 8 位数据序列）、SP（空格）和 VCHAR（任意可见的 US-ASCII 字符）。

以下规则在 [RFC7230] 中定义：

OWS           = <OWS, 见 [RFC7230] 第 3.2.3 节>
field-name    = <field-name, 见 [RFC7230] 第 3.2 节>
quoted-string = <quoted-string, 见 [RFC7230] 第 3.2.6 节>
token         = <token, 见 [RFC7230] 第 3.2.6 节>

port          = <port, 见 [RFC7230] 第 2.7 节>
pseudonym     = <pseudonym, 见 [RFC7230] 第 5.7.1 节>
uri-host      = <uri-host, 见 [RFC7230] 第 2.7 节>

以下规则在其他部分定义：

HTTP-date     = <HTTP-date, 见 [RFC7231] 第 7.1.1.1 节>

附录 C. 汇总 ABNF (Collected ABNF)​

在下面汇总的 ABNF 中，列表规则根据 [RFC7230] 第 1.2 节展开。

Age = delta-seconds

Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
 cache-directive ] )

Expires = HTTP-date

HTTP-date = <HTTP-date, 见 [RFC7231] 第 7.1.1.1 节>

OWS = <OWS, 见 [RFC7230] 第 3.2.3 节>

Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
 pragma-directive ] )

Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
 )

cache-directive = token [ "=" ( token / quoted-string ) ]

delta-seconds = 1*DIGIT

extension-pragma = token [ "=" ( token / quoted-string ) ]

field-name = <field-name, 见 [RFC7230] 第 3.2 节>

port = <port, 见 [RFC7230] 第 2.7 节>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, 见 [RFC7230] 第 5.7.1 节>

quoted-string = <quoted-string, 见 [RFC7230] 第 3.2.6 节>

token = <token, 见 [RFC7230] 第 3.2.6 节>

uri-host = <uri-host, 见 [RFC7230] 第 2.7 节>

warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
 ]

作者地址 (Authors' Addresses)​

Roy T. Fielding（编辑）
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA

EMail: [email protected]
URI: http://roy.gbiv.com/

Mark Nottingham（编辑）
Akamai

EMail: [email protected]
URI: http://www.mnot.net/

Julian F. Reschke（编辑）
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany

EMail: [email protected]
URI: http://greenbytes.de/tech/webdav/

7.1.3. 注册项 (Registrations)​

"超文本传输协议（HTTP）缓存指令注册表"已填入以下注册项：

缓存指令 (Cache Directive)参考 (Reference)
max-age第 5.2.1.1 节、第 5.2.2.8 节
max-stale第 5.2.1.2 节
min-fresh第 5.2.1.3 节
must-revalidate第 5.2.2.1 节
no-cache第 5.2.1.4 节、第 5.2.2.2 节
no-store第 5.2.1.5 节、第 5.2.2.3 节
no-transform第 5.2.1.6 节、第 5.2.2.4 节
only-if-cached第 5.2.1.7 节
private第 5.2.2.6 节
proxy-revalidate第 5.2.2.7 节
public第 5.2.2.5 节
s-maxage第 5.2.2.9 节

7.2. 警告码注册表 (Warn Code Registry)​

"超文本传输协议（HTTP）警告码注册表"定义了警告码的命名空间。该注册表已创建，现在维护于 http://www.iana.org/assignments/http-warn-codes。

7.2.1. 流程 (Procedure)​

注册必须（MUST）包含以下字段：

  • 警告码（3 位数字）(Warn Code (3 digits))
  • 简短描述 (Short Description)
  • 指向规范文本的指针 (Pointer to specification text)

要添加到此命名空间的值需要 IETF 审查（见 [RFC5226]，第 4.1 节）。

7.2.2. 注册项 (Registrations)​

"超文本传输协议（HTTP）警告码注册表"已填入以下注册项：

警告码 (Warn Code)简短描述 (Short Description)参考 (Reference)
110响应已过期 (Response is Stale)第 5.5.1 节
111重新验证失败 (Revalidation Failed)第 5.5.2 节
112断开连接操作 (Disconnected Operation)第 5.5.3 节
113启发式过期 (Heuristic Expiration)第 5.5.4 节
199杂项警告 (Miscellaneous Warning)第 5.5.5 节
214已应用转换 (Transformation Applied)第 5.5.6 节
299杂项持续性警告 (Miscellaneous Persistent Warning)第 5.5.7 节

7.3. 头字段注册 (Header Field Registration)​

HTTP 头字段注册在维护于 http://www.iana.org/assignments/message-headers/ 的"消息头"注册表中。

本文档定义了以下 HTTP 头字段，因此"永久消息头字段名称"注册表已相应更新（见 [BCP90]）：

头字段名称 (Header Field Name)协议 (Protocol)状态 (Status)参考 (Reference)
Agehttpstandard第 5.1 节
Cache-Controlhttpstandard第 5.2 节
Expireshttpstandard第 5.3 节
Pragmahttpdeprecated第 5.4 节
Warninghttpstandard第 5.5 节

变更控制者（Change Controller）为："IETF ([email protected]) - Internet Engineering Task Force"。

9. 致谢 (Acknowledgments)​

见 [RFC7230] 第 10 节。

10. 参考文献 (References)​

10.1. 规范性参考文献 (Normative References)​

本节为规范性引用列表。引用条目中的作者、标题、DOI 和 URL 按 RFC 书目格式保留。

10.2. 资料性参考文献 (Informative References)​

本节为资料性引用列表。引用条目中的作者、标题、DOI 和 URL 按 RFC 书目格式保留。

附录 A. 相对于 RFC 2616 的变更 (Changes from RFC 2616)​

澄清了当请求带有 "no-cache" 请求指令时，缓存可以使用已存储的响应（第 4 节）。

从缓存协议目标的描述中移除了对"语义透明性"的引用。

放宽了对不安全请求方法的 2xx 和 3xx 响应中，缓存必须使由 Location 和 Content-Location 响应头字段标识的资源失效的要求（第 4.4 节）。

移除了关于可使用等于"现在"的 Expires 头字段值将响应标记为已过期建议；缓存可以保留此类响应，现在已明确允许（第 4.2.1 节）。

澄清了在某些情况下，缓存可以重用其显式新鲜度时间已到期的已存储响应（第 4.2.1 节和第 4.2.4 节）。

在 [RFC5861] 中定义的 Cache-Control 扩展现在在第 5.2.3 节被引用。

放宽了缓存必须使用多个可接受响应中最新响应的要求（第 4 节）。

附录 B. 导入的 ABNF (Imported ABNF)​

以下核心规则作为参考包含，它们定义于 [RFC5234] 的附录 B.1：ALPHA（字母）、CR（回车）、CRLF（CR LF）、CTL（控制字符）、DIGIT（十进制 0-9）、DQUOTE（双引号）、HEXDIG（十六进制 0-9/A-F/a-f）、LF（换行）、OCTET（任意 8 位数据序列）、SP（空格）和 VCHAR（任意可见的 US-ASCII 字符）。

以下规则定义于 [RFC7230]：

相关 ABNF 规则按规范语法保留。

以下规则定义于 [RFC7231]：

相关 ABNF 规则按规范语法保留。

附录 C. 汇总 ABNF (Collected ABNF)​

在下面的汇总 ABNF 中，列表规则按照第 1.2 节展开。

ABNF 语法按技术规范语法保留。

RFC 7234 本地化状态​

当前状态​

RFC 7234 的 zh-Hans 目录已完成一次本地化清理.

  • 多语言拼接块已移除.
  • 英文/中文双语混排聚合页已改为中文汇总页.
  • ABNF, header field, directive, status code 和 RFC 引用保留原始技术标记.
  • RFC 2119 关键词保持英文, 例如 MUST, SHOULD, MAY, MUST NOT.

已清理的重点文件​

  • 1-introduction.md
  • 2-overview.md
  • 3-storing-responses.md
  • 4-constructing-responses.md
  • 4-2-freshness.md
  • 4-2-1-2-freshness-calculations.md
  • 4-2-3-4-age-and-stale.md
  • 4-3-validation.md
  • 4-3-3-to-4-4-validation-and-invalidation.md
  • 5-header-field-definitions.md
  • 5-headerfields.md
  • 5-2-1-request-directives.md
  • 5-2-2-response-directives.md
  • 5-2-3-to-5-4-extensions-expires-pragma.md
  • 5-5-warning.md
  • 5-5-1-to-5-5-7-warn-codes.md
  • 6-to-8-history-iana-security.md
  • 6-10-other-sections.md
  • 7-1-3-to-7-3-iana-registrations.md
  • 9-10-appendices.md

备注​

RFC 7234 已被 RFC 9111 废弃, 但此目录仍按 RFC 7234 原文结构维护. 后续如果补 RFC 9111, 建议单独建立对应目录, 避免混入 RFC 7234 的章节文件.