Firefox、HTTP/2 Pushのサポート終了を意図

 (groups.google.com)
1 ポイント 投稿者 GN⁺ 2024-09-08 | 1件のコメント | WhatsAppで共有
  • Firefoxは利用率の低さと互換性対応の負担が大きくなった HTTP/2 Push を、すべてのプラットフォームで数日以内に無効化し、実装コードは当面ツリーに残す予定
  • ブラウザーエコシステムではすでにサポートが縮小しており、Chrome 106 は2022年9月にこれを無効化し、Safariの最新バージョンもローカルテストでpush streamを拒否している
  • ChromeはHTTP/2 Pushの利用率の低さを理由に挙げ、代替手段として rel="preload" と 103 Early Hints を推奨していた
  • Firefoxは保守コストが大きくないためサポートを続けてきたが、ここ数か月でHTTP/2 Pushが原因の Firefoxでのみ発生するWeb互換性バグ が現れている
  • サーバーやWebサイトがpushを使いながらFirefoxでのテストを省略すると、特定のサイトが Firefoxでのみ動作しない可能性がある

FirefoxのHTTP/2 Push無効化計画

  • Firefoxはすべてのプラットフォームで HTTP/2 Push を無効化する予定
  • 削除作業はBugzillaの 1915848 - Pref off HTTP/2 push で追跡されている
  • まずはpreferenceで無効化し、実装コードは当面ツリーに残す
  • 完全削除は来年春の ESR 140 ブランチ以前に行われる可能性が高い

ブラウザー別のサポート状況と無効化の理由

  • Chrome

    • Chrome 106 は2022年9月にHTTP/2 Pushを無効化
    • 関連ステータスは Chrome Platform Status で確認できる
    • Chromeは利用率の低さを理由に挙げ、代替手段として rel="preload" と 103 Early Hints を推奨

  • Safari

    • 公式なdeprecation資料は確認できていないが、現行バージョンはNode.jsサーバーを使ったローカルテストでpush streamを拒否する

  • Firefox

    • Firefoxはこれまで保守負担が大きくなかったため、HTTP/2 Pushのサポートを継続してきた
    • ここ数か月でHTTP/2 Pushにより、Firefoxのみに影響する Web互換性の問題 が発生している
      • 関連事例として bug 1915830 がある
      • サーバーやWebサイトがpushを使いながらFirefoxでテストしない場合、Firefoxでのみサイトが停止することがあり、例として bug 1913100 がある

関連記事

