什麼優先：ETag或Last-Modified HTTP標頭？

對於後面的兩個請求，如果其中一個標頭被改變，那麼以下兩個標頭中的哪一個會被瀏覽器賦予更多權重：ETag或Last-Modified？什麼優先：ETag或Last-Modified HTTP標頭？

2009-05-05 user101442

是不是更像是一個「OR」表達。在僞碼：

if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient 
    GetFromServer 
else 
    GetFromCache

來源

2009-05-05 10:12:13 Gidon

我想最後修改的時間戳應該區別比較，如：如果ETagFromServer = ETagOnClient ||！ LastModifiedOfOverServer> LastModifiedOnClient – RoyM 2014-08-31 15:32:29

這是一個AND語句，因爲ETag可能很弱，在這種情況下，您可以擁有語義等價的實體，然後回退到最後修改的標頭。考慮一種情況，一張圖片可以重新編碼，我們想說原始的和重新編碼是相同的，儘管它們不是字節相同的。在這種情況下，我們希望使用上次修改作爲後備，這就是爲什麼它們必須一致 – ParoX 2016-03-24 04:30:56

根據RFC 2616部分13.3.4中，HTTP 1.1客戶端必須使用ETag的任何緩存條件請求，並且如果兩個一個ETag和上次修改都存在，它應該使用這兩者。除非服務器明確聲明弱，否則ETag頭被認爲是一個強有力的驗證器（參見13.3.3節），而最後修改的頭被認爲是弱的，除非它和Date頭之間至少存在一分鐘差異。但請注意，服務器不需要發送（但它應該，如果可以的話）。

注意，客戶端不檢查頭，看看他們是否已經改變;它只是在下一個有條件的請求中盲目地使用它們;由服務器決定是否發送請求的內容或304 Not Modified響應。如果服務器只發送一個，那麼客戶端將單獨使用該服務器（儘管只有強有力的驗證器才能用於Range請求）。當然，它也可以由中間緩存（除非它們已經通過緩存控制指令被緩存）和服務器決定它們將如何處理標題; RFC規定，如果驗證器不一致，它們絕不能返回304 Not Modified，但由於標頭值是由服務器生成的，因此它有很大的餘地。

在實踐中，我注意到，瀏覽器，火狐和IE 7+所有同時發送標題，如果有的話。我還測試了發送修改標題時的行爲，我已經從RFC中的信息中猜測了這些行爲。我測試的四個客戶端只在頁面被刷新時發送條件請求，或者是當前進程第一次請求頁面。

來源

2009-10-13 13:01:15

=！是正確的比較運算符。客戶端需要保留從服務器接收的文字字符串，因爲轉換可能會造成很小的差異。你不能認爲'更新更好'。

爲什麼？考慮服務器運營商恢復資源的錯誤版本的情況。恢復版本更舊 - 但是正確。

客戶機必須使用當前由服務器提供的版本;它只能在相同的情況下使用緩存版本。因此，服務器必須檢查平等，而不是「更新」。

來源

2014-11-14 12:48:08 AccuracyInReponses

什麼優先：ETag或Last-Modified HTTP標頭？

回答

相關問題