在 Chrome 中看到一些奇怪的行为，不确定这是否是使用 appcache 时的预期行为，或者只是 Chrome。
它是一个单页应用程序，由我们的 RestAPI 提供支持，当在 HTTP 下请求 RestAPI 时它可以正常工作，但是一旦我们将 url 更改为 HTTPS 版本，它就会停止工作。 Chrome 的控制台中没有太多（即任何）信息来说明为什么它决定停止工作。
我们已经设法将范围缩小到NETWORKappcache 文件中的部分，我们让它工作的唯一方法是使用*通配符，我们不想这样做，因为它绕过了应用程序缓存的整个点，并降低了安全性（根据我阅读文档等的理解）。
我们已经尝试了 API url 的所有变体（例如在各个相关位置与通配符的组合），但似乎都不起作用（甚至是https://*不允许成功的请求）。
有没有有经验的人知道到底是怎么回事？
Thanks
需要一些澄清（请参阅我的评论），但与此同时：
The NETWORK根据规范，清单的行为实际上是为了通过减少在线和离线行为之间的差异来使“离线应用程序的测试更简单”。事实上，它只是增加了另一个问题。
默认情况下，清单中未明确显示的任何内容（在清单文件中列出）、缓存的隐式部分（指向清单的已访问页面）或被FALLBACK前缀，即使您在线，也将无法加载，除非 url 列在NETWORK部分或NETWORK部分列表*.
通配符在中没有特殊含义NETWORK部分，如果您列出http://whatever.com/*它将允许对该 url 的请求，因为星号是 url 中的有效字符。唯一的特殊情况是单个*，这意味着“允许页面对不在缓存中的任何资源发出网络请求”。
基本上，使用* in NETWORK不是安全风险，事实上这可能是您想要做的，我构建的每个 AppCache 站点都使用它。
我画了这个流程图来尝试解释 appcache 如何加载页面和资源：
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
