6. Response Status Codes (レスポンスステータスコード)
ステータスコード (status-code) 要素は、リクエストを理解して満たそうとした試みの結果を示す3桁の整数コードです。
HTTP ステータスコードは拡張可能です。HTTP クライアントは、すべての登録されたステータスコードの意味を理解する必要はありませんが、そのような理解が明らかに望ましいことは言うまでもありません。ただし、クライアントは、最初の桁で示されるように、任意のステータスコードのクラスを理解しなければならず (MUST)、認識できないステータスコードを、そのクラスの x00 ステータスコードと同等のものとして扱わなければなりません。ただし、受信者は、認識できないステータスコードを含むレスポンスをキャッシュしてはなりません (MUST NOT)。
たとえば、認識できないステータスコード 471 をクライアントが受信した場合、クライアントはリクエストに何か問題があったと想定し、400 (Bad Request) ステータスコードを受信したかのようにレスポンスを扱うことができます。レスポンスメッセージには通常、ステータスを説明する表現が含まれます。
ステータスコードの最初の桁は、レスポンスのクラスを定義します。最後の2桁には分類の役割はありません。最初の桁には5つの値があります：
- 1xx (Informational / 情報)：リクエストが受信され、処理を継続中
- 2xx (Successful / 成功)：リクエストが正常に受信、理解、受け入れされた
- 3xx (Redirection / リダイレクト)：リクエストを完了するためにさらなるアクションが必要
- 4xx (Client Error / クライアントエラー)：リクエストに不正な構文が含まれているか、実行できない
- 5xx (Server Error / サーバーエラー)：サーバーが明らかに有効なリクエストを実行できなかった
6.1. Overview of Status Codes (ステータスコードの概要)
以下にリストされているステータスコードは、この仕様で定義されています。ここにリストされている理由フレーズは推奨にすぎません。プロトコルに影響を与えることなく、ローカルの同等のもので置き換えることができます。
デフォルトでキャッシュ可能として定義されているステータスコード（たとえば、この仕様の 200、203、204、206、300、301、404、405、410、414、および 501）を含むレスポンスは、メソッド定義または明示的なキャッシュ制御によって特に示されない限り、ヒューリスティック有効期限でキャッシュによって再利用できます [RFC7234]。他のすべてのステータスコードは、デフォルトでキャッシュできません。
| コード | 理由フレーズ | 定義位置 |
|---|---|---|
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | RFC7233 |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | RFC7232 |
| 305 | Use Proxy | Section 6.4.5 |
| 306 | (Unused) | Section 6.4.6 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | RFC7235 |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | RFC7235 |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | RFC7232 |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | RFC7233 |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
6.2. Informational 1xx (情報 1xx)
1xx (Informational) クラスのステータスコードは、要求されたアクションを完了して最終レスポンスを送信する前に、接続ステータスまたはリクエスト進行状況を通信するための暫定レスポンスを示します。HTTP/1.0 は 1xx ステータスコードを定義していないため、サーバーは HTTP/1.0 クライアントに 1xx レスポンスを送信してはなりません (MUST NOT)。
1xx レスポンスは、ステータス行の後の最初の空行で終了します（空行はヘッダーセクションの終わりを示します）。1xx レスポンスはメッセージボディを含むことができないため、常にヘッダーフィールドの後の最初の空行で終了します。
HTTP/1.1 クライアントは、クライアントが 100 (Continue) ステータスメッセージを期待していない場合でも、最終レスポンスの前に1つ以上の 1xx レスポンスを受信する準備をしなければなりません (MUST)。ユーザーエージェントは、予期しない 1xx レスポンスを無視してもよい (MAY) です。
プロキシは、プロキシ自体が 1xx レスポンスの生成を要求した場合を除き、1xx レスポンスを転送しなければなりません (MUST)。たとえば、プロキシがリクエストを転送するときに "Expect: 100-continue" フィールドを追加した場合、対応する 100 (Continue) レスポンスを転送する必要はありません。
6.2.1. 100 Continue (続行)
100 (Continue) ステータスコードは、リクエストの最初の部分が受信され、まだサーバーによって拒否されていないことを示します。サーバーは、リクエストが完全に受信され、処理された後に最終レスポンスを送信する予定です。
リクエストに 100-continue 期待を含む Expect ヘッダーフィールドが含まれている場合、100 レスポンスは、Section 5.1.1 で説明されているように、サーバーがリクエストペイロードボディを受信したいことを示します。クライアントはリクエストの送信を続行し、100 レスポンスを破棄する必要があります。
リクエストに 100-continue 期待を含む Expect ヘッダーフィールドが含まれていなかった場合、クライアントはこの暫定レスポンスを単に破棄できます。
6.2.2. 101 Switching Protocols (プロトコル切り替え)
101 (Switching Protocols) ステータスコードは、サーバーが、Upgrade ヘッダーフィールド（[RFC7230] の Section 6.7）を介して、この接続で使用されているアプリケーションプロトコルの変更に関するクライアントのリクエストを理解し、それに従う意思があることを示します。サーバーは、101 レスポンスを終了する空行の直後に有効になるプロトコルを示す Upgrade ヘッダーフィールドをレスポンスで生成しなければなりません (MUST)。
サーバーは、そうすることが有利な場合にのみプロトコルの切り替えに同意すると想定されます。たとえば、新しいバージョンの HTTP への切り替えは古いバージョンよりも有利である可能性があり、リアルタイムの同期プロトコルへの切り替えは、そのような機能を使用するリソースを配信する場合に有利である可能性があります。
6.3. Successful 2xx (成功 2xx)
2xx (Successful) クラスのステータスコードは、クライアントのリクエストが正常に受信、理解、受け入れされたことを示します。
6.3.1. 200 OK (OK)
200 (OK) ステータスコードは、リクエストが成功したことを示します。200 レスポンスで送信されるペイロードは、リクエストメソッドに依存します。この仕様で定義されているメソッドの場合、ペイロードの意図された意味は次のように要約できます：
- GET：ターゲットリソースの表現；
- HEAD：GET と同じ表現だが、表現データなし；
- POST：アクションのステータスまたはそれから得られた結果の表現；
- PUT, DELETE：アクションのステータスの表現；
- OPTIONS：通信オプションの表現；
- TRACE：エンドサーバーが受信したリクエストメッセージの表現。
CONNECT へのレスポンスを除き、200 レスポンスは常にペイロードを持ちますが、オリジンサーバーは長さゼロのペイロードボディを生成してもよい (MAY) です。ペイロードが必要ない場合、オリジンサーバーは代わりに 204 (No Content) を送信する必要があります。CONNECT の場合、成功した結果はトンネルであり、200 レスポンスヘッダーセクションの直後に開始されるため、ペイロードは許可されません。
200 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.3.2. 201 Created (作成済み)
201 (Created) ステータスコードは、リクエストが満たされ、1つ以上の新しいリソースが作成されたことを示します。リクエストによって作成されたプライマリリソースは、レスポンスの Location ヘッダーフィールドによって識別されるか、Location フィールドが受信されなかった場合は、有効なリクエスト URI によって識別されます。
201 レスポンスペイロードは通常、作成されたリソースを説明し、リンクします。201 レスポンスにおける ETag や Last-Modified などのバリデーターヘッダーフィールドの意味と目的については、Section 7.2 を参照してください。
6.3.3. 202 Accepted (受理)
202 (Accepted) ステータスコードは、リクエストが処理のために受け入れられたが、処理が完了していないことを示します。リクエストは最終的に実行される場合とされない場合があります。実際に処理が行われるときに許可されない可能性があるためです。HTTP には、非同期操作からステータスコードを再送信する機能はありません。
202 レスポンスは意図的に非コミットです。その目的は、サーバーが他のプロセス（おそらく1日に1回しか実行されないバッチ指向プロセス）のリクエストを受け入れることを許可し、プロセスが完了するまでユーザーエージェントのサーバーへの接続が持続する必要がないようにすることです。このレスポンスとともに送信される表現は、リクエストの現在のステータスを説明し、リクエストがいつ満たされるかの見積もりをユーザーに提供できるステータスモニターを指す（または埋め込む）必要があります。
6.3.4. 203 Non-Authoritative Information (非権威情報)
203 (Non-Authoritative Information) ステータスコードは、リクエストは成功したが、含まれているペイロードは変換プロキシ（[RFC7230] の Section 5.7.2）によってオリジンサーバーの 200 (OK) レスポンスから変更されたことを示します。このステータスコードにより、プロキシは変換が適用されたときに受信者に通知できます。その知識は、コンテンツに関する後の決定に影響を与える可能性があるためです。たとえば、コンテンツの将来のキャッシュ検証リクエストは、同じリクエストパス（同じプロキシを介して）に沿ってのみ適用できる場合があります。
203 レスポンスは、214 Transformation Applied の警告コード（[RFC7234] の Section 5.5）に似ていますが、任意のステータスコードを持つレスポンスに適用できるという利点があります。
203 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.3.5. 204 No Content (内容なし)
204 (No Content) ステータスコードは、サーバーがリクエストを正常に満たし、レスポンスペイロードボディに送信する追加のコンテンツがないことを示します。レスポンスヘッダーフィールドのメタデータは、要求されたアクションが適用された後のターゲットリソースとその選択された表現を参照します。
たとえば、PUT リクエストへのレスポンスとして 204 ステータスコードが受信され、レスポンスに ETag ヘッダーフィールドが含まれている場合、PUT は成功し、ETag フィールド値にはそのターゲットリソースの新しい表現のエンティティタグが含まれています。
204 レスポンスにより、サーバーはアクションがターゲットリソースに正常に適用されたことを示すことができ、同時にユーザーエージェントが現在の「ドキュメントビュー」（ある場合）から離れる必要がないことを暗示します。サーバーは、ユーザーエージェントが独自のインターフェイスに従ってユーザーに成功の何らかの指示を提供し、レスポンスの新しいまたは更新されたメタデータをそのアクティブな表現に適用すると想定します。
たとえば、204 ステータスコードは、保存されているドキュメントがユーザーが編集できるように残っているように、「保存」アクションに対応するドキュメント編集インターフェイスで一般的に使用されます。また、分散バージョン管理システム内など、自動データ転送が普及していることが期待されるインターフェイスでも頻繁に使用されます。
204 レスポンスは、メッセージボディを含むことができないため、ヘッダーフィールドの後の最初の空行で終了します。
204 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.3.6. 205 Reset Content (コンテンツのリセット)
205 (Reset Content) ステータスコードは、サーバーがリクエストを満たし、ユーザーエージェントがリクエストを送信した「ドキュメントビュー」をオリジンサーバーから受信した元の状態にリセットすることを望んでいることを示します。
このレスポンスは、ユーザーがデータ入力をサポートするコンテンツ（フォーム、メモ帳、キャンバスなど）を受信し、そのスペースでデータを入力または操作し、入力されたデータがリクエストで送信され、次にデータ入力メカニズムが次の入力のためにリセットされ、ユーザーが別の入力アクションを簡単に開始できるようにする、一般的なデータ入力ユースケースをサポートすることを目的としています。
205 ステータスコードは追加のコンテンツが提供されないことを意味するため、サーバーは 205 レスポンスでペイロードを生成してはなりません (MUST NOT)。言い換えれば、サーバーは 205 レスポンスに対して次のいずれかを実行しなければなりません (MUST)：a) 値が 0 の Content-Length ヘッダーフィールドを含めることによって、レスポンスの本文の長さがゼロであることを示す；b) 値が chunked の Transfer-Encoding ヘッダーフィールドと、単一のゼロ長チャンクで構成されるメッセージボディを含めることによって、レスポンスのペイロードの長さがゼロであることを示す；または、c) ヘッダーセクションを終了する空行を送信した直後に接続を閉じる。
6.4. Redirection 3xx (リダイレクト 3xx)
3xx (Redirection) クラスのステータスコードは、リクエストを満たすためにユーザーエージェントがさらなるアクションを取る必要があることを示します。Location ヘッダーフィールド（Section 7.1.2）が提供されている場合、特定のステータスコードが理解されていなくても、ユーザーエージェントは Location フィールド値によって参照される URI にリクエストを自動的にリダイレクトしてもよい (MAY) です。Section 4.2.1 で定義されているように、安全であることが知られていないメソッドについては、ユーザーが安全でないリクエストをリダイレクトしたくない可能性があるため、自動リダイレクトは注意して行う必要があります。
いくつかのタイプのリダイレクトがあります：
-
リソースが Location フィールドによって提供される別の URI で利用可能である可能性があることを示すリダイレクト。ステータスコード 301 (Moved Permanently)、302 (Found)、および 307 (Temporary Redirect) の場合。
-
元のリクエストターゲットを表現できるマッチングリソースの選択を提供するリダイレクト。300 (Multiple Choices) ステータスコードの場合。
-
Location フィールドによって識別される別のリソースへのリダイレクト。そのリソースは、リクエストへの間接的なレスポンスを表現できます。303 (See Other) ステータスコードの場合。
-
以前にキャッシュされた結果へのリダイレクト。304 (Not Modified) ステータスコードの場合。
注意： HTTP/1.0 では、ステータスコード 301 (Moved Permanently) と 302 (Found) が最初のタイプのリダイレクトのために定義されました（[RFC1945]、Section 9.3）。初期のユーザーエージェントは、リダイレクトターゲットに適用されるメソッドが元のリクエストと同じかどうか、または GET として書き換えられるかどうかで分かれました。HTTP は元々 301 と 302 に前者のセマンティクスを定義し（CERN での元の実装と一致させるため）、303 (See Other) を後者のセマンティクスと一致させるために定義しましたが、主流の実践は徐々に 301 と 302 にも後者のセマンティクスに収束しました。HTTP/1.1 の最初の改訂版では、分岐した実践の影響を受けることなく前者のセマンティクスを示すために 307 (Temporary Redirect) が追加されました。10年以上経った今でも、ほとんどのユーザーエージェントは 301 と 302 に対してメソッドの書き換えを行います。したがって、この仕様は、元のリクエストが POST の場合、その動作を適合させます。
クライアントは、循環リダイレクト（つまり、「無限」リダイレクトループ）を検出して介入すべきです (SHOULD)。
注意： この仕様の初期バージョンでは、最大5回のリダイレクトが推奨されていました（[RFC2068]、Section 10.3）。コンテンツ開発者は、一部のクライアントがそのような固定制限を実装する可能性があることに注意する必要があります。
6.4.1. 300 Multiple Choices (複数の選択肢)
300 (Multiple Choices) ステータスコードは、ターゲットリソースに複数の表現があり、それぞれが独自のより具体的な識別子を持ち、代替案に関する情報が提供されているため、ユーザー（またはユーザーエージェント）がそれらの識別子の1つ以上にリクエストをリダイレクトすることによって優先表現を選択できることを示します。言い換えれば、サーバーは、ユーザーエージェントがそのニーズに最も適切な表現を選択するために反応的交渉に従事することを望んでいます（Section 3.4.2）。
サーバーに優先選択がある場合、サーバーは優先選択の URI 参照を含む Location ヘッダーフィールドを生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのために Location フィールド値を使用してもよい (MAY) です。
HEAD 以外のリクエストメソッドの場合、サーバーは、ユーザーまたはユーザーエージェントが最も好むものを選択できる表現メタデータと URI 参照のリストを含む 300 レスポンスでペイロードを生成すべきです (SHOULD)。ユーザーエージェントは、提供されたメディアタイプを理解している場合、そのリストから自動的に選択してもよい (MAY) です。自動選択のための特定の形式は、この仕様では定義されていません。HTTP はそのペイロードの定義と直交したままにしようとするためです。実際には、表現は、共有設計またはコンテンツネゴシエーションによって決定される、ユーザーエージェントに受け入れられると信じられる、解析しやすい形式、または一般的に受け入れられるハイパーテキスト形式で提供されます。
300 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
注意： 300 ステータスコードの元の提案では、URI ヘッダーフィールドが代替表現のリストを提供するものとして定義されていたため、200、300、および 406 レスポンスに使用でき、HEAD メソッドへのレスポンスで転送できるはずでした。しかし、デプロイの欠如と構文に関する意見の相違により、URI と Alternates（後続の提案）の両方がこの仕様から削除されました。Link ヘッダーフィールドのセット [RFC5988] を使用してリストを伝達することは可能ですが、それぞれが "alternate" の関係を持ちますが、デプロイメントは鶏と卵の問題です。
6.4.2. 301 Moved Permanently (恒久的に移動)
301 (Moved Permanently) ステータスコードは、ターゲットリソースに新しい恒久的な URI が割り当てられており、このリソースへの将来の参照では、囲まれた URI の1つを使用すべきであることを示します。リンク編集機能を持つクライアントは、可能な限り、有効なリクエスト URI への参照を、サーバーが送信した1つ以上の新しい参照に自動的に再リンクすべきです。
サーバーは、新しい恒久的な URI の優先 URI 参照を含む Location ヘッダーフィールドをレスポンスで生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのために Location フィールド値を使用してもよい (MAY) です。サーバーのレスポンスペイロードには通常、新しい URI へのハイパーリンクを含む短いハイパーテキストノートが含まれます。
注意： 歴史的な理由により、ユーザーエージェントは後続のリクエストのリクエストメソッドを POST から GET に変更してもよい (MAY) です。この動作が望ましくない場合は、代わりに 307 (Temporary Redirect) ステータスコードを使用できます。
301 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.4.3. 302 Found (発見)
302 (Found) ステータスコードは、ターゲットリソースが一時的に別の URI の下に存在することを示します。リダイレクトは時々変更される可能性があるため、クライアントは将来のリクエストには有効なリクエスト URI を引き続き使用すべきです。
サーバーは、別の URI の URI 参照を含む Location ヘッダーフィールドをレスポンスで生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのために Location フィールド値を使用してもよい (MAY) です。サーバーのレスポンスペイロードには通常、別の URI へのハイパーリンクを含む短いハイパーテキストノートが含まれます。
注意： 歴史的な理由により、ユーザーエージェントは後続のリクエストのリクエストメソッドを POST から GET に変更してもよい (MAY) です。この動作が望ましくない場合は、代わりに 307 (Temporary Redirect) ステータスコードを使用できます。
6.4.4. 303 See Other (他を参照)
303 (See Other) ステータスコードは、サーバーがユーザーエージェントを、Location ヘッダーフィールドの URI によって示される別のリソースにリダイレクトしており、それが元のリクエストへの間接的なレスポンスを提供することを意図していることを示します。ユーザーエージェントは、その URI を対象とする検索リクエスト（HTTP を使用している場合は GET または HEAD リクエスト）を実行でき、それもリダイレクトされる可能性があり、最終的な結果を元のリクエストへの答えとして提示できます。Location ヘッダーフィールドの新しい URI は、有効なリクエスト URI と同等であるとは見なされないことに注意してください。
このステータスコードは、任意の HTTP メソッドに適用されます。これは主に、POST アクションの出力をユーザーエージェントを選択されたリソースにリダイレクトできるようにするために使用されます。そうすることで、POST レスポンスに対応する情報を、元のリクエストとは独立して、個別に識別、ブックマーク、およびキャッシュできる形式で提供します。
GET リクエストへの 303 レスポンスは、オリジンサーバーがサーバーによって HTTP 経由で転送できるターゲットリソースの表現を持っていないことを示します。ただし、Location フィールド値は、ターゲットリソースを説明するリソースを参照しているため、その他のリソースに対して検索リクエストを行うと、元のターゲットリソースを表すことを意味することなく、受信者にとって有用な表現が得られる可能性があります。何が表現できるか、どの表現が適切か、何が有用な説明である可能性があるかという質問は、HTTP の範囲外であることに注意してください。
HEAD リクエストへのレスポンスを除き、303 レスポンスの表現には、Location ヘッダーフィールドで提供されているのと同じ URI 参照へのハイパーリンクを含む短いハイパーテキストノートが含まれるべきです。
6.4.5. 305 Use Proxy (プロキシを使用)
305 (Use Proxy) ステータスコードは、この仕様の以前のバージョンで定義されており、現在は非推奨です（付録 B）。
6.4.6. 306 (Unused / 未使用)
306 ステータスコードは、この仕様の以前のバージョンで定義されましたが、もはや使用されず、コードは予約されています。
6.4.7. 307 Temporary Redirect (一時リダイレクト)
307 (Temporary Redirect) ステータスコードは、ターゲットリソースが一時的に別の URI の下に存在し、ユーザーエージェントがその URI への自動リダイレクトを実行する場合、リクエストメソッドを変更してはならない (MUST NOT) ことを示します。リダイレクトは時間の経過とともに変更される可能性があるため、クライアントは将来のリクエストには元の有効なリクエスト URI を引き続き使用すべきです。
サーバーは、別の URI の URI 参照を含む Location ヘッダーフィールドをレスポンスで生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのために Location フィールド値を使用してもよい (MAY) です。サーバーのレスポンスペイロードには通常、別の URI へのハイパーリンクを含む短いハイパーテキストノートが含まれます。
注意： このステータスコードは 302 (Found) に似ていますが、リクエストメソッドを POST から GET に変更することを許可しない点が異なります。この仕様は、301 (Moved Permanently) に相当するものを定義していません（ただし、[RFC7538] はこの目的のためにステータスコード 308 (Permanent Redirect) を定義しています）。
6.5. Client Error 4xx (クライアントエラー 4xx)
4xx (Client Error) クラスのステータスコードは、クライアントがエラーを起こしたように見えることを示します。HEAD リクエストへの応答を除き、サーバーは、エラー状況の説明と、それが一時的な状態か恒久的な状態かを含む表現を送信すべきです (SHOULD)。これらのステータスコードは、任意のリクエストメソッドに適用されます。ユーザーエージェントは、含まれている表現をユーザーに表示すべきです (SHOULD)。
6.5.1. 400 Bad Request (不正なリクエスト)
400 (Bad Request) ステータスコードは、クライアントエラーと認識されるもの（たとえば、不正な形式のリクエスト構文、無効なリクエストメッセージのフレーミング、または欺瞞的なリクエストルーティング）のために、サーバーがリクエストを処理できないか、処理しないことを示します。
6.5.2. 402 Payment Required (支払いが必要)
402 (Payment Required) ステータスコードは、将来の使用のために予約されています。
6.5.3. 403 Forbidden (禁止)
403 (Forbidden) ステータスコードは、サーバーがリクエストを理解したが、それを承認することを拒否していることを示します。リクエストが禁止された理由を公開したいサーバーは、レスポンスペイロード（ある場合）でその理由を説明できます。
リクエストで認証資格情報が提供された場合、サーバーはそれらがアクセスを許可するのに不十分であると考えています。クライアントは、同じ資格情報でリクエストを自動的に繰り返すべきではありません (SHOULD NOT)。クライアントは、新しいまたは異なる資格情報でリクエストを繰り返してもよい (MAY) です。ただし、資格情報に関係のない理由でリクエストが禁止される場合があります。
禁止されたターゲットリソースの現在の存在を「隠す」ことを望むオリジンサーバーは、代わりにステータスコード 404 (Not Found) で応答してもよい (MAY) です。
6.5.4. 404 Not Found (未検出)
404 (Not Found) ステータスコードは、オリジンサーバーがターゲットリソースの現在の表現を見つけられなかったか、それが存在することを開示する意思がないことを示します。404 ステータスコードは、この表現の欠如が一時的か恒久的かを示しません。オリジンサーバーが（おそらく何らかの構成可能な手段を通じて）条件が恒久的である可能性が高いことを知っている場合は、404 よりも 410 (Gone) ステータスコードが推奨されます。
404 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.5.5. 405 Method Not Allowed (メソッド不許可)
405 (Method Not Allowed) ステータスコードは、リクエスト行で受信されたメソッドがオリジンサーバーによって認識されているが、ターゲットリソースによってサポートされていないことを示します。オリジンサーバーは、ターゲットリソースの現在サポートされているメソッドのリストを含む Allow ヘッダーフィールドを 405 レスポンスで生成しなければなりません (MUST)。
405 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.5.6. 406 Not Acceptable (受理不可)
406 (Not Acceptable) ステータスコードは、リクエストで受信されたプロアクティブネゴシエーションヘッダーフィールド（Section 5.3）に従って、ターゲットリソースにユーザーエージェントが受け入れ可能な現在の表現がなく、サーバーがデフォルトの表現を提供する意思がないことを示します。
サーバーは、利用可能な表現特性と対応するリソース識別子のリストを含むペイロードを生成すべきです (SHOULD)。ユーザーまたはユーザーエージェントは、そこから最も適切なものを選択できます。ユーザーエージェントは、そのリストから最も適切な選択を自動的に行ってもよい (MAY) です。ただし、この仕様では、Section 6.4.1 で説明されているように、そのような自動選択のための標準を定義していません。
6.5.7. 408 Request Timeout (リクエストタイムアウト)
408 (Request Timeout) ステータスコードは、サーバーが待機する準備ができていた時間内に完全なリクエストメッセージを受信しなかったことを示します。サーバーは、レスポンスに "close" 接続オプション（[RFC7230] の Section 6.1）を送信すべきです (SHOULD)。408 は、サーバーが待機を続けるのではなく接続を閉じることを決定したことを意味するためです。クライアントに転送中の未解決のリクエストがある場合、クライアントはそのリクエストを新しい接続で繰り返してもよい (MAY) です。
6.5.8. 409 Conflict (競合)
409 (Conflict) ステータスコードは、ターゲットリソースの現在の状態との競合のために、リクエストを完了できなかったことを示します。このコードは、ユーザーが競合を解決してリクエストを再送信できる可能性がある状況で使用されます。サーバーは、ユーザーが競合の原因を認識するのに十分な情報を含むペイロードを生成すべきです (SHOULD)。
競合は、PUT リクエストへの応答で最も発生しやすいです。たとえば、バージョン管理が使用されており、PUT されている表現に、以前の（サードパーティの）リクエストによって行われた変更と競合するリソースへの変更が含まれている場合、オリジンサーバーは 409 レスポンスを使用して、リクエストを完了できないことを示す可能性があります。この場合、レスポンス表現には、リビジョン履歴に基づいて差分をマージするのに役立つ情報が含まれる可能性があります。
6.5.9. 410 Gone (消失)
410 (Gone) ステータスコードは、ターゲットリソースへのアクセスがオリジンサーバーで利用できなくなり、この条件が恒久的である可能性が高いことを示します。オリジンサーバーが条件が恒久的であるかどうかを知らない、または判断する機能がない場合は、代わりにステータスコード 404 (Not Found) を使用すべきです。
410 レスポンスは主に、リソースが意図的に利用できなくなり、サーバーの所有者がそのリソースへのリモートリンクを削除することを望んでいることを受信者に通知することによって、Web メンテナンスのタスクを支援することを目的としています。このようなイベントは、期間限定のプロモーションサービスや、オリジンサーバーのサイトに関連付けられなくなった個人に属するリソースで一般的です。恒久的に利用できないすべてのリソースを "gone" としてマークしたり、マークを任意の期間保持したりする必要はありません。これはサーバーの所有者の裁量に委ねられています。
410 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.5.10. 411 Length Required (長さが必要)
411 (Length Required) ステータスコードは、サーバーが定義された Content-Length（[RFC7230] の Section 3.3.2）なしでリクエストを受け入れることを拒否していることを示します。クライアントは、リクエストメッセージのメッセージボディの長さを含む有効な Content-Length ヘッダーフィールドを追加した場合、リクエストを繰り返してもよい (MAY) です。
6.5.11. 413 Payload Too Large (ペイロードが大きすぎる)
413 (Payload Too Large) ステータスコードは、リクエストペイロードがサーバーが喜んで処理できる、または処理できるサイズよりも大きいため、サーバーがリクエストの処理を拒否していることを示します。サーバーは、クライアントがリクエストを続行するのを防ぐために接続を閉じてもよい (MAY) です。
条件が一時的である場合、サーバーは、それが一時的であることと、クライアントがいつ再試行してもよい (MAY) かを示すために Retry-After ヘッダーフィールドを生成すべきです (SHOULD)。
6.5.12. 414 URI Too Long (URI が長すぎる)
414 (URI Too Long) ステータスコードは、リクエストターゲット（[RFC7230] の Section 5.3）がサーバーが解釈する意思のある長さよりも長いため、サーバーがリクエストのサービスを拒否していることを示します。このまれな条件は、クライアントが POST リクエストを長いクエリ情報を含む GET リクエストに不適切に変換した場合、クライアントがリダイレクトの「ブラックホール」（たとえば、自身のサフィックスを指すリダイレクトされた URI プレフィックス）に陥った場合、またはサーバーがセキュリティホールを悪用しようとするクライアントの攻撃を受けている場合にのみ発生する可能性があります。
414 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.5.13. 415 Unsupported Media Type (サポートされていないメディアタイプ)
415 (Unsupported Media Type) ステータスコードは、ペイロードがターゲットリソースのこのメソッドでサポートされていない形式であるため、オリジンサーバーがリクエストのサービスを拒否していることを示します。形式の問題は、リクエストで示された Content-Type または Content-Encoding、またはデータを直接検査した結果による可能性があります。
6.5.14. 417 Expectation Failed (期待失敗)
417 (Expectation Failed) ステータスコードは、リクエストの Expect ヘッダーフィールド（Section 5.1.1）で与えられた期待が、少なくとも1つのインバウンドサーバーによって満たされなかったことを示します。
6.5.15. 426 Upgrade Required (アップグレードが必要)
426 (Upgrade Required) ステータスコードは、サーバーが現在のプロトコルを使用してリクエストを実行することを拒否しているが、クライアントが別のプロトコルにアップグレードした後であればそうする意思がある可能性があることを示します。サーバーは、必要なプロトコルを示すために 426 レスポンスで Upgrade ヘッダーフィールドを送信しなければなりません (MUST)（[RFC7230] の Section 6.7）。
例：
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol.
6.6. Server Error 5xx (サーバーエラー 5xx)
5xx (Server Error) クラスのステータスコードは、サーバーがエラーを起こしたか、要求されたメソッドを実行できないことを認識していることを示します。HEAD リクエストへの応答を除き、サーバーは、エラー状況の説明と、それが一時的な状態か恒久的な状態かを含む表現を送信すべきです (SHOULD)。ユーザーエージェントは、含まれている表現をユーザーに表示すべきです (SHOULD)。これらのステータスコードは、任意のリクエストメソッドに適用されます。
6.6.1. 500 Internal Server Error (内部サーバーエラー)
500 (Internal Server Error) ステータスコードは、サーバーがリクエストの実行を妨げる予期しない条件に遭遇したことを示します。
6.6.2. 501 Not Implemented (未実装)
501 (Not Implemented) ステータスコードは、サーバーがリクエストを満たすために必要な機能をサポートしていないことを示します。これは、サーバーがリクエストメソッドを認識せず、どのリソースに対してもそれをサポートできない場合の適切なレスポンスです。
501 レスポンスは、デフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御によって特に示されない限り（[RFC7234] の Section 4.2.2 を参照）。
6.6.3. 502 Bad Gateway (不正なゲートウェイ)
502 (Bad Gateway) ステータスコードは、ゲートウェイまたはプロキシとして機能しているサーバーが、リクエストを満たそうとしてアクセスしたインバウンドサーバーから無効なレスポンスを受信したことを示します。
6.6.4. 503 Service Unavailable (サービス利用不可)
503 (Service Unavailable) ステータスコードは、一時的な過負荷または予定されたメンテナンスのために、サーバーが現在リクエストを処理できないことを示します。これは、ある程度の遅延の後に緩和される可能性があります。サーバーは、クライアントがリクエストを再試行する前に待つ適切な時間を提案するために Retry-After ヘッダーフィールド（Section 7.1.3）を送信してもよい (MAY) です。
注意： 503 ステータスコードの存在は、サーバーが過負荷になったときにそれを使用しなければならないことを意味するものではありません。一部のサーバーは、単に接続を拒否する場合があります。
6.6.5. 504 Gateway Timeout (ゲートウェイタイムアウト)
504 (Gateway Timeout) ステータスコードは、ゲートウェイまたはプロキシとして機能しているサーバーが、リクエストを完了するためにアクセスする必要があった上流サーバーから、タイムリーなレスポンスを受信しなかったことを示します。
6.6.6. 505 HTTP Version Not Supported (HTTP バージョン非対応)
505 (HTTP Version Not Supported) ステータスコードは、サーバーがリクエストメッセージで使用された HTTP のメジャーバージョンをサポートしていない、またはサポートを拒否していることを示します。サーバーは、[RFC7230] の Section 2.6 で説明されているように、このエラーメッセージを除いて、クライアントと同じメジャーバージョンを使用してリクエストを完了することができない、または望まないことを示しています。サーバーは、そのバージョンがサポートされていない理由と、そのサーバーでサポートされている他のプロトコルについての説明を含む表現を生成すべきです (SHOULD)。