HTTP ETag
| HTTP／HTTPS |
|---|
 |
| 版本 |
| 請求方法 |
| 報文主體 |
| 頭欄位 |
| 狀態碼 |
| 相關主題 |
ETag或實體標籤（entity tag）是萬維網協議HTTP的一部分。
ETag是HTTP協議提供的若干機制中的一種Web緩存驗證機制，並且允許客戶端進行緩存協商。這就使得緩存變得更加高效，而且節省帶寬。如果資源的內容沒有發生改變，Web伺服器就不需要發送一個完整的響應。ETag也可用於樂觀並發控制[1]，作為一種防止資源同步更新而相互覆蓋的方法。
ETag是一個不透明的標識符，由Web伺服器根據URL上的資源的特定版本而指定。如果那個URL上的資源內容改變，一個新的不一樣的ETag就會被分配。用這種方法使用ETag即類似於指紋，並且他們能夠被快速地被比較，以確定兩個版本的資源是否相同。ETag的比較只對同一個URL有意義——不同URL上的資源的ETag值可能相同也可能不同，從他們的ETag的比較中無從推斷。
部署風險
[編輯]ETag在HTTP頭字段中的使用是可選的（不像HTTP/1.1的其他頭字段是強制性的）。HTTP規範從未指定生成ETag的方法。
生成ETag常用的方法包括對資源內容使用抗碰撞散列函數，使用最近修改的時間戳的哈希值，甚至只是一個版本號。
為了避免使用過時的緩存數據，用於生成ETag的方法應保證（同時儘可能的實用）每一個ETag都是唯一的。然而，只要ETag的生成函數可以用數學證明，即使生成的ETag可能重複，其概率也是可接受範圍內的無窮小，那麼就可以判斷這個函數是可用的。
一些早期的校驗和函數，如CRC32和CRC64，常會碰到哈希碰撞問題。正因如此，他們並不是用於生成ETag的好選擇。
強校驗和弱校驗
[編輯]ETag機制同時支持強校驗和弱校驗。它們通過ETag標識符的開頭是否存在「W/」來區分，如：
"123456789" -- 一个强ETag验证符 W/"123456789" -- 一个弱ETag验证符
強校驗的ETag匹配要求兩個資源內容的每個字節需完全相同，包括所有其他實體字段（如Content-Language）不發生變化。強ETag允許重新裝配和緩存部分響應，以及字節範圍請求。弱校驗的ETag匹配要求兩個資源在語義上相等，這意味着在實際情況下它們可以互換，而且緩存副本也可以使用。不過這些資源不需要每個字節相同，因此弱ETag不適合字節範圍請求。當Web伺服器無法生成強ETag的時候，比如動態生成的內容，弱ETag就可能發揮作用了。
典型用法
[編輯]在典型用法中，當一個URL被請求，Web伺服器會返回資源和其相應的ETag值，它會被放置在HTTP的「ETag」字段中：
ETag: "686897696a7c876b7e"
然後，客戶端可以決定是否緩存這個資源和它的ETag。以後，如果客戶端想再次請求相同的URL，將會發送一個包含已保存的ETag和「If-None-Match」字段的請求。
If-None-Match: "686897696a7c876b7e"
客戶端請求之後，伺服器可能會比較客戶端的ETag和當前版本資源的ETag。如果ETag值匹配，這就意味着資源沒有改變，伺服器便會發送回一個極短的響應，包含HTTP 「304 未修改」的狀態。304狀態告訴客戶端，它的緩存版本是最新的，並應該使用它。
然而，如果ETag的值不匹配，這就意味着資源很可能發生了變化，那麼，一個完整的響應就會被返回，包括資源的內容，就好像ETag沒有被使用。這種情況下，客戶端可以用新返回的資源和新的ETag替代先前的緩存版本。
ETag值可用於網頁監視系統。大多數站點沒有為網頁設置ETag頭信息，這一事實阻礙了高效的網頁監測。當Web監視器不知道網站內容是否發生變化的時候，它不得不被檢索和分析所有的內容，這不僅佔用發佈者的計算資源，還有訂閱者的。
用ETag來跟蹤用戶
[編輯]由於HTTP cookie被越來越多的注重私隱保護的用戶刪除，可以將ETag用來追蹤唯一用戶[2]。2011年7月，Ashkan Soltani和加州大學伯克利分校的一組研究者，包括Hulu.com將ETag用於追蹤用途。[3]Hulu和KISSmetrics在2011年7月29日停止了這樣的追蹤，[4]而KISSmetrics和超過20位其用戶面臨關於「無法刪除」的cookie的集體訴訟，其中包括了ETag的使用。[5]
因為ETag由瀏覽器保存，並且在訪問統一資源時隨之後請求返回，一個追蹤伺服器可以輕鬆地重複設定任何從瀏覽器收到的ETag，以保持ETag不變，類似於持久cookie。額外的緩存頭部也能增強ETag的持久性。[6]
根據實現，ETag可以通過清除瀏覽器緩存清除。
參考資料
[編輯]- ^ Editing the Web - Detecting the Lost Update Problem Using Unreserved Checkout. W3C Note. 10 May 1999 [2014-05-22]. （原始內容存檔於2013-06-03）.
- ^ tracking without cookies. 17 February 2003 [2014-05-22]. （原始內容存檔於2013-06-03）.
- ^ Flash Cookies and Privacy II: Now with HTML5 and ETag Respawning. 29 July 2011 [2014-05-22]. （原始內容存檔於2013-06-03）.
- ^ Respawn Redux. 11 August 2011 [2014-05-22]. （原始內容存檔於2013-06-03）.
- ^ AOL, Spotify, GigaOm, Etsy, KISSmetrics sued over undeletable tracking cookies. [2014-05-22]. （原始內容存檔於2014-05-22）.
- ^ Cookieless cookies (using ETags as cookies). [2014-05-22]. （原始內容存檔於2013-08-27）.
外部連結
[編輯]- Apache HTTP Server Documentation - FileETag Directive（頁面存檔備份，存於互聯網檔案館）
- Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout（頁面存檔備份，存於互聯網檔案館）, W3C Note, 10 May 1999.
- Old SQUID Development projects - ETag support（頁面存檔備份，存於互聯網檔案館） (completed in 2001)
- Using ETags to Reduce Bandwidth & Workload with Spring & Hibernate（頁面存檔備份，存於互聯網檔案館）
- Live demo of zombie cookie using ETags
- ETag in HTTP/1.1 specification（頁面存檔備份，存於互聯網檔案館）
- Concerning ETags and Datestamps by Lars R. Clausen (2004)