1

我一直在阅读Dive Into HTML5中的离线章节，它给我留下了一些问题。

它说

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

但是，让我们以同一篇文章中讨论的 Wikipedia 示例为例。每当编辑文章时，必须更改清单文件以反映编辑，并且任何已离线存储页面的用户都会丢失它们，因为它们没有在清单中明确提及。这真的是可取的行为吗？如果是，为什么不执行以下操作：

  1. 将文件存储在脱机缓存中，直到它们被明确删除，即使清单发生更改
  2. 当文件被改变时更新缓存中的文件（例如，当服务器没有返回 304 Not modified 时）

如果一个人得到上述两点描述的行为，他的选择是什么？使用本地存储还是什么？

4

1 回答 1

3

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

AppCache 通常会以意想不到的方式工作，就像 Jake Archibald 在他的博客文章Application Cache is a Douchebag中解释的那样。

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

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

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

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