Cloudflare 终于支持 HTTP Vary 头：内容协商缓存难题破解

HTTP 中最棘手的部分终于被攻克

Cloudflare 近期宣布支持 HTTP 协议中被开发者戏称为"最丑陋部分"的 Vary 头。这一变化看似不起眼，却解决了困扰众多开发者多年的边缘缓存难题。知名开发者 Simon Willison 在 Hacker News 的讨论中直言，他"多年来一直期待 Cloudflare 能实现这个功能"。

Vary 头是 HTTP 内容协商机制的核心。它告诉缓存服务器：同一个 URL 的响应内容可能会因请求头（如 Accept、Accept-Encoding、Accept-Language）的不同而变化。理解它为何重要，需要先看清它试图解决的问题。

内容协商与缓存的经典冲突

一个典型场景是：当用户代理发送 Accept: text/html 时，服务器返回 HTML 页面；而当客户端请求其他格式时，服务器则返回 JSON 或其他数据格式。这种基于请求头的内容协商，是构建灵活 API 与网页共存服务的常见做法。

问题在于边缘缓存的介入。Simon Willison 指出，过去这种模式"根本无法部署在 Cloudflare 缓存之后"。原因很直接——Cloudflare 此前只对图片资源尊重 Vary 头，对其他类型的响应则一律忽略。

后果可想而知：缓存系统可能把某次请求返回的 JSON 版本存了下来，随后又把这个 JSON 直接返回给一个明明期待 HTML 的用户。同一个 URL，缓存错了内容类型，页面直接崩坏。这正是 Vary 头被称为 HTTP"最丑陋部分"的现实写照——概念简单，正确实现却异常棘手。

HTTP 内容协商（Content Negotiation）是 HTTP/1.1 规范定义的一种机制，允许服务端根据客户端能力或偏好返回同一资源的不同表示形式。最常见的协商维度包括：Accept（内容格式，如 HTML/JSON/XML）、Accept-Encoding（压缩方式，如 gzip/br）、Accept-Language（语言偏好，如 zh-CN/en-US）以及 Accept-Charset（字符集）。当服务端根据这些请求头动态调整响应时，必须在响应中附上对应的 Vary 头，告知下游缓存哪些请求头的差异会导致响应内容不同。若省略 Vary 头，缓存服务器便无从得知响应内容依赖哪些请求维度，极易将针对特定客户端类型的响应错误地返回给其他类型的请求者，造成所谓的「缓存污染」。这一机制在单机场景下逻辑清晰，但在 CDN 分布式缓存层实现时复杂度急剧上升。

为什么 Vary 支持这么难做

Vary 头的实现复杂性，源于它要求缓存系统为同一 URL 维护多个变体（variant）版本。缓存不能再简单地以 URL 作为键，而必须结合 Vary 中列出的请求头值来生成组合缓存键。

对于运行在全球数百个节点的 CDN 而言，这意味着缓存命中逻辑、存储开销和一致性维护都会成倍增加。当 Vary 头引用像 User-Agent 这类高基数字段时，缓存的有效性甚至可能被彻底摧毁——每个略有差异的浏览器标识都会产生一个新变体。这也是许多 CDN 长期选择性忽略 Vary 头的技术原因。

Cloudflare 此次全面支持 Vary，意味着开发者终于可以放心地在边缘缓存层部署内容协商方案，而不必担心缓存污染问题。

「高基数」（High Cardinality）是理解 Vary 头危险性的关键概念。所谓基数，指某个字段可能取值的数量级。Accept-Language 的常见取值有限（数十种语言组合），属于低基数字段，对缓存的影响可控。但 User-Agent 字符串因浏览器版本、操作系统、设备型号的组合而呈现出数以百万计的不同值，属于极高基数字段——一旦 Vary: User-Agent 出现，缓存系统实际上需要为每个独特的浏览器标识单独存储一份响应副本，缓存命中率趋近于零，CDN 反而成了透明代理。正因如此，HTTP 规范的建议是：Vary 头应只列出真正影响响应内容的最小头部集合，且应优先选择低基数字段。许多 CDN 为保护自身基础设施稳定性，选择拒绝或忽略包含高基数字段的 Vary 头，或干脆全面放弃 Vary 支持。

实践中的另一种取舍

有意思的是，尽管 Simon Willison 期待这个功能多年，他本人却已经决定不再使用基于 Accept 头的内容协商模式。

他给出的理由值得每位 API 设计者思考：他更偏好"能可预测地返回 HTML 或 JSON 的 URL"。具体做法是——在应用中为 URL 添加 .json 后缀来显式请求 JSON 数据，而不是依赖请求头来隐式切换格式。

这种设计哲学与内容协商代表了两种不同思路：

• 内容协商（Vary 依赖）：一个 URL 服务多种表示形式，通过请求头区分，语义上更符合 REST 理念，但对缓存和调试不友好。
• 显式 URL 后缀：/data 返回 HTML，/data.json 返回 JSON，URL 与内容一一对应，可预测、易缓存、便于调试和分享。

后者牺牲了一定的 HTTP 语义纯粹性，换来了工程实践中的确定性。这也解释了为何即便 Cloudflare 补齐了 Vary 支持，仍有不少开发者会继续选择更简单的后缀方案。

对开发者意味着什么

这项更新为需要内容协商的团队打开了新的可能。对于那些已经依赖 Accept 头返回不同格式、又希望享受 Cloudflare 边缘缓存加速的应用，现在可以更安全地组合使用两者。

但更深层的启示在于：技术能力的补齐并不等于设计方案的最优。Vary 头终于可用，但是否使用它，仍取决于你对可预测性、可缓存性和 API 语义之间的权衡。对多数追求简单和确定性的项目而言，显式的 URL 约定或许仍是更稳妥的选择。

无论如何，HTTP"最丑陋的部分"终于在主流 CDN 上得到了正确对待，这本身就是基础设施成熟度的一个积极信号。