HTML5离线存储实战之manifest的那些坑
Author：[email protected] Date：
html5离线缓存搞了n久，要做谁都会。但是，这么些年来，还是没有普及，因为坑太多，这里就来唠叨下
manifest的contentType应为 : text/cache-manifest
首先就是要声明 manifest的mime类型，apache下可以在httpd.conf中加上
AddType text/cache-manifest manifest
AddType text/cache-manifest .appcache
其中.appche是manifest文件的扩展名，经测试chrmoe即使不加mime类型也可以正常的解析，但是ff或者safari则必须使用.appcache的声明，否则报错。(其中试过将这两句加入到.htaccess中，失败)
引入manifest的页面,即使没有被列入缓存清单中，仍然会被用户代理缓存
在线的情况下,用户代理每次访问页面，都会去读一次manifest.如果发现其改变, 则重新加载全部清单中的资源。包括manifest也会再次加载一次.(所以给所有缓存资源配置合理的304机制.是十分有必要的.)
applicationCache.update(), 只会立刻检测manifest文件,而不会更新相应资源.并且会遵守304相关http缓存头.
对于浏览器来说,manifest的加载是要晚于其他资源的. 这就导致check manifest的过程是滞后的.发现manifest改变.所有浏览器的实现都是紧随这做静默更新资源.以保证下次pv,应用到更新.
manifest文件必须与引入它的页面同源.
manifest中的url ,必须与manifest使用相同的协议.如果manifest文件是一个https或其他加密协议资源,则其清单中明示项(explicit section)的资源都必须和manifest同源.
备用项和备用名称空间,必须与当前的manifest同源
备用项如果发生命中,则也会被缓存.
在写相对路径的时候 不是相对 引入它的html 而是相对 manifest文件所在目录的
a,b两个页面,引入相同资源,但a有使用manifest,而b没有.那么,即使a页面缓存了资源.b页面也不会有效.而且b页面强制更新了资源.a页面的缓存也不会因为b的更新，而更新.
a页面引入manifest,缓存的资源, 在浏览器地址栏中直接访问,则也命中offline application的缓存.刷新也如此.至少chrome,FF都是如此实现的
a,b两个页面,引用同一份manifest A. 则更新A,更新R,刷新b, b对应的R资源更新后,a的R资源副本也会随之更新. 这就是cache group的机制.因为a和b对应的application cache,同属于同一个application cache group.. 建议为manifest文件配置304相关 头域时,也配置expires和cache-control : max-age.因为chrome,safari,以及android,只有304相关头域，而没有expires 或 max-age时,不会有304，而只会是200, opera则无视一切http cache头域.总是200.
转载本站文章《HTML5离线存储实战之manifest的那些坑》,
请注明出处：https://www.zhoulujun.cn/html/webfront/SGML/html5/2017_0401_7977.html