淺談瀏覽器HTTP的緩存機(jī)制_第1頁(yè)
淺談瀏覽器HTTP的緩存機(jī)制_第2頁(yè)
淺談瀏覽器HTTP的緩存機(jī)制_第3頁(yè)
淺談瀏覽器HTTP的緩存機(jī)制_第4頁(yè)
淺談瀏覽器HTTP的緩存機(jī)制_第5頁(yè)
已閱讀5頁(yè)，還剩17頁(yè)未讀， 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明：本文檔由用戶提供并上傳，收益歸屬內(nèi)容提供方，若內(nèi)容存在侵權(quán)，請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

淺談瀏覽器HTTP的緩存機(jī)制針對(duì)瀏覽器的http緩存的分析也算是老生常談了，每隔一段時(shí)間就會(huì)冒出一篇不錯(cuò)的文章，其原理也是各大公司面試時(shí)幾乎必考的問(wèn)題。之所以還寫一篇這樣的文章，是因?yàn)榻诙荚诟阈录夹g(shù)，想“回歸”下基礎(chǔ)，也希望盡量總結(jié)的更詳盡些。那么你是否還需要閱讀本篇文章呢？可以試著回答下面這個(gè)問(wèn)題：我們?cè)谠L問(wèn)百度首頁(yè)的時(shí)候，會(huì)發(fā)現(xiàn)不管怎么刷新頁(yè)面，靜態(tài)資源基本都是返回200（fromcache）：隨便點(diǎn)開一個(gè)靜態(tài)資源是醬的：哎喲有Response報(bào)頭數(shù)據(jù)呢，看來(lái)服務(wù)器也正常返回了etag什么鬼的應(yīng)有盡有，那狀態(tài)200不是應(yīng)該對(duì)應(yīng)的非緩存狀態(tài)么？要fromcache的話不是應(yīng)該返回304才合理么？難道是度娘的服務(wù)器故障了嗎？如果你知道答案，那就可以忽略本文了。http報(bào)文中與緩存相關(guān)的首部字段我們先來(lái)瞅一眼RFC2616規(guī)定的47種http報(bào)文首部字段中與緩存相關(guān)的字段，事先了解一下能讓咱在心里有個(gè)底：1.通用首部字段（就是請(qǐng)求報(bào)文和響應(yīng)報(bào)文都能用上的字段）2.請(qǐng)求首部字段3.響應(yīng)首部字段4.實(shí)體首部字段后續(xù)大體也會(huì)依次介紹它們。場(chǎng)景模擬為方便模擬各種緩存效果，我們建個(gè)非常簡(jiǎn)單的場(chǎng)景。1.頁(yè)面文件我們建個(gè)非常簡(jiǎn)單的html頁(yè)面，上面只有一個(gè)本地樣式文件和圖片：<html><head><title>緩存測(cè)試title><linkrel="stylesheet"href="css/reset.css">head><body><h1>哥只是一個(gè)標(biāo)題h1><p><imgsrc="img/dog.jpg"/>p>body>html>2.首部字段修改有時(shí)候一些瀏覽器會(huì)自行給請(qǐng)求首部加上一些字段（如chrome使用F5會(huì)強(qiáng)制加上“cache-control:max-age=0”）,會(huì)覆蓋掉一些字段（比如pragma）的功能；另外有時(shí)候我們希望服務(wù)器能多/少返回一些響應(yīng)字段。這種情況我們就希望可以手動(dòng)來(lái)修改請(qǐng)求或響應(yīng)報(bào)文上的內(nèi)容了。那么如何實(shí)現(xiàn)呢？這里我們使用Fiddler來(lái)完成任務(wù)。搜索后端架構(gòu)師公眾號(hào)回復(fù)“架構(gòu)整潔”，送你一份驚喜禮包。在Fiddler中我們可以通過(guò)“bpuXXX”指令來(lái)攔截指定請(qǐng)求，然后手動(dòng)修改請(qǐng)求內(nèi)容再發(fā)給服務(wù)器、修改響應(yīng)內(nèi)容再發(fā)給客戶端。以我們的example為例，頁(yè)面文件走nginx通過(guò)http://localhost/可直接訪問(wèn)，所以我們直接執(zhí)行“bpulocalhost”攔截所有地址中帶有該字樣的請(qǐng)求：點(diǎn)擊被攔截的請(qǐng)求，可以在右欄直接修改報(bào)文內(nèi)容（上半?yún)^(qū)域是請(qǐng)求報(bào)文，下半?yún)^(qū)域是響應(yīng)報(bào)文），點(diǎn)擊黃色的“BreakonResponse”按鈕可以執(zhí)行下一步（把請(qǐng)求發(fā)給服務(wù)器），點(diǎn)擊綠色的按鈕“RuntoCompletion”可以直接完成整個(gè)請(qǐng)求過(guò)程：通過(guò)這個(gè)方法我們可以很輕松地模擬出各種http緩存場(chǎng)景。3.瀏覽器的強(qiáng)制策略如上述，當(dāng)下大多數(shù)瀏覽器在點(diǎn)擊刷新按鈕或按F5時(shí)會(huì)自行加上“Cache-Control:max-age=0”請(qǐng)求字段，所以我們先約定成俗——后文提及的“刷新”多指的是選中url地址欄并按回車鍵（這樣不會(huì)被強(qiáng)行加上Cache-Control）。事實(shí)上有的瀏覽器還有一些更奇怪的行為，在后續(xù)我們回答文章開頭問(wèn)題的時(shí)候會(huì)提到。石器時(shí)代的緩存方式在http1.0時(shí)代，給客戶端設(shè)定緩存方式可通過(guò)兩個(gè)字段——“Pragma”和“Expires”來(lái)規(guī)范。雖然這兩個(gè)字段早可拋棄，但為了做http協(xié)議的向下兼容，你還是可以看到很多網(wǎng)站依舊會(huì)帶上這兩個(gè)字段。1.Pragma當(dāng)該字段值為“no-cache”的時(shí)候（事實(shí)上現(xiàn)在RFC中也僅標(biāo)明該可選值），會(huì)知會(huì)客戶端不要對(duì)該資源讀緩存，即每次都得向服務(wù)器發(fā)一次請(qǐng)求才行。Pragma屬于通用首部字段，在客戶端上使用時(shí)，常規(guī)要求我們往html上加上這段meta元標(biāo)簽（而且可能還得做些hack放到body后面去）：

