浏览器静态资源的版本控制新思路.强制更新指定资源缓存.的探讨
此篇,探討的是一種可以讓腳本自己更新自己緩存副本的能力. 因為上一版本,絕大多是朋友,給我的反饋是看不懂,所以我爭取在這個重寫的版本中.詳細把每個細節都介紹一二. ?如果大多數細節，都是您了解的,則跳躍性閱讀即可. thx.
另:本文討論的 方案,在國內的網絡環境.很難實施. 僅僅是一種探討 .?此篇內容非常多. 感謝您的寶貴時間,希望能耐心看完. ?
?
?
關于緩存
在開始之前,不得不提到 ?"web?緩存".如果您對它有充分理解，請直接跳過.
我們可以簡單的理解下什么是資源文件的緩存, ?比如一個頁面中引入了一個腳本 a.js ,這個文件的內容可能不會經常變化. 所以每次打開這個頁面, 如果都去服務器端加載這個腳本,而它又沒有任何變化，就會顯得很多余.浪費帶寬和時間. 所以瀏覽器可以把一些不常改變的東西,做本地緩存,即,當我再次打開這個頁面時,使用的a.js,不再通過網絡,去服務器下載,而是直接使用瀏覽器緩存的副本. 一般我們稱這種資源為"靜態資源". 我們可以借助HTTP協議，通過一些緩存控制頭域和配套的緩存控制指令,來告知瀏覽器.某個文件,你可以緩存多久, 在這個允許的時間范圍內,你無須到服務器下載,而可以直接使用你的緩存副本. ?有趣的是, 類似的緩存機制,不僅僅瀏覽器具備,充斥在整個網絡中的一些代理服務器,也有相似的功能.所以我們稱這種代理服務器為 "緩存代理服務器" .
你可以把瀏覽器,緩存代理,服務器原站,想象成這樣子:
瀏覽器 : 你的學習筆記?
緩存代理: 你的學習成績優異的同桌同學 A
原始服務器: 你的老師.
當你遇到一個,老師曾經教過，但是被你遺忘的問題,你就先去問了同學A ,他說:"這個問題我會,我告訴你". 然后你再把答案記在自己的學習筆記上. 下次再遇到這個問題,你就無需再問.你只要看看自己的學習筆記就行了. ?這個過程,就是緩存代理的作用,當緩存代理有a.js的副本,并且確認這個副本沒有過期時,就會把副本直接作為響應返回給瀏覽器. 然后瀏覽器再把響應作為副本,自己緩存起來.?
假如同學 A 也不知道這個問題的答案,我們看看會發生什么. ?他為了面子,就對你說:"稍等下,我要上個廁所,回來告訴你." . 然后這貨，跑到老師那邊,得到了答案.記在他自己的筆記上.然后又跑回來,把答案告訴了你. ?這就是緩存代理的回源過程.緩存代理，自己沒有副本,或者確認副本過期了以后,就會這樣做.
假如有一天,教育局更改了教材,發現那個問題的答案,其實一直有需要改進的地方. 又怎么辦呢. 老實會緊急在課堂說對所有的同學們說:"對于問題A,老的答案可能有些問題,現在我們來重新學習一下這個問題....." . 然后同學們會如何呢? 會重新記一份筆記.把新的答案記下來.
后來,老師發現,來問問題的同學越來越多,嚴重耽誤了他干別的事情, 他決定請一個助教,專門來應對來問問題的同學們.他把常見問題的答案都告訴給這個助教.讓他在教研室門口,攔住所有來問問題的學生,并把他們想要的答案,告知他們. 這位助教扮演的角色,就是我們耳熟能詳的"反向代理",又因為他也有一份答案保留.并不是每次都代替學生來問問題.所以，它也是緩存代理. 而反向代理和非反向代理的區別,就是, 同學A,是你主動去問的. 而助教是被動存在的.他是老師安排的. 所以從你的角度來說,助教就是反向代理.因為他是服務提供者安排并控制的.
再后來,由于教委的人抽風,經常要更新答案. 無論是同學,還是老師,都有些崩潰. 同學也發現,剛從其他同學 或助教那里得來的答案,往往和老師去教委開會后,獲得的最新答案有出入. 有些細心的學生,逐漸開始不信任別的同學,甚至是助教的答案.他每次像問問題,被助教攔和其他同學攔下來時,都會大喊一句:"別想糊弄我,你給我去問老師". 迫于淫威,他們可能就真的不自作主張的把自己的答案告訴你.而去很抱歉的,打擾老師了. 這是一種傳遞性的情況. 也是我們后面要經常提到的 端對端重載的概念.. ?但是現實和理想總是有些偏差, ?你對同學A發威, 同學A買賬了.結果他對攔在門口的助教說,這個問題，我們想知道老師怎么說.但是助教可能并不買賬.因為老師交代過他.任何問題,你都別來煩我.直接把你的答案給他們就是了... 所以.往往你還是拿不到最新的答案. 這就是協議的遵守和違約. 有時候違約并不是單向的. 比如同學A,他很有自信,他為了不沒事就往辦公室跑. 即使老師交代他, 某個問題的答案最近可能有改動.如果明天有同學還問你某個問題.你一定要來我這里確認一下,拿到新的內容在做答復. 但是同學A,完全沒當一回事,自作主張的把自己的答案直接交給了 來問的同學.并且還騙他說,這就是最新的.相信我吧... 這種人,就是我們后面可能要提到的,ISP,或一些內網的 流氓緩存代理所干的骯臟勾當.
?
前面的比喻，可能并不是特別恰當.但是基本上能說清楚這個過程了.?
然后,我建議你可以詳細的看看這個鏈接里的內容 :?http://www.cnblogs.com/_franky/archive/2011/11/23/2260109.html
看完后，我們來提一下幾個Http1.1 的Cache-Control頭域的重要的偽指令, 你可以把這些指令看做是,老師的承諾,比如老師說,這個答案大家可以放心.在半年內,是不會有什么變化的. 指令也可以是學生發出的.比如學生對助教說, 你滾蛋,我要老師那里最新的答案..?
如果,你看過我上面給出的鏈接的全部內容,那么下面這幾個偽指令,你就不會陌生 :?
1. max-age = x (單位秒) ?緩存新鮮期.對所有代理有效,包括用戶代理(也就是我們的瀏覽器)
2. s-maxage = x (單位秒) 緩存的新鮮期,僅對緩存代理有效(不包括我們的瀏覽器)
3. no-cache ?請求頭中出現這個是告知緩存代理不要拿你的緩存副本來騙我,請你回源. ?說白了就是,我的期望是,服務器端直接返回給我一個最新鮮的版本.(對應名詞:端對端重載)
請記住這幾個東西,我們會在稍后的地方詳細講解對他們的使用. ?現在，我們開始聊聊,我們到底要解決什么問題.
要解決的問題:
我們在日常開發中,引入的腳本資源大概長下面這個摸樣:
| <script?src=http://www.a.com/a.js?v=20121212></script> <script?src=http://www.a.com/20121212/a.js></script> |
其中 20121212 部分我們是作為版本號來存在的.?
當然,也有一種做法,并不是把日期作為版本號,比如拿文件的內容,用某種hash算法,獲得一個字串,作為版本號.這樣可以防止競爭對手枚舉版本號方式變相攻擊,導致緩存代理們,緩存錯誤的內容.但是不管怎么樣.更新資源,我們總是需要改變資源的url. 這本身沒有什么問題. ?但假如我們沒有辦法修改url的資源就變的束手無策了. ?這樣的場景經常發生在第三方腳本身上. ?比如我們的腳本作為第三方腳本,存在于某些渠道網站的頁面中. 當文件更新時,我們可能沒辦法強迫哪些渠道修改腳本的url . 所以. 常見的做法有兩種:
(1). 減少腳本的過期時間. 比如10分鐘的過期時間(baidu聯盟的腳本文件的過期時間是兩個小時)
(2). 使用一個永不緩存的小加載器腳本.加載后面的主腳本. 通過修改加載器腳本中 主腳本的url來實現更新.
顯然.兩種方式,都是一些權衡的產物. 很難說哪個更好.也許只有更合適自身情況的方案.才是相對好的那一個. 而本文.主要想探討的是第三種方案. 即腳本自更新技術.他是一種無版本號,且強制更新自身的方式. 但這個方案不是無懈可擊的.至少通過我一個月的測試.發現他在中國的網絡環境下.很難推廣使用. 具體細節會在后面詳細討論. ??
?
?
讓我們開始今天的正題:??假設我們有一種方法.可以在得知 xxx.js 已經有了新版本.需要客戶端重新去服務器獲取新版本時.立刻實現更新. 這個xxx.js.而且url并不發生變化. 那么是一件多么快意的事情啊. ?我們來描述一下大概的場景.
A頁面部署了?http://www.a.com/a.js?. 這個腳本每次會動態的去服務器獲取一些數據.填充到A頁面. 這些數據是動態的.所以不涉及到緩存. ?突然動態數據中有一個段數據是通知 a.js有了新版本要更新了. ?a.js控制瀏覽器,立刻向服務器重新發起一個到http://www.a.com/a.js 自身的請求.獲取到新版本的內容.同時，瀏覽器更新本地緩存.并且.這次更新動作.不會再次解釋執行a.js的內容. ?這就是我們理想的更新模式. 有了這個模式. 我們可以把a.js的緩存時間設置為10年. 一但a.js很長時間都沒內容更新.那么就不會有任何浪費性的請求到達服務器. ? ?這時候,你可能會問. 用戶刷新瀏覽器.是不會直接拿本地緩存的.而是會發起http請求. 至少也會有一個304的響應才對. 事實卻是如此. 但是請記得. 還是有相當多的情況.用戶只是不斷的點鏈接跳來跳去.又或者在地址欄中直接輸入網址,又或者從收藏夾中訪問某個頁面. ?當這種情況下.如果a.js的緩存時間很短. 就會經常因a.js緩存過期,而導致瀏覽器發起http請求. 我們這個方案的最終目的之一.就是要消滅這部分額外的請求. 從而節省寶貴的流量. ?流量的節省不僅僅體現在客戶端， 還體現在 反向代理的回源花費的流量. ?如果a.js的緩存時間很短. 非特殊設置下. 反向代理也同樣會頻繁的回源. ?大多數CDN.可都是雙向收費的. 減少回源.也是我們的目標之一. ?現在我們簡單總結下.這個方案的好處:
(1). 可以讓靜態資源擁有非常長的過期時間. 從而帶來網絡流量上的成本節省.
(2). 這個方案,可以做到需要更新靜態資源時.立刻更新.并在用戶下次訪問時.使用最新的版本.
?
現在.我們就來討論下這個方案的細節. 我們可能存在以下幾個疑惑:
(1)如何保證瀏覽器發起一個對a.js的http請求.
(2)如何保證這次請求只更新緩存.而不解釋執行a.js?
?
對于問題(1) . 我們的答案是 . location.reload 這個BOM 方法 + ajax代理(少數瀏覽器需要). ?我們需要借助一個iframe. 把要更新的資源放在iframe中. 然后調用iframe的 location.reload方法來做. ?遺憾的是. 無論是location.reload 還是ajax 代理方式.各個瀏覽器的行為都不太一樣. 這些行為差異.主要體現在是否會真的發起對a.js的請求. 以及發出的http請求頭域的差異.
好在經過我不懈的測試.最終還是覆蓋了所有主流瀏覽器,以及主流版本.
?
?
我們先來看看reload API 的一些情況.?
下如果你不明白 Cache-Control, Pragma, if-None-Match, If-Modified-Since .以及直接走cache的含義.
我建議你先讀一下:??http://www.cnblogs.com/_franky/archive/2011/11/23/2260109.html
?
reload(true) html頁面本身:| Browser | Cache-Control | Pragma | If-None-Match | If-Modified-Since | 是否仍然直接走cache |
| IE6,IE7,IE8 | 無 | no-cache | 無 | 無 | 否 |
| IE9,IE10 | no-cache | 無 | 無 | 無 | 否 |
| Firefox | no-cache | no-cache | 無 | 無 | 否 |
| Chrome | max-age=0 | 無 | 有 | 有 | 否 |
| Safari | max-age=0 | no-cache | 無 | 無 | 否 |
| Opera | no-cache | no-cache | 無 | 無 | 否 |
| Browser | Cache-Control | Pragma | If-None-Match | If-Modified-Since | 是否仍然直接走cache |
| IE6,IE7,IE8 | 無 | no-cache | 無 | 無 | 否 |
| IE9,IE10 | no-cache | 無 | 無 | 無 | 否 |
| Firefox | no-cache | no-cache | 無 | 無 | 否 |
| Chrome | max-age=0 | 無 | 有 | 有 | 否 |
| Safari3 | max-age=0 | no-cache | 無 | 無 | 否 |
| Safari4+ | max-age=0 | no-cache | 有 | 有 | 否 |
| Opera11.0- | - | - | - | - | 是 |
| Opera11.64+ | no-cache | no-cache | 無 | 無 | 否 |
| Browser | Cache-Control | Pragma | If-None-Match | If-Modified-Since | 是否仍然直接走cache |
| IE6,IE7,IE8 | 無 | no-cache | 有 | 有 | 否 |
| IE9,IE10 | 無 | 無 | 有 | 有 | 否 |
| Firefox | max-age=0 | 無 | 有 | 有 | 否 |
| Chrome | max-age=0 | 無 | 有 | 有 | 否 |
| Safari | max-age=0 | no-cache | 無 | 無 | 否 |
| Opera | no-cache | no-cache | 無 | 無 | 否 |
| Browser | Cache-Control | Pragma | If-None-Match | If-Modified-Since | 是否仍然直接走cache |
| IE6,IE7,IE8 | 無 | no-cache | 無 | 無 | 否 |
| IE9,IE10 | 無 | 無 | 有 | 有 | 否 |
| Firefox | max-age=0 | 無 | 無 | 有 | 否 |
| Chrome | max-age=0 | 無 | 有 | 有 | 否 |
| Safari3 | max-age=0 | no-cache | 無 | 無 | 否 |
| Safari4+ | max-age=0 | no-cache | 有 | 有 | 否 |
| Opera | - | - | - | - | 是 |
?
以上,四個表.其實我們要關心的是 硬編碼外鏈腳本資源的情況.因為他們正是我們要更新的靜態資源.
補充: 所謂硬編碼即 直接寫在html頁面中的腳本.而不是借助dom api動態插入而加載的腳本.
在結果中.我們尤其要關注的是那些請求中帶有 Cache-Control : no-cache 瀏覽器. ?還記得前面我一再提到的端對端重載的概念么? 根據http1.1協議.這樣做.會導致所有遵守http1.1協議的緩存代理服務器回源. 假如.所有的緩存代理都遵守http1.1的端對端重載. 那么這將給原站帶來災難. 瞬間帶來海量的請求.如果我們當前的瞬時流量很大.壓垮原站.那就是分分鐘的事情.所以為了防止這種情況出現.我們必須強迫我們的反向代理(比如我們的CDN).不支持端對端重載. 然后在a.js有更新時,清除CDN對a.js的緩存(幾乎所有的CDN,都會開發這種接口的.大公司自搭的更是如此). 這樣做的結果.就是保證每個節點都只回源一次.壓力可以忽略不計. ?你一定會問.那就用reload(false) 唄. 這樣就沒有端對端重載了. ?但是我們不要忘記 其他緩存代理的影響. 我們仍然還是希望用戶和 反向代理之間的那些 緩存代理可以遵守端對端重載,從而正確的回源. (但實際情況,我自己測試下來,發現大部分緩存代理都不支持.端對端重載... 所以這里true,也好,false也罷.真的無所謂了. 只要你發起請求.我們就謝天謝地了.)
細心的你，一定發現Opera11.0-?似乎不能用reload . 沒關系.我們可以用ajax 代理方式來做. 我們可以創建一個永久緩存的 html頁面.根據url中的hash 部分.來傳入要更新資源. 該html頁面所在的域,與要更新的資源同域.即可有效的更新了. 你也許問.為啥其他瀏覽器不能這樣做. 下面這個表,會給我們答案:
AJAX ? 設置xhr.setRequestHeader('Cache-Control', 'no-cache');.發起請求的情況:
| Browser | Cache-Control | 是否自動加入Pragma : no-cache | If-None-Match | If-Modified-Since | 是否仍然直接走cache |
| IE | - | 否 | - | - | 是 |
| Firefox | no-cache | 否 | 無 | 無 | 否 |
| Chrome6- | max-age=0 | 否 | 無 | 無 | 否 |
| Chrome7+ | no-cache | 否 | 無 | 無 | 否 |
| Safari5.0- | max-age=0 | 是 | 無 | 無 | 否 |
| Safari5.1+ | no-cache | 否 | 無 | 無 | 否 |
| Opera10.7- | 無 | 否 | 無 | 無 | 否 |
| Opera11+ | no-cache | 否 | 無 | 無 | 否 |
我們看到.IE.是不發起http請求的. 而其他瀏覽器雖然可以.但是我們為了節省對那個代理html的請求. 還是使用reload好了. ?這時候你也許會說. reload ? ireload難道不也需要一個iframe 頁面作為容器么? ?答案是 no . 不需要. ?我們只需要 iframe.src = about:blank ?或 配合 DataURI 來做就好了. 這樣就只有在 opera瀏覽器下.我們需要使用 ajax代理 訪問額外的html頁面了.
然后,我們來看看如何讓資源加載,而不執行.或不渲染(對于.css來說. 是的.這個方案可不僅僅只對.js)
加載資源不執行不渲染的方式:
其實,針對不同瀏覽器,方法還是很多的.?參考地址:http://www.cnblogs.com/_franky/archive/2010/12/09/1901720.html?。有興趣可以仔細看下.
我所推薦的方式是:
IE 全系, Opera全系, Safari5-, Chrome7-: 使用 <script type="text/c" src="xxx"></script> 方式加載資源
ps: 對于Safari5.0-,和Chrome6-,應注意加載資源的方式,.js采用 script,.css采用下面的link 方式.原因會在后面 非IE的 iframe,處理方案中詳細解析.
Chrome8+, Safari5.1+, Firefox全系建議使用Link標簽來做:??<link rel="stylesheet" media="c" href="xxx" />
?
我那份關于資源預加載的帖子里描述的其他方法，或多或少都有其他一些缺陷,所以請記得,上面兩種方式,就是你需要的.加載資源,不執行,不渲染的方式了.
原理就是 script的 type給個不認識的值, ?以及 ?link stylesheet 的media 給個不認識的值. 就讓所有主流的A級瀏覽器,達到了只加載資源的目的.
?
?
一切看起來還不錯. 但是這引出了后面我們要說的一些惡心問題. 其中任何一問題,都一度讓我想要放棄. 但最終我堅持了下載.并一一解決了. 僅作為一個 偏執狂的心酸歷程.記錄下來好了:
?
?
到此,原理方面，討論結束. 我們來點實施上的經驗:
顯然,我們在更新一些資源的時候,他們要有iframe作為容器, 但是我們顯然不希望這個iframe,部署一個真正的實體頁面來做. 否則reload這個額外的iframe,也很苦惱.如何解決?
?
1.??IE下 用 一個 src 為?about:blank的 iframe,通過動態寫入文檔流的方式,組織其html.來加載這些資源.
爽的地方就在這里, IE下,reload 一個動態寫入的文檔流.刷新后還是記得這些文檔流內的內容. 就搞定問題了. 又因為 about:blank 被視為同parent頁面同域. 所以似乎 iframe.contentWindow.document.write 就滿足一切需求了.?
但是很不幸, IE全系,至今都有一個同源策略的bug. 即 在我們創建一個 src 為about:blank的iframe前,parent?頁面修改過document.domain. 則該iframe就被視為同parent頁,跨域.也就是說 我們的iframe.contentWindow.document 是沒權限的.
解決辦法:
使用javascript: 偽協議. 即 設置iframe的url 為 javascript:document.write(xxx)的方式來寫入文檔流.實現同樣的功能. 記住,write的機會只有一次.所以我們務必要一次性把內容寫入. 但是當我們決定這樣做的那一刻起,注定我們要面對IE系對我們設置的重重考驗.因為這樣做可能帶來的問題如下:
(1).?當parent頁存在 base標簽,且target 為_blank時, 使用偽協議方式,會導致IE系彈窗(并可能會被瀏覽器攔截).?
解決辦法: 掃描parent頁面的所有base標簽,看是不是target為_blank.如果有,就暫時把它的target改為 _self. ?后面對iframe寫入偽協議結束后.再改回去.
ps: 務必迭代所有base標簽,網上有資料說, 多個base標簽 只有第一個生效是錯誤的. 實際上只要有target=_blank的base,無論他在哪，優先級都高于其他.
且,務必不要移除base標簽,因為你可能遇到 IE6 base單閉合引發的bug.導致base后面的節點都被IE6解析成base的子節點.移除它，再恢復是很可怕的.
(2).?避免過早的獲取document.contentWindow.document,導致拿不到iframe的document.
?
解決辦法: iframe的url設置為about:blank后在iframe.onload中獲取其document對象.
?
?
? ? ??(3). ?不恰當的寫入方式,造成parent頁的document.readyState永遠卡在inneractive狀態.進一步導致parent頁面的onload事件，永遠不會被觸發.
解決辦法: 不要對iframe.立刻寫偽協議,而是在iframe.onload后,再次setTimeout 去寫入偽協議. 注意這兩個條件都是必要的.
ps: 記得onload注冊要在 iframe的url 設置為'about:blank' 之前.
?
??(4). IE8- iframe.onload,被認定跨域,注冊無效問題.
解決辦法:?請使用iframe.attachEvent('onload', callback)的方式.
?
(5). iframe.src = "about:blank" ,導致IE全系,后退按鈕bug.(體現為,parent頁后退按鈕失效.可以無限按后退,并導致iframe內部的資源無限重載)
解決辦法: ?用iframe.contentWindow.location.replace('about:blank') 代替 iframe.src = "about:blank"方式. 前者,跳轉的好處是，不會使iframe,產生記錄.
ps: 此bug的本質原因就是iframe.src= xxx 產生歷史記錄.再寫入偽協議.造成了這個惡心的問題.
另外, 請別擔心location.replace會受同源策略限制. 如果你寫過反iframe嵌套的腳本,就知道，這個api,完全不受限制.
? ? ? ? ? ? ? ? ? 需要說明的是,新創建的iframe,是沒這個問題的.只有你打算復用某個已經有src屬性的iframe時才要注意這個問題.
?
(6). 不恰當的使用偽協議，寫入文檔流,IE,出現,并永遠卡在loading狀態.(不停的轉啊轉...)
解決辦法: 無需理會,因為我們的需求,先天上，幫我們修正了這個bug.即iframe內部產生一個網絡請求(cache的不算).就會修正這個bug.
?
小結: 其實IE,或非IE,在使用偽協議的時候,bug遠不止這么多,只不過我們的需求，先天上,繞過了他們而已.所以我就不再一一列出了.
?
(7). 寫入文檔流,接口不一致的隱患問題
本質上來說,這并不是一個bug. 而是一個隱患. 因為我們直接使用doc.write 和使用偽協議寫入doc.write,有一個區別:
偽協議 : str = 'javascript:document.write("' + xxx + ?'")'; iframe.src = str;
直接寫文檔流: 則是iframe.contentWindow.document.write(xxx);
這就產生了一個接口的不一致性, 那么我們的腳本在大多數沒有修改document.domain的頁面,因為直接寫文檔流,沒有權限限制,而被通過.則規避了xxx 內容中單引號或雙引號的轉意問題. 而用偽協議方式,因為我們要拼接一個外部包裹的字符串，就必須考慮內部的單雙引號的轉意.雖然技術上,我們可以借助單雙引號的交錯嵌套,避免轉意序列\' 或\"的使用. 但是,我們也應該人為的保持接口的一致性.因為此部分功能,可能被你用在別的地方,而被寫入文檔流的數據,可能是不確定的. 那么保持一致性,可以做到要出錯，兩個分支都出錯，要么就都通過. 避免了測試用例不全.帶來的隱患.導致線上事故的發生. ?這是我們一個血的教訓.所以覺得,十分有必要補充進來的.
解決辦法: iframe.contentWindow.document.write(eval('"' + str +'"'));
? 例子:?
var str = '<script>alert(\\"\'franky\'\\")<\/script>';
document.write(eval('"' + str +'"'));//打印 'franky'
? ? ? ? ? ??
當然,就這一點上，可能我們還有另外一個選擇,就是先用偽協議,寫一段'<script>document.domain = 父頁面.document.domain</script>進iframe的文檔流. 然后,iframe 和parent就同域了.按道理就可以繼續轉回使用iframe.contentWindow.document.write了.(但我實測,還是會無法寫入.所以我還是選擇了偽協議方式) 不過，請務必要記得.不要這樣:iframe.src = 'javacript:document.domain = xxx';?.這樣做是會被ie拋出異常的.所以你要:
iframe.src = 'javascript:document.open();document.write("<script>document.domain = \'xxx\'<\/script>");undefined';
? ? ? ? ? ? ? ? ? ? 另外值得一提的就是, 后面將要介紹的dataURI方式.以及普通document.write處理<\/script> 時,不能要寫成<\\\/script>(早期webkit 版本存在 bug. 新的則會自動修正html錯誤) .雖然你那樣寫,IE和其他非IE較新版本的瀏覽器會自動修正.但是在運行時,會有一些微妙差異.尤其是在你的更新腳本.可以執行的時候.此處不是重點.就不詳細解釋了. 保持接口一致性,需要費一番心思.(尤其是,復用iframe,以及這個接口,不僅僅用于資源更新,還有其他用途的時候.).我是自己寫了些中間函數來處理這一系列惱人的問題...
? ? ? ? ? ? ? ? ? ? 還有一點就是webkit下 dataURI的iframe,會被視為跨域,而Firefox,Opera,則沒問題.所以reload可以在外面做.而不必需要在iframe里面做.
??
?
2.關于非IE的方案:
我只能很遺憾的說, 方案1僅對IE有效,其他瀏覽器不可行. ?FF表現為,資源不被加載, Chrome,Safari,Opera,表現為,iframe,嵌套性的reload parent頁面.導致無限嵌套的iframe出現.并不停的reload. 原因也無需解釋.
?但其實, DataURI 的方式可以解決這個問題,,比如 src="data:text/html;charset=utf-8," + encodeURIComponent的html內容.
? ? ?最初,我在測試這個方式的時候，是失敗的. 后來我發現aoao的blog,記錄非IE使用DataURI方式. 在與aoao請教后，發現了我的悲劇. 我使用dataURI時, 內部加載資源,用了自適應協議方式,即. //www.a.com/a.js 的方式. 導致其被自適應為 data://www.a.com/a.js 而不是我們期望的http://www.a.com/a.js . 所以失敗了... ?所以在使用dataURI時,切忌寫全協議頭.
?
那么我們看看,哪些瀏覽器可以毫無顧忌的使用DataURI方式.
Firefox1.0+?(FF0.8版本，我沒測.無視它吧)
Chrome10+
Safari5.1+
Opera11.6+
?
而其他低版本的非IE,存在的問題,并不直接和DataURI有關.
大多數情況下,他們和加載資源的方式有關系, 比如.js 使用link href的方式加載. .css使用 script方式加載等. 這樣的本質問題是,瀏覽器會有一個會話級的緩存.它會記住第一次加載某資源的類型,如果它記住某個本來是.js的資源卻使用link href方式加載,則再次加載該資源時,即使你使用script src 方式常規加載. 也會導致這個腳本不被執行. .只有重啟瀏覽器,才能修正這個問題.?
Chrome3-Chrome7?(Chrome1-2不存在這個類型差異的bug. )注意加載資源方式最好互相對應. （會話級緩存,該資源的類型,導致不渲染或不執行.）
Safari5.0-?注意加載資源方式，最好相互對應. (會話級緩存，該資源類型,導致reload,更新指定資源,不會為不同類型的資源提供緩存.即link方式加載.js. .js再加載仍然是老的)
后面是比較悲劇的情況了:
Chrome8 和Chrome9?,我們無法使用script 方式加載而保證不執行. 只能使用link 或Object 或其他方式. 但是他們仍然存在不同類型,不執行或不渲染的問題.
我在純技巧的角度上，始終沒有想出解決辦法, 那么我們唯一能做的是,假如 我要更新的資源,我確保它在我試圖更新它之前,它已經被正確的方式加載過. 那么我就可以隨便使用script 或link方式,去強制更新他們了. 因為瀏覽器已經正確的記住了他們的類型. ?所以,我們需要評估使用環境，是否可以用. 又或者我們不考慮 比較低版本的問題瀏覽器,那么一切都不是問題了.
?
我們來總結一下:
?
我們可以在
IE全系?
使用about:blank方式創建iframe,并使用恰當的方式(或者直接寫文檔流,或借助javascript偽協議)寫入文檔流,并配合<script type="text/c" src=xxx>來實現更新指定資源.
?
FF全系,Chrome10 +, Opera11.6+,Safari5.1+?
使用dataURI方式創建iframe.并使用<link rel="stylesheet" media="c" href="xxx" />方式,更新指定資源.
?
Chrome1-2
使用dataURI方式創建iframe,并使用<script type="text/c" src=xxx>來實現更新指定資源
?
Chrome3-7, Safari5.0-
使用dataURI方式創建iframe,并使用根據資源類型,切換使用對應的link 或script方式來實現更新指定資源
?
?
?Chrome8-9
使用dataURI方式創建iframe,并在確保資源在一次會話中,已經被正確方式加載過. 再使用<link rel="stylesheet" media="c" href="xxx" />方式,更新指定資源.
?
?Opera11-
目前,reload方式無解. 我仍然沒有想出應對的辦法. 但是考慮到Opera11-,千分之一都不到的占有率.也許我們會欣慰很多. 更何況,我們可以使用ajax來搞.
?
?
最后的話
感謝你，花了這么長時間看到這里. 但是我仍然要說一下這個方案最終沒有被采納的原因. 還記得我一再說的 流氓緩存代理么. 是的.我們的很多ISP,都有流氓緩存代理存在.
他們會無視 Cache-Control : no-cache請求頭域, 無視 Cache-Control: s-maxage=0 響應頭域. (僅對緩存代理有效的一個響應頭.),甚至無視Expires 和 max-age= xxx.自顧自的去緩存任何資源. 在我的測試中.部分ISP的緩存代理.甚至還會緩存 .php 的 動態資源(即no-cache的資源). 而有的緩存代理則有擴展名策略. 即，假設某資源是一個常見的 動態資源文件的擴展名.比如 .php .aspx ?之類的東西.他們會和 .js .css等常見靜態資源的緩存策略存在差異(即使,他們的響應頭域完全一致). 遺憾的是.這樣稍微有點良心的流氓ISP.最多只占一半..
我在實際測試中.遇到的最多的 無法更新的用戶.大多數來自教育網. ?不死心的我. 最終出了必殺技. ?我們啟用了在教育網內部的布置了雙線接入?CDN節點. . 試圖攔截部分來自教育網的請求到該節點上. 然后當該節點回源時.走另外的出口.而不走教育網統一的出口.以繞過教育網公共出口的流氓緩存代理. 但是效果也十分不理想. ?一部分可能是因為 相當多的用戶的local dns 解析到了錯誤的節點上. 一部分則可能是各個院校自己也存在類似的緩存代理.用于節省其流量成本. ??
?
還記得前陣子,方舟子 污蔑360瀏覽器竄號的問題么? 是的.就是污蔑. 因為竄號就是類似的流氓ISP的流氓緩存代理導致的. 導致其緩存了 setCookie: sessionID的響應.. ? 這種問題誣陷給瀏覽器.不得不說 Mr Know all 方舟子先生.實在是太能胡扯了.
?
好吧.似乎跑題了. 我要說的就是這些了. ?我在這個方案上.大概花了兩個月的時間. 一個月.寫代碼.并不斷完善. ?另一個月做實際測試. 最終得到的結果很讓人傷心.. 特更新此文記錄之.
?
? 最后補充一點數據:?
類似流氓緩存代理.即更新失敗的情況大約占8%左右.
Cache-Control: s-maxage=0響應頭域的使用.是有一定效果的. 包括教育網內的CDN節點.也能起到一定作用. 我最高的時候.看到的某一天的數據.達到96%的更新成功率. 說以說.最理想的狀態下.也有4%的用戶會更新失敗. 這是難以接受的情況.?
?轉載于：http://www.cnblogs.com/_franky/archive/2012/07/05/2577141.html
總結
以上是生活随笔為你收集整理的浏览器静态资源的版本控制新思路.强制更新指定资源缓存.的探讨的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【MySQL（七）】脏页
- 下一篇： 浏览器相关知识3