MVC 捆绑和缓存问题

Question

我将 System.Web.Optimization 与 MVC 4 应用程序一起使用，该应用程序托管在一些负载平衡器后面的场上。有一些客户端通过他们身边的缓存代理访问这个网络。我们无法控制他们的代理。

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。服务器完全忽略了这一点，只会提供捆绑包。

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

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