哪些 CDN 解决方案支持通过内容协商进行缓存？答案

【问题标题】：Which CDN solutions support caching with content negotiation?哪些 CDN 解决方案支持通过内容协商进行缓存？
【发布时间】：2013-12-13 02:43:06
【问题描述】：

我通过内容协商提供一组资源。具体来说，任何 URL 都可以用不同的格式表示，取决于客户端的 Accept 标头。

这方面的一个例子可以在 Facebook 上看到：

curl -H "Accept: application/json" http://graph.facebook.com/daft-punk
JSON 格式的结果
curl -H "Accept: text/turtle" http://graph.facebook.com/daft-punk
海龟的结果

我正在寻找基于 URL 和客户端的 Accept 标头缓存内容的 CDN。

CloudFlare 不支持这一点：如果一个客户端请求 HTML，那么对该 URL 的所有后续请求都会收到 HTML 表示，而不管他们的偏好如何。 Others have similar issues.

例如，如果我将 CloudFlare 放置在 graph.facebook.com 上（并将其配置为缓存“无扩展”资源，默认情况下它不会这样做），那么它将行为不正确：

我通过 curl 在 JSON 中请求http://graph.facebook.com/daft-punk；
作为响应，CloudFlare 会从服务器请求 JSON 原始文件，将其缓存并提供服务。
我通过浏览器请求http://graph.facebook.com/daft-punk（因此是HTML）；
作为响应，CloudFlare 会发送缓存的 JSON (!) 表示，即使原始服务器会发送 HTML 版本。

正确的行为是 CloudFlare 再次询问服务器，因为第二个客户端有不同的 Accept 标头。在此之后，可以从缓存中提供具有相似 Accept 标头的请求。

哪些 CDN 解决方案支持内容协商，并且还缓存协商的内容？
所以请注意，仅尊重Accept 是不够的；协商的响应也应该被缓存。

PS1：很容易让您自己的缓存服务器支持它。例如，对于 nginx：

proxy_cache_key "$scheme$host$request_uri$http_accept";

请注意客户端的 Accept 标头如何成为索引缓存的键的一部分。我想要 CDN 上的那个。

PS2：不能为不同的表示使用不同的 URL。我的应用程序位于Linked Data 域中，其中 URL 起着重要的识别作用。

【问题讨论】：

【解决方案1】：

似乎 maxcdn 仍然可以为内容协商设置自定义 nginx 规则（尽管他们的常见问题解答说）-http://blog.maxcdn.com/how-to-reduce-image-size-with-webp-automagically/#comment-1048561182

【讨论】：

【解决方案2】：

目前我想不出我们会以什么方式影响这一点。例如，我们没有cache HTML by default。你真的看到过这个问题吗？你开过支持票吗？

【讨论】：

在我开始这个帖子之前，我已经创建了一个支持请求 (#68719)。工作人员非常乐于助人，但他们确认 CloudFlare 不支持缓存内容协商响应。他们还表示，它“不在近期的路线图中添加”。默认是基于扩展的，所以带有.html extension 的文件在默认情况下不会被缓存（但这可以改变）。问题：尝试使用内容协商缓存任何站点。无论新客户端的 Accept 标头如何，只缓存第一个提供的表示，并重复提供。这在未来会有所改善吗？
问题更新了 CloudFlare（以及我测试过的其他问题）的示例。