16. Extending HTTP (HTTP拡張)

HTTPは, 新しいバージョンを導入せずにプロトコルに機能を導入するために使用できる多数の汎用拡張ポイントを定義しています. これには, メソッド, ステータスコード, フィールド名, および定義されたフィールド内のさらなる拡張ポイント (認証スキームやキャッシュディレクティブなど ([CACHING]のセクション5.2.3のCache-Control拡張を参照)) が含まれます. HTTPのセマンティクスはバージョン管理されていないため, これらの拡張ポイントは永続的です. 使用中のプロトコルのバージョンは, それらのセマンティクスに影響しません.

バージョン非依存の拡張は, 使用中のプロトコルの特定のバージョンに依存したり, それと相互作用したりすることは推奨されません. これが避けられない場合は, 拡張がバージョン間でどのように相互運用できるかについて慎重に検討する必要があります.

さらに, HTTPの特定のバージョンには, 独自の拡張ポイントがある場合があります. たとえば, HTTP/1.1のtransfer codings ([HTTP/1.1]のセクション6.1) やHTTP/2のSETTINGSまたはフレームタイプ ([HTTP/2]) などです. これらの拡張ポイントは, それらが発生するプロトコルのバージョンに固有です.

バージョン固有の拡張は, そのプロトコル要素によって明示的に許可されない限り, バージョン非依存のメカニズムまたは拡張ポイント (メソッドやヘッダーフィールドなど) のセマンティクスを上書きまたは変更することはできません. たとえば, CONNECTメソッド (セクション9.3.6) はこれを許可しています.

これらのガイドラインにより, パスの一部が異なるバージョンのHTTPを実装している場合でも, プロトコルが正確かつ予測可能に動作することが保証されます.

16.1. Method Extensibility (メソッド拡張性)

16.1.1. Method Registry (メソッドレジストリ)

"Hypertext Transfer Protocol (HTTP) Method Registry"は, IANAによって https://www.iana.org/assignments/http-methods で管理されており, メソッド名を登録します.

HTTPメソッドの登録には, 以下のフィールドを含める必要があります (MUST):

• Method Name (メソッド名) (セクション9を参照)
• Safe ("yes" または "no", セクション9.2.1を参照)
• Idempotent ("yes" または "no", セクション9.2.2を参照)
• Pointer to specification text (仕様テキストへのポインタ)

この名前空間に追加される値には, IETFレビューが必要です ([RFC8126]のセクション4.8を参照).

16.1.2. Considerations for New Methods (新しいメソッドの考慮事項)

標準化されたメソッドは汎用的です. つまり, 特定のメディアタイプ, リソースの種類, またはアプリケーションだけでなく, 潜在的にあらゆるリソースに適用可能です. そのため, 直交技術には直交仕様が必要であるため, 新しいメソッドは単一のアプリケーションやデータ形式に固有ではない文書に登録することが望ましいです.

メッセージ解析 (セクション6) はメソッドのセマンティクスから独立している必要があるため (HEADへの応答を除く), 新しいメソッドの定義は, 解析アルゴリズムを変更したり, リクエストまたはレスポンスメッセージ上のコンテンツの存在を禁止したりすることはできません. 新しいメソッドの定義では, 値が "0" のContent-Lengthヘッダーフィールドを要求することにより, ゼロ長のコンテンツのみが許可されることを指定できます.

同様に, 新しいメソッドは, CONNECTとOPTIONSでそれぞれ許可されている特別なhost:portおよびアスタリスク形式のリクエストターゲットを使用することはできません (セクション7.1). ターゲットURIには絶対形式の完全なURIが必要です. これは, リクエストターゲットを絶対形式で送信する必要があるか, またはターゲットURIが他のメソッドと同じ方法でリクエストコンテキストから再構築されることを意味します.

新しいメソッドの定義では, それが安全であるか (セクション9.2.1), べき等であるか (セクション9.2.2), キャッシュ可能であるか (セクション9.2.3), リクエストコンテンツに関連付けられるセマンティクス (ある場合), およびメソッドがヘッダーフィールドまたはステータスコードのセマンティクスに対して行う改良を示す必要があります. 新しいメソッドがキャッシュ可能である場合, その定義では, キャッシュが応答を格納し, それを使用して後続のリクエストを満たす方法と条件を記述する必要があります. 新しいメソッドでは, 条件付きにできるかどうか (セクション13.1), およびその場合, 条件がfalseのときにサーバーがどのように応答するかを記述する必要があります. 同様に, 新しいメソッドが部分応答セマンティクス (セクション14.2) に対して何らかの用途がある可能性がある場合は, これも文書化する必要があります.

注意: "M-" で始まるメソッド名の定義は避けてください. そのプレフィックスは, [RFC2774]によって割り当てられたセマンティクスを持つと誤解される可能性があるためです.

16.2. Status Code Extensibility (ステータスコード拡張性)

16.2.1. Status Code Registry (ステータスコードレジストリ)

"Hypertext Transfer Protocol (HTTP) Status Code Registry"は, IANAによって https://www.iana.org/assignments/http-status-codes で管理されており, ステータスコード番号を登録します.

登録には, 以下のフィールドを含める必要があります (MUST):

• Status Code (ステータスコード) (3桁)
• Short Description (簡単な説明)
• Pointer to specification text (仕様テキストへのポインタ)

HTTPステータスコード名前空間に追加される値には, IETFレビューが必要です ([RFC8126]のセクション4.8を参照).

16.2.2. Considerations for New Status Codes (新しいステータスコードの考慮事項)

現在のステータスコードで定義されていない応答のセマンティクスを表現する必要がある場合, 新しいステータスコードを登録できます. ステータスコードは汎用的です. つまり, 特定のメディアタイプ, リソースの種類, またはHTTPのアプリケーションだけでなく, 潜在的にあらゆるリソースに適用可能です. そのため, 新しいステータスコードは単一のアプリケーションに固有ではない文書に登録することが望ましいです.

新しいステータスコードは, セクション15で定義されているカテゴリのいずれかに該当する必要があります. 既存のパーサーが応答メッセージを処理できるようにするため, 新しいステータスコードはコンテンツを禁止することはできませんが, ゼロ長のコンテンツを義務付けることはできます.

まだ広く展開されていない新しいステータスコードの提案は, 登録されることについて明確な合意が得られるまで, コードに特定の番号を割り当てることを避けるべきです. 代わりに, 初期のドラフトでは, "4NN" や "3N0" .. "3N9" などの表記を使用して, 番号を時期尚早に消費することなく, 提案されたステータスコードのクラスを示すことができます.

新しいステータスコードの定義では, そのステータスコードを含む応答を引き起こすリクエスト条件 (たとえば, リクエストヘッダーフィールドやメソッドの組み合わせ) と, 応答ヘッダーフィールドへの依存関係 (たとえば, どのフィールドが必要か, どのフィールドがセマンティクスを変更できるか, 新しいステータスコードと共に使用されるときにどのフィールドセマンティクスがさらに洗練されるか) を説明する必要があります.

デフォルトでは, ステータスコードは, それが発生する応答に対応するリクエストにのみ適用されます. ステータスコードがより大きな適用範囲に適用される場合 (たとえば, 問題のリソースへのすべてのリクエストまたはサーバーへのすべてのリクエスト) は, これを明示的に指定する必要があります (MUST). その際, すべてのクライアントが新しいステータスコードを理解しない可能性があるため, より大きな範囲を一貫して適用するとは限らないことに注意する必要があります.

新しい最終ステータスコードの定義では, それがヒューリスティックにキャッシュ可能かどうかを指定する必要があります. 明示的な鮮度情報がある場合, 最終ステータスコードを持つ任意の応答をキャッシュできることに注意してください. ヒューリスティックにキャッシュ可能として定義されたステータスコードは, 明示的な鮮度情報なしでキャッシュすることが許可されます. 同様に, must-understandキャッシュディレクティブが使用されている場合, ステータスコードの定義はキャッシュ動作に制約を課すことができます. 詳細については, [CACHING]を参照してください.

最後に, 新しいステータスコードの定義では, コンテンツが識別されたリソースと暗黙的な関連付けを持つかどうかを示す必要があります (セクション6.4.2).

16.3. Field Extensibility (フィールド拡張性)

HTTPの最も広く使用されている拡張ポイントは, 新しいヘッダーおよびトレーラーフィールドの定義です.

