上篇文章我們知道，當我們給catch-control 設定了 no-catch 後，每次瀏覽器對這個資源的請求時，都會到伺服器端進行資源驗證，驗證完之後，如果確定這個資源可以使用快取，瀏覽器才會讀取本地的快取。
下面是瀏覽器請求資料過程中關於快取的步驟。
進行資料驗證，主要是有兩個header： last-modified 與 etag .
last-modified 即上次修改時間。
它主要配合if-modified-since 或者 if-unmodified-since 這兩個header 使用。
（如果我們請求的乙個資源，它返回的header 中有last-modified 並指定了乙個時間；那麼下次瀏覽器再傳送這個請求的時候就會帶上這個時間，並把它放在 if-modified-since（通常） 或者 if-unmodified-since 這兩個header中；伺服器就可以根據if-modified-since 或者 if-unmodified-since 這兩個header的值對比資源上次修改的時間，如果兩個時間一致，那麼就可以使用快取）
etag 它是乙個更為嚴格的驗證
它是用過資料簽名的方式驗證
它根據資料內容產生乙個唯一的編碼（資料不同，編碼結果不同）。最典型的做法，是我們對資料內容做乙個雜湊計算。
它主要配合 if-match 或者 if-none-match 使用。
同上，通過對比資源的簽名判斷是否使用快取。
下面我們來實驗一下。
server.js 如下
testmaxage.html 如下
hello world
don't speak
開啟localhost：8888 頁面。
重新整理兩次頁面後，我們可以看看 script.js 請求。確實是有 if-modified-since 和 if-none-match 的。
但是，這時候，這個請求還是會返回資料。
我們希望驗證通過伺服器端就不要返回資料了。
這時候，我們重新整理兩次瀏覽器，會發現在控制台仍然會有返回資料，這其實是瀏覽器將命中快取中的資料顯示出來的。瀏覽器實際上是根據http code 304，來認定使用快取資料的（當我們在304時，返回其他資料，會直接被忽略）。
done.
MyBatis 快取詳解 一級快取驗證
基於mybatis standalone 工程，注意演示一級快取需要先關閉二級快取，localcachescope 設定為session 判斷是否命中快取 如果再次傳送sql 到資料庫執行，說明沒有命中快取 如果直接列印物件，說明是從記憶體快取中取到了結果。1 在同乙個session 中共享 2 不...
快取驗證Last Modified和Etag的使用
快取工作示意圖 瀏覽器建立乙個請求，然後請求到達本地快取，如果找到了則直接返回給瀏覽器，如果沒有，可能會經過 服務，然後去 快取中去找，如果命中，則直接返回，如果沒有，才會到源伺服器進行請求。在http協議裡面，資料的驗證方式，主要有兩個驗證頭 last modified 和 etag。last m...
快取驗證Last Modified和Etag的使用
快取工作示意圖 在http協議裡面，資料的驗證方式，主要有兩個驗證頭 last modified 和 etag。last modified 配合last modified since或者if unmodified since使用，對比上次修改的時間驗證資源是否需要更新。etag 是乙個更加嚴格的資料...