互联网工程任务组(IETF) M. Nottingham
请求评论: 9875 Cloudflare
类别: 标准轨道 2025年10月
ISSN: 2070-1721

HTTP 缓存组


摘要

本规范介绍了一种在 HTTP 缓存中描述已存储响应间关系的方法,通过将存储的响应与一个或多个字符串关联,从而对其进行分组。

本备忘录状态

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

本文件是互联网工程任务组(IETF)的产品,代表了 IETF 社区的共识。已通过公众审查,并获得互联网工程指导组(IESG)的批准发布。有关注网标准的更多信息见 RFC 7841 第2节

关于本文件当前状态、任何勘误以及如何反馈信息,详见 https://www.rfc-editor.org/info/rfc9875

Copyright Notice

Copyright (c) 2025 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.


1. 简介

HTTP缓存[HTTP-CACHING]以单个资源为粒度运作;一个已存储响应的新鲜度不会影响其他响应。这种粒度可以提升缓存效率——例如,一个页面由多个有不同缓存要求的资源组成时尤其如此。

然而,在某些情况下,利用已存储响应之间的关系能够提升缓存效率。

例如,常常需要使一组相关资源失效。这可能是因为有状态变更请求对其它资源产生了副作用,或者仅仅出于管理便利(如,“使站点某部分失效”)。将响应分组为一体,为表达这些关系提供了直接方式,而不是依赖URL结构等间接手段。

除了共享失效事件,分组表达的关系还可被缓存用来优化自身行为(如,告知缓存驱逐算法的运作)。

第2节介绍了一种通过将HTTP缓存中的响应关联到一个或多个反映其关系的分组,来描述已存储响应关系的方法。同时也描述了缓存如何利用该信息将失效事件应用到某个分组成员上。

第3节介绍了此类事件的一种新来源:一个使得状态变更响应可触发分组失效的HTTP响应头字段。

这些机制仅在单一缓存内、针对与单一源服务器关联的存储响应间工作(见2.1节)。它们不涉及多缓存间的状态同步问题(如层级或网格结构),也不支持将来自不同源的响应分组。

1.1. 符号约定

本文档中的关键字“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”按照BCP 14 [RFC2119][RFC8174]中的说明解释,仅当这些词大写出现时按上述含义理解。

本规范使用了[STRUCTURED-FIELDS]中的如下术语:List、String和Parameter。


2. Cache-Groups响应头字段

Cache-Groups响应头字段是一个字符串列表(详见3.13.3.3节,[STRUCTURED-FIELDS])。列表的每个成员都是用来标识该响应所属分组的值。这些字符串是不可透明的——虽然服务器可能赋予它们含义,缓存本身对其结构与内容并不做解释(除了用于唯一标识分组)。

HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "scripts"

成员的顺序不具备特殊意义。未知参数应被忽略。

实现必须至少支持值中含有32个分组,每个成员长度不小于32个字符。注意,HTTP字段长度的通用限制可能影响此字段值的实际大小。

2.1. 分组响应的识别

两个存储于同一缓存中的响应仅当满足下列所有条件时,才被视为属于同一分组:

  1. 它们都包含一个Cache-Groups响应头字段,且该字段包含同一个字符串(无论该字符串在列表中的哪个位置,逐字符比较,区分大小写)。

  2. 它们具有相同的URI源(见RFC9110第4.3.1节)。

2.2. 缓存行为

2.2.1. 失效处理

使存储响应失效的缓存可以使与该响应同分组(详见2.1节)的其它存储响应也失效。注意,分组失效不会触发进一步的分组连锁失效;即该机制不会级联。

缓存扩展可以显式加强上述要求。例如,定向缓存控制头字段[TARGETED]可能规定处理该头字段的缓存必须使这类响应失效。


3. Cache-Group-Invalidation响应头字段

Cache-Group-Invalidation响应头字段是一个字符串列表(详见3.13.3.3节,[STRUCTURED-FIELDS])。每个成员是该响应按2.2.1节所需失效的分组标识符。

例如,在执行影响两个缓存组的POST请求后,响应可指示与这两组相关的存储响应均需要失效,如:

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia"

对于安全方法(例如GET,见RFC9110第9.2.1节)的请求,其响应中的Cache-Group-Invalidation头字段必须被忽略。

缓存在接收到对非安全请求的响应中的Cache-Group-Invalidation头字段时,可以使所有与所列分组同组(按2.1节)的存储响应失效。

缓存扩展可明确增强上述要求。例如,定向缓存控制头字段[TARGETED]可能要求处理该信号的缓存必须遵循Cache-Group-Invalidation。

成员的顺序无特殊意义。未知参数应被忽略。

实现必须至少支持值中含有32个分组,每个成员长度不小于32个字符。注意,HTTP字段长度的通用限制可能影响此字段值的实际大小。


4. IANA相关事项

IANA已在“超文本传输协议(HTTP)字段名注册表”中增加了如下条目:

字段名:
Cache-Groups
状态:
永久
参考文献:
RFC 9875
字段名:
Cache-Group-Invalidation
状态:
永久
参考文献:
RFC 9875

5. 安全性考虑

该机制允许同一源的资源互相使对方失效。因此,代表多方的源(有时称为“虚拟主机”)可能让一方将其资源与他方资源归为一组,或发送信号影响其他资源。

希望减轻此类风险的共享主机可控制对本规范定义的头字段的访问。

6. 参考文献

6.1. 规范性引用

[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., 和 J. Reschke, Ed., “HTTP 缓存”,STD 98,RFC 9111,DOI 10.17487/RFC9111,2022年6月,<https://www.rfc-editor.org/info/rfc9111>。
[HTTP]
Fielding, R., Ed., Nottingham, M., Ed., 和 J. Reschke, Ed., “HTTP 语义”,STD 97,RFC 9110,DOI 10.17487/RFC9110,2022年6月,<https://www.rfc-editor.org/info/rfc9110>。
[RFC2119]
Bradner, S., “用于RFC中的需求级别术语”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月,<https://www.rfc-editor.org/info/rfc2119>。
[RFC8174]
Leiba, B., “RFC 2119术语中的大小写歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月,<https://www.rfc-editor.org/info/rfc8174>。
[STRUCTURED-FIELDS]
Nottingham, M. 和 P-H. Kamp, “HTTP结构化字段值”,RFC 9651,DOI 10.17487/RFC9651,2024年9月,<https://www.rfc-editor.org/info/rfc9651>。

6.2. 补充性引用

[TARGETED]
Ludin, S., Nottingham, M., 和 Y. Wu, “定向HTTP缓存控制”,RFC 9213,DOI 10.17487/RFC9213,2022年6月,<https://www.rfc-editor.org/info/rfc9213>。

致谢

感谢Stephen Ludin的审阅与建议。


作者地址

Mark Nottingham
Cloudflare
墨尔本
澳大利亚
EMail: mnot@mnot.net
URI: https://www.mnot.net/