Question

我正在使用自定义框架来捆绑样式表和脚本。（即，这些是动态生成的响应，而不是静态文件。）

初次请求的响应，当第一次生成响应时，包括以下标题：

HTTP/1.1 200 OK
Cache-Control: public, no-transform, max-age=31536000
Content-Type: text/css; charset=utf-8
Content-Encoding: gzip
Last-Modified: Mon, 25 Aug 2014 18:15:50 GMT
Vary: Accept-Encoding
Date: Tue, 09 Sep 2014 16:19:36 GMT
Content-Length: 3126

既然上面的响应已经由服务器生成并缓存，那么对这些标题的后续请求将被响应：

HTTP/1.1 200 OK
Cache-Control: public, no-transform, max-age=31536000
Content-Type: text/css; charset=utf-8
Content-Encoding: gzip
Last-Modified: Mon, 25 Aug 2014 18:15:50 GMT
Date: Tue, 09 Sep 2014 16:20:00 GMT
Content-Length: 3126

忽略新的Date值，标题与缺少Vary标题的明显例外相同。

我在野外看到的一个令人讨厌的后果是，如果为给定资产生成的第一个响应未被压缩（由于相应的客户端不支持压缩），则服务器缓存该非压缩响应和为所有后续请求提供给所有客户。

知道如何让服务器保留缓存响应的Vary标头吗？

我正在使用HttpCacheability.Public来回复这些问题。我可以通过使用HttpCacheability.Private来避免此问题，但我更愿意允许服务器和代理缓存响应。

有些阅读让我相信，如果你因编码而异，那么IIS无法进行“内核缓存”。但我不确定这是否意味着我无法在服务器上缓存，或者它只是阻止了一种特殊的服务器端缓存。

更新

我最初使用以下内容设置Vary标题：

response.AppendHeader("Vary", "Accept-Encoding");

我尝试了另一种指定方法：

response.Cache.SetVaryByCustom("Accept-Encoding");

这导致永远不会发出Vary。甚至没有第一次回复。

作为最后的手段，我也在考虑使用：

response.Cache.SetNoServerCaching();

这会导致Cache-Control标头仍然指定public（以便代理仍然可以缓存），但会阻止服务器缓存。

Answer 1

根据我对该问题所做的更新，我尝试了另一种指定Vary标题的方法：

response.Cache.VaryByHeaders["Accept-Encoding"] = true;

......它解决了这个问题。响应现在在来自多个客户端的请求之间保留Vary标头，并且也由服务器缓存。

在提供服务器缓存的响应时，IIS 7正在剥离Vary标头

更新

1 个答案: