[http] Last-Modified, If-Modified-Since, ETag 和 If-None-Match 介紹

在上一篇介紹了 http 關於 cache 的 header ，但當 cache 過期或是需要 revalidate 時又是如何運作的呢?

此篇將介紹幾個常見的 revalidate 的 http header

request

用於做 revalidate 時，檢查檔案在指定時間後是否有被變更，若有回傳 200 及新的檔案內容，反之則回傳 304 (Not Modified) 即可。

response:

在 response 帶回此檔案上次在伺服器被修改的時間，以備做 revalidate 時發送的 timestamp。

實際上的使用情境會像是以下步驟:

client 發 request 與伺服器要 image.png 檔案
server 回傳 Cache-Control: max-age=86400, no-cache , Last-Modified: Wed, 21 Oct 2018 07:28:00 GMT 及 image.png 檔案
client 收到後將 image.png 存入 cache
client 下次來訪網頁，再次要 image.png，因為 no-cache 所以需要做 revalidate，因此會發送 If-Modified-Since: Wed, 21 Oct 2018 07:28:00 GMT
server 看檔案在 Wed, 21 Oct 2018 07:28:00 GMT 在這之後是否有被修改

這樣就結束了 revalidate，可以看出這樣既檢查檔案修改時間也可以省下許多檔案(body)的流量。

優點

缺點

request:

用於做 revalidate 時，檢查內容的 hash 值是否有更改，若有回傳 200 及新的檔案內容，反之則回傳 304 (Not Modified) 即可。

response:

在 response 帶回此檔案 ETag 值，以備做 revalidate 時發送的 timestamp。

實際上的使用情境會像是以下步驟:

client 發 request 與伺服器要 image.png 檔案
server 回傳 Cache-Control: max-age=86400, no-cache , ETag: “33a64df551425fcc55e4d42a148795d9f25f89d4” 及 image.png 檔案
client 收到後將 image.png 存入 cache
client 下次來訪網頁，再次要 image.png，因為 no-cache 所以需要做 revalidate，因此會發送 If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
server 計算此檔案的 ETag 值是否有更改

這樣就結束了 revalidate，可以看出這樣既可以檢查檔案內容也可以省下許多檔案(body)的流量。

優點

客製 ETag 計算，如 apache 就提供 inode, last modified time, mtime 及 size 等等，簡單來說不容易 collision 的 hash function 都可以，較有彈性
可以自己決定 hash function，因此若設計得宜精準且正確性高
向下相容 Last-Modified ，如 nginx 預設是拿 last modified time 來做 ETag

缺點

參考資料: