asp.net-mvc - MVC 捆绑和缓存问题

Question

我将 System.Web.Optimization 与 MVC 4 应用程序一起使用，该应用程序托管在一些负载均衡器后面的场上。有一些客户端通过其侧的缓存代理访问此 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 参数中的哈希值与旧文件内容不匹配，捆绑包仍会随旧内容一起交付。这对这个特定的客户来说是不利的。

在我们更糟糕的情况下，客户端的代理现在将旧脚本缓存在带有新哈希的新 URL 下，这将导致这个问题也被转移到该缓存后面的所有其他客户端。

我怎么能告诉捆绑，用 404 来回答带有错误哈希的请求，这样就不会缓存错误的内容？

Answer 1

目前散列仅用于在客户端缓存 bust。服务器完全忽略了这一点，只会为捆绑提供服务。

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

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