<meta

http-equiv="Pragma"

content="no-cache">它告訴瀏覽器每次請(qǐng)求頁(yè)面時(shí)都不要讀緩存，都得往服務(wù)器發(fā)一次請(qǐng)求才行。BUT!!!事實(shí)上這種禁用緩存的形式用處很有限：1.僅有IE才能識(shí)別這段meta標(biāo)簽含義，其它主流瀏覽器僅能識(shí)別“Cache-Control:

no-store”的meta標(biāo)簽（見出處）。

2.在IE中識(shí)別到該meta標(biāo)簽含義，并不一定會(huì)在請(qǐng)求字段加上Pragma，但的確會(huì)讓當(dāng)前頁(yè)面每次都發(fā)新請(qǐng)求（僅限頁(yè)面，頁(yè)面上的資源則不受影響）。做了測(cè)試后發(fā)現(xiàn)也的確如此，這種客戶端定義Pragma的形式基本沒(méi)起到多少作用。不過(guò)如果是在響應(yīng)報(bào)文上加上該字段就不一樣了：如上圖紅框部分是再次刷新頁(yè)面時(shí)生成的請(qǐng)求，這說(shuō)明禁用緩存生效，預(yù)計(jì)瀏覽器在收到服務(wù)器的Pragma字段后會(huì)對(duì)資源進(jìn)行標(biāo)記，禁用其緩存行為，進(jìn)而后續(xù)每次刷新頁(yè)面均能重新發(fā)出請(qǐng)求而不走緩存。2.Expires有了Pragma來(lái)禁用緩存，自然也需要有個(gè)東西來(lái)啟用緩存和定義緩存時(shí)間，對(duì)http1.0而言，Expires就是做這件事的首部字段。Expires的值對(duì)應(yīng)一個(gè)GMT（格林尼治時(shí)間），比如“Mon,22Jul200211:12:01GMT”來(lái)告訴瀏覽器資源緩存過(guò)期時(shí)間，如果還沒(méi)過(guò)該時(shí)間點(diǎn)則不發(fā)請(qǐng)求。在客戶端我們同樣可以使用meta標(biāo)簽來(lái)知會(huì)IE（也僅有IE能識(shí)別）頁(yè)面（同樣也只對(duì)頁(yè)面有效，對(duì)頁(yè)面上的資源無(wú)效）緩存時(shí)間：<metahttp-equiv="expires"content="mon,18apr201614:30:00GMT">如果希望在IE下頁(yè)面不走緩存，希望每次刷新頁(yè)面都能發(fā)新請(qǐng)求，那么可以把“content”里的值寫為“-1”或“0”。注意的是該方式僅僅作為知會(huì)IE緩存時(shí)間的標(biāo)記，你并不能在請(qǐng)求或響應(yīng)報(bào)文中找到Expires字段。如果是在服務(wù)端報(bào)頭返回Expires字段，則在任何瀏覽器中都能正確設(shè)置資源緩存的時(shí)間：在上圖里，緩存時(shí)間設(shè)置為一個(gè)已過(guò)期的時(shí)間點(diǎn)（見紅框），則刷新頁(yè)面將重新發(fā)送請(qǐng)求（見藍(lán)框）。那么如果Pragma和Expires一起上陣的話，聽誰(shuí)的？我們?cè)囈辉嚲椭懒耍何覀兺ㄟ^(guò)Pragma禁用緩存，又給Expires定義一個(gè)還未到期的時(shí)間（紅框），刷新頁(yè)面時(shí)發(fā)現(xiàn)均發(fā)起了新請(qǐng)求（藍(lán)框），這意味著Pragma字段的優(yōu)先級(jí)會(huì)更高。BUT，響應(yīng)報(bào)文中Expires所定義的緩存時(shí)間是相對(duì)服務(wù)器上的時(shí)間而言的，如果客戶端上的時(shí)間跟服務(wù)器上的時(shí)間不一致（特別是用戶修改了自己電腦的系統(tǒng)時(shí)間），那緩存時(shí)間可能就沒(méi)啥意義了。Cache-Control針對(duì)上述的“Expires時(shí)間是相對(duì)服務(wù)器而言，無(wú)法保證和客戶端時(shí)間統(tǒng)一”的問(wèn)題，http1.1新增了Cache-Control來(lái)定義緩存過(guò)期時(shí)間，若報(bào)文中同時(shí)出現(xiàn)了Pragma、Expires和Cache-Control，會(huì)以Cache-Control為準(zhǔn)。Cache-Control也是一個(gè)通用首部字段，這意味著它能分別在請(qǐng)求報(bào)文和響應(yīng)報(bào)文中使用。在RFC中規(guī)范了Cache-Control的格式為："Cache-Control"":"cache-directive作為請(qǐng)求首部時(shí)，cache-directive的可選值有：作為響應(yīng)首部時(shí)，cache-directive的可選值有：我們依舊可以在HTML頁(yè)面加上meta標(biāo)簽來(lái)給請(qǐng)求報(bào)頭加上Cache-Control字段：另外Cache-Control允許自由組合可選值，例如：Cache-Control:max-age=3600,must-revalidate它意味著該資源是從原服務(wù)器上取得的，且其緩存（新鮮度）的有效時(shí)間為一小時(shí)，在后續(xù)一小時(shí)內(nèi)，用戶重新訪問(wèn)該資源則無(wú)須發(fā)送請(qǐng)求。當(dāng)然這種組合的方式也會(huì)有些限制，比如no-cache就不能和max-age、min-fresh、max-stale一起搭配使用。組合的形式還能做一些瀏覽器行為不一致的兼容處理。例如在IE我們可以使用no-cache來(lái)防止點(diǎn)擊“后退”按鈕時(shí)頁(yè)面資源從緩存加載，但在Firefox中，需要使用no-store才能防止歷史回退時(shí)瀏覽器不從緩存中去讀取數(shù)據(jù)，故我們?cè)陧憫?yīng)報(bào)頭加上如下組合值即可做兼容處理：Cache-Control:no-cache,no-store緩存校驗(yàn)字段上述的首部字段均能讓客戶端決定是否向服務(wù)器發(fā)送請(qǐng)求，比如設(shè)置的緩存時(shí)間未過(guò)期，那么自然直接從本地緩存取數(shù)據(jù)即可（在chrome下表現(xiàn)為200fromcache），若緩存時(shí)間過(guò)期了或資源不該直接走緩存，則會(huì)發(fā)請(qǐng)求到服務(wù)器去。我們現(xiàn)在要說(shuō)的問(wèn)題是，如果客戶端向服務(wù)器發(fā)了請(qǐng)求，那么是否意味著一定要讀取回該資源的整個(gè)實(shí)體內(nèi)容呢？我們?cè)囍@么想——客戶端上某個(gè)資源保存的緩存時(shí)間過(guò)期了，但這時(shí)候其實(shí)服務(wù)器并沒(méi)有更新過(guò)這個(gè)資源，如果這個(gè)資源數(shù)據(jù)量很大，客戶端要求服務(wù)器再把這個(gè)東西重新發(fā)一遍過(guò)來(lái)，是否非常浪費(fèi)帶寬和時(shí)間呢？答案是肯定的，那么是否有辦法讓服務(wù)器知道客戶端現(xiàn)在存有的緩存文件，其實(shí)跟自己所有的文件是一致的，然后直接告訴客戶端說(shuō)“這東西你直接用緩存里的就可以了，我這邊沒(méi)更新過(guò)呢，就不再傳一次過(guò)去了”。為了讓客戶端與服務(wù)器之間能實(shí)現(xiàn)緩存文件是否更新的驗(yàn)證、提升緩存的復(fù)用率，Http1.1新增了幾個(gè)首部字段來(lái)做這件事情。1.

