私たちは、HTML5アプリケーションキャッシュ機能使用している：戻って、ユーザーがこのアプリケーションに移動すると、彼らはすでに、すべての静的ファイルがキャッシュされていますし、アプリケーションがそのためずにロードされているHTTP厳格な交通のセキュリティとHTML5アプリケーションキャッシュ
<html manifest=".appcache">
...
</html>
をネットワーク要求。
アプリケーションがロードされると、動的コンテンツをロードするAJAXリクエストが生成され、ブラウザはアプリケーションキャッシュマニフェストが古くなっているかどうかをチェックし、バックグラウンドで新しいバージョンのアプリケーションをダウンロードする可能性があります。
多くのユーザーが、安全でない接続（HTTP、HTTPSではなく）でこのアプリケーションにアクセスしています。
アプリケーションをホストするサーバーにHTTP Strict Transport Security（HSTS）を導入する段階にあります。
実装HSTSは、当社のサーバーは、このような要求を処理することを意味します
要求（HTTPのみ）安全ではない場合、サーバーはHTTPステータス301とにリダイレクト
Locationヘッダーで応答しますURIを要求しましたが、スキームをhttpsに変更しています。それ以外は、要求がセキュア（HTTPS）の場合、サーバーは通常通り処理しますが、
Strict-Transport-Securityヘッダーを使用してレスポンスを修飾します。
したがって、新しいユーザーがHTTP経由でアプリケーションを開くと、代わりにHTTPSにリダイレクトされ、アプリケーションキャッシュマニフェストが安全な場所を使用してインストールされます。それは最高です。
ただし、（HTTP経由の）返信ユーザーは、安全でない場所に既にキャッシュされているバージョンがあるため、安全な場所にリダイレクトされません。アプリケーションキャッシュマニフェストはロードされません（リダイレクトのため）。したがって、返されたユーザーは、キャッシュしたアプリケーションのバージョンに悩まされており、もはや許可されていないHTTPを使用して立ち往生しています。これは非常に悪いです。
HTTPユーザーをHTTPSバージョンに戻す方法を考え出す必要があります。 どのように最善を尽くしますか？ （それがリダイレクトされるため）
は、ブラウザがアプリケーションマニフェストを取得することはできません。
私はそれを参照してください方法は、二つの問題があります。したがって、アプリケーションを新しいバージョンにアップグレードすることはできません。
/.appcacheをプレーンHTTPで処理できるようにサーバーを構成することで、この問題を克服できる可能性があります。我々は変更javascriptのロジックのいくつかの種類を実装する必要があるかもしれません、という回避策我々はアプリケーションがまだHTTPの場所にアクセスされる、それを行う場合であっても（そのため、何がマニフェストによってキャッシュされています）
HTTPSに対する
document.location.hrefのスキーム。私はこのアプローチが嫌いですが、この時点で私たちが得たのはこれだけです。
我々はこの問題を次のように解決に落ち着い