我们正在使用HTML5应用缓存功能：
<html manifest=".appcache">
...
</html>
当返回用户导航到此应用程序时，他们已经缓存了所有静态文件，因此在没有网络请求的情况下加载应用程序。
加载应用程序后，它将发出加载动态内容的AJAX请求，浏览器将检查应用程序缓存清单是否已过时，并可能在后台下载新版本的应用程序。
我们的许多用户通过不安全的连接（HTTP，而不是HTTPS）访问此应用程序。
我们正在托管应用程序的服务器上引入HTTP严格传输安全（HSTS）。
实施HSTS意味着我们的服务器将处理这样的请求：
如果请求不安全（仅限HTTP），则服务器将响应HTTP状态301和Location标头，该标头重定向到请求的URI，但将方案更改为https。< / p>
否则;如果请求是安全的（HTTPS），服务器将正常处理它，但使用Strict-Transport-Security标头装饰响应。
因此，当新用户通过HTTP打开我们的应用程序时，他们将被重定向到HTTPS，然后使用安全位置安装应用程序缓存清单。那是完美的。
但是，返回的用户（通过HTTP）将不会被重定向到安全位置（因为他们已经在不安全的位置上拥有缓存版本）。应用程序缓存清单不会加载（因为它是重定向）。因此，返回的用户会被他们缓存的应用程序版本所困，并且他们不再使用不再允许的HTTP。这非常糟糕。
我们需要想出一种方法将返回的HTTP用户转换为HTTPS版本。 如何做到最好？
我认为这有两个问题：
浏览器无法获取应用程序清单（因为它是重定向）。因此无法将应用程序升级到新版本。
我们可以通过配置服务器以允许{1}}通过普通HTTP提供服务来克服此问题。
即使我们这样做，仍然可以在HTTP位置访问应用程序（因为清单缓存了什么）
要解决这个问题，我们可能必须实现某种将/.appcache方案更改为HTTPS的javascript逻辑。
我不喜欢这种方法，但它是我们目前唯一获得的方法。
答案 0 :(得分：0)
我们解决了这个问题的以下解决方案：
当服务器收到不安全的请求以获取应用程序缓存清单（在我们的例子中为
/.appcache）时，将返回404响应而不是正常的HTTPS重定向（301）。
获取404会导致缓存清单失效，因此浏览器将尝试在下次刷新时重新加载应用程序，这将导致它获取index.html并重定向到安全位置。