要約

  • RFC 9218 の Priority と PRIORITY_UPDATE は応答処理への入力であり、サーバーは無視しても HTTP 応答を正常に提供できる。
  • HTTP/3 ではストリーム間に到着順序の保証がなく、更新を保持する資源もローカル方針で制限できる。送信済みの更新は、実行済みのスケジューリング記録ではない。

HTTP Priority を読むとき、まず区別したいのは、プロトコルが運ぶ情報と、実装がその情報で行う判断である。Priority ヘッダーは、エンドポイントが応答の優先順位をどう見ているかを表すエンドツーエンドの信号である。PRIORITY_UPDATE は HTTP/2 と HTTP/3 のためのフレームで、特定の応答またはプッシュ対象のパラメータを運ぶ。ただし後者は hop-by-hop、つまり一つの区間だけの信号だ。

この違いは配送経路をまたぐ推論を止める。中間者は元のヘッダーをそのまま渡せるし、次の hop 向けに異なる優先度を PRIORITY_UPDATE で付け加えることもできる。ヘッダーを置換または追加して、後続の受信者に対する元のクライアント信号を上書きすることもできる。上流で見えた値が下流のスケジューラの入力だった、とログなしに断定する理由はない。

RFC 9218 の原則はさらに狭い。HTTP/2 と HTTP/3 のサーバーは、並行する応答データを任意の方法でスケジュールでき、クライアントの優先度信号を無視しても応答を成功させられる。ヘッダーとフレームはサーバーの応答優先化プロセスへの入力で、提案にすぎず、二つの応答の処理順または送信順を保証しない。

これは仕様の弱点ではない。サーバーはキャッシュ内容、利用可能な資源、ネットワークやトランスポートの状態、アプリケーションの処理、展開固有の制約を知っている。RFC 9218 も、クライアントとサーバーのパラメータをどう合成するかについて統一式を要求しない。合成は実装の判断である。共通の語彙は、局所的な資源判断を消去するためではなく、それらと共存するためにある。

HTTP/3 の時間関係は特に慎重に扱うべきだ。ストリーム間には保証された順序がないため、更新フレームが参照するリクエストストリームより先に受信されることがある。受信者は最新の更新をバッファしてよいが、それに使う資源はローカル実装方針で制限できる。フレームが送られたことは選好の発信を示す。しかし、いつその情報が対象のキューで利用可能になったか、保存されたか、採用されたかを示さない。

応答ヘッダーも確認書にはならない。RFC 9218 は、クライアントが応答の Priority ヘッダーの有無を、優先化が起きたという承認として解釈してはならないと述べる。最終 HTTP 応答が得られても、依存リソース、スクリプト、レイアウト、端末性能を経た描画や、人が見た結果とは別の事実である。

調査では、信号を小さく正しく使うべきだ。発信値、各 hop での受信・書換え、受信者の合成ルール、ローカルキューの決定、バイト配送、そして実測した表示結果を分けて残す。前の段階のデータで後の段階の空白を埋めないことが、性能診断の再現性を守る。

出典