摘要

  • Cache-Groups 允许响应声明一个或多个不透明、区分大小写的组字符串。
  • 组成员关系只在同一个缓存和同一个 URI 源站内成立。
  • 安全请求的响应中出现 Cache-Group-Invalidation 时必须忽略；不安全请求中则可以使共享所列组的已存储响应失效。
  • 失效是可选行为，除非其他缓存扩展强化它，而且不会沿着新形成的组关系级联。

RFC 9875 为 HTTP 缓存增加了表达响应关联关系的方式。响应可以声明组，缓存据此把同一范围内的已存储响应视为相关。组字符串是不透明的，外部不能从字符串本身推断业务含义；同时它们区分大小写。因此，规范没有替组织决定组的命名、所有权或授权方式。真正的控制面仍然是组空间的管理，以及谁有权产生和解释这些字段。

必须先划清缓存边界。一个缓存中的组状态不会自动出现在另一个缓存中，浏览器、代理、反向代理或其他中间层也不会因此共享同一份组目录。该机制同样不会关联不同 URI 源站的响应。把它描述成跨缓存、跨 CDN 或跨源站同步，会超出 RFC 9875 的事实范围。即使本地缓存已经处理了信号，路径中其他缓存的状态仍可能不同。

失效字段同时包含强制处理和可选处理两层含义。对安全请求的响应，Cache-Group-Invalidation 必须被忽略；这是字段处理规则，不是运营人员可以随意调节的策略。对不安全请求的响应，它可以使共享指定组的已存储响应失效。可以并不等于必须，除非另一项缓存扩展明确增强该行为。失效也不会递归追踪后来形成关联的其他组。

因此存在两类相反的故障。状态改变后，相关响应可能仍然陈旧。另一方面，如果组名过于宽泛，或者多个租户共用源站而权限控制不足，某一方可能与另一方资源建立组关系，甚至影响另一方资源的失效。组名不透明并不等于安全隔离；共享源站尤其需要托管方控制字段的产生和访问权限。

工程上的决定不是把一个响应头当作全站清除按钮，而是明确它在哪个缓存、哪个源站和哪个权限域内有效。需要多缓存一致性的系统必须另行设计同步机制。采用该机制时，应说明哪些缓存会观察到它、失效是否可选，以及哪些请求上的字段必然不会产生作用。

来源