Cache-Status HTTP 响应头字段

这是一个互联网标准轨道文档。

本文件是互联网工程任务组（IETF）的成果，代表 IETF 社区的共识。它已获得公开评审，并由互联网工程指导小组（IESG）批准发布。关于互联网标准的更多信息请参见 RFC 7841 第2节。

关于本文档当前状态、勘误及如何反馈信息，可访问 https://www.rfc-editor.org/info/rfc9211 获取。

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

为了便于调试（无论是人工还是自动化工具），HTTP 缓存经常在响应中追加头字段，以说明它们如何处理该请求。不幸的是，这些头字段的语义通常不明确，且不同实现之间在语义和语法上各不相同。

本规范为此目的定义了一个新的 HTTP 响应头字段 "Cache-Status"，并为其提供了标准化的语法与语义。

Cache-Status HTTP 响应头字段用于指示缓存如何处理该响应及其对应的请求。该头字段的语法符合 [STRUCTURED-FIELDS] 的规定。

其值是一个 List。列表的每个成员表示处理过该请求的一个缓存。第一个成员表示最接近源服务器的缓存，最后一个成员表示最接近用户的缓存（如果用户代理自身追加了值，则可能包括用户代理的缓存）。

缓存决定何时在响应中添加 Cache-Status 头字段。有些缓存可能会对所有响应添加该字段，而另一些仅在特定配置或请求包含激活调试模式的头字段时添加。有关相关安全注意事项，请参见 第 6 节。

中间件 SHOULD NOT 向其本地生成的响应追加 Cache-Status 成员，即使该中间件包含缓存，也不应追加，除非该生成的响应是基于已存储响应（例如 304 (Not Modified) 和 206 (Partial Content) 都基于已存储的响应）。例如，代理因请求格式错误生成 400 响应时不会添加 Cache-Status，因为该响应是代理生成的，而非源服务器生成的。

在向 Cache-Status 头字段添加值时，缓存 SHOULD 保留已存在的字段值，以便调试处理该请求的整个缓存链。

列表的每个成员都要标识插入该成员的缓存，该标识 MUST 是一个 String 或 Token。根据部署情况，这可以是产品或服务名称（例如 "ExampleCache" 或 "Example CDN"）、主机名（"cache-3.example.com"）、IP 地址或生成的字符串。

列表的每个成员可以包含描述该缓存如何处理请求的参数。尽管这些参数为 OPTIONAL，但鼓励缓存尽可能提供更多信息。

本规范定义了以下参数。

Cache-Status: ExampleCache; hit

Cache-Status: ExampleCache; hit; ttl=376

Cache-Status: ExampleCache; hit; ttl=-412

Cache-Status: ExampleCache; fwd=uri-miss

Cache-Status: ExampleCache; fwd=stale; fwd-status=304

Cache-Status: ExampleCache; fwd=uri-miss; collapsed

Cache-Status: ExampleCache; fwd=uri-miss; collapsed=?0

Cache-Status: OriginCache; hit; ttl=1100,
              "CDN Company Here"; hit; ttl=545

Cache-Status: ReverseProxyCache; hit
Cache-Status: ForwardProxyCache; fwd=uri-miss; collapsed; stored
Cache-Status: BrowserCache; fwd=uri-miss

可以通过在 "HTTP Cache-Status" 注册表中注册来定义新的 Cache-Status 参数。

注册请求由指定的专家审核并批准，依据 [RFC8126]，详见 第 4.5 节。推荐但不强制要求提交规范文档。

• 社区反馈
• 该值是否定义得足够明确
• 优先采用通用参数，而非供应商、应用或部署特定的值。如果社区无法达成通用值的共识，则参数名称应相应地具体（例如以能够识别供应商、应用或部署的前缀命名）。

Name:

[Cache-Status 参数键的名称；参见 Section 3.1.2 中关于 [STRUCTURED-FIELDS] 的语法要求]

Type:

[参数值的 Structured Type；参见 Section 3.1.2 中关于 [STRUCTURED-FIELDS] 的说明]

Description:

[参数语义的描述]

Reference:

[若有，引用定义该参数的规范]

有关将注册请求发送到何处的详细信息，请参见注册表 <https://www.iana.org/assignments/http-cache-status>。

IANA 已创建 "HTTP Cache-Status" 注册表，地址为 <https://www.iana.org/assignments/http-cache-status>，并将第 2 节 中定义的类型填入其中；其关联程序见 第 4 节。

Field name:

Cache-Status

Status:

permanent

Reference:

RFC 9211

攻击者可以利用 Cache-Status 中的信息探测缓存（及其他组件）的行为，从而推断使用该缓存的活动。Cache-Status 头字段本身可能并不会直接产生这些风险，但它可以帮助攻击者更容易地利用这些风险。

例如，知道缓存是否存储了某个响应可能帮助攻击者对敏感数据执行计时攻击。

此外，暴露缓存键（cache key）可能帮助攻击者了解对缓存键的修改，从而助长缓存投毒攻击。详情参见 [ENTANGLE]。

可以通过多种技术来缓解这些基础风险（例如使用加密与认证，避免在缓存键中包含攻击者可控的数据等），具体方法取决于风险的性质。注意，仅对键进行混淆并不能缓解此类风险。

为避免协助此类攻击，可以省略 Cache-Status 头字段，仅在客户端被授权接收时发送，或仅在客户端被授权时才发送包含敏感信息（例如 key 参数）的字段。