我正在将System.Web.Optimization与MVC 4应用程序一起使用，该应用程序托管在一些负载均衡器后面的服务器场中。有些客户端通过缓存代理访问此Web。我们无法控制他们的代理。
MVC捆绑很聪明，因为它在捆绑脚本引用后面添加了一个？v = {hash} url参数，这对于捆绑包中的文件是唯一的。因此，每当捆绑包中的文件发生更改时，哈希值也会更改，并且将再次请求该文件。
问题是：如果该哈希值与当前文件不匹配，如何阻止捆绑包的传送？
通常的部署过程是：
在最后一个问题中存在一个问题： 假设服务器1和2已经更新，服务器3当前正在更新（并且不在服务器场中），服务器4到8尚未更新。
现在有可能约。 1/4，服务器1或2应答请求。它们都有新脚本，因此它们在bundle url后面的哈希值与服务器4-8使用的哈希值不同。
然而，有可能约。 3/4，对于具有更新的散列的该脚本的下一个请求正好被加载到一个尚未更新的服务器上。即使url参数中的hashe与旧文件内容不匹配，仍然会使用旧内容传递该bundle。这对这个特定的客户来说很糟糕。
在我们的恶劣情况下，客户端的代理现在使用新哈希将旧脚本缓存在新URL下，这将导致此问题被转移到该缓存后面的所有其他客户端。
如何告诉捆绑，用404错误的哈希回答请求，以便不能缓存错误的内容？
答案 0 :(得分：0)
目前，哈希仅用于缓存客户端上的半身像。服务器完全忽略了这一点，并且只是为捆绑服务提供服务。
好消息是客户端无法缓存捆绑包的“错误”版本，因为我们使用捆绑包的实际内容来计算捆绑包哈希值。因此，如果您的服务器仍然具有混合/陈旧版本的文件，则哈希将在最终更新时发生更改。
不幸的是，鉴于你有一个服务器场是不同的状态，我没有一个很好的解决办法，因为你可以避免这种情况。