哪些CDN解决方案支持内容协商缓存?

Rub*_*rgh 11 caching http cdn content-negotiation cloudflare

我通过内容协商提供一系列资源.具体而言,任何URL都可以用不同的格式表示,具体取决于客户端的Accept标题.

Facebook的一个例子可以在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和客户端标题来缓存内容的CDNAccept.

出了什么问题的例子

CloudFlare不支持这一点:如果一个客户端要求HTML,那么对该URL的所有后续请求都会收到HTML表示,而不管其首选项如何.其他人有类似的问题.

例如,如果我将CloudFlare置于其上graph.facebook.com(并将其配置为缓存"无扩展"资源,默认情况下不会这样),那么它将表现不正确:

  1. http://graph.facebook.com/daft-punk通过卷曲请求JSON;
    作为回应,CloudFlare从服务器询问JSON原始文件,缓存它并提供服务.
  2. 我要求http://graph.facebook.com/daft-punk通过我的浏览器(因此在HTML中);
    作为响应,CloudFlare发送缓存的JSON(!)表示,即使原始服务器已发送HTML版本.

反而需要什么

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

哪些CDN解决方案支持内容协商,还缓存协商内容?
所以请注意,仅尊重接受是不够的; 协商响应也应该缓存.



PS1:很容易让自己的缓存服务器支持它.例如,对于nginx:

proxy_cache_key "$scheme$host$request_uri$http_accept";
Run Code Online (Sandbox Code Playgroud)

请注意客户端的Accept标头是如何为缓存编制索引的键的一部分.我希望在CDN上.


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

dam*_*are -2

我目前想不出我们会以任何方式对此产生影响。例如,我们默认不缓存 HTML 。您实际上看到过这个问题吗?您开立了支持票吗?