8. IANAの考慮事項 (IANA Considerations)
この仕様は、[RFC2817]、[RFC2818]、[RFC4229]によって確立されたレジストリを更新するとともに、メソッド名、ステータスコード、および関連するセマンティクスの新しいレジストリを定義します。
8.1. メソッド登録 (Method Registration)
"ハイパーテキスト転送プロトコル(HTTP)メソッドレジストリ"は、リクエストメソッドトークンの名前空間を定義します(セクション4)。メソッドレジストリは作成されており、現在http://www.iana.org/assignments/http-methodsで管理されています。
8.1.1. 手順 (Procedure)
登録には、次のフィールドを含める必要があります(MUST):
- メソッド名 (Method Name)
- 安全性 (Safe) (はい/いいえ)
- 冪等性 (Idempotent) (はい/いいえ)
- 仕様テキストへのポインタ (Pointer to specification text)
この名前空間に追加される値には、IETFレビューが必要です([RFC5226]のセクション4.1を参照)。
8.1.2. 新しいメソッドの考慮事項 (Considerations for New Methods)
標準化されたメソッドは汎用的です。つまり、特定のメディアタイプ、リソースの種類、またはアプリケーションだけでなく、潜在的にあらゆるリソースに適用できます。そのため、直交技術には直交仕様が必要であるため、単一のアプリケーションやデータ形式に固有でないドキュメントに新しいメソッドを登録することが推奨されます。
メッセージ解析([RFC7230]のセクション3)はメソッドセマンティクスから独立している必要があるため(HEADへのレスポンスを除く)、新しいメソッドの定義は解析アルゴリズムを変更したり、リクエストまたはレスポンスメッセージにメッセージボディの存在を禁止したりすることはできません。新しいメソッドの定義は、値が"0"のContent-Lengthヘッダーフィールドを要求することで、ゼロ長のメッセージボディのみが許可されることを指定できます。
新しいメソッド定義は、それが安全である(セクション4.2.1)か、冪等である(セクション4.2.2)か、キャッシュ可能である(セクション4.2.3)か、リクエストメッセージボディ(存在する場合)に関連付けられるセマンティクスは何か、およびレスポンスメッセージボディ(存在する場合)に関連付けられるセマンティクスは何かを示す必要があります。リクエストメソッドの冪等性は、オリジンサーバーでの実装のプロパティであることに注意してください。実装は意図された動作から逸脱する可能性があるため、クライアントはメソッドが冪等または安全であることに依存できません。
新しいメソッドがキャッシュ可能である場合、その定義は、キャッシュがどのように、どのような条件下でレスポンスを保存し、それを使用して後続のリクエストを満たすことができるかを説明する必要があります(ought to)。新しいメソッドは、それが条件付きにできるか([RFC7232]のセクション5)、もしそうであれば、条件が偽の場合にサーバーがどのように応答するかを説明する必要があります(ought to)。同様に、新しいメソッドが部分的なレスポンスセマンティクス([RFC7233])に何らかの用途がある場合、それも文書化する必要があります(ought to)。
注: [RFC2774]によって割り当てられたセマンティクスを持つと誤解される可能性があるため、"M-"で始まるメソッド名の定義は避けてください。
8.1.3. 登録 (Registrations)
HTTPのメソッド登録手順は、この仕様に従って更新されました。HTTPメソッドレジストリは、以下の登録で更新されました:
| メソッド名 | 安全性 | 冪等性 | 参照 |
|---|---|---|---|
| GET | はい | はい | セクション4.3.1 |
| HEAD | はい | はい | セクション4.3.2 |
| POST | いいえ | いいえ | セクション4.3.3 |
| PUT | いいえ | はい | セクション4.3.4 |
| DELETE | いいえ | はい | セクション4.3.5 |
| CONNECT | いいえ | いいえ | セクション4.3.6 |
| OPTIONS | はい | はい | セクション4.3.7 |
| TRACE | はい | はい | セクション4.3.8 |
8.2. ステータスコード登録 (Status Code Registration)
"ハイパーテキスト転送プロトコル(HTTP)ステータスコードレジストリ"は、レスポンスステータスコードトークンの名前空間を定義します(セクション6)。ステータスコードレジストリは作成されており、現在http://www.iana.org/assignments/http-status-codesで管理されています。
8.2.1. 手順 (Procedure)
登録には、次のフィールドを含める必要があります(MUST):
- ステータスコード (Status Code) (3桁)
- 簡単な説明 (Short Description)
- 仕様テキストへのポインタ (Pointer to specification text)
HTTPステータスコード名前空間に追加される値には、IETFレビューが必要です([RFC5226]のセクション4.1を参照)。
8.2.2. 新しいステータスコードの考慮事項 (Considerations for New Status Codes)
現在のステータスコードで定義されていないレスポンスのセマンティクスを表現する必要がある場合、新しいステータスコードを登録できます。ステータスコードは汎用的です。特定のメディアタイプ、リソースの種類、またはHTTPのアプリケーションだけでなく、潜在的にあらゆるリソースに適用できます。そのため、単一のアプリケーションに固有でないドキュメントに新しいステータスコードを登録することが推奨されます。
新しいステータスコードは、セクション6で定義されたカテゴリのいずれかに該当する必要があります。既存のパーサーがレスポンスメッセージを処理できるようにするため、新しいステータスコードはペイロードを禁止することはできませんが、ゼロ長のペイロードボディを義務付けることはできます。
まだ広く展開されていない新しいステータスコードの提案は、登録される明確なコンセンサスが得られるまで、コードに特定の番号を割り当てることを避ける必要があります(ought to)。代わりに、初期のドラフトでは"4NN"や"3N0"のような表記を使用して、番号を時期尚早に消費することなく提案されたステータスコードのクラスを示すことができます。
新しいステータスコードの定義は、必要な前提条件、ステータスをトリガーしたリクエストの特性、およびそのようなレスポンスを処理するための予想されるクライアントの動作を含む、そのステータスコードを持つレスポンスのセマンティクスを説明する必要があります(ought to)。
8.2.3. 登録 (Registrations)
ステータスコードレジストリは、以下の登録で更新されました:
| 値 | 説明 | 参照 |
|---|---|---|
| 100 | Continue | セクション6.2.1 |
| 101 | Switching Protocols | セクション6.2.2 |
| 200 | OK | セクション6.3.1 |
| 201 | Created | セクション6.3.2 |
| 202 | Accepted | セクション6.3.3 |
| 203 | Non-Authoritative Information | セクション6.3.4 |
| 204 | No Content | セクション6.3.5 |
| 205 | Reset Content | セクション6.3.6 |
| 206 | Partial Content | [RFC7233], セクション4.1 |
| 300 | Multiple Choices | セクション6.4.1 |
| 301 | Moved Permanently | セクション6.4.2 |
| 302 | Found | セクション6.4.3 |
| 303 | See Other | セクション6.4.4 |
| 304 | Not Modified | [RFC7232], セクション4.1 |
| 305 | Use Proxy | セクション6.4.5 |
| 306 | (Unused) | セクション6.4.6 |
| 307 | Temporary Redirect | セクション6.4.7 |
| 400 | Bad Request | セクション6.5.1 |
| 401 | Unauthorized | [RFC7235], セクション3.1 |
| 402 | Payment Required | セクション6.5.2 |
| 403 | Forbidden | セクション6.5.3 |
| 404 | Not Found | セクション6.5.4 |
| 405 | Method Not Allowed | セクション6.5.5 |
| 406 | Not Acceptable | セクション6.5.6 |
| 407 | Proxy Authentication Required | [RFC7235], セクション3.2 |
| 408 | Request Timeout | セクション6.5.7 |
| 409 | Conflict | セクション6.5.8 |
| 410 | Gone | セクション6.5.9 |
| 411 | Length Required | セクション6.5.10 |
| 412 | Precondition Failed | [RFC7232], セクション4.2 |
| 413 | Payload Too Large | セクション6.5.11 |
| 414 | URI Too Long | セクション6.5.12 |
| 415 | Unsupported Media Type | セクション6.5.13 |
| 416 | Range Not Satisfiable | [RFC7233], セクション4.4 |
| 417 | Expectation Failed | セクション6.5.14 |
| 426 | Upgrade Required | セクション6.5.15 |
| 500 | Internal Server Error | セクション6.6.1 |
| 501 | Not Implemented | セクション6.6.2 |
| 502 | Bad Gateway | セクション6.6.3 |
| 503 | Service Unavailable | セクション6.6.4 |
| 504 | Gateway Timeout | セクション6.6.5 |
| 505 | HTTP Version Not Supported | セクション6.6.6 |
8.3. ヘッダーフィールド登録 (Header Field Registration)
この仕様は、[RFC4229]で定義されたHTTPヘッダーフィールドレジストリを[RFC3864]の登録手順で更新します。
8.3.1. 新しいヘッダーフィールドの考慮事項 (Considerations for New Header Fields)
ヘッダーフィールドは、HTTP拡張性フレームワークの重要なコンポーネントです。これらは、メッセージまたはリソースに関連付けられた追加データを定義します。新しいヘッダーフィールドを定義する際には、多くの考慮事項があります。
新しいヘッダーフィールドは、少なくとも以下を定義する必要があります:
- フィールド名([RFC7230]のセクション3.2)
- フィールド値の期待される文法
- フィールドのセマンティクス
- リクエストヘッダーフィールドの場合、それらがどのようにメッセージセマンティクスをオーバーライドまたは拡張できるか
- レスポンスヘッダーフィールドの場合、それらがどのようにレスポンスの解釈を変更するか
- フィールドがキャッシュによって保存されるべきか、および後続のリクエストへのレスポンスで返されることができるか
- フィールドがプロキシによって転送されるべきか
以下を文書化することも有用です:
- ヘッダーフィールドが中間者によって使用されることを意図しているか、またはエンドツーエンドのみか
- セキュリティとプライバシーの考慮事項(セクション9を参照)
- 他のヘッダーフィールドとの相互作用
新しいヘッダーフィールドの定義に関する詳細なアドバイスは、"HTTPヘッダーフィールド仕様のガイドライン"[RFC6648bis]で入手できます。
8.3.2. 登録 (Registrations)
http://www.iana.org/assignments/message-headers/にある"ハイパーテキスト転送プロトコル(HTTP)ヘッダーフィールドレジストリ"は、以下の恒久的な登録で更新される必要があります([RFC3864]を参照):
| ヘッダーフィールド名 | プロトコル | ステータス | 参照 |
|---|---|---|---|
| Accept | http | standard | セクション5.3.2 |
| Accept-Charset | http | standard | セクション5.3.3 |
| Accept-Encoding | http | standard | セクション5.3.4 |
| Accept-Language | http | standard | セクション5.3.5 |
| Allow | http | standard | セクション7.4.1 |
| Content-Encoding | http | standard | セクション3.1.2.2 |
| Content-Language | http | standard | セクション3.1.3.2 |
| Content-Location | http | standard | セクション3.1.4.2 |
| Content-Type | http | standard | セクション3.1.1.5 |
| Date | http | standard | セクション7.1.1.2 |
| Expect | http | standard | セクション5.1.1 |
| From | http | standard | セクション5.5.1 |
| Location | http | standard | セクション7.1.2 |
| Max-Forwards | http | standard | セクション5.1.2 |
| MIME-Version | http | standard | 付録A.1 |
| Referer | http | standard | セクション5.5.2 |
| Retry-After | http | standard | セクション7.1.3 |
| Server | http | standard | セクション7.4.2 |
| User-Agent | http | standard | セクション5.5.3 |
| Vary | http | standard | セクション7.1.4 |
変更コントローラーは: "IETF ([email protected]) - Internet Engineering Task Force"。
8.4. コンテンツコーディング登録 (Content Coding Registration)
"HTTPコンテンツコーディングレジストリ"は、コンテンツコーディング名の名前空間を定義します(セクション3.1.2.1)。コンテンツコーディングレジストリは作成されており、現在http://www.iana.org/assignments/http-parametersで管理されています。
8.4.1. 手順 (Procedure)
登録には、次のフィールドを含める必要があります(MUST):
- 名前 (Name)
- 説明 (Description)
- 仕様テキストへのポインタ (Pointer to specification text)
"x-"で始まる名前は私的使用のために予約されており([RFC5226]で定義)、登録できません。
この名前空間に追加される値には、IETFレビューが必要です([RFC5226]のセクション4.1を参照)。
8.4.2. 登録 (Registrations)
コンテンツコーディングレジストリは、以下の登録で更新されました:
| 名前 | 説明 | 参照 |
|---|---|---|
| compress | UNIX "compress" データ形式 | セクション3.1.2.1 |
| deflate | "deflate" 圧縮データ | セクション3.1.2.1 |
| gzip | GZIP ファイル形式 | セクション3.1.2.1 |
| identity | 予約済み (エンコードなしの同義語) | セクション3.1.2.1 |