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 回答