HTTP の拡張可能な優先順位付けスキーム

これはインターネット標準トラックの文書です。

この文書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティの合意を表しています。公開審査を受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関するさらなる情報は RFC 7841 のセクション 2 をご覧ください。

この文書の現状、訂正情報、およびフィードバックの送付方法に関する情報は https://www.rfc-editor.org/info/rfc9218 で入手できます。

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

HTTP のリソース表現（[HTTP]）が、1 つ以上の他のリソースと関係を持つことは一般的です。クライアントは取得した表現を処理する過程でこれらの関係を発見し、さらに取得リクエストを行うことがよくあります。同時に、関係の性質によってはクライアントがローカルで利用可能なリソースの処理を継続できなくなることがあります。例としては、HTML 文書の視覚レンダリングが、文書が参照する CSS ファイルの取得によってブロックされる可能性があります。これに対して、インライン画像はレンダリングをブロックせず、画像のチャンクが到着するごとに段階的に描画されます。

HTTP/2 [HTTP/2] と HTTP/3 [HTTP/3] は、単一接続内でのリクエストとレスポンスの多重化をサポートします。多重化を提供するプロトコルの実装において重要な機能は、情報送信の優先順位を決める能力です。例えば、HTML 文書をできるだけ早く意味のある形で表示させるためには、HTTP サーバーがクライアントに送信する HTTP レスポンス、またはそれらのチャンクを優先することが重要です。

HTTP/2 および HTTP/3 のサーバーは、同時に発生するレスポンスデータの送信を任意の方法でスケジュールできます。サーバーはクライアントの優先度シグナルを無視しても正常にレスポンスを提供できます。しかし、クライアントがどのようにリクエストを発行しレスポンスを消費するかを無視して動作するサーバーは、クライアントアプリケーションの性能を最適でないものにする恐れがあります。優先度シグナルにより、クライアントはリクエストの優先度に関する見解を伝えることができます。サーバー側にもクライアントとは独立したニーズがあり、しばしば優先度シグナルを他の利用可能な情報と組み合わせてレスポンスデータのスケジューリングに反映させます。

RFC 7540 [RFC7540] のストリーム優先度は、クライアントが「優先度ツリー」を伝える一連の優先度シグナルを送信できるようにしていました。このツリーの構造は、クライアントが望む相対的な順序付けと帯域幅の重み付け分配を表します。サーバーはこれらの優先度シグナルを優先決定の入力として使用できます。

RFC 7540 ストリーム優先度の設計と実装には欠点があることが観察され（詳細は セクション 2 を参照）、結果として HTTP/2 ではこれらのストリーム優先度シグナルの使用が非推奨となりました。HTTP/2 はワイヤ互換性を維持するためにこれらのプロトコル要素を残しています（[HTTP/2]参照）。つまり、本仕様で説明する代替シグナリングが存在しても、それらは依然として使用され得ます。

本書は絶対値を用いる拡張可能な HTTP レスポンス優先付けスキームを説明します。セクション 4 は優先度パラメータを定義し、これは標準化され拡張可能な優先度情報の形式です。セクション 5 はプロトコルバージョンに依存しない初期優先度を伝える Priority ヘッダーフィールドを定義します。クライアントはこのヘッダーフィールドを送信してレスポンスの優先度に関する見解を示すことができます。同様に、仲介者の背後にいるサーバーは、転送時の優先度を仲介者にヒントとして示すために使用できます。リクエスト送信後、クライアントは自らのレスポンス優先度の見解を変更でき（セクション 6 参照）、HTTP/2/HTTP/3 固有のフレーム（7.1 と 7.2）を送信してそれを伝えることができます。

ヘッダーフィールドとフレームの優先度シグナルは、サーバーのレスポンス優先付けプロセスへの入力となります。これらはあくまで提案に過ぎず、あるレスポンスが他のレスポンスに対して特定の処理順や送信順序を必ず保証するわけではありません。セクション 10 と セクション 12 は、サーバーがこれらのシグナルをどのように扱うかについての考慮事項とガイダンスを提供します。

RFC 7540 のストリーム優先度（Section 5.3 of [RFC7540]）は、クライアントがストリームの依存関係と重みを信号として送り、不均衡なツリーを記述する複雑なシステムでした。展開と相互運用性が限定的であるという問題があり、HTTP/2 の改訂で非推奨になりました。HTTP/2 はワイヤ互換性を維持するためにこれらのプロトコル要素を残しているため（Section 5.3.2 of [HTTP/2]参照）、本仕様で説明するような代替シグナリングが存在してもそれらが使われる可能性があります。

