MVC捆綁和緩存問題

Question

我正在使用System.Web.Optimization與MVC 4應用程序，該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參數中的hashe與舊文件內容不匹配，但捆綁包仍然會與舊內容一起交付。這對於這個特定的客戶很不好。

在我們的情況下，客戶端的代理現在將舊腳本緩存在具有新散列的新URL下，這會導致此問題被轉移到緩存後面的所有其他客戶端。

我該如何判斷綁定，以404錯誤的散列來回答請求，以便不會緩存錯誤的內容？

Answer 1

目前哈希僅用於緩存客戶端上的半身像。服務器完全忽略這一點，只會提供捆綁服務。

好消息是，客戶端無法緩存'錯誤'版本的捆綁包，因爲我們使用捆綁包的實際內容來計算捆綁哈希值。因此，如果您的服務器仍然存在混合/過時的文件版本，則散列在最終更新時會發生變化。

不幸的是，我沒有一個很好的解決方法，因爲你有一個服務器場是不同的狀態，所以你可以避免這種情況。