Chromeで奇妙な動作が見られますが、appcacheを使用した場合に期待される動作なのか、Chromeだけなのかわからない。
これは、RestAPIを利用したシングルページアプリであり、RestAPIがHTTPで要求されている場合は正常に機能しますが、URLをHTTPSバージョンに変更するとすぐに機能しなくなります。Chromeのコンソールには、動作を停止する理由について多くの（つまり、まったく）情報がありません。
NETWORKappcacheファイルのセクションに絞り込むことができました。これを機能させる唯一の方法は、*ワイルドカードを使用することです。これは、appcacheのポイント全体をバイパスするため、実行したくないものです。そしてセキュリティを低下させます（ドキュメントなどを読んだ私の理解から）。
API URLのすべてのバリエーションを試しましたが（関連するさまざまな場所でワイルドカードと組み合わせた場合など）、機能していないようです（https://*リクエストが成功しない場合でも）。
何が起こっているのかを知っている経験者はいますか？
ありがとう
少し説明が必要です（私のコメントを参照）が、それまでの間：
マニフェストのNETWORK動作は、仕様によれば、オンラインとオフラインの動作の違いを減らすことで、「オフラインアプリケーションのテストをより簡単にする」ために実際にあります。実際には、それは別の落とし穴を追加するだけです。
デフォルトでは、マニフェストに明示的に含まれていないもの（マニフェストファイルにリストされている）、暗黙的にキャッシュの一部（マニフェストを指す訪問済みページ）、またはFALLBACKプレフィックスで覆われているものは、たとえ'URLがNETWORKセクションまたはNETWORKセクションリストにリストされていない限り、オンライン*です。
アスタリスクはURLの有効な文字であるため、ワイルドカードはNETWORKセクションで特別な意味を持ちません。リストhttp://whatever.com/*すると、そのURLへのリクエストが許可されます。唯一の特殊なケースは単一*です。これは、「ページがキャッシュにないリソースに対してネットワーク要求を行うことを許可する」ことを意味します。
基本的に、inを使用*するNETWORKことはセキュリティリスクではありません。実際、おそらくそれはあなたがやりたいことです。私が構築したすべてのAppCacheサイトはそれを使用します。
このフローチャートを作成して、appcacheがページとリソースをロードする方法を説明しました。
