Asp.net mvc MVC绑定和缓存问题

我将System.Web.Optimization与MVC4应用程序一起使用，该应用程序位于一些负载平衡器后面的服务器场上。有些客户端通过缓存代理访问此web。我们无法控制他们的代理

MVC绑定是智能的，因为它在绑定脚本引用后面附加了一个？v={hash}url参数，该参数对于绑定中的文件是唯一的。因此，每当捆绑包中的文件发生更改时，哈希也会发生更改，并且会再次请求该文件

问题是：如果散列与当前文件不匹配，我如何阻止包的交付

通常的部署过程是：

• 将服务器1从负载平衡器中取出
• 更新服务器1
• 服务器1上的测试内容
• 将服务器1放回服务器场
• 对服务器场中的所有其他服务器进行清洗并重复，一次一台

在最后一步中，有一个问题： 假设服务器1和2已经更新，服务器3当前正在更新（服务器场中没有），服务器4到8尚未更新

现在有大约1/4的机会，服务器1或2会响应请求。它们都有新的脚本，因此它们在bundle url后面的散列与服务器4-8使用的散列不同

尽管如此，仍有大约3/4的可能性，即针对此脚本的下一个请求（包含更新的哈希）被加载到一个尚未更新的服务器。即使url参数中的哈希值与旧文件内容不匹配，捆绑包仍然与旧内容一起交付。这对这个特定的客户来说是不好的

在我们的worser场景中，客户端的代理现在使用新的哈希将旧脚本缓存在新url下，这将导致该问题也被转移到缓存后面的所有其他客户端

---

我如何告诉捆绑，用404回答错误的哈希请求，这样就不会缓存错误的内容了？

目前，哈希仅用于缓存客户端上的bust。服务器完全忽略了这一点，只提供捆绑服务

好消息是客户端无法缓存捆绑包的“错误”版本，因为我们使用捆绑包的实际内容计算捆绑包哈希。因此，如果您的服务器仍然有混合/过时版本的文件，则哈希将在最终更新时更改

---

不幸的是，我没有一个很好的解决方法来解决如何避免这种情况，因为您的服务器场是不同的状态

第二部分对于解释的用例是错误的。服务器场中的Web服务器要么处于未更改的旧状态，要么处于已完全更新的状态。因此，当新服务器位于服务器场中时，有可能带有脚本链接的HTML附带了来自已更新服务器的新哈希。该请求可能会加载到尚未更新的服务器。这会忽略散列并传递旧脚本。使用该长时间缓存头，代理将为请求相同新脚本的所有其他客户端提供错误（旧）脚本。这显然是个大问题，明白了，我现在明白了