當啓用Rack :: Deflater時，ETag會發生變化

當啓用Rack :: Deflater來gzip我的響應主體時，偶然發現了一些奇怪的東西。也許我錯過了一些東西，但是啓用了這個功能後，響應被壓縮了，但是對於資源的ETag在每個請求上都發生了變化。這迫使應用程序每次都會做出響應，而不是發送304.這種方式在沒有啓用Rack :: Deflater的情況下運行，並且我已驗證頁面源不會更改。我正在使用精簡版的Web應用程序運行Rails應用程序。當啓用Rack :: Deflater時，ETag會發生變化

Gemfile.lock的 https://gist.github.com/2510816

有什麼方法我可以從機架中間件獲得更多的輸出，所以我也許能看到什麼回事？

在此先感謝。

來源

2012-04-27 Nick Dancer

所以我已經解決了我原來的問題，但仍然沒有得到理想的結果。原來Rack :: Deflater需要在中間件堆棧中的Rack :: ETag之前。仍然不知道爲什麼這會導致ETag改變每個請求，但是如果我將config.middleware.use "Rack::Deflater"更改爲 config.middleware.insert_before "Rack::ETag", "Rack::Deflater"，那麼ETag會在請求之間變得一致。我還沒有得到一個304，但我認爲這是因爲不正確的緩存控制頭和原來的問題無關。希望這有助於未來的人。

來源

2012-04-28 12:05:07

僅供參考'Rack :: ETag'中間只是創建標籤，無論它獲得什麼。將它放在中間件堆棧中的'Rack :: Deflater'之後，它將嘗試創建壓縮數據的散列，這是不正確的。 – 2012-04-28 12:43:27

是的，這是有道理的，但即使它從壓縮數據生成它，如果輸入數據和因此壓縮數據沒有改變，那麼服務器產生的ETag不應該保持不變。 – 2012-04-28 12:59:50

只要算法是確定性的，不會從外部添加任何數據。你也不能指望。猜測，壓縮是添加時間戳。或者可能隨機化其散列函數。 – 2012-04-28 13:06:29

當啓用Rack :: Deflater時，ETag會發生變化

回答

相關問題