新しいフィールドは, 受信者によって理解されるときに, 以前に定義されたフィールドの解釈を上書きまたは強化したり, リクエスト評価の前提条件を定義したり, 応答の意味を洗練したりするように定義できます.

ただし, フィールドを定義しても, その展開または受信者による認識が保証されるわけではありません. ほとんどのフィールドは, 受信者が認識されないフィールドを安全に無視 (ただしダウンストリームに転送) できることを期待して設計されています. 他のケースでは, 送信者が特定のフィールドを理解する能力は, その以前の通信によって示される場合があります. おそらく, プロトコルバージョンまたは以前のメッセージで送信したフィールド, または特定のメディアタイプの使用によって示されます. 同様に, そのような検査がフィールドの導入とともに定義されている場合, OPTIONSリクエストを介して, または定義されたwell-known URI [RFC8615]と相互作用することによって, サポートの直接検査が可能な場合があります.

16.3.1. Field Name Registry (フィールド名レジストリ)

"Hypertext Transfer Protocol (HTTP) Field Name Registry"は, HTTPフィールド名の名前空間を定義します.

いずれの当事者もHTTPフィールドの登録を要求できます. 新しいHTTPフィールドを作成する際に考慮すべき事項については, セクション16.3.2を参照してください.

"Hypertext Transfer Protocol (HTTP) Field Name Registry"は https://www.iana.org/assignments/http-fields/ にあります. 登録リクエストは, そこにある指示に従うか, "[email protected]" メーリングリストに電子メールを送信することで行うことができます.

フィールド名は, 指定されたexpertの助言に基づいて登録されます (IESGまたはその代理によって任命されます). ステータスが 'permanent' のフィールドには, Specification Requiredが必要です ([RFC8126]のセクション4.6).

登録リクエストは, 以下の情報で構成されます:

Field name (フィールド名): リクエストされたフィールド名. セクション5.1で定義されたfield-name構文に準拠する必要があり (MUST), 文字, 数字, およびハイフン ('-') 文字のみに制限されるべきであり (SHOULD), 最初の文字は文字である必要があります.

Status (ステータス): "permanent", "provisional", "deprecated", または "obsoleted".

Specification document(s) (仕様文書): フィールドを指定する文書への参照. 文書のコピーを取得するために使用できるURIを含めることが望ましいです. 関連するセクションの指示も含めることができますが, 必須ではありません.

そしてオプションで:

Comments (コメント): 予約されたエントリに関する情報など, 追加情報.

Expert(s) は, コミュニティと協議して, レジストリで収集する追加のフィールドを定義できます.

標準で定義された名前のステータスは "permanent" です. Expert(s) がコミュニティと協議した後, 使用中であると判断した場合, 他の名前も permanentとして登録できます. 他の名前は "provisional" として登録されるべきです (SHOULD).

Provisional エントリは, expert(s) がコミュニティと協議して使用されていないと判断した場合, expert(s) によって削除できます. Expert(s) は, いつでも provisional エントリのステータスを permanent に変更できます.

Expert(s) が, 未登録の名前が広く展開されており, 適時に登録される可能性が低いと判断した場合, 第三者 (expert(s) を含む) が名前を登録できることに注意してください.

16.3.2. Considerations for New Fields (新しいフィールドの考慮事項)

HTTPヘッダーおよびトレーラーフィールドは, プロトコルの広く使用されている拡張ポイントです. それらはアドホックな方法で使用できますが, より広く使用されることを意図したフィールドは, 相互運用性を確保するために慎重に文書化する必要があります.

特に, 新しいフィールドを定義する仕様の作成者は, 次の側面を検討し, 適切な場合は文書化することをお勧めします:

• フィールドを使用できる条件. たとえば, 応答またはリクエストのみ, すべてのメッセージ, 特定のリクエストメソッドへの応答のみなど.

• フィールドのセマンティクスが, 特定のリクエストメソッドまたはステータスコードでの使用など, そのコンテキストによってさらに洗練されるかどうか.

