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://www.rfc-editor.org/rfc/rfc2616#section-7.1

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

304（未修改）状态代码表示已收到条件 GET 或 HEAD 请求，如果不是条件评估结果为 false，则会导致 200（OK）响应。换句话说，服务器不需要传输目标资源的表示，因为该请求表明发出有条件请求的客户端已经具有有效的表示；

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

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

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

我的结论是 ASP.NET 和 IIS 正确解释了此规范，并且不支持您尝试执行的操作。一个证明是 Apache 和其他流行的 Web 服务器执行与上面解释的相同的操作。

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