1件のコメント

 
GN⁺ 2024-09-08
Hacker News の意見

  • HTTP/2 Push は結局うまくいかないという「突然の発見」が出たあとでも、以前からなぜうまくいかないのかを説明していたのに無視されていた人たちに何の謝罪もないのが腹立たしい
    Google のより賢い人たちが必要だと言うのだから仕様に押し込もう、という空気が何年もあり、仕様にはもっとはるかに保守的に向き合うべき。Google の一部が良いと思った 投機的な拡張目標 を入れ続けるようなやり方はやめるべき

    • HTTP と Web パフォーマンスを改善することに、あまり意味があるようには見えない。すでに 1080p 動画ストリーミング が可能なほど帯域幅があり、リアルタイムゲームができるほど遅延も低く、初めてオンラインに接続した頃より CPU は1000倍強力になっている
      ブラウザを遅くしているのは、たいていサイトを押しつぶしている広告、トラッカー、雑多なものだけで、それを直すために使うのは Google の発明品ではなく uBlock Origin だ。最近 Google が Web 標準に押し込んでいるものは、普通の開発者のためではなく、広告をもっと入れるため、あるいはデータセンター費用を0.1%節約するためのもののように見える
    • 以前から、非グラフィカルな Web 利用、たとえば高速で非インタラクティブな情報検索には HTTP/2 より HTTP/1.1 パイプライニング のほうが満足度が高かったと言うと、HN ではダウンボートや皮肉な返信を受けがちだった
      HTTP/2 は、ある一社が自社の利益に合わせて公共資源である www へのアクセスを支配し続けようとする事例に見える。Chrome を使うと HTTP/2 を試すことになり、同じ会社が検索エンジン、ハードウェア、ブラウザ、そして今ではネットワークプロトコルまで支配している。HTTP/2 は事実上 HTTP/Chrome と見てもよい
    • 彼らには 年次昇進資料 が本当に必要だったのだと理解してあげてほしい
    • 早すぎる正解は間違いと同じ

  • HTTP/2 Push が失敗した理由として示されている説明に、説得力を感じたことがない。Google はたいてい Jake Archibald の記事を指し示すが、その記事はプロトコル自体がうまくいかない理由というより、ブラウザ実装がどれほどお粗末だったかを列挙している側に近く見える
    ブラウザはすでに preload リンクをサポートしており、これは Push ヘッダーと実質的に同じ役割を果たすべきものだ。キャッシュや認証ヘッダーのような2017年時点の実装上の難点も、既存の preload 処理コードを再利用できなかったのか疑問だ
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Preload ヘッダー は HTTP/2 Push と「実質的に同じ」とは言えない。結果が似ることはあるが動作方式は異なり、「Preload」という言葉を使うという非常に表面的な部分を除けばかなり違う
      HTTP/2 Push は、サーバーがクライアントに必要だと判断したリソースを先回りして送り込み、往復1回を減らす方式であり、DOM→レンダリングのパイプラインとは別にリソースを送って遅延を減らすことが目的だ。Preload ヘッダーは、サーバーが本文と一緒に並列ロードすべきリソースを知らせ、パースや JS 評価の前に取得させる方式だ。103 Early Hints は、レスポンス生成が終わる前、本文の最初のバイトより前に Preload ヒントを送り、取得段階をさらに前倒しする
      核心的な違いは、サーバー主導かクライアント主導か、本文と一緒か最初のバイト以前かにある。HTTP/2 Push が目標達成に弱い最も単純な理由はキャッシュだ。ブラウザはすでに持っているリソースをリクエストしないが、サーバーはクライアントのキャッシュに何があるかを知らない。Push は不要なリソースを送るリスクが大きく、103/Preload は外れても無駄になるのは役に立たないヘッダー数バイト程度なので、実装も簡単でコストも低い
    • Push 仕様への理解が、仕様と同じくらい錆びついていた。サーバーがクライアントに必要だと予想した コンテンツ全体 を実際に送り込む点を忘れていて、preload リンクのように依存関係を示唆するヘッダーだけがリクエストに含まれるものだと勘違いしていた
    • セキュリティ上、Push されたリソースはページが取得するまで 特殊なケース として扱う必要があり、その一つとして別個のキャッシュが必要になる
    • Push 削除の言い訳が特に滑稽なのは、開発者がそもそも Push をきちんと活用する機会をほとんど得られなかったからだ。入ってくる Push を見ることも、それに反応することもできなかった
      https://github.com/whatwg/fetch/issues/51
      皆が注目していたコンテンツ配信のユースケースにも、まだ多くの可能性があったように思う。公に見える試みも多くなく、何を Push すべきかを実験できるライブラリや出発点にアクセスできた人もほとんどいなかった

  • HTTP/3 0-RTT 開始 で一部の速度を取り戻し、103 Early Hints でブラウザにアセットを早めにプリロードさせることができる。この組み合わせには HTTP/1 と意味的に後方互換であるという利点もある。リバースプロキシやロードバランサーでも扱いやすい

  • HTTP/2 Push が結局消えていくのを見ると少し惜しい。アイデアはすっきりしていたが、フレームワークでの採用が低調で、もっと注目されていればよかった機能だ
    .NET 側は最後まで出さず、nginx には基本的な実装程度があった。キャッシュダイジェスト がなかったこともずっと足かせになった。Chrome は「どうせ誰も気づかないだろう」といった理由も一部挙げて削除し、NAT でいつも素晴らしく動作する UDP ですべてを再設計することのほうが重要だったようだ

    • UDP と NAT で問題を経験したことはないが、それが人々をいら立たせて IPv6 への移行 を促すなら、ひそかに笑っていることにする

  • HTTP/2 が標準化される前に Mike Belshe と話したときも、すでにこの機能は利点の実現が難しく、問題や落とし穴が多いため、H2 から外そうという空気があった
    最大の問題の一つは、ブラウザキャッシュにすでにあるものを送ったり、重要でないコンテンツを送りすぎたりする 過剰な Push だった。実際に Push のせいでページロードがさらに遅くなった非常に悪い事例も見た。ブラウザがローカルキャッシュに何を持っているかをサーバーに知らせる提案もあったが、さまざまな問題にぶつかった。HTTP Early Hints と Resource Hints が H2 Push の必要性をおおむねなくし、実装がはるかに簡単で、不要な取得を避けられ、理解もしやすい

  • 「WebサーバーやWebサイトが Push を使っていて Firefox でテストしていないと、Firefox だけでサイトが止まることがあり得る」という解釈もできるが、別の解釈も可能。
    他のブラウザーは HTTP/2 Push を拒否して黙って無視する一方、Firefox は一部の境界条件で大きく転ぶ。たとえば「Firefox がヘッダー名の大文字に遭遇すると接続をリセットするようだ」という内容。

    • その解釈はあまり合っていない。他のブラウザーが仕様を実装していないのであって、Firefox は仕様を実装している。仕様はこの違反をどう扱うべきかを非常に明確にしており、そのような WebサーバーやWebサイトの実装が壊れているということ。仕様準拠のクライアントでテストしていれば、壊れていると分かったはず。
    • 記事でははっきり述べている。Firefox は HTTP/2 Push のサポートコストが最近までは大きくなかったため継続していたが、ここ数か月で Firefox にだけ影響する Web互換性バグが HTTP/2 Push 経由で発生した。
      この記事は、他のブラウザーのように H2 Push を拒否して黙って無視する、まさにその措置を説明しているように見え、何かを隠しているようには見えない。
    • 逆の形でもいくらでも起こり得た。新しい仕様が1つのブラウザーにだけ実装され、たいていは Chrome が先に不完全な形で出し、サーバーがそれを誤って実装して同じ問題が起きる、という具合。

  • Push がなぜもっと広く採用されなかったのか気になる。大きな欠陥があるにもかかわらず、HTTP/2 がゲームチェンジャーになると見なされた大きな理由の1つだった。
    ブラウザー対応の不足だったのか、それとも CDN との相性が悪かったのかは分からない。

    • Server Push が大規模に展開されなかった理由は、有害になり得るから。サーバーはクライアントが必要とするかもしれないアセットを押し込むが、そのアセットはすでにクライアントのキャッシュにあるかもしれない。
      後者の場合、特にモバイルでは有害な負担になる。サーバーはそのアセットが実際にクライアントに必要かどうかを絶対に正確には分からない。Early Hints の方がおそらく優れていて、サーバーが必要なアセットを素早く知らせれば、クライアントが取得するか、すでに持っているかを判断できる。
    • 利用を検討したが考えを変えた。Index.html のリクエストが来たら、普通は script.js と style.css を押し込みたくなるだろうが、そうすると数百 kbit を送ったことになる。
      ユーザーが再び index.html をリクエストしたら、また全部送るべきなのか？リソースはすでにユーザーのキャッシュにある可能性が高い。送らないなら、何を送るべきかどうやって分かるのか？キャッシュに何があり何がないかはブラウザーだけが知っている。結局、初回訪問を速くする代わりに再訪問で帯域を浪費するか、初回訪問は遅いままにして再訪問を速くするか、という選択になる。
    • ゲームチェンジャーではあったかもしれないが、それは Google/Amazon/Meta 規模、あるいはそれより少し小さい程度の会社に当てはまる話。
      それ以外の大多数にとっては巨大な複雑性の増大であり、実質的に無視された。
    • Chrome が Push サポートを終了することにした際に出した、より詳しい分析を見ると参考になるかもしれない。
      https://developer.chrome.com/blog/removing-push/
    • 十分な時間が与えられなかったように思う。HTTP/2 RFC がまとまった2015年になってようやく、HTTP/2 サポートを含む最初の Apache リリースが出たし、2017年にも Server Push の扱い方にブラウザー間の不一致があった。
      nginx の Push サポートは、Wikipedia 基準では2018年ごろに入ったようだ。こうした変更が安定版ディストリビューションのバージョンやデフォルト設定まで降りてくるには時間が必要。自分の Apache サーバーで初めて HTTP/2 を有効にしたのも2020年だったし、2024年でも直接サポートしていないアプリケーションサーバーがある可能性は高い。

  • …Firefox で、という話。

    • すでに他では全部削除されたようだ

  • 関連記事に見える。ほかにもあるだろうか？
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - 2022年8月、コメント201件
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - 2022年7月、コメント2件
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - 2020年12月、コメント168件
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - 2020年11月、コメント133件
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - 2020年9月、コメント2件
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - 2020年1月、コメント71件
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - 2018年10月、コメント16件
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - 2018年2月、コメント63件
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - 2017年7月、コメント23件
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - 2017年5月、コメント20件
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - 2017年4月、コメント59件
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - 2017年3月、コメント2件
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - 2017年2月、コメント9件
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - 2016年8月、コメント6件
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - 2016年8月、コメント25件
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - 2016年8月、コメント2件
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - 2016年2月、コメント13件

  • 驚きではない。特定の目的のために作られた既存プロトコルの上に、本来の設計目標とほとんど関係のない機能を付け足すと、たいていこうなる
    たいていの場合は低レベルのプロトコルから始めて、そのままユースケースに合わせるほうがよく、その点では WebSockets が双方向通信の問題をすでにエレガントに解いていると思う。深いファイル／スクリプト階層をロードするときの遅延を減らすには、rel="preload" や rel="modulepreload" タグが優れていて、構造もシンプルだ

    • HTTP/2 Push は、遅延を減らした preload リンクとまさに同じユースケースに合っていたはずだ
      要するに、サーバーが事前に読み込むべきコンテンツをヘッダーで送り、リンクタグが送信されたりパースされたりする前から先読みさせるというものだった。ストリーミングをサポートするページにはあまり有用ではないだろうが、HTMLページ全体がサーバー側でレンダリングされるまでリクエストが止まっている場合には、目に見えるメリットがあったかもしれない
    • HTTP/2 は新しい低レベルプロトコルであり、HTTP Push はそもそも双方向通信に関する機能ではなかった
    • HTTP も双方向通信ではないのか？