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

Question

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

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

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

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

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

谢谢

Answer 1

需要一点澄清(见我的评论),但在此期间:

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

默认情况下,清单中未明确显示的任何内容(在清单文件中列出),隐式部分缓存(指向清单的访问页面)或FALLBACK前缀覆盖的内容都将无法加载,即使您'在线,除非该NETWORK部分或NETWORK部分列表中列出了网址*.

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

基本上,使用*in NETWORK不是安全风险,实际上它可能就是你想要做的,我构建的每个AppCache站点都使用它.

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