Cloudflare 终于支持 HTTP 最丑的 Vary 头
We just shipped support for the ugliest part of HTTP: Vary – Cloudflare Blog
HTTP 协议中的 Vary 头常被称为“最丑陋的部分”，因为它极易导致缓存碎片化，让本可复用的内容变成成千上万个孤立的缓存条目。Cloudflare 刚刚推出了全新的 Cache Rules 功能，原生支持 Vary 头。现在，源服务器只需声明哪些请求头可能影响响应，而你可以决定 Cloudflare 如何处理这些差异：是标准化相似请求以合并缓存，还是精确透传以保持区分，亦或是直接绕过缓存。这一更新旨在解决“正确缓存却毫无用处”的困境，在确保响应准确性的同时，大幅减少缓存浪费，提升命中率。
丑陋并不意味着无用，但如果不加控制，完美的缓存策略也可能变得毫无价值。
HN 评论区
24- simonw
我盼着 Cloudflare 能支持这个功能已经好多年了。
这里经典的场景是：发送 "accept: text/html" 的用户代理获取 HTML，而不发送该头的用户代理则获取 JSON 或其他格式。
过去这在 Cloudflare 缓存后面根本无法部署，因为他们除了图片之外会忽略所有资源的 Vary 头——所以你有可能缓存了 JSON 版本，然后把它返回给期待 HTML 的用户。
（抛开 Cloudflare 这个功能不谈，我最终决定不再使用这种模式，因为我更倾向于让 URL 可预测地返回 HTML 或 JSON——我会在我的应用 URL 后加 .json 后缀来提供 JSON 服务。）
- colmmacc
哇，这勾起了我的回忆。二十多年前，我为 Apache 2.0 的各种 mod_cache 子模块添加了 Vary 支持，结果发现投入产出比太低了。这暴露了太多用户代理的 Bug 和疯狂的后端实现。我记得当时有过争论，关于能否基于非字面虚拟头（比如地理位置头）来缓存变量，还有一个疯狂的请求是要根据 "Date:" 头来 Vary……这完全说不通。整个机制就是聪明反被聪明误。语言选择最终落在 URL 里（/en-US/..）而不是通过 "Vary: Accept-Lang" 特性来实现，这倒也不足为奇。
- tiffanyh
我只希望 Cloudflare 能兑现一年前的承诺，将企业级功能开放给更低层级（付费）的用户，但他们至今尚未做到。
https://blog.cloudflare.com/enterprise-grade-features-for-al...
比如 Prefetch 功能：https://developers.cloudflare.com/speed/optimization/content...