Last-Modified服務(wù)器將資源傳遞給客戶端時(shí)，會(huì)將資源最后更改的時(shí)間以“Last-Modified:GMT”的形式加在實(shí)體首部上一起返回給客戶端?？蛻舳藭?huì)為資源標(biāo)記上該信息，下次再次請(qǐng)求時(shí)，會(huì)把該信息附帶在請(qǐng)求報(bào)文中一并帶給服務(wù)器去做檢查，若傳遞的時(shí)間值與服務(wù)器上該資源最終修改時(shí)間是一致的，則說(shuō)明該資源沒(méi)有被修改過(guò)，直接返回304狀態(tài)碼即可。至于傳遞標(biāo)記起來(lái)的最終修改時(shí)間的請(qǐng)求報(bào)文首部字段一共有兩個(gè)：⑴

If-Modified-Since:

Last-Modified-value示例為If-Modified-Since:Thu,31Mar201607:07:52GMT該請(qǐng)求首部告訴服務(wù)器如果客戶端傳來(lái)的最后修改時(shí)間與服務(wù)器上的一致，則直接回送304和響應(yīng)報(bào)頭即可。搜索頂級(jí)架構(gòu)師公眾號(hào)回復(fù)“架構(gòu)”，送你一份驚喜禮包。當(dāng)前各瀏覽器均是使用的該請(qǐng)求首部來(lái)向服務(wù)器傳遞保存的Last-Modified值。⑵

If-Unmodified-Since:

Last-Modified-value告訴服務(wù)器，若Last-Modified沒(méi)有匹配上（資源在服務(wù)端的最后更新時(shí)間改變了），則應(yīng)當(dāng)返回412(PreconditionFailed)狀態(tài)碼給客戶端。當(dāng)遇到下面情況時(shí)，If-Unmodified-Since字段會(huì)被忽略：1.Last-Modified值對(duì)上了（資源在服務(wù)端沒(méi)有新的修改）；

2.服務(wù)端需返回2XX和412之外的狀態(tài)碼；

3.傳來(lái)的指定日期不合法Last-Modified說(shuō)好卻也不是特別好，因?yàn)槿绻诜?wù)器上，一個(gè)資源被修改了，但其實(shí)際內(nèi)容根本沒(méi)發(fā)生改變，會(huì)因?yàn)長(zhǎng)ast-Modified時(shí)間匹配不上而返回了整個(gè)實(shí)體給客戶端（即使客戶端緩存里有個(gè)一模一樣的資源）。2.ETag為了解決上述Last-Modified可能存在的不準(zhǔn)確的問(wèn)題，Http1.1還推出了ETag實(shí)體首部字段。服務(wù)器會(huì)通過(guò)某種算法，給資源計(jì)算得出一個(gè)唯一標(biāo)志符（比如md5標(biāo)志），在把資源響應(yīng)給客戶端的時(shí)候，會(huì)在實(shí)體首部加上“ETag:唯一標(biāo)識(shí)符”一起返回給客戶端?？蛻舳藭?huì)保留該ETag字段，并在下一次請(qǐng)求時(shí)將其一并帶過(guò)去給服務(wù)器。服務(wù)器只需要比較客戶端傳來(lái)的ETag跟自己服務(wù)器上該資源的ETag是否一致，就能很好地判斷資源相對(duì)客戶端而言是否被修改過(guò)了。如果服務(wù)器發(fā)現(xiàn)ETag匹配不上，那么直接以常規(guī)GET200回包形式將新的資源（當(dāng)然也包括了新的ETag）發(fā)給客戶端；如果ETag是一致的，則直接返回304知會(huì)客戶端直接使用本地緩存即可。那么客戶端是如何把標(biāo)記在資源上的ETag傳去給服務(wù)器的呢？請(qǐng)求報(bào)文中有兩個(gè)首部字段可以帶上ETag值：⑴