多くの RFC 7540 サーバー実装は HTTP/2 の優先度シグナルに基づいて動作していません。

優先付けは、サーバーがリソースに関して持っている情報や、リクエストが生成される順序に基づく情報を使用できます。例えば、サーバーは HTML 文書の構造を知っていれば、ユーザー体験にとって重要な画像の配信を他の画像より優先したいと考えるかもしれません。RFC 7540 では、同じ条件下でもクライアントごとに非常に異なるシグナリングになる可能性があるため、サーバーがクライアントからのシグナルを解釈するのが困難でした。本書は、解釈を少なくしバリエーションを抑えた、より単純で制約のあるシグナリングを記述します。

RFC 7540 は仲介者に対してサーバーが優先度シグナルを提供するための方法を定義していません。

RFC 7540 のストリーム優先度は同一接続上で同時に共有される他のリクエストに対して相対的に表現されます。これは、他のリクエストがどのように接続を共有するかを知らずにリクエストを生成するアプリケーションや、ストリーム間で強い順序保証を持たないプロトコル（HTTP/3 など）に組み込むのが難しい設計です。

独立した研究による実験（[MARX]）は、少なくとも Web のユースケースにおいて、より単純なスキームが実際に用いられている複雑な RFC 7540 設定と同等以上の性能特性を達成できることを示しています。

本書で定義される優先度スキームは主に HTTP レスポンスメッセージの優先付けに焦点を当てています（詳細は Section 3.4 of [HTTP] を参照）。本書は新しい優先度パラメータ（セクション 4）と、それらのパラメータを伝達する手段（セクション 5 および セクション 7）を定義しており、これはレスポンスの優先度を決定する責任があるサーバーに優先度を伝えることを目的としています。セクション 10 は、サーバーがこれらの信号を他の入力や要因と組み合わせて動作する際の考慮事項を提供します。

CONNECT メソッド（Section 9.3.6 of [HTTP]）はトンネルを確立するために使用できます。シグナリングはトンネルにも同様に適用されます；サーバー優先付けに関する追加の考慮事項は セクション 11 に記載されています。

セクション 9 は、クライアントが自身で生成するリクエストメッセージに対してこのスキームの要素をローカルに適用する方法を説明します（任意）。

いくつかの HTTP 拡張は HTTP/2 または HTTP/3 のストリーム動作を変更したり、新しいデータ搬送メカニズムを定義する可能性があります。そのような拡張は、本優先度スキームをどのように適用するかを独自に定義できます。

優先度情報はキーと値のペアの連続であり、将来の拡張の余地を残します。各キーと値のペアは優先度パラメータを表します。

Priority HTTP ヘッダーフィールド（セクション 5）は、リクエストまたはレスポンスが発行される際にこの優先度パラメータのセットをエンドツーエンドで送る手段です。リクエスト送信後、クライアントは自らのレスポンス優先度の見解を変更でき（セクション 6）、HTTP バージョン固有の PRIORITY_UPDATE フレーム（7.1 と 7.2）を送信してそれを行えます。フレームは優先度パラメータを単一ホップだけ伝達します。

仲介者は PRIORITY_UPDATE フレームや Priority ヘッダーフィールドで優先度シグナルを消費・生成できます。仲介者が次ホップへ Priority リクエストヘッダーフィールドだけを渡す場合、クライアントからの元のエンドツーエンド信号を保持します（セクション 14参照）。仲介者は Priority ヘッダーフィールドを渡すと同時に PRIORITY_UPDATE フレームを送信することもできます。これは、元のクライアントのエンドツーエンド信号を保存しつつ、次ホップに対して別の優先度を使用するよう指示する効果が得られます（セクション 7 のガイダンスに従う）。仲介者が Priority リクエストヘッダーフィールドを置き換えたり追加したりすると、元のクライアントのエンドツーエンド信号を上書きし、リクエストの後続の受信者すべてに影響を及ぼす可能性があります。

Priority ヘッダーフィールドおよび PRIORITY_UPDATE フレームの両方において、優先度パラメータのセットは Dictionary としてエンコードされます（Section 3.2 of [STRUCTURED-FIELDS]参照）。

