HTML5的一個重要特性就是離線存儲，所謂的離線存儲就是將一些資源文件保存在本地，這樣后續的頁面重新加載將使用本地資源文件，在離線情況下可以繼續訪問web應用，同時通過一定的手法（更新相關文件或者使用相關API），可以更新、刪除離線存儲等操作；
HTML5的離線存儲使用一個manifest文件來標明哪些文件是需要被存儲的，使用如 <html manifest='offline.manifest'> 來引入一個manifest文件，這個文件的路徑可以是相對的，也可以是絕對的，如果你的web應用很多，而且希望能集中管理manifest文件，那么靜態文件服務器是個不錯的選擇。
對于manifest文件，要求：文件的mime-type必須是 text/cache-manifest類型。如果你是JAVA工程，在你的web.xml中配置請求后綴為manifest的格式：
- <mime-mapping>
- <extension>manifest</extension>
- <mime-type>text/cache-manifest</mime-type>
- </mime-mapping>
這樣可以控制請求到的manifest文件格式為text/cache-manifest的。
manifest文件的格式：
- CACHE MANIFEST# 這一句必須存在，而且必須放在頭部# 指明緩存入口CACHE:index.htmlstyle.cssimages/logo.pngscripts/main.js# 以下資源必須在線訪問NETWORK:login.php# 如果index.php無法訪問則用404.html代替FALLBACK:/index.php /404.html
這樣幾步就可以完成對離線存儲的支持。接下來要思考的，是如何更新離線存儲？
當用戶本地再次聯網的時候，本地的離線存儲資源需要檢查是否需要更新，這個更新過程，也是通過manifest的更新來控制的，更新了manifest文件，瀏覽器會自動的重新下載新的manifest文件并在下一次刷新頁面的時候進行資源文件的重新請求（第三次刷新替換本地緩存為最新緩存），而且這個請求是全局性的，也就是所有在manifest緩存列表中的文件都會被請求一次，而不是單獨請求某個特定修改過的資源文件，因為manifest是不知道哪個文件被修改過了的。
對于全局更新的擔心是不必要的，因為對于沒有更新過的資源文件，請求依舊是304響應，只有真正更新過的資源文件才是200.
所以控制離線存儲的更新，需要2個步驟，一是更新資源文件，二是更新manifest文件，特別的，更新manifest文件是不需要修改什么特定內容的，只要是這個文件隨意一處被修改，那么瀏覽器就會感知，對于我們的資源文件通常名稱是固定的，比如**.css，更新內容不會帶有文件名更新的情況下，需要更新manifest文件怎么操作呢？一個比較好的方式是更新任意一處# 開頭的注釋即可，其目的只是告訴瀏覽器這個manifest文件被更新過。
以上的這些內容，其更新操作都是瀏覽器自動完成的。同樣的，W3C定義了離線存儲的API規范：http://www.whatwg.org/specs/web- ... k/#applicationcache
提供了如下API：
- // 更新，一般來說更新下載是通過用戶**（如瀏覽器）自動完成的，但是這個方法適用于一些長期打開的頁面，比如郵件系統，可能這個頁面是長期打開的，而不會有刷新動作，所以這個就比較適合做自動更新下載
- void update();
- // 取消
- void abort();
- // 替換緩存內容 ，對于manifest文件的改變，通常是下一次的刷新才會觸發下載更新，第三次刷新才會切換使用新的緩存文件，通過這個方法，可以強制將緩存替換
- void swapCache();
提供了如下的事件：
- Event handler Event handler event type
- onchecking checking
- onerror error
- onnoupdate noupdate
- ondownloading downloading
- onprogress progress
- onupdateready updateready
- oncached cached
- onobsolete obsolete
最后說一個對于manifest比較特別的地方：對于某個文件a.htm，其中有 <html manifest='a.manifest'> ，那么離線存儲中，會自動將a.htm加入到列表中，這意味著a.htm的再次刷新將從本地緩存中獲取，這樣的機制從官方得到的答復是“特別的設計”，而對我們來說，這種強加的特性在后續的開發過程中會有不少問題。
比如：
1、如何計算PV UV，由于當前頁面被強制加入manifest，那么PV 和UV的統計，成了一個難題，因為請求不再是發送到服務器；
2、對于某個使用manifest的文件，其帶有的參數可能是隨機性的統計參數，如sid=123sss, sid=234fff ，尤其是比如商品詳情的id字段等，這樣每個頁面都自動加入到manifest中，將會帶來很大的存儲開銷，而且是毫無意義的；
所以伴隨而來的，是如何在現有的體系架構下進行數據統計的難題，一個常規的方案是進入離線存儲頁面后自動發出ajax請求，以告知服務器統計PV UV；
對于第二個問題，可能就比較棘手，但是將GET請求的方式改成POST的方式確實是個解決問題的方案。