ASP.NET MVC OutputCache不存储自定义标头
本文关键字：自定义 存储 NET MVC OutputCache ASP | 更新日期: 2023-09-27 18:21:10
我的应用程序使用带有OutputCache的ASP.NET MVC 5（详细地说，我们使用MVCDonutCache）来缓存高流量站点和昂贵的路由。
有些Actions有一个Custom ActionFilter，它根据视图模型添加一个Content-Range标头。没有缓存，它就像魅力一样发挥作用。当启用缓存时，第一个命中是可以的（响应中存在Content-Range标头），但第二个只包含Content-Type和HTML/JON-response，并且我们的自定义Content-Range标头丢失（这破坏了客户端功能）。
有没有任何方法可以在不编写自己的OutputCache实现的情况下启用正确的头缓存？
非常感谢。
缓存的响应是一个"304-未修改"；HTTP响应，并且这种响应不应返回实体标头（除了一些例外，如"Last Modified"）。
"；内容范围"；您试图返回的标头是一个实体标头：
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）如果不是因为该情况评估为false。换句话说，不需要服务器传输目标资源的表示，因为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响应的组件。