本書は u（urgency）と i（incremental）という優先度パラメータを定義します。これらの優先度パラメータを含まない HTTP リクエストを受け取った場合、サーバーはそれらがデフォルト値で指定されたものとして振る舞うべきです（SHOULD）。

仲介者は自らが転送するリクエストとレスポンスからのシグナルを組み合わせることができます。レスポンスにおける優先度パラメータの省略は、リクエストにおける省略とは異なる方法で扱われる点に注意してください（セクション 8参照）。

受信者は Dictionary を Section 4.2 of [STRUCTURED-FIELDS] に記載されたとおりに解析します。Dictionary が正常に解析された場合、本書は追加の要求として、未知の優先度パラメータ、範囲外の値を持つ優先度パラメータ、または予期しない型の値は無視されなければならない（MUST）ことを定めます。

Priority HTTP ヘッダーフィールドは、優先度パラメータを運ぶ Dictionary です（セクション 4を参照）。リクエストおよびレスポンスに現れることがあり、エンドツーエンドの信号として、HTTP レスポンスをどのように優先付けすべきかというエンドポイントの見解を示します。セクション 8は、仲介者がクライアントとサーバーから送られた優先度情報をどう組み合わせられるかを説明します。クライアントは Priority レスポンスヘッダーフィールドの出現や省略を、何らかの優先付けが実際に行われたことの確認（acknowledgement）として解釈してはなりません。Priority ヘッダーフィールド値に基づいてエンドポイントがどのように振る舞うかについての指針は、セクション 9および10に示されています。

Priority ヘッダーフィールドを含む HTTP リクエストはキャッシュされ、後続のリクエストに再利用される場合があります；詳細は [CACHING] を参照してください。オリジンサーバーが受け取った HTTP リクエストの性質に基づいて Priority レスポンスヘッダーフィールドを生成する場合、サーバーはキャッシュ可能性やキャッシュされたレスポンスの適用性を制御するために、Cache-Control や Vary のようなキャッシュ動作を制御するヘッダーフィールドを使用して管理することが期待されます。

クライアントがリクエストを送信した後、レスポンスの優先度を変更することが有益な場合があります。例えば、ブラウザが JavaScript ファイルのプレフェッチリクエストを Priority リクエストヘッダーフィールドの緊急度パラメータを u=7（バックグラウンド）に設定して発行することがあります。ユーザーがその新しい JavaScript ファイルを参照するページへ移動したとき、プレフェッチが進行中であれば、ブラウザは Priority フィールド値を u=0 に設定した再優先付けシグナルを送信するでしょう。そのような再優先付けには PRIORITY_UPDATE フレーム（セクション 7）を使用できます。

本書は HTTP/2 [HTTP/2] および HTTP/3 [HTTP/3] 向けに新しい PRIORITY_UPDATE フレームを規定します。これは優先度パラメータを運び、バージョン固有の識別子に基づいて優先対象を参照します。HTTP/2 ではこの識別子はストリーム ID であり、HTTP/3 ではストリーム ID または push ID のいずれかです。Priority ヘッダーフィールドと異なり、PRIORITY_UPDATE フレームはホップバイホップの信号です。

PRIORITY_UPDATE フレームはクライアントによってコントロールストリーム上で送信され、レスポンスを運ぶストリームとは独立して送信できます。これにより、レスポンスやプッシュストリームの再優先付けに使ったり、Priority ヘッダーフィールドの代わりにレスポンスの初期優先度を示すために使用できます。

PRIORITY_UPDATE フレームは、Priority Field Value フィールド内にすべての優先度パラメータの完全なセットを伝えます。優先度パラメータを省略することは、そのパラメータのデフォルト値を使用することを示す信号です。Priority Field Value の解析に失敗した場合、それを接続エラーとして扱ってもよい（MAY）です。HTTP/2 ではそのエラーは PROTOCOL_ERROR 型、HTTP/3 では H3_GENERAL_PROTOCOL_ERROR 型になります。

