ASP.NET MVC OutputCache不存储自定义标头

Question

我的应用程序使用带有OutputCache的ASP.NET MVC 5（详细地说，我们使用MVCDonutCaching）来缓存高流量站点和昂贵的路由。

某些Actions具有Custom ActionFilter，它根据视图模型添加Content-Range标头。 没有缓存它就像魅力一样。 启用缓存后，第一次命中即可（响应中存在Content-Range标头） - 但第二次只包含Content-Type和HTML / JSON响应，并且我们的自定义Content-Range标头丢失（这打破了客户端功能）。

有没有办法在不编写自己的OutputCache实现的情况下启用正确的头缓存？

非常感谢你。

Answer 1

缓存的响应是“304 - 未修改”的HTTP响应，并且这种响应不会返回实体标头（除了“Last-Modified”之类的一些例外）。

您尝试返回的“Content-Range”标头是实体标头：

http://www.freesoft.org/CIE/RFC/2068/178.htm

以下是实体标头的完整列表：

https://tools.ietf.org/html/rfc2616#section-7.1

304没有返回实体头的原因是304响应不应该返回目标资源的完整表示，因为没有任何改变。

304（未修改）状态代码表示已收到条件GET或HEAD请求，如果不是因为条件已评估为假，则会产生200（OK）响应。 换句话说，服务器不需要传送目标资源的表示，因为请求指示使请求有条件的客户端已经具有有效表示;

这意味着不应再次传输实体标头。 这确保了一致性，并且还具有一些性能优势。

如果条件GET使用强缓存验证器（参见第13.3.3节），则响应不应包括其他实体头。 否则（即条件GET使用弱验证器），响应不得包含其他实体头; 这可以防止缓存的实体主体和更新的标头之间的不一致。

https://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-23#section-4.1

我的结论是ASP.NET和IIS正确地解释了这个规范，并且不支持你想要做的事情。 对此的证明是Apache和其他流行的Web服务器的行为与上面解释的相同。

如果您仍需要304中的标题，则必须识别并替换（如果可能）负责过滤304响应的组件。