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

【问题标题】：ASP.NET MVC OutputCache does not store Custom HeadersASP.NET MVC OutputCache 不存储自定义标头
【发布时间】：2014-09-08 19:35:03
【问题描述】：

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

一些动作有一个自定义动作过滤器，它根据视图模型添加一个Content-Range 标题。没有缓存它就像魅力一样。启用缓存后，第一个命中没问题（响应中存在Content-Range 标头）-但第二个仅包含 Content-Type 和 HTML/JSON 响应以及我们的自定义 Content-Range 标头丢失（这会破坏客户端功能）。

有没有什么方法可以在不编写自己的 OutputCache 实现的情况下启用正确的标头缓存？

非常感谢。

【问题讨论】：

是发出请求还是使用本地缓存的请求，OutputCache 设置的目的是什么？
请求被发送到服务器并由它回答。请求通过路由并在 DonutOutputCache ActionFilter 上停止，该 ActionFilter 提供原始 Http 内容的副本，设置内容类型和一些缓存标头。
自定义头部动作过滤器注解是在输出缓存注解之前还是之后？

标签： c# asp.net-mvc caching

【解决方案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 请求已收到，并会导致 200 （OK）响应，如果不是因为条件已经评估为假。换句话说，不需要服务器传输目标资源的表示，因为 request 表示发出请求的客户端有条件的，已经有一个有效的表示；

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

如果条件 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 响应的组件。

【讨论】：