クライアントは参照するストリームがオープンする前に PRIORITY_UPDATE フレームを送信してもよい（ただし HTTP/2 のプッシュストリームは例外；セクション 7.1参照）。さらに、HTTP/3 ではストリーム間の順序が保証されないため、フレームが意図より早く受信されることがあります。いずれのケースでも、サーバーがまだ開かれていないリクエストストリームを参照する PRIORITY_UPDATE フレームを受け取るという競合状態が発生します。この問題を解決するために、スケジューリングの目的では、最も最近受信した PRIORITY_UPDATE フレームを最新の情報として他の信号より優先して扱うことができます。サーバーは最も最近受信した PRIORITY_UPDATE フレームをバッファし、参照されたストリームが開かれたときにそれを適用することが推奨されます（SHOULD）。各ストリームのために PRIORITY_UPDATE フレームを保持することはサーバー資源を要するため、ローカル実装ポリシーで上限を設けることができます。送信できる PRIORITY_UPDATE フレームの数に制限はありませんが、最も最近受信したフレームのみを保存することでリソース負担を制限できます。

クライアントが HTTP レスポンスをどのように優先付けすべきかを最もよく理解しているとは限りません。サーバーはクライアントが示した優先度に追加の情報を持っており、それを組み合わせることでレスポンスの優先付けを改善できる場合があります。例えば、ある HTML 文書の利用が埋め込み画像の一つに強く依存することがあり、そのような依存関係の存在は通常サーバーが最もよく把握しています。また同じ緊急度でフォントと画像の両方に対するリクエストが来た場合、サーバーは視覚的クライアントが早期にテキスト情報をレンダリングできるようフォントをより高い優先度にするかもしれません。

オリジンは Priority レスポンスヘッダーフィールドを用いて、HTTP レスポンスをどのように優先付けすべきかの見解を示せます。HTTP レスポンスを転送する仲介者は、Priority レスポンスヘッダーフィールドに見つかる優先度パラメータとクライアントの Priority リクエストヘッダーフィールドを組み合わせて、自身の優先付けプロセスの入力として使えます。優先度のマージ方法に関する指針は提供しません；これは実装上の判断に委ねられます。

HTTP レスポンスに優先度パラメータが欠けていることは、サーバーがクライアント提供値を変更する意図がないことを示します。これはリクエストヘッダーフィールドとは異なり、リクエストでは優先度パラメータの省略はそのデフォルト値を用いることを意味します（セクション 4参照）。

非規範的な例として、クライアントが緊急度を 5、インクリメンタルを true に設定して HTTP リクエストを送信した場合：

:method = GET
:scheme = https
:authority = example.net
:path = /menu.png
priority = u=5, i

そしてオリジンが以下で応答した場合

:status = 200
content-type = image/png
priority = u=1

仲介者は緊急度をクライアントの指定した 5 からサーバー提供値の 1 に変更するかもしれません。これは仲介者がサーバー側の値をクライアント側の値より優先するためです。インクリメンタル値はサーバーが i パラメータを指定していないため引き続きクライアント指定の true のままです。

クライアントはローカルの処理や、生成するリクエストに関するスケジューリングの選択を行うために優先度値を使用してもよい（MAY）。

一般に、HTTP サーバーは可能な限り早くすべてのレスポンスを送信することが望ましいです。しかし、単一接続で複数のリクエストを提供する場合、接続帯域幅などの資源をめぐってリクエスト間で競合が生じる可能性があります。本節は、そのような競合が存在する際にサーバーが競合するレスポンスの送信順序をどのようにスケジュールできるかについての考慮事項を示します。

サーバーのスケジューリングは多くの入力に基づく優先付けプロセスであり、優先度シグナルはその一形態に過ぎません。実装上の選択やデプロイ環境のような要因も役割を果たします。特定の接続は多くの動的な組み合わせを持ち得ます。これらの理由から、普遍的なスケジューリングアルゴリズムを記述することはできません。本書はサーバーが優先度パラメータに基づいてどのように動作するかについての基本的で網羅的でない推奨事項を提供します。優先度シグナルと他の要因をどう組み合わせるかの詳細は記述しません。エンドポイントは優先度シグナルに基づいた特定の処理を当てにしてはなりません。優先度を表現することはあくまで提案です。

可能であれば、サーバーは緊急度パラメータ（セクション 4.1）を尊重し、高緊急度のレスポンスを低緊急度のものより先に送信することが推奨されます（RECOMMENDED）。

インクリメンタルパラメータはクライアントがレスポンスバイトを到着に合わせてどう処理するかを示します。可能であれば、サーバーはインクリメンタルパラメータ（セクション 4.2）を尊重することが推奨されます（RECOMMENDED）。

