4

我将 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 的错误哈希回答请求，以便不会缓存错误的内容？

4

1 回答 1

0

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

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

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

于 2013-02-06T19:00:06.310 回答