为什么HTML5脱机重新缓存整个清单，并且仅在清单文件更改时？

Question

我一直在阅读Dive Into HTML5中的chapter on offline，这给我留下了一些问题。

它说

  

每次更改脱机Web应用程序中的某个资源时，都需要更改缓存清单文件本身。这可以像更改单个字符一样简单。我发现完成此任务的最简单方法是包含带有修订号的注释行。更改注释中的修订号，然后Web服务器将返回新更改的缓存清单文件，您的浏览器将注意到该文件的内容已更改，它将启动该进程以重新下载所有列出的资源清单。

但是让我们看一下同一篇文章中讨论的维基百科示例。每当编辑文章时，必须更改清单文件以反映编辑，并且任何已离线存储页面的用户将丢失它们，因为清单中未明确提及它们。这真的是理想的行为吗？如果是，请不要执行以下操作：

1. 将文件存储在脱机缓存中，直到明确删除它们，即使清单发生更改
也是如此
2. 更改缓存中的文件（例如，当服务器未返回304未修改时）

如果要获得上述两点所描述的行为，他的选择是什么？使用本地存储或什么？

Answer 1

首先，查看appcachefacts.info以更好地了解这一令人困惑的规范。

AppCache通常会以意想不到的方式工作，例如Jake Archibald在他的博文Application Cache is a Douchebag中解释。

在其中，通过做一些iframe魔术来实现上述行为。我通过向appcache清单添加静态页面并通过非缓存片段页面的AJAX调用（基于onClick等外部事件）加载正文内容，并将正文数据存储在WebSQL数据库中以供将来（可能是脱机）引用而离开。实际上，这使我的离线应用程序完全基于JavaScript而没有任何页面重新加载。

代替WebSQL，您也可以使用HTML5本地存储，但可能会对5MB存储限制感到不安。

至于为什么，我只能推测。我认为：

1. Appcache在显式删除之前不会存储文件，因此appcache大小将保持适度。在维基百科示例中，缓存每个访问过的页面并且从不清除（可能已删除！）页面似乎是一个坏主意。
2. 每次重新加载页面时都不会重新检查清单中的文件，因为这意味着服务器请求的爆炸性增长。如果您的清单文件包含30个文件，它将在每个页面加载时发出30个额外请求。即使它们是异步执行的，这也是不可接受的。