同じ緊急度の非インクリメンタルレスポンスは、ストリーム ID の昇順（クライアントがリクエストを行った順序に対応）で帯域配分を優先することにより提供されるべきです（SHOULD）。これによりクライアントはリクエスト順序を使ってレスポンス順序に影響を与えられます。

同じ緊急度のインクリメンタルレスポンスは、それらの間で帯域を共有して提供されるべきです（SHOULD）。インクリメンタルレスポンスのメッセージ内容は、パーツまたはチャンクが受信されるごとに使われます。クライアントは単一のリソース全体を受け取るよりも、複数リソースの一部を受け取る方が有益である場合があります。どれだけの部分が有用であるかはリソースごとに異なります。本スキームはサイズやタイプ、その他の入力を用いてどのように優先付けを決定すべきかについて明示的な義務を課しません。

1. 同じ緊急度で、大きな非インクリメンタルリソースのリクエストがあり、その直後に小さなインクリメンタルリクエストがある場合。
2. 同じ緊急度で、長さが不定のインクリメンタルリクエストがあり、その直後に大きな非インクリメンタルリソースがある場合。

可能な限りサーバーはそのような飢餓（starvation）を避けることが推奨されます（RECOMMENDED）。その方法は実装の判断です。例えば、サーバーはコンテンツサイズなどの他の情報に基づいて特定のインクリメンタル型のレスポンスを先行して送ることが考えられます。

サーバープッシュの最適なスケジューリングは困難であり、特にプッシュされたリソースがアクティブな同時リクエストと競合する場合に難しくなります。サーバーはプッシュのスケジューリング時に、プッシュするリソースのタイプやサイズ、プッシュを引き起こしたリクエストの優先度、アクティブな同時レスポンスの数、他のアクティブな同時レスポンスの優先度など多くの要因を考慮できます。これらを適用する最良の方法に関する一般的な指針はありません。単純すぎるサーバーは高すぎる優先度でプッシュしてクライアントのリクエストをブロックするか、低すぎる優先度でプッシュしてレスポンスを遅延させ、サーバープッシュの意図した目的を損なう可能性があります。

優先度シグナルはサーバープッシュのスケジューリングにおける要因です。パラメータ値のデフォルトの概念は、クライアントが明示的に初期優先度を示さないためわずかに異なって適用されます。サーバーはオリジンレスポンスに含まれる優先度シグナルを適用できる；マージに関するガイダンスは セクション 8 にあります。オリジンのシグナルがない場合、デフォルトのパラメータ値を適用することは最適でない可能性があります。サーバーがプッシュレスポンスのスケジュールをどのように決めても、PUSH_PROMISE または HEADERS フレームに Priority フィールドを含めることで、クライアントに意図した優先度を通知できます。

ストリームが CONNECT リクエストを運ぶ場合、本書のスケジューリング指針はそのストリーム上のフレームに適用されます。複数の CONNECT リクエストを発行するクライアントはインクリメンタルパラメータを true に設定できます。インクリメンタルパラメータの取り扱いに関する推奨事項（セクション 10）を実装するサーバーは、これらを公平にスケジュールし、一つの CONNECT ストリームが他をブロックするのを防ぐ可能性が高いです。

TCP や QUIC のようなトランスポートプロトコルは、パケット損失を検出して失われた情報を再送することで信頼性を提供します。セクション 10 の考慮事項に加えて、再送データのスケジューリングは新規データと競合する可能性があります。本節の残りは QUIC を使用する場合の考慮事項を論じます。

Section 13.3 of [QUIC] は次のように述べています："アプリケーションで指定された優先度がない限り、エンドポイントは再送データを新規データより優先して送信すべきである（SHOULD）"。HTTP/3 アプリケーションが本書で定義された優先度スキームを使用し、QUIC トランスポート実装がアプリケーション指定のストリーム優先度をサポートする場合、ストリームの優先度を考慮して新規データと再送データの両方をスケジューリングするトランスポートは、アプリケーションの期待により適合する可能性があります。ただし、幾つかの要因やトレードオフに依存するため、トランスポートがどのようにスケジュールを選ぶかに関する要件はありません。例えば、高緊急度ストリームの新規データを低優先度ストリームの再送データより優先するか、あるいは優先度に関わらず再送データを新規データより優先するかは実装次第です。

