鍍金池/ 問(wèn)答/Java  Linux  HTML/ 關(guān)于瀏覽器緩存和本地靜態(tài)資源的問(wèn)題

關(guān)于瀏覽器緩存和本地靜態(tài)資源的問(wèn)題

學(xué)nginx的時(shí)候把瀏覽器的緩存機(jī)制琢磨了一下。把相關(guān)http header研究了一下。
然后突然想起一個(gè)問(wèn)題,就是以前在本地開(kāi)發(fā)的過(guò)程中修改js文件時(shí)由于瀏覽器緩存導(dǎo)致新的改動(dòng)并沒(méi)有生效,必須清空才可以。
然后就想結(jié)合剛了解的http緩存機(jī)制來(lái)弄清楚以前那個(gè)js文件不生效的問(wèn)題。
可是問(wèn)題來(lái)了。為什么js文件在修改之后,刷新頁(yè)面,瀏覽器沒(méi)有從本地服務(wù)器獲取新的js文件而是從緩存中讀取。
我確認(rèn)了request header 里的cache-control是 max-age=0,就是說(shuō)向服務(wù)器確認(rèn)該js文件是否需要更新。
那有改動(dòng)的話應(yīng)該是重新請(qǐng)求js文件 且status為200才對(duì)呃。。。。
還是說(shuō)只要js文件的名字沒(méi)變。那么瀏覽器就認(rèn)為緩存是存在的,可以直接讀????并不需要判斷etag或者last-modified

回答
編輯回答
心沉

request header的cache-control: max-age=0只有在CTRL + F5強(qiáng)刷時(shí)才會(huì)加入
正常訪問(wèn)并不會(huì)加這種頭

你要控制瀏覽器的行為,應(yīng)該在服務(wù)端的cache-control里配置
不能脫離服務(wù)端的cache-control討論瀏覽器的緩存機(jī)制

request header是給服務(wù)器看的,不是給瀏覽器看的,你的理解本身就不對(duì)

服務(wù)端通過(guò)cache-control、etag、last-modified告訴瀏覽器和緩存服務(wù)器應(yīng)該怎么存儲(chǔ)和處理這個(gè)URL
如果符合一定規(guī)則(具體看下方文章),瀏覽器并不會(huì)向服務(wù)器發(fā)出請(qǐng)求,而是直接使用本地緩存

如果符合一定規(guī)則需要向服務(wù)器發(fā)出請(qǐng)求,瀏覽器通過(guò)If-Modified-Since If-None-Match cache-control告訴服務(wù)器應(yīng)該響應(yīng)304還是200

這篇文章已經(jīng)講得很清楚了:
https://developers.google.com...

2017年2月9日 19:18
編輯回答
萌面人

你自己一堆概念都沒(méi)有搞清楚。

可是問(wèn)題來(lái)了。為什么js文件在修改之后,刷新頁(yè)面,瀏覽器沒(méi)有從本地服務(wù)器獲取新的js文件而是從緩存中讀取。

首先,瀏覽器不知道你的 js 文件到底有沒(méi)有改。瀏覽器如果沒(méi)有發(fā)出遠(yuǎn)端請(qǐng)求,那么一定是“緩存頭”機(jī)制在發(fā)生作用。(前提是瀏覽器自己正確實(shí)現(xiàn)了 HTTP 協(xié)議的相關(guān)要求)

我確認(rèn)了request header 里的cache-control是 max-age=0,就是說(shuō)向服務(wù)器確認(rèn)該js文件是否需要更新。
那有改動(dòng)的話應(yīng)該是重新請(qǐng)求js文件 且status為200才對(duì)呃。。。。

這是你服務(wù)器的事,不是瀏覽器這個(gè)客戶端的事。

還是說(shuō)只要js文件的名字沒(méi)變。那么瀏覽器就認(rèn)為緩存是存在的,可以直接讀????并不需要判斷etag或者last-modified

文件名沒(méi)有變,緩存策略受“頭”控制。
文件名變了,一定不會(huì)有緩存,因?yàn)闉g覽器標(biāo)識(shí)資源是依賴 URI 的,文件名(準(zhǔn)備說(shuō)是是 URL 中的 path)是這個(gè) URI 的一部分。

2017年11月1日 15:43
編輯回答
祈歡

第一你可以用chrome開(kāi)發(fā)者工具中network查看,具體的js是從disk,或者內(nèi)存,還是獲取最新。
第二更新緩存的最有效辦法就是更新版本號(hào),如j.js?v=1.0

2017年11月6日 13:35