If-None-Match:ETag-value示例為If-None-Match:"56fcccc8-1699"告訴服務(wù)端如果ETag沒(méi)匹配上需要重發(fā)資源數(shù)據(jù)，否則直接回送304和響應(yīng)報(bào)頭即可。當(dāng)前各瀏覽器均是使用的該請(qǐng)求首部來(lái)向服務(wù)器傳遞保存的ETag值。⑵

If-Match:ETag-value告訴服務(wù)器如果沒(méi)有匹配到ETag，或者收到了“*”值而當(dāng)前并沒(méi)有該資源實(shí)體，則應(yīng)當(dāng)返回412(PreconditionFailed)狀態(tài)碼給客戶端。否則服務(wù)器直接忽略該字段。If-Match的一個(gè)應(yīng)用場(chǎng)景是，客戶端走PUT方法向服務(wù)端請(qǐng)求上傳/更替資源，這時(shí)候可以通過(guò)If-Match傳遞資源的ETag。

需要注意的是，如果資源是走分布式服務(wù)器（比如CDN）存儲(chǔ)的情況，需要這些服務(wù)器上計(jì)算ETag唯一值的算法保持一致，才不會(huì)導(dǎo)致明明同一個(gè)文件，在服務(wù)器A和服務(wù)器B上生成的ETag卻不一樣。如果Last-Modified和ETag同時(shí)被使用，則要求它們的驗(yàn)證都必須通過(guò)才會(huì)返回304，若其中某個(gè)驗(yàn)證沒(méi)通過(guò)，則服務(wù)器會(huì)按常規(guī)返回資源實(shí)體及200狀態(tài)碼。在較新的nginx上默認(rèn)是同時(shí)開啟了這兩個(gè)功能的：上圖的前三條請(qǐng)求是原始請(qǐng)求，接著的三條請(qǐng)求是刷新頁(yè)面后的新請(qǐng)求，在發(fā)新請(qǐng)求之前我們修改了reset.css文件，所以它的Last-Modified和

