2

在 Chrome 中看到一些奇怪的行为,不确定在使用 appcache 时是否是预期的行为,或者只是 Chrome。

它是一个单页应用程序,由我们的 RestAPI 提供支持,当在 HTTP 下请求 RestAPI 时它可以正常工作,但是一旦我们将 url 更改为 HTTPS 版本,它就会停止工作。Chrome 的控制台中没有太多(即任何)信息说明它决定停止工作的原因。

我们已经设法将其缩小到NETWORKappcache 文件中的部分,我们可以让它工作的唯一方法是使用*通配符,我们不想这样做,因为它绕过了 appcache 的全部点,并降低安全性(根据我阅读文档等的理解)。

我们已经尝试了 API url 的任何和所有变体(如在各种相关位置将它与通配符组合),但似乎没有一个工作(即使 ahttps://*不允许成功的请求)。

任何有经验的人都知道发生了什么吗?

谢谢

4

1 回答 1

6

需要一点澄清(见我的评论),但与此同时:

根据规范,清单的NETWORK行为确实可以通过减少在线和离线行为之间的差异来使“离线应用程序的测试更简单”。实际上,它只是增加了另一个问题。

默认情况下,任何不在清单中显式(在清单文件中列出)、隐式缓存的一部分(指向清单的已访问页面)或被FALLBACK前缀覆盖的任何内容都将无法加载,即使您'在线,除非 url 列在NETWORKsection 或NETWORKsection lists 中*

通配符在该部分中没有特殊含义NETWORK,如果您列出http://whatever.com/*它将允许对该 url 的请求,因为星号是 url 中的有效字符。唯一的特殊情况是 single *,这意味着“允许页面对不在缓存中的任何资源进行网络请求”。

Basically, using * in NETWORK isn't a security risk, in fact it's probably what you want to do, every AppCache site I've built uses it.

I drew this flow chart to try and explain how appcache loads pages and resources:

Appcache flow chart

于 2013-03-08T18:07:54.740 回答