在Chrome中看到一些奇怪的行为，不确定使用appcache还是仅使用Chrome时是否出现了预期的行为。
这是一个单页应用程序，由RestAPI提供支持，当在HTTP下请求RestAPI时，它可以正常工作，但是，一旦我们将URL更改为HTTPS版本，它就会停止工作。 Chrome的控制台中没有太多(即任何内容)有关为何决定停止工作的信息。
我们设法将其范围缩小到appcache文件中的NETWORK部分，使它起作用的唯一方法是使用我们不想做的*通配符，因为它绕过了整个主题。 appcache，并降低了安全性(据我了解，阅读文档等)。
我们已经尝试了API网址的所有变体(如将其与各个相关位置的通配符结合使用)，但似乎没有任何效果(即使https://*都不允许成功请求)。
有经验的人都知道发生了什么事吗？
谢谢
最佳答案
需要澄清一下(请参阅我的评论)，但与此同时:
根据规范，清单的NETWORK行为确实可以通过减少在线行为与离线行为之间的差异来简化“离线应用程序的测试”。实际上，它只是增加了另一个陷阱。
缺省情况下，即使清单中未显式(在清单文件中列出)，缓存的隐含部分(指向清单的访问页面)或被FALLBACK前缀覆盖的任何内容都将无法加载，即使您处于在线状态，除非url在NETWORK部分中列出，或者NETWORK部分列出*。
通配符在NETWORK部分中没有特殊含义，如果您列出http://whatever.com/*，它将允许对该URL的请求，因为星号是url中的有效字符。唯一的特殊情况是单个*，这意味着“允许页面对不在缓存中的任何资源发出网络请求”。
基本上，在*中使用NETWORK不会带来安全风险，实际上，这可能就是您要执行的操作，我构建的每个AppCache站点都使用它。
我绘制了此流程图以尝试解释appcache如何加载页面和资源:
关于html5-appcache - Chrome中限制了应用程序缓存网络中的SSL路径，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/15293684/