应用程序缓存网络中SSL通道在Chrome中的限制(SSL path in appcache net

眼看在Chrome中一些奇怪的行为，不知道这是否使用应用程序缓存的时候，或者只是Chrome的预期行为。

这是一个单页的应用程序，搭载我们的RESTAPI，当被请求的RESTAPI下HTTP，但只要我们将URL更改为HTTPS版本，那么它停止工作，它工作正常。 这里没有很多（即有）的信息在Chrome的控制台，为什么它决定停止工作。

我们已经成功地缩小它在NETWORK中的应用程序缓存文件部分，我们可以得到它的工作的唯一办法就是使用*通配符，这是我们不希望这样做，因为绕过的整点应用程序缓存，并减少（从阅读文档等，从我的理解）的安全性。

我们试过的任何和所有的API网址的变化（如在各种相关地点的通配符其组合），但似乎没有工作（即使是https://*不允许成功的请求）。

任何有经验的知道这是怎么回事呢？

谢谢

Answer 1:

需要一点点澄清（见我的意见）的，但在此期间：

该NETWORK清单的行为是真的要动手，根据规范，使“的离线应用简单的测试”，通过减少在线和离线行为之间的区别。 在现实中，它只是增加了一个疑难杂症。

默认情况下，任何不明确的清单（在清单文件中列出），高速缓存（一个访问的页面指向清单），或覆盖由隐含部分FALLBACK前缀，将无法加载，即使你在线，除非该URL在所列NETWORK部分或NETWORK部分列出* 。

通配符不具备的特殊含义NETWORK部分，如果你列出http://whatever.com/*它将使请求到该网址，为星号是在URL中有效的字符。 唯一的特例是一个单一的* ，这意味着“允许网页制作为不在缓存中的任何资源网络请求”。

基本上，使用*在NETWORK是不是安全风险，实际上它可能是你想要做什么，每一个应用程序缓存的网站我已经建立了使用它。

我画这个流程图，试图解释如何加载网页应用程序缓存和资源：

文章来源: SSL path in appcache network being restricted in Chrome