appcache网络中的SSL路径受Chrome限制

Question

在Chrome中看到一些奇怪的行为，并且在使用appcache或Chrome时不确定它是否是预期的行为。

这是一个单页应用程序，由我们的RestAPI提供支持，当在HTTP下请求RestAPI时它可以正常工作，但是只要我们将URL更改为HTTPS版本，它就会停止工作。 Chrome控制台中没有很多（即任何）信息，因为它决定停止工作。

我们已经设法将其缩小到appcache文件中的NETWORK部分，我们可以使用它的唯一方法是使用我们不想要的*通配符这样做，因为它绕过了appcache的整个点，并降低了安全性（从我理解阅读文档等）。

我们尝试了API网址的任何和所有变体（在各种相关位置与通配符的组合），但似乎都没有工作（即使https://*不允许成功请求）

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

由于

Answer 1

需要一点澄清（参见我的评论），但同时：

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

默认情况下，清单中未明确显示的任何内容（在清单文件中列出），隐式地是缓存的一部分（指向清单的访问页面），或者由FALLBACK前缀覆盖，即使您在线，也无法加载，除非该网址列在NETWORK部分或NETWORK部分列表*中。

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

基本上，在*中使用NETWORK并不存在安全风险，实际上它可能就是您想要做的，我构建的每个AppCache网站都使用它。

我绘制了这个流程图，试图解释appcache如何加载页面和资源：