リソースがキャッシュにある場合、ブラウザはサーバープッシュをキャンセルしますか？
HTTP/2仕様は、Push_PROMISEフレームで識別されたリソースは、クライアントがキャンセルした場合にプッシュされないことを示しています。
ブラウザがすでにキャッシュにあるリソースを検出すると、このリソースのプッシュをキャンセルする必要があります。ただし、ブラウザがそれを検出する方法がわかりません。フレームは、etagや最終変更などの追加情報を提供して、ブラウザがキャッシュエントリを削除する必要があるかどうか、またはプッシュをキャンセルできるかどうかを検出できるようにしますか？
可能であれば、ある程度の帯域幅を節約できます。ただし、サーバープッシュはクライアントキャッシュの最適化を損なうようです。
HTTP/2では、サーバーはPush_PROMISEフレームを使用してリソースのrequestをクライアントにプッシュします。
サーバーからクライアントに移動するとき、これは応答ではなく要求であり、クライアントがそのリソースをフェッチするために行う要求です。
クライアントがPush_PROMISEを受信すると、URIを調べて、このリソースのキャッシュステータスを把握できます。ブラウザは通常、通常受信されるリソースとプッシュされるリソースに異なるキャッシュを使用します。キャッシュがまだ有効な場合、クライアントは、プッシュされたストリームのRST_STREAMフレームをサーバーに送信することにより、そのストリームをキャンセルできます。
その間、サーバーはリソースをプッシュするために必要なものを開始します。これにより、etagなどの一般的な応答ヘッダーを含むHEADERS応答フレームが生成されます。クライアントがHEADERS応答フレームを受信すると、ストリームをキャンセルする機会がもう1つありますが、もちろん、DATAフレームは処理中である可能性があり、おそらくすべてです。
帯域幅を節約することは興味深いかもしれませんが、通常、少しの帯域幅を無駄にすることは問題ではありません。ユーザーエクスペリエンスの観点からさらに重要なのはレイテンシーであり、プッシュメカニズムはそれをかなり削減します。
プッシュメカニズムがクライアントキャッシュの最適化を損なうことはないと思います。この場合、ブラウザベンダーはこの機能と戦っていたはずですが、代わりにほとんどのベンダー（すべてではない）がこの機能を実装しており、ユーザーエクスペリエンスとレイテンシーの低下に非常に優れた結果をもたらしています。
確かに、メカニズムは改善される可能性があります。たとえば、クライアントとサーバーが、プッシュされているリソースに関する詳細情報を提供するヘッダーに同意するようにすることで、これまでのところかなりうまく機能しています。
[免責事項：私はJettyコミッターです] Javaエコシステム（ ほぼ3年前 ）、 Jetty Project 確かに興味があります より多くの議論とアイデア HTTP/2プッシュについて。
簡単で短い答え：はい、ブラウザはサーバーのプッシュをキャンセルしますこのURLがキャッシュにある場合。