HTTPとHTTPSによってフェッチされた同じJavaScriptは、ブラウザーによって別々にキャッシュされますか？
WebサーバーがHTTPとHTTPSの両方をサポートするとします。ブラウザがHTTP GETとHTTPS GETを使用して同じJavaScriptをフェッチし、JavaScriptがキャッシュ可能な場合、ブラウザは同じJavaScriptの2つのコピーをキャッシュしますか？
私が尋ねている理由は、キャッシュが1つだけキャッシュされている場合、攻撃者が最初に被害者をだましてHTTP経由でJavaScriptをダウンロードさせ、途中で侵害して、キャッシュポイズニング攻撃を仕掛けることは可能ですか？
リソースはURLとプロトコル（http://またはhttps://）はURLの一部です。プロトコルが異なるため、URLも異なる必要があり、2つの個別のキャッシュエントリがあります。
http://リソースとhttps://リソースが異なるデータを提供する場合は、アクセス方法以外はすべて同じであっても、まったく問題ありません。たとえば、http://へのアクセスは今日、リダイレクトレスポンスをもたらすことが多く、https://へのアクセスは実際のコンテンツを提供します。したがって、ブラウザはこれらのリソースを互いに独立してキャッシュします。
概要：
- 標準に準拠したブラウザのプライマリキャッシュキーは絶対URIです。
- 絶対URIは、すべての安全でない要求に対して
http:で始まり、すべての安全な要求に対してhttps:で始まります - したがって、安全にフェッチされたリソースは、安全にフェッチされなかったリソースと同じキャッシュキーを使用できません。
現在のHTTPの標準は複数の「RFC」ドキュメントに分割されており、複雑な部分が多いため、 RFC 7234 は完全にキャッシュ専用です。
セクション2「キャッシュ操作の概要」には、次の要約があります。
プライマリキャッシュキーは、リクエストメソッドとターゲットURIで構成されます。ただし、現在一般的に使用されているHTTPキャッシュは通常、GETへの応答のキャッシュに限定されているため、多くのキャッシュは他のメソッドを拒否し、URIのみをプライマリキャッシュキーとして使用します。
これは、セクション4の最初の箇条書きでより正式に述べられています。
リクエストとともに提示された場合、キャッシュは、提示された有効なリクエストURI（RFC7230のセクション5.5）が保存されたレスポンスのURIと一致しない限り[...]
RFC 7230のセクション5.5 と言うことから始まります
ユーザーエージェントの場合、有効なリクエストURIはターゲットURIです。
ブラウザーは「ユーザーエージェント」なので、ここで私たちが関係しているのはこれです。 「ターゲットURI」が定義されている セクション5.1 ：
URI参照（セクション2.7）は、通常、「ターゲットリソース」の識別子として使用されます。ユーザーエージェントは、「ターゲットURI」を取得するためにその絶対形式に解決します。フラグメント識別子はクライアント側の処理用に予約されているため（RFC3986、セクション3.5）、ターゲットURIは参照のフラグメントコンポーネントを除外します（ある場合）。
URIの一般的な定義は RFC 3986 にあり、HTTP固有の問題はRFC 7230の3ページを占めます。この目的に最も関連する部分は RFC 3986セクション4.1 です。これは、絶対URIのこの文法を定義します。
絶対URI =スキーム "：" hier-part ["？"クエリ]
重要なことに、schemeは絶対URIの必須部分です。 HTTP URIは常にスキーマhttpを使用し、HTTPS URIは常にスキーマhttpsを使用するため、絶対URI、つまりブラウザの「プライマリキャッシュキー」が決して衝突することはありません。
他の回答ではポートについて言及しています。 RFC 7230、セクション2.7.1 は、[RFC 3986、セクション3.2]で定義されている「権限」セクションを含むものとしてhttp URIを定義します。
権限= [userinfo "@"]ホスト["："ポート]
ポートはオプションで、 RFC 7230、セクション2.7.1 はhttp URIスキームのデフォルトを定義します。
ポートサブコンポーネントが空または指定されていない場合、TCPポート80（WWWサービス用に予約されているポート））がデフォルトです。
そして、「https」のデフォルトを定義する次のセクション：
上記の「http」スキームの要件はすべて「https」スキームの要件でもありますが、TCPポート443は、ポートサブコンポーネントが空または指定されていない場合のデフォルトです。 ...
その後、次のようになります。
- ポート80にないHTTPリクエストには、絶対URIにポート番号を含める必要があります
- ポート443にないHTTPSリクエストには、絶対URIにポート番号を含める必要があります
- 異なる絶対URIを持つため、異なるポート番号が指定された2つのリクエストが同じキャッシュキーを持つことはありません。
したがって、これらのURIはすべて個別にキャッシュされます。
- http://example.com/some/resource （デフォルトのポート80）
- https://example.com/some/resource （デフォルトのポート443）
- http://example.com:8000/some/resource （デフォルト以外のポート）
- https://example.com:8000/some/resource （デフォルト以外のポート）
- http://example.com:443/some/resource （HTTPSに通常使用されるポートでの安全でないリクエスト）
- https://example.com:80/some/resource （通常のHTTPに使用されるポートでの安全なリクエスト）
私が明確にしていない唯一のことは、ブラウザーがURIを正規化する必要があるかどうか、正規化する必要があるかどうか、いずれにしてもデフォルトであるポートを明示的に言及する必要があるかどうかです。つまり、これらの2つのURIが別々にキャッシュされるかどうか。
上記の定義により、同じリソースを表すことが保証されているため、これらを同じキャッシュキーに正規化した場合の実際的な結果は考えられません。
はい、それらは異なるネットワーク宛先であるためです。標準ポートを使用している場合、tcpポートはロケーションバーに表示されません。
HTTPのデフォルトはtcpポート80です。Www.example.com：80
Httpsのデフォルトはtcpポート443 Www.example.com:443です
ドメインとIPが同じであっても、ポートは異なります。ブラウザの観点から見ると、ブラウザはさまざまなサイトと通信しています。
[〜＃〜]更新[〜＃〜]
ネットワークは、Sがhttpsで行うほどの影響はありません。これも別のURIです。
別のURLは別のリソースとして扱われるべきであるという仕様が非常に明確であるという事実は別として、そうでない場合、誰かがこれに気づいてこれを悪用した可能性があると思いませんか？ Cookieによって公開されたすべての問題（および「安全な」フラグによって対処された）は、20年以上前から知られています。
したがって、ブラウザは両方のURLを取得する必要があります。キャッシュは、異なるソースからダウンロードされたが、異なるキーを介してアクセスされたファイルの単一のコピーを保持する可能性があるか、またはこの重複除外はファイルシステムのより深いところで発生する可能性があります（重複除外）。しかし、これは発生するだけです後キャッシュ（またはファイルシステム）は、ファイルが同じであると判断しました。
はい、これらは異なる起源です。同じコンテンツを提供する可能性は非常に高いですが、技術的にはまったく異なるコンテンツを提供できます。このため、ブラウザはそれらを同じリソースとして扱うことができません。
サーバー側の観点からは、異なるプロトコル（HTTPとHTTPSなど）で同じURL（www.test.comなど）が異なるファイルソースを使用できます。したがって、TLSを使用するURLは、TLSを使用しないURLとはまったく異なるWebサイトを出力できます。これだけでも、ブラウザは両方のファイルに同じキャッシュを使用しないと思います。