Section 6.2.4 of [QUIC-RECOVERY] は、Probe Timeout タイマの期限切れ後にプローブパケットを送る際のアプリケーション優先度に関する考慮事項も強調しています。アプリケーション指定の優先度をサポートする QUIC 実装は、プローブデータを選ぶ際にストリームの相対的な優先度を用いるかもしれません。

通常、HTTP 実装は帯域幅を競う接続間の公平性を維持するために下位のトランスポートに依存します。仲介者がクライアント接続で受け取った HTTP リクエストをバックエンド接続に転送する際、その仲介者がリクエストをどのように合流（coalesce）または分割するかによって、異なるクライアントが異なるパフォーマンスを経験する可能性があります。仲介者がリクエスト転送時に優先度シグナルも利用すると、この不均衡は拡大することがあります。セクション 13.1 および 13.2 は、この不公平性拡大を緩和する方法を論じます。

逆に、セクション 13.3 は、サーバーが優先度シグナルに応じて意図的に一部の接続に異なる帯域配分を行う方法について論じます。

ホップバイホップのフレームを用いる HTTP/2 の優先付けスキームとは対照的に、Priority ヘッダーフィールドは「エンドツーエンド」として定義されています。

クライアントがレスポンスをどのように処理するかは、そのリクエストを生成したクライアントに関連する特性であり、仲介者のものではありません。したがって、それはエンドツーエンドの特性です。Priority ヘッダーフィールドによって運ばれるこれらのエンドツーエンド特性が、接続を共有するレスポンス間の優先付けにどのように影響するかはホップバイホップの問題です。

Priority ヘッダーフィールドをエンドツーエンドとして定義することは、キャッシング仲介者にとって重要です。そのような仲介者は、Priority ヘッダーフィールドの値をレスポンスとともにキャッシュし、キャッシュしたレスポンスを提供する際にキャッシュされたヘッダーフィールドの値を利用できます。これはヘッダーフィールドがホップバイホップではなくエンドツーエンドとして定義されているために可能になります。

セクション 7 は PRIORITY_UPDATE フレームのサーバーバッファリングに関する考慮事項を説明しています。

セクション 10 は、特定の方法でレスポンスを優先するとサーバーがレスポンスを送信する能力を枯渇（starve）させる可能性がある例を提示しています。

[STRUCTURED-FIELDS] のセキュリティ考慮事項は、セクション 4 で定義された優先度パラメータの処理にも適用されます。

Field Name:

Priority

Status:

permanent

Reference:

This document

Code:

0x9

Name:

SETTINGS_NO_RFC7540_PRIORITIES

Initial Value:

0

Reference:

This document

Code:

0x10

Frame Type:

PRIORITY_UPDATE

Reference:

This document

Value:

0xF0700-0xF0701

Frame Type:

PRIORITY_UPDATE

Status:

permanent

Reference:

This document

Change Controller:

IETF

Contact:

ietf-http-wg@w3.org

IANA は <https://www.iana.org/assignments/http-priority> に "Hypertext Transfer Protocol (HTTP) Priority" レジストリを作成し、表 1 のエントリで初期化しました。手続きの詳細は セクション 4.3.1 を参照してください。

Roy Fielding はヘッダーフィールドを用いて優先度を表現するというアイデアを <https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf> で提示しました。また <https://github.com/pmeenan/http3-prioritization-proposal> では、Patrick Meenan が緊急度と並列性の組で優先度を表現することを提唱しました。HTTP/2 優先度を無効化する機能は、Brad Lassey と Lucas Pardue による [PRIORITY-SETTING] に触発されたものであり、その文書に対するフィードバックに基づく修正が本仕様には反映されています。

HTTP/2 優先度の代替を定義する動機は、幅広い HTTP コミュニティ内での議論から引き出されています。特に Roberto Peon、Martin Thomson、Netflix に対して、本書へ明示的に取り込まれたテキストについて感謝します。

上記の人々に加えて、本書は HTTP 優先度デザインチーム（Alan Frindell、Andrew Galloni、Craig Taylor、Ian Swett、Matthew Cox、Mike Bishop、Roberto Peon、Robin Marx、Roy Fielding、および本書著者）による幅広い議論に大きく負っています。

Yang Chi は再送スケジューリングの節に貢献しました。