• 伝達される情報の適用範囲. デフォルトでは, フィールドは関連付けられているメッセージにのみ適用されますが, 一部の応答フィールドは, リソースのすべての表現, リソース自体, またはさらに広い範囲に適用されるように設計されています. 応答フィールドの範囲を拡大する仕様では, コンテンツネゴシエーション, 適用期間, および (場合によっては) マルチテナントサーバーデプロイメントなどの問題を慎重に検討する必要があります.

• 仲介者がフィールドの値を挿入, 削除, または変更することが許可される条件.

• フィールドがトレーラーで許可されるかどうか. デフォルトでは許可されません (セクション6.5.1を参照).

• Connectionヘッダーフィールドにフィールド名をリストすることが適切か, または必須かどうか (つまり, フィールドがhop-by-hopである場合; セクション7.6.1を参照).

• フィールドがプライバシー関連データの開示など, 追加のセキュリティ上の考慮事項を導入するかどうか.

デフォルトとは異なる動作を許可したいリクエストヘッダーフィールドには, 文書化すべき追加の考慮事項があります:

• Varyレスポンスヘッダーフィールドにフィールド名をリストすることが適切かどうか (たとえば, オリジンサーバーのコンテンツ選択アルゴリズムがリクエストヘッダーフィールドを使用する場合; セクション12.5.5を参照).

• PUTリクエストで受信したときにサーバーがフィールドを格納することを意図しているかどうか (セクション9.3.4を参照).

• セキュリティ上の懸念により自動的にリクエストをリダイレクトするときにフィールドを削除すべきかどうか (セクション15.4を参照).

16.3.2.1. Considerations for New Field Names (新しいフィールド名の考慮事項)

新しいフィールドを定義する仕様の作成者は, 短いが説明的なフィールド名を選択することをお勧めします. 短い名前は不必要なデータ転送を避けます. 説明的な名前は, より広い用途を持つ可能性のある名前の混乱や "占拠" を避けます.

そのため, 限定的な使用のフィールド (単一のアプリケーションまたはユースケースに限定されたヘッダーなど) は, その使用 (または略語) をプレフィックスとして含む名前を使用することが推奨されます. たとえば, Fooアプリケーションが Descriptionフィールドを必要とする場合, "Foo-Desc" を使用する場合があります. "Description" は汎用的すぎ, "Foo-Description" は不必要に長いです.

field-name構文は任意のトークン文字を許可するように定義されていますが, 実際には, 一部の実装はフィールド名で受け入れる文字に制限を設けています. 相互運用可能であるために, 新しいフィールド名は英数字, "-", および "." に制限されるべきであり (SHOULD), 文字で始まるべきです (SHOULD). たとえば, アンダースコア ("_") 文字は, 非HTTPゲートウェイインターフェイスを通過するときに問題になる可能性があります (セクション17.10を参照).

フィールド名は "X-" で始まるべきではありません. 詳細については, [BCP178]を参照してください.

HTTPフィールド名では, 他のプレフィックスが使用されることがあります. たとえば, "Accept-" は多くのコンテンツネゴシエーションヘッダーで使用され, "Content-" はセクション6.4で説明されているように使用されます. これらのプレフィックスは, フィールドの目的を認識するための補助にすぎず, 自動処理をトリガーしません.

16.3.2.2. Considerations for New Field Values (新しいフィールド値の考慮事項)

新しいHTTPフィールドの定義における主要なタスクは, フィールド値構文の仕様です: 送信者が生成すべきもの, および受信者が受信したものからセマンティクスをどのように推論すべきか.

作成者は, 新しいフィールド値の構文を定義するために, この仕様のABNFルールまたは [RFC8941]のルールを使用することが推奨されます (ただし必須ではありません).

作成者は, 複数のフィールド行の組み合わせがそれらにどのように影響するかを慎重に検討することをお勧めします (セクション5.3を参照). 送信者が誤って複数の値を送信する可能性があり, 仲介者とHTTPライブラリの両方が自動的に組み合わせを実行できるため, これはすべてのフィールド値に適用されます. 単一の値のみが予想される場合でもです.

したがって, 作成者は, コンマを含む値を区切るかエンコードすることをお勧めします (たとえば, セクション5.6.4のquoted-stringルール, [RFC8941]のStringデータ型, またはフィールド固有のエンコーディング). これにより, フィールドデータ内のコンマが, リスト値を区切るコンマと混同されないことが保証されます.