ETag均發(fā)生了改變，服務(wù)器因此返回了新的文件給客戶端（狀態(tài)值為200）。而dog.jpg我們沒(méi)有做修改，其Last-Modified和

ETag在服務(wù)端是保持不變的，故服務(wù)器直接返回了304狀態(tài)碼讓客戶端直接使用緩存的dog.jpg即可，沒(méi)有把實(shí)體內(nèi)容返回給客戶端（因?yàn)闆](méi)必要）。緩存實(shí)踐當(dāng)我們?cè)谝粋€(gè)項(xiàng)目上做http緩存的應(yīng)用時(shí)，我們還是會(huì)把上述提及的大多數(shù)首部字段均使用上，例如使用Expires來(lái)兼容舊的瀏覽器，使用Cache-Control來(lái)更精準(zhǔn)地利用緩存，然后開啟ETag跟Last-Modified功能進(jìn)一步復(fù)用緩存減少流量。那么這里會(huì)有一個(gè)小問(wèn)題——Expires和Cache-Control的值應(yīng)設(shè)置為多少合適呢？答案是不會(huì)有過(guò)于精準(zhǔn)的值，均需要進(jìn)行按需評(píng)估。例如頁(yè)面鏈接的請(qǐng)求常規(guī)是無(wú)須做長(zhǎng)時(shí)間緩存的，從而保證回退到頁(yè)面時(shí)能重新發(fā)出請(qǐng)求，百度首頁(yè)是用的Cache-Control:private，騰訊首頁(yè)則是設(shè)定了60秒的緩存，即Cache-Control:max-age=60。而靜態(tài)資源部分，特別是圖片資源，通常會(huì)設(shè)定一個(gè)較長(zhǎng)的緩存時(shí)間，而且這個(gè)時(shí)間最好是可以在客戶端靈活修改的。以騰訊的某張圖片為例：/vipstyle/vipportal/v4/img/common/logo.png?max_age=2592000客戶端可以通過(guò)給圖片加上“max_age”的參數(shù)來(lái)定義服務(wù)器返回的緩存時(shí)間：當(dāng)然這需要有一個(gè)前提——靜態(tài)資源能確保長(zhǎng)時(shí)間不做改動(dòng)。如果一個(gè)腳本文件響應(yīng)給客戶端并做了長(zhǎng)時(shí)間的緩存，而服務(wù)端在近期修改了該文件的話，緩存了此腳本的客戶端將無(wú)法及時(shí)獲得新的數(shù)據(jù)。解決該困擾的辦法也簡(jiǎn)單——把服務(wù)側(cè)ETag的那一套也搬到前端來(lái)用——頁(yè)面的靜態(tài)資源以版本形式發(fā)布，常用的方法是在文件名或參數(shù)帶上一串md5或時(shí)間標(biāo)記符：/hm.js?e23800c454aa573c0ccb16b52665ac26/tb/_/tbean_safe_ajax_94e7ca2.js/ninja/2/2016/04/ninja145972803357449.jpg如果文件被修改了，才更改其標(biāo)記符內(nèi)容，這樣能確?？蛻舳四芗皶r(shí)從服務(wù)器收取到新修改的文件。關(guān)于開頭的問(wèn)題現(xiàn)在回過(guò)頭來(lái)看文章開頭的問(wèn)題，可能會(huì)覺得答案很容易回答出來(lái)。百度首頁(yè)的資源在刷新后實(shí)際沒(méi)有發(fā)送任何請(qǐng)求，因?yàn)镃ache-Control定義的緩存時(shí)間段還沒(méi)到期。在Chrome中即使沒(méi)發(fā)送請(qǐng)求，但只要從本地的緩存中取，都會(huì)在Network面板顯示一條狀態(tài)為200且注明“fromcache”的偽請(qǐng)求，其Response內(nèi)容只是上一次回包留下的數(shù)據(jù)。然而這并不是問(wèn)題的全部答案，我們前面提到過(guò)，在Chrome中如果點(diǎn)擊“刷新”按鈕，Chrome會(huì)強(qiáng)制給所有資源加上“Cache-Control:max-age=0”的請(qǐng)求首部并向服務(wù)器發(fā)送驗(yàn)證請(qǐng)求的，而在文章開頭的動(dòng)圖中，我們的確點(diǎn)擊了“刷新”按鈕，卻不見瀏覽器發(fā)去新請(qǐng)求（并返回304）。關(guān)于這個(gè)問(wèn)題其實(shí)在組內(nèi)跟小伙伴們討論過(guò)，通過(guò)Fiddler抓包發(fā)現(xiàn)，如果關(guān)閉Chrome的開發(fā)者面板再點(diǎn)擊“刷新”按鈕，瀏覽器是會(huì)按預(yù)期發(fā)送驗(yàn)證請(qǐng)求且接收返回的304響應(yīng)的，另外這個(gè)奇怪的情況在不同的網(wǎng)站甚至不同的電腦下出現(xiàn)頻率都不一致，所以暫時(shí)將其歸咎于瀏覽器的怪異反應(yīng)。那么有這么一個(gè)問(wèn)題——是否有辦法在瀏覽器點(diǎn)擊“刷新”按鈕的時(shí)候不讓瀏覽器去發(fā)新的驗(yàn)證請(qǐng)求呢？辦法還是有的，就是不怎么實(shí)用——在頁(yè)面加載完畢后通過(guò)腳本動(dòng)態(tài)地添加資源：$(window).load(function(){varbg='/wallpaper/100.jpg';setTimeout(function(){//setTimeout是必須的$('#bgOut').css('background-image','url('+bg+')');},0);});出處來(lái)自知乎，更具體的解釋可以去看看。其它相關(guān)的首部字段事實(shí)上較常用和重要的緩存相關(guān)字段我們都介紹完了，這里順帶講講幾個(gè)跟緩存有關(guān)系，但沒(méi)那么主要的響應(yīng)首部字段。1.Vary“vary”本身是“變化”的意思，而在http報(bào)文中更趨于是“varyfrom”（與。。。不同）的含義，它表示服務(wù)端會(huì)以什么基準(zhǔn)字段來(lái)區(qū)分、篩選緩存版本。我們先考慮這么一個(gè)問(wèn)題——在服務(wù)端有著這么一個(gè)地址，如果是IE用戶則返回針對(duì)IE開發(fā)的內(nèi)容，否則返回另一個(gè)主流瀏覽器版本的內(nèi)容。這很簡(jiǎn)單，服務(wù)端獲取到請(qǐng)求的User-Agent字段做處理即可。但是用戶請(qǐng)求的是代理服務(wù)器而非原服務(wù)器，且代理服務(wù)器如果直接把緩存的IE版本資源發(fā)給了非IE的客戶端，這就出問(wèn)題了。因此Vary便是著手處理該問(wèn)題的首部字段，我們可以在響應(yīng)報(bào)文加上：Vary:User-Agent便能知會(huì)代理服務(wù)器需要以User-Agent這個(gè)請(qǐng)求首部字段來(lái)區(qū)別緩

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙，網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽，若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間，僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理，對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯，并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容，請(qǐng)與我們聯(lián)系，我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論