メインコンテンツまでスキップ

4.7. Specifying HTTP Header Fields (HTTP ヘッダーフィールドの指定)

4.7. Specifying HTTP Header Fields (HTTP ヘッダーフィールドの指定)

アプリケーションは新しい HTTP ヘッダーフィールドを定義する必要があることがよくあります。その場合, [HTTP] セクション 16.3 の手順に従って, "ハイパーテキスト転送プロトコル (Hypertext Transfer Protocol, HTTP) フィールド名レジストリ" に登録しなければなりません (MUST)。

[STRUCTURED-FIELDS] は, ヘッダーフィールド値を定義する標準化された方法を提供し, それらの解析と処理を容易にします。アプリケーションは新しいヘッダーフィールドを定義するときに構造化フィールドを使用すべきです (SHOULD)。

ヘッダーフィールドを定義するとき, アプリケーションは次のことを考慮する必要があります:

  • ヘッダーフィールド名は説明的であり, [HTTP] セクション 16.3.1 の命名規則に従うべきです (SHOULD)。

  • ヘッダーフィールドは [RFC6648] に従って "X-" プレフィックスを使用すべきではありません (SHOULD NOT)。

  • ヘッダーフィールドの値の構文は明確に指定されるべきです (SHOULD)。[STRUCTURED-FIELDS] の使用が推奨されます。

  • ヘッダーフィールドのセマンティクスは, いつ送信されるべきか, どのように解釈されるべきかを含めて明確に説明されるべきです (SHOULD)。

  • アプリケーションは, ヘッダーフィールドがホップバイホップかエンドツーエンドかを検討すべきです (SHOULD)。ほとんどのアプリケーション定義ヘッダーフィールドはエンドツーエンドであるべきです。

  • アプリケーションは, ヘッダーフィールドがメッセージに複数回出現する場合に何が起こるかを指定すべきです (SHOULD)。

  • アプリケーションは, ヘッダーフィールドがリクエスト, レスポンス, または両方を対象としているかを指定すべきです (SHOULD)。

アプリケーションは, 新しいものを定義するのではなく, 可能な限り既存のヘッダーフィールドを再利用すべきです (SHOULD)。たとえば, アプリケーションが送信されているコンテンツのタイプを識別する必要がある場合, 新しいヘッダーフィールドを定義するのではなく Content-Type を使用すべきです。

既存のヘッダーフィールドを再利用するとき, アプリケーションは定義されたセマンティクスと構文を尊重しなければなりません (MUST)。