：HTTP嚴格傳輸安全和HTML5應用程序緩存我們使用的HTML5應用程序緩存功能
<html manifest=".appcache">
...
</html>
當返回用戶導航到該應用程序，他們將已經全部靜態文件緩存和應用程序加載，因此不網絡請求。
一旦應用程序被加載，它將使AJAX請求加載動態內容，瀏覽器將檢查應用程序高速緩存清單是否過時，並可能在後臺下載新版本的應用程序。
我們的許多用戶都通過不安全的連接（HTTP，而不是HTTPS）訪問此應用程序。
我們正在主持應用程序的服務器上引入HTTP嚴格傳輸安全性（HSTS）。
實施HSTS意味着，我們的服務器會處理這樣的請求：
如果請求是不安全的（HTTP只），那麼服務器會重定向到HTTP狀態301和
Location頭回應請求的URI，但改變方案爲https。否則;如果請求是安全的（HTTPS），服務器將按正常方式處理該請求，但使用
Strict-Transport-Security標頭修飾響應。
所以，當一個新的用戶通過HTTP打開我們的應用程序，他們將改用重定向到HTTPS，然後應用程序緩存清單是使用安全的位置安裝。那很完美。
但是，返回的用戶（通過HTTP）不會被重定向到安全位置（因爲它們在不安全位置上已經有一個緩存版本）。應用程序緩存清單將不會加載（因爲它是重定向）。所以返回的用戶被他們緩存的應用程序版本所困住，並且他們被使用不再被允許的HTTP卡住了。這是很差。
我們需要想出一種將返回的HTTP用戶轉換爲HTTPS版本的方法。 如何做到最好？
我看到它的方式有兩個問題：
瀏覽器無法讀取應用程序清單（因爲它是一個重定向）。因此無法將應用程序升級到新版本。
我們可以通過配置我們的服務器來允許
/.appcache通過普通的HTTP服務來解決這個問題。即使我們這樣做，應用程序將仍然在HTTP地址訪問（因爲那什麼是由清單緩存）
要解決的是，我們可能必須實現某種JavaScript邏輯改變
document.location.href到HTTPS的方案。我不喜歡這種方法，但這是我們目前唯一獲得的方法。