たとえば, Content-Typeフィールド値は, 引用符で囲まれた文字列内でのみコンマを許可します. これは, 複数の値が存在する場合でも確実に解析できます. Locationフィールド値は, 模倣すべきではない反例を提供します: URIにはコンマを含めることができるため, コンマを含む単一の値と2つの値を確実に区別することはできません.

シングルトン値を持つフィールドの作成者 (セクション5.5を参照) は, さらに, 複数のメンバーを含むメッセージをどのように処理するかを文書化することをお勧めします (妥当なデフォルトはフィールドを無視することですが, これが常に正しい選択であるとは限りません).

16.4. Authentication Scheme Extensibility (認証スキーム拡張性)

16.4.1. Authentication Scheme Registry (認証スキームレジストリ)

"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"は, チャレンジおよびクレデンシャルの認証スキームの名前空間を定義します. これは https://www.iana.org/assignments/http-authschemes で管理されています.

登録には, 以下のフィールドを含める必要があります (MUST):

• Authentication Scheme Name (認証スキーム名)
• Pointer to specification text (仕様テキストへのポインタ)
• Notes (注記) (オプション)

この名前空間に追加される値には, IETFレビューが必要です ([RFC8126]のセクション4.8を参照).

16.4.2. Considerations for New Authentication Schemes (新しい認証スキームの考慮事項)

HTTP認証フレームワークの特定の側面は, 新しい認証スキームの動作方法に制約を課します:

• HTTP認証はステートレスであると想定されます: リクエストを認証するために必要なすべての情報は, サーバーが以前のリクエストを記憶することに依存するのではなく, リクエストで提供される必要があります (MUST). 基礎となる接続に基づく, または接続にバインドされた認証は, この仕様の範囲外であり, 認証されたユーザー以外のいずれの当事者も接続を使用できないことを保証するための手順が講じられない限り, 本質的に欠陥があります (セクション3.3を参照).

• 認証パラメータ "realm" は, セクション11.5で説明されている保護空間を定義するために予約されています. 新しいスキームは, その定義と互換性のない方法でそれを使用してはなりません (MUST NOT).

• "token68" 表記は, 既存の認証スキームとの互換性のために導入されました. チャレンジまたはクレデンシャルごとに1回だけ使用できます. したがって, 新しいスキームは代わりにauth-param構文を使用すべきです. そうしないと, 将来の拡張が不可能になります.

• チャレンジとクレデンシャルの解析は, この仕様で定義されており, 新しい認証スキームによって変更することはできません. auth-param構文が使用される場合, すべてのパラメータはトークンと引用符で囲まれた文字列の両方の構文をサポートすべきであり, 構文上の制約は解析後 (つまり, 引用符で囲まれた文字列の処理後) にフィールド値で定義されるべきです. これは, 受信者がすべての認証スキームに適用される汎用パーサーを使用できるようにするために必要です.

  注意: "realm" パラメータの値構文が引用符で囲まれた文字列に制限されているという事実は, 新しいパラメータに対して繰り返すべきではない悪い設計選択です.

• 新しいスキームの定義では, 不明な拡張パラメータの処理を定義すべきです. 一般に, "must-ignore" ルールは "must-understand" ルールよりも望ましいです. そうしないと, レガシー受信者が存在する場合に新しいパラメータを導入することが困難になるためです. さらに, 新しいパラメータを定義するためのポリシー (たとえば, "仕様を更新する" または "このレジストリを使用する") を記述することをお勧めします.

• 認証スキームは, オリジンサーバー認証 (つまり, WWW-Authenticateを使用) またはプロキシ認証 (つまり, Proxy-Authenticateを使用), あるいはその両方で使用可能かどうかを文書化する必要があります.

• Authorizationヘッダーフィールドで伝送されるクレデンシャルは, ユーザーエージェントに固有であり, したがって, それらが出現するリクエストの範囲内で, "private" キャッシュレスポンスディレクティブ ([CACHING]のセクション5.2.2.7) と同じ効果をHTTPキャッシュに与えます.

  したがって, Authorizationヘッダーフィールドでクレデンシャルを伝送しないことを選択した新しい認証スキーム (たとえば, 新しく定義されたヘッダーフィールドを使用) は, キャッシュレスポンスディレクティブ (たとえば, "private") の使用を義務付けることにより, キャッシングを明示的に禁止する必要があります.

• Authentication-Info, Proxy-Authentication-Info, またはその他の認証関連の応答ヘッダーフィールドを使用するスキームは, 関連するセキュリティ上の考慮事項を検討し, 文書化する必要があります (セクション17.16.4を参照).

16.5. Range Unit Extensibility (レンジ単位拡張性)

16.5.1. Range Unit Registry (レンジ単位レジストリ)

"HTTP Range Unit Registry"は, レンジ単位名の名前空間を定義し, 対応する仕様を参照します. これは https://www.iana.org/assignments/http-parameters で管理されています.

HTTPレンジ単位の登録には, 以下のフィールドを含める必要があります (MUST):

• Name (名前)
• Description (説明)
• Pointer to specification text (仕様テキストへのポインタ)

この名前空間に追加される値には, IETFレビューが必要です ([RFC8126]のセクション4.8を参照).

16.5.2. Considerations for New Range Units (新しいレンジ単位の考慮事項)

ページ, セクション, レコード, 行, または時間などの形式固有の境界などの他のレンジ単位は, HTTPでアプリケーション固有の目的で使用できる可能性がありますが, 実際にはあまり使用されていません. 代替レンジ単位の実装者は, それらがコンテンツコーディングや汎用の仲介者とどのように機能するかを検討すべきです.

16.6. Content Coding Extensibility (コンテンツコーディング拡張性)

16.6.1. Content Coding Registry (コンテンツコーディングレジストリ)

"HTTP Content Coding Registry"は, IANAによって https://www.iana.org/assignments/http-parameters/ で管理されており, content-coding名を登録します.

コンテンツコーディングの登録には, 以下のフィールドを含める必要があります (MUST):

• Name (名前)
• Description (説明)
• Pointer to specification text (仕様テキストへのポインタ)

コンテンツコーディングの名前は, エンコーディング変換が同一でない限り (https://www.iana.org/assignments/http-parameters/ にある "HTTP Transfer Coding Registry" による), 転送コーディングの名前と重複してはなりません (MUST NOT) (セクション8.4.1で定義されている圧縮コーディングの場合のように).

この名前空間に追加される値には, IETFレビューが必要であり ([RFC8126]のセクション4.8), セクション8.4.1で定義されているコンテンツコーディングの目的に準拠する必要があります (MUST).

16.6.2. Considerations for New Content Codings (新しいコンテンツコーディングの考慮事項)

新しいコンテンツコーディングは, 可能な限り自己記述的であるべきです. コーディング形式自体内で検出可能なオプションのパラメータを持ち, 転送中に失われる可能性のある外部メタデータに依存しないようにすべきです.

16.7. Upgrade Token Registry (アップグレードトークンレジストリ)

"Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"は, Upgradeヘッダーフィールドでプロトコルを識別するために使用されるprotocol-nameトークンの名前空間を定義します. レジストリは https://www.iana.org/assignments/http-upgrade-tokens で管理されています.

登録された各プロトコル名は, 連絡先情報と, アップグレード後に接続がどのように処理されるかを詳述する一連の仕様 (オプション) に関連付けられています.

登録は "First Come First Served" ベースで行われ ([RFC8126]のセクション4.4を参照), 以下のルールに従います:

1. protocol-nameトークンは, 一度登録されると, 永久に登録されたままになります.

2. protocol-nameトークンは大文字と小文字を区別せず, 送信者が生成する優先ケースで登録されます.

3. 登録には, 登録の責任者を指定する必要があります (MUST).

4. 登録には, 連絡先を指定する必要があります (MUST).

5. 登録では, そのトークンに関連付けられた一連の仕様を指定できます (MAY). そのような仕様は公開されている必要はありません.

6. 登録では, 登録時にそのトークンに関連付けられた予想される "protocol-version" トークンのセットを指定すべきです (SHOULD).

7. 責任者は, いつでも登録を変更できます (MAY). IANAは, そのようなすべての変更の記録を保持し, リクエストに応じて提供します.

8. IESGは, プロトコルトークンの責任を再割り当てできます (MAY). これは通常, 責任者に連絡できない場合にのみ使用されます.