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

15. Status Codes (ステータスコード)

15. Status Codes (ステータスコード)​

レスポンスのステータスコードは、リクエストの結果とレスポンスのセマンティクスを記述する3桁の整数コードであり、リクエストが成功したかどうか、および含まれるコンテンツ（ある場合）を示します。すべての有効なステータスコードは、100から599までの範囲内にあります。

ステータスコードの最初の桁は、レスポンスのクラスを定義します。最後の2桁には分類の役割はありません。最初の桁には5つの値があります：

  • 1xx (Informational): リクエストが受信され、処理を継続中

  • 2xx (Successful): リクエストが正常に受信、理解、受け入れられた

  • 3xx (Redirection): リクエストを完了するために、さらなるアクションが必要

  • 4xx (Client Error): リクエストに不正な構文が含まれているか、実行できない

  • 5xx (Server Error): サーバーが明らかに有効なリクエストの実行に失敗した

HTTPステータスコードは拡張可能です。クライアントは、登録されているすべてのステータスコードの意味を理解する必要はありませんが、そのような理解は明らかに望ましいです。ただし、クライアントは、最初の桁で示されるように、任意のステータスコードのクラスを理解しなければならず (MUST)、認識できないステータスコードを、そのクラスのx00ステータスコードと同等のものとして扱わなければなりません (MUST)。

例えば、クライアントが認識できないステータスコード471を受信した場合、最初の桁からリクエストに何か問題があったことがわかり、400 (Bad Request) ステータスコードを受信したかのようにレスポンスを扱うことができます。レスポンスメッセージには通常、ステータスを説明する表現が含まれています。

範囲100..599外の値は無効です。実装は、非HTTPステータスの内部通信（例：ライブラリエラー）のために、その範囲外の3桁の整数値（すなわち、600..999）を使用することがよくあります。無効なステータスコードを含むレスポンスを受信したクライアントは、5xx (Server Error) ステータスコードを持つかのようにレスポンスを処理すべきです (SHOULD)。

単一のリクエストには、複数の関連するレスポンスが存在する可能性があります：「informational」(1xx) 範囲のステータスコードを持つ0個以上の「interim」(非最終) レスポンス、その後に他の範囲のステータスコードを持つ正確に1つの「final」レスポンスが続きます。

15.1. Overview of Status Codes (ステータスコード概要)​

以下にリストされているステータスコードは、この仕様で定義されています。ここにリストされている理由フレーズは推奨にすぎません - ローカルの同等物に置き換えることも、完全に省略することもでき、プロトコルに影響を与えません。

ヒューリスティックにキャッシュ可能として定義されているステータスコード（例えば、この仕様では200、203、204、206、300、301、308、404、405、410、414、および501）を持つレスポンスは、メソッド定義または明示的なキャッシュ制御 [CACHING] によって特に示されない限り、キャッシュによってヒューリスティック有効期限で再利用できます。他のすべてのステータスコードは、ヒューリスティックにキャッシュ可能ではありません。

この仕様の範囲外の追加のステータスコードが、HTTPで使用するために指定されています。そのようなステータスコードはすべて、セクション16.2で説明されているように、「Hypertext Transfer Protocol (HTTP) Status Code Registry」内に登録されるべきです (ought to)。

15.2. Informational 1xx (情報レスポンス)​

1xx (Informational) クラスのステータスコードは、要求されたアクションを完了し、最終レスポンスを送信する前に、接続ステータスまたはリクエストの進行状況を通信するための中間レスポンスを示します。HTTP/1.0では1xxステータスコードが定義されていないため、サーバーはHTTP/1.0クライアントに1xxレスポンスを送信してはなりません (MUST NOT)。

1xxレスポンスは、ヘッダーセクションの終わりで終了します。コンテンツまたはトレーラーを含めることはできません。

クライアントは、最終レスポンスの前に受信した1つ以上の1xxレスポンスを解析できなければなりません (MUST)、たとえクライアントが1つを期待していなくても。ユーザーエージェントは、予期しない1xxレスポンスを無視してもかまいません (MAY)。

プロキシは、プロキシ自体が1xxレスポンスの生成を要求した場合を除き、1xxレスポンスを転送しなければなりません (MUST)。例えば、プロキシがリクエストを転送する際に「Expect: 100-continue」ヘッダーフィールドを追加した場合、対応する100 (Continue) レスポンスを転送する必要はありません。

15.2.1. 100 Continue​

100 (Continue) ステータスコードは、リクエストの最初の部分が受信され、まだサーバーによって拒否されていないことを示します。サーバーは、リクエストが完全に受信され、処理された後に最終レスポンスを送信する意図を持っています。

リクエストに100-continue期待を含むExpectヘッダーフィールドが含まれている場合、100レスポンスは、セクション10.1.1で説明されているように、サーバーがリクエストコンテンツを受信したいことを示します。クライアントは、リクエストの送信を継続し、100レスポンスを破棄すべきです (ought to)。

リクエストに100-continue期待を含むExpectヘッダーフィールドが含まれていなかった場合、クライアントはこの中間レスポンスを単に破棄できます。

15.2.2. 101 Switching Protocols (プロトコル切り替え)​

101 (Switching Protocols) ステータスコードは、サーバーがクライアントのリクエストを理解し、Upgradeヘッダーフィールド (セクション7.8) を介して、この接続で使用されているアプリケーションプロトコルの変更に同意する意思があることを示します。サーバーは、このレスポンス後に有効になるプロトコルを示すUpgradeヘッダーフィールドをレスポンスに生成しなければなりません (MUST)。

サーバーは、それが有利である場合にのみプロトコルの切り替えに同意すると想定されます。例えば、新しいバージョンのHTTPへの切り替えは古いバージョンよりも有利である可能性があり、そのような機能を使用するリソースを配信する場合、リアルタイムで同期的なプロトコルへの切り替えが有利である可能性があります。

15.3. Successful 2xx (成功)​

2xx (Successful) クラスのステータスコードは、クライアントのリクエストが正常に受信、理解、受け入れられたことを示します。

15.3.1. 200 OK​

200 (OK) ステータスコードは、リクエストが成功したことを示します。200レスポンスで送信されるコンテンツは、リクエストメソッドに依存します。この仕様で定義されているメソッドの場合、コンテンツの意図する意味は次のように要約できます：

| Request Method | Response content is a representation of: | | GET | the target resource | | HEAD | the target resource, like GET, but without | | | transferring the representation data | | POST | the status of, or results obtained from, | | | the action | | PUT, DELETE | the status of the action | | OPTIONS | communication options for the target | | | resource | | TRACE | the request message as received by the | | | server returning the trace |

表 6

CONNECTへのレスポンスを除き、200レスポンスは、メッセージフレーミングがコンテンツの長さが0であることを明示的に示さない限り、メッセージコンテンツを含むことが期待されます。成功時にコンテンツがないことを示すリクエストの何らかの側面がある場合、オリジンサーバーは代わりに204 (No Content) レスポンスを送信すべきです (ought to)。CONNECTの場合、成功の結果はトンネルであり、200レスポンスヘッダーセクションの直後に開始されるため、コンテンツはありません。

200レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

GETまたはHEADへの200レスポンスでは、オリジンサーバーは、選択された表現の利用可能なバリデーターフィールド（セクション8.8）を送信すべきであり (SHOULD)、強力なエンティティタグとLast-Modified日付の両方が優先されます。

状態変更メソッドへの200レスポンスでは、レスポンスで送信されたバリデーターフィールド（セクション8.8）は、リクエストセマンティクスを正常に適用した結果として形成された新しい表現の現在のバリデーターを伝えます。PUTメソッド（セクション9.3.4）には、そのようなバリデーターの送信を妨げる可能性のある追加要件があることに注意してください。

15.3.2. 201 Created (作成完了)​

201 (Created) ステータスコードは、リクエストが満たされ、1つ以上の新しいリソースが作成されたことを示します。リクエストによって作成された主要なリソースは、レスポンス内のLocationヘッダーフィールド、またはLocationヘッダーフィールドが受信されない場合はターゲットURIによって識別されます。

201レスポンスコンテンツは、通常、作成されたリソースを記述し、リンクします。レスポンスで送信されたバリデーターフィールド（セクション8.8）は、リクエストによって作成された新しい表現の現在のバリデーターを伝えます。PUTメソッド（セクション9.3.4）には、そのようなバリデーターの送信を妨げる可能性のある追加要件があることに注意してください。

15.3.3. 202 Accepted (受理)​

202 (Accepted) ステータスコードは、リクエストが処理のために受け入れられたが、処理が完了していないことを示します。リクエストは、処理が実際に行われるときに許可されない可能性があるため、最終的に実行される場合と実行されない場合があります。HTTPには、非同期操作からステータスコードを再送信する機能はありません。

202レスポンスは意図的に非コミットです。その目的は、サーバーが他のプロセス（おそらく1日に1回しか実行されないバッチ指向のプロセス）のリクエストを受け入れることを許可することであり、ユーザーエージェントのサーバーへの接続がプロセスが完了するまで持続することを要求しません。このレスポンスで送信される表現は、リクエストの現在のステータスを記述し、ユーザーにリクエストがいつ満たされるかの推定を提供できるステータスモニターへのポイント（または埋め込み）をすべきです (ought to)。

15.3.4. 203 Non-Authoritative Information (非権威情報)​

203 (Non-Authoritative Information) ステータスコードは、リクエストが成功したが、同封されたコンテンツがオリジンサーバーの200 (OK) レスポンスのものから変換プロキシ（セクション7.7）によって変更されていることを示します。このステータスコードにより、プロキシは変換が適用されたことを受信者に通知できます。これは、コンテンツに関する後の決定に影響を与える可能性があるためです。例えば、コンテンツの将来のキャッシュ検証リクエストは、同じリクエストパス（同じプロキシ経由）でのみ適用可能な場合があります。

203レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.3.5. 204 No Content (コンテンツなし)​

204 (No Content) ステータスコードは、サーバーがリクエストを正常に満たし、レスポンスコンテンツで送信する追加のコンテンツがないことを示します。レスポンスヘッダーフィールドのメタデータは、要求されたアクションが適用された後のターゲットリソースとその選択された表現を参照します。

例えば、PUTリクエストへのレスポンスとして204ステータスコードが受信され、レスポンスにETagフィールドが含まれている場合、PUTは成功し、ETagフィールド値にはそのターゲットリソースの新しい表現のエンティティタグが含まれています。

204レスポンスにより、サーバーは、アクションがターゲットリソースに正常に適用されたことを示すことができますが、ユーザーエージェントが現在の「ドキュメントビュー」（ある場合）から離れる必要がないことを暗示します。サーバーは、ユーザーエージェントが独自のインターフェースに従ってユーザーに成功を何らかの形で示し、レスポンス内の新しいまたは更新されたメタデータをアクティブな表現に適用すると想定しています。

例えば、204ステータスコードは、「保存」アクションに対応するドキュメント編集インターフェースで一般的に使用され、保存されているドキュメントがユーザーが編集できる状態で利用可能なままになります。また、分散バージョン管理システム内など、自動データ転送が一般的であることが期待されるインターフェースでも頻繁に使用されます。

204レスポンスは、ヘッダーセクションの終わりで終了します。コンテンツまたはトレーラーを含めることはできません。

204レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.3.6. 205 Reset Content (コンテンツのリセット)​

205 (Reset Content) ステータスコードは、サーバーがリクエストを満たし、ユーザーエージェントがリクエストを送信させた「ドキュメントビュー」を、オリジンサーバーから受信した元の状態にリセットすることを望んでいることを示します。

このレスポンスは、ユーザーがデータ入力をサポートするコンテンツ（フォーム、メモ帳、キャンバスなど）を受信し、そのスペースでデータを入力または操作し、入力されたデータをリクエストで送信させ、その後、ユーザーが別の入力アクションを簡単に開始できるように、次のエントリのためにデータ入力メカニズムがリセットされるという一般的なデータ入力ユースケースをサポートすることを目的としています。

205ステータスコードは、追加のコンテンツが提供されないことを意味するため、サーバーは205レスポンスでコンテンツを生成してはなりません (MUST NOT)。

15.3.7. 206 Partial Content (部分コンテンツ)​

206 (Partial Content) ステータスコードは、サーバーが選択された表現の1つ以上の部分を転送することにより、ターゲットリソースの範囲リクエストを正常に満たしていることを示します。

範囲リクエスト（セクション14）をサポートするサーバーは、通常、要求されたすべての範囲を満たそうとします。より少ないデータを送信すると、残りのデータに対する別のクライアントリクエストが発生する可能性が高いためです。ただし、サーバーは、一時的な利用不可、キャッシュ効率、負荷分散などの独自の理由により、要求されたデータのサブセットのみを送信したい場合があります。206レスポンスは自己記述的であるため、クライアントは範囲リクエストを部分的にしか満たさないレスポンスを理解できます。

クライアントは、206レスポンスのContent-TypeおよびContent-Rangeフィールドを検査して、どの部分が含まれているか、および追加のリクエストが必要かどうかを判断しなければなりません (MUST)。

206レスポンスを生成するサーバーは、以下のサブセクションで要求される場合に加えて、同じリクエストへの200 (OK) レスポンスで送信されていたであろうフィールドの場合、次のヘッダーフィールドを生成しなければなりません (MUST)：Date、Cache-Control、ETag、Expires、Content-Location、およびVary。

206レスポンスに存在するContent-Lengthヘッダーフィールドは、このメッセージのコンテンツのオクテット数を示します。これは通常、選択された表現の完全な長さではありません。各Content-Rangeヘッダーフィールドには、選択された表現の完全な長さに関する情報が含まれています。

If-Rangeヘッダーフィールドを含むリクエストへの206レスポンスを生成する送信者は、クライアントがすでにそれらのヘッダーフィールドを含む以前のレスポンスを持っているため、要求されるもの以外の他の表現ヘッダーフィールドを生成すべきではありません (SHOULD NOT)。それ以外の場合、送信者は、同じリクエストへの200 (OK) レスポンスで送信されていたであろうすべての表現ヘッダーフィールドを生成しなければなりません (MUST)。

206レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.3.7.1. Single Part (単一部分)​

単一の部分が転送される場合、206レスポンスを生成するサーバーは、選択された表現のどの範囲が含まれているかを記述するContent-Rangeヘッダーフィールドと、その範囲で構成されるコンテンツを生成しなければなりません (MUST)。例：

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...
15.3.7.2. Multiple Parts (複数部分)​

複数の部分が転送される場合、206レスポンスを生成するサーバーは、セクション14.6で定義されている「multipart/byteranges」コンテンツと、「multipart/byteranges」メディアタイプとその必須のboundaryパラメータを含むContent-Typeヘッダーフィールドを生成しなければなりません (MUST)。単一部分レスポンスとの混同を避けるため、サーバーは、複数部分レスポンスのHTTPヘッダーセクションでContent-Rangeヘッダーフィールドを生成してはなりません (MUST NOT)（このフィールドは代わりに各部分で送信されます）。

マルチパートコンテンツの各ボディ部分のヘッダー領域内で、サーバーは、そのボディ部分に含まれる範囲に対応するContent-Rangeヘッダーフィールドを生成しなければなりません (MUST)。選択された表現が200 (OK) レスポンスでContent-Typeヘッダーフィールドを持っていた場合、サーバーは各ボディ部分のヘッダー領域で同じContent-Typeヘッダーフィールドを生成すべきです (SHOULD)。例：

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

複数の範囲が要求された場合、サーバーは、受信したRangeヘッダーフィールドで対応するrange-specが表示された順序に関係なく、重複する範囲、または複数の部分を送信するオーバーヘッドよりも小さいギャップで区切られた範囲を結合してもかまいません (MAY)。「multipart/byteranges」の各部分間の典型的なオーバーヘッドは、選択された表現のメディアタイプと選択されたboundaryパラメータの長さに応じて約80バイトであるため、多くの小さな不連続部分を転送することは、選択された表現全体を転送するよりも効率が悪い場合があります。

クライアントが複数の部分を要求しないため、単一の範囲へのリクエストに対してマルチパートレスポンスを生成してはなりません (MUST NOT)。ただし、複数の範囲が要求され、結合後に1つの範囲のみが満足可能であると判明した場合、または1つの範囲のみが残った場合、サーバーは単一のボディ部分のみを持つ「multipart/byteranges」レスポンスを生成してもかまいません (MAY)。「multipart/byteranges」レスポンスを処理できないクライアントは、複数の範囲を要求するリクエストを生成してはなりません (MUST NOT)。

マルチパートレスポンスを生成するサーバーは、満足できないと判断された範囲、または他の範囲に結合された範囲を除いて、受信したRangeヘッダーフィールドで対応するrange-specが表示されたのと同じ順序で部分を送信すべきです (SHOULD)。マルチパートレスポンスを受信するクライアントは、各ボディ部分に存在するContent-Rangeヘッダーフィールドを検査して、そのボディ部分に含まれる範囲を判断しなければなりません (MUST)。クライアントは、要求したのと同じ範囲、または要求したのと同じ順序で範囲を受信することに依存できません。

15.3.7.3. Combining Parts (部分の結合)​

接続が早期に閉じられた場合、またはリクエストが1つ以上のRange指定を使用した場合、レスポンスは表現のサブ範囲のみを転送する可能性があります。そのようないくつかの転送の後、クライアントは同じ表現のいくつかの範囲を受信した可能性があります。これらの範囲は、すべてが同じ強力なバリデーター（セクション8.8.1）を共通に持っている場合にのみ、安全に結合できます。

ターゲットリソースへのGETリクエストに対する複数の部分レスポンスを受信したクライアントは、同じ強力なバリデーターを共有している場合、それらのレスポンスをより大きな連続範囲に結合してもかまいません (MAY)。

最新のレスポンスが不完全な200 (OK) レスポンスである場合、そのレスポンスのヘッダーフィールドが結合レスポンスに使用され、一致する保存されたレスポンスのヘッダーフィールドを置き換えます。

最新のレスポンスが206 (Partial Content) レスポンスであり、一致する保存されたレスポンスの少なくとも1つが200 (OK) である場合、結合されたレスポンスヘッダーフィールドは、最新の200レスポンスのヘッダーフィールドで構成されます。一致する保存されたレスポンスがすべて206レスポンスである場合、最新のヘッダーフィールドを持つ保存されたレスポンスが結合レスポンスのヘッダーフィールドのソースとして使用されますが、クライアントは、Content-Range以外の新しいレスポンスで提供される他のヘッダーフィールドを使用して、保存されたレスポンス内の対応するヘッダーフィールドのすべてのインスタンスを置き換えなければなりません (MUST)。

結合されたレスポンスコンテンツは、新しいレスポンスとすべての一致する保存されたレスポンス内の部分コンテンツ範囲の和集合で構成されます。和集合が表現の全範囲で構成される場合、クライアントは、完全な長さを反映するContent-Lengthヘッダーフィールドを含む完全な200 (OK) レスポンスであるかのように、結合されたレスポンスを処理しなければなりません (MUST)。それ以外の場合、クライアントは、次のいずれかとして連続範囲のセットを処理しなければなりません (MUST)：結合されたレスポンスが表現のプレフィックスである場合は不完全な200 (OK) レスポンス、「multipart/byteranges」コンテンツを含む単一の206 (Partial Content) レスポンス、またはContent-Rangeヘッダーフィールドによって示される1つの連続範囲をそれぞれ持つ複数の206 (Partial Content) レスポンス。

15.4. Redirection 3xx (リダイレクション)​

3xx (Redirection) クラスのステータスコードは、リクエストを満たすためにユーザーエージェントによってさらなるアクションが必要であることを示します。いくつかのタイプのリダイレクトがあります：

  1. このリソースが、301 (Moved Permanently)、302 (Found)、307 (Temporary Redirect)、および308 (Permanent Redirect) のステータスコードのように、Locationヘッダーフィールドによって提供される別のURIで利用可能である可能性があることを示すリダイレクト。

  2. 300 (Multiple Choices) ステータスコードのように、このリソースを表現できる一致するリソースの選択肢を提供するリダイレクト。

  3. 303 (See Other) ステータスコードのように、リクエストへの間接的なレスポンスを表現できる、Locationヘッダーフィールドによって識別される別のリソースへのリダイレクト。

  4. 304 (Not Modified) ステータスコードのように、以前に保存された結果へのリダイレクト。

| 注意: HTTP/1.0では、ステータスコード301 (Moved Permanently) | および302 (Found) は、CERNでの実装に合わせて、元々メソッド保持 | ([HTTP/1.0]、セクション9.3) として定義されていました。303 (See Other) | は、メソッドをGETに変更するリダイレクト用に定義されました。しかし、 | 初期のユーザーエージェントは、POSTリクエストをPOSTとしてリダイレクト | するか（当時の現行仕様に従って）、またはGETとしてリダイレクトするか | （別のサイトにリダイレクトされる場合の安全な代替手段）で分かれました。 | 一般的な慣行は最終的にメソッドをGETに変更することに収束しました。 | 307 (Temporary Redirect) および308 (Permanent Redirect) [RFC7538] | は、メソッド保持リダイレクトを明確に示すために後で追加され、ステータス | コード301および302は、POSTリクエストをGETとしてリダイレクトできる | ように調整されました。

Locationヘッダーフィールド（セクション10.2.2）が提供される場合、ユーザーエージェントは、特定のステータスコードが理解されていなくても、Locationフィールド値によって参照されるURIにリクエストを自動的にリダイレクトしてもかまいません (MAY)。セクション9.2.1で定義されているように安全であることが知られていないメソッドの場合、ユーザーが安全でないリクエストをリダイレクトすることを望まない可能性があるため、自動リダイレクトは注意して行う必要があります。

リダイレクトされたリクエストを自動的に追跡する場合、ユーザーエージェントは、次の変更を加えて元のリクエストメッセージを再送信すべきです (SHOULD)：

  1. ターゲットURIを、元のリクエストのターゲットURIに対して相対的に解決した後、リダイレクトレスポンスのLocationヘッダーフィールド値によって参照されるURIに置き換えます。

  2. 実装によって自動的に生成されたヘッダーフィールドを削除し、新しいリクエストに適切な更新された値に置き換えます。これには次が含まれます：

    1. 接続固有のヘッダーフィールド（セクション7.6.1を参照）、

    2. クライアントのプロキシ構成に固有のヘッダーフィールド（Proxy-Authorizationを含むがこれに限定されない）、

    3. オリジン固有のヘッダーフィールド（ある場合）（Hostを含むがこれに限定されない）、

    4. 実装のキャッシュによって追加された検証ヘッダーフィールド（例：If-None-Match、If-Modified-Since）、および

    5. リソース固有のヘッダーフィールド（Referer、Origin、Authorization、およびCookieを含むがこれに限定されない）。

  3. セキュリティ上の影響がある場合、実装によって自動的に生成されなかったヘッダーフィールド（つまり、呼び出しコンテキストによって追加されたためにリクエストに存在するもの）の削除を検討します。これには、AuthorizationおよびCookieが含まれますが、これらに限定されません。

  4. 該当する場合、リダイレクトステータスコードのセマンティクスに従ってリクエストメソッドを変更します。

  5. リクエストメソッドがGETまたはHEADに変更された場合、Content-Encoding、Content-Language、Content-Location、Content-Type、Content-Length、Digest、Last-Modifiedを含む（がこれらに限定されない）コンテンツ固有のヘッダーフィールドを削除します。

クライアントは、循環リダイレクト（つまり、「無限」リダイレクトループ）を検出し、介入すべきです (SHOULD)。

| 注意: この仕様の以前のバージョンでは、最大5つのリダイレクトを | 推奨していました（[RFC2068]、セクション10.3）。コンテンツ開発者は、 | 一部のクライアントがそのような固定制限を実装している可能性があることを | 認識する必要があります。

15.4.1. 300 Multiple Choices (複数の選択肢)​

300 (Multiple Choices) ステータスコードは、ターゲットリソースに複数の表現があり、それぞれに独自のより具体的な識別子があり、ユーザー（またはユーザーエージェント）がそれらの識別子の1つ以上にリクエストをリダイレクトすることによって優先表現を選択できるように、代替案に関する情報が提供されていることを示します。つまり、サーバーは、ユーザーエージェントが、そのニーズに最も適した表現を選択するためにリアクティブネゴシエーション（セクション12）に従事することを望んでいます。

サーバーに優先選択肢がある場合、サーバーは、優先選択肢のURI参照を含むLocationヘッダーフィールドを生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもかまいません (MAY)。

HEAD以外のリクエストメソッドの場合、サーバーは、ユーザーまたはユーザーエージェントが最も好ましいものを選択できる表現メタデータとURI参照のリストを含む300レスポンスにコンテンツを生成すべきです (SHOULD)。ユーザーエージェントは、提供されたメディアタイプを理解している場合、そのリストから自動的に選択してもかまいません (MAY)。HTTPはコンテンツの定義に対して直交したままにしようとするため、自動選択の特定の形式はこの仕様では定義されていません。実際には、表現は、共有設計またはコンテンツネゴシエーションによって決定されるように、ユーザーエージェントに受け入れ可能であると考えられる解析しやすい形式、または一般的に受け入れられているハイパーテキスト形式で提供されます。

300レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

| 注意: 300ステータスコードの元の提案では、URIヘッダーフィールドが | 代替表現のリストを提供するものとして定義されており、200、300、および | 406レスポンスで使用可能で、HEADメソッドへのレスポンスで転送される | ものでした。しかし、デプロイメントの欠如と構文に関する意見の相違に | より、URIとAlternates（後続の提案）の両方がこの仕様から削除されました。 | Linkヘッダーフィールド値 [RFC8288] としてリストを通信することは可能 | ですが、そのメンバーは「alternate」の関係を持ちますが、デプロイメント | は鶏と卵の問題です。

15.4.2. 301 Moved Permanently (恒久的な移動)​

301 (Moved Permanently) ステータスコードは、ターゲットリソースに新しい恒久的なURIが割り当てられており、このリソースへの将来の参照は、同封されたURIの1つを使用すべきであることを示します。サーバーは、リンク編集機能を持つユーザーエージェントが、ターゲットURIへの参照を、サーバーによって送信された新しい参照の1つで恒久的に置き換えることができることを示唆しています。ただし、ユーザーエージェントが参照を積極的に編集している場合（例：コンテンツの作成に従事している）、接続が保護されており、オリジンサーバーが編集されているコンテンツの信頼できる権限である場合を除き、この提案は通常無視されます。

サーバーは、新しい恒久的なURIの優先URI参照を含むLocationヘッダーフィールドをレスポンスに生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもかまいません (MAY)。サーバーのレスポンスコンテンツには、通常、新しいURIへのハイパーリンクを含む短いハイパーテキストメモが含まれます。

| 注意: 歴史的な理由により、ユーザーエージェントは、後続のリクエストの | ためにリクエストメソッドをPOSTからGETに変更してもかまいません (MAY)。 | この動作が望ましくない場合は、代わりに308 (Permanent Redirect) | ステータスコードを使用できます。

301レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.4.3. 302 Found (発見)​

302 (Found) ステータスコードは、ターゲットリソースが一時的に別のURIの下に存在することを示します。リダイレクトが時折変更される可能性があるため、クライアントは将来のリクエストのためにターゲットURIを使用し続けるべきです (ought to)。

サーバーは、別のURIのURI参照を含むLocationヘッダーフィールドをレスポンスに生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもかまいません (MAY)。サーバーのレスポンスコンテンツには、通常、別のURIへのハイパーリンクを含む短いハイパーテキストメモが含まれます。

| 注意: 歴史的な理由により、ユーザーエージェントは、後続のリクエストの | ためにリクエストメソッドをPOSTからGETに変更してもかまいません (MAY)。 | この動作が望ましくない場合は、代わりに307 (Temporary Redirect) | ステータスコードを使用できます。

15.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参照へのハイパーリンクを含む短いハイパーテキストメモを含むべきです (ought to)。

15.4.5. 304 Not Modified (未変更)​

304 (Not Modified) ステータスコードは、条件付きGETまたはHEADリクエストが受信され、条件がfalseと評価されたという事実がなければ、200 (OK) レスポンスになっていたことを示します。言い換えれば、リクエストを条件付きにしたクライアントがすでに有効な表現を持っていることをリクエストが示しているため、サーバーがターゲットリソースの表現を転送する必要はありません。したがって、サーバーは、その保存された表現を200 (OK) レスポンスのコンテンツであるかのように使用するようにクライアントをリダイレクトしています。

304レスポンスを生成するサーバーは、同じリクエストへの200 (OK) レスポンスで送信されていたであろう次のヘッダーフィールドのいずれかを生成しなければなりません (MUST)：

  • Content-Location, Date, ETag, and Vary

  • Cache-Control and Expires ([CACHING] を参照)

304レスポンスの目的は、受信者がすでに1つ以上のキャッシュされた表現を持っている場合に情報転送を最小化することであるため、送信者は、メタデータがキャッシュ更新をガイドする目的で存在する場合（例：レスポンスにETagフィールドがない場合、Last-Modifiedが役立つ可能性がある）を除き、上記にリストされたフィールド以外の表現メタデータを生成すべきではありません (SHOULD NOT)。

304レスポンスを受信するキャッシュの要件は、[CACHING] のセクション4.3.4で定義されています。条件付きリクエストが、共有プロキシに条件付きGETを送信する独自のキャッシュを持つユーザーエージェントなどのアウトバウンドクライアントから発信された場合、プロキシはそのクライアントに304レスポンスを転送すべきです (SHOULD)。

304レスポンスは、ヘッダーセクションの終わりで終了します。コンテンツまたはトレーラーを含めることはできません。

15.4.6. 305 Use Proxy (プロキシを使用)​

305 (Use Proxy) ステータスコードは、この仕様の以前のバージョンで定義されており、現在は非推奨です（[RFC7231] の付録B）。

15.4.7. 306 (Unused) (未使用)​

306ステータスコードは、この仕様の以前のバージョンで定義されましたが、現在は使用されておらず、コードは予約されています。

15.4.8. 307 Temporary Redirect (一時的なリダイレクト)​

307 (Temporary Redirect) ステータスコードは、ターゲットリソースが一時的に別のURIの下に存在し、ユーザーエージェントがそのURIへの自動リダイレクトを実行する場合、リクエストメソッドを変更してはならない (MUST NOT) ことを示します。リダイレクトは時間とともに変化する可能性があるため、クライアントは将来のリクエストのために元のターゲットURIを使用し続けるべきです (ought to)。

サーバーは、別のURIのURI参照を含むLocationヘッダーフィールドをレスポンスに生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもかまいません (MAY)。サーバーのレスポンスコンテンツには、通常、別のURIへのハイパーリンクを含む短いハイパーテキストメモが含まれます。

15.4.9. 308 Permanent Redirect (恒久的なリダイレクト)​

308 (Permanent Redirect) ステータスコードは、ターゲットリソースに新しい恒久的なURIが割り当てられており、このリソースへの将来の参照は、同封されたURIの1つを使用すべきであることを示します。サーバーは、リンク編集機能を持つユーザーエージェントが、ターゲットURIへの参照を、サーバーによって送信された新しい参照の1つで恒久的に置き換えることができることを示唆しています。ただし、ユーザーエージェントが参照を積極的に編集している場合（例：コンテンツの作成に従事している）、接続が保護されており、オリジンサーバーが編集されているコンテンツの信頼できる権限である場合を除き、この提案は通常無視されます。

サーバーは、新しい恒久的なURIの優先URI参照を含むLocationヘッダーフィールドをレスポンスに生成すべきです (SHOULD)。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもかまいません (MAY)。サーバーのレスポンスコンテンツには、通常、新しいURIへのハイパーリンクを含む短いハイパーテキストメモが含まれます。

308レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

| 注意: このステータスコードは、兄弟コードよりもはるかに新しく | （2014年6月）、したがってどこでも認識されるとは限りません。 | デプロイメントの考慮事項については、[RFC7538] のセクション4を | 参照してください。

15.5. Client Error 4xx (クライアントエラー)​

4xx (Client Error) クラスのステータスコードは、クライアントがエラーを起こしたようであることを示します。HEADリクエストへのレスポンスの場合を除き、サーバーは、エラー状況の説明、およびそれが一時的なものか恒久的なものかを含む表現を送信すべきです (SHOULD)。これらのステータスコードは、任意のリクエストメソッドに適用できます。ユーザーエージェントは、含まれている表現をユーザーに表示すべきです (SHOULD)。

15.5.1. 400 Bad Request (不正なリクエスト)​

400 (Bad Request) ステータスコードは、不正なリクエスト構文、無効なリクエストメッセージフレーミング、または欺瞞的なリクエストルーティングなど、クライアントエラーと認識されるものが原因で、サーバーがリクエストを処理できない、または処理しないことを示します。

15.5.2. 401 Unauthorized (未認証)​

401 (Unauthorized) ステータスコードは、ターゲットリソースに対する有効な認証資格情報が不足しているため、リクエストが適用されていないことを示します。401レスポンスを生成するサーバーは、ターゲットリソースに適用可能な少なくとも1つのチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション11.6.1）を送信しなければなりません (MUST)。

リクエストに認証資格情報が含まれていた場合、401レスポンスは、それらの資格情報に対して認証が拒否されたことを示します。ユーザーエージェントは、新しいまたは置き換えられたAuthorizationヘッダーフィールド（セクション11.6.2）を使用してリクエストを繰り返してもかまいません (MAY)。401レスポンスに以前のレスポンスと同じチャレンジが含まれており、ユーザーエージェントがすでに少なくとも1回認証を試みている場合、ユーザーエージェントは、通常、関連する診断情報が含まれているため、同封された表現をユーザーに提示すべきです (SHOULD)。

15.5.3. 402 Payment Required (支払いが必要)​

402 (Payment Required) ステータスコードは、将来の使用のために予約されています。

15.5.4. 403 Forbidden (禁止)​

403 (Forbidden) ステータスコードは、サーバーがリクエストを理解したが、それを実行することを拒否することを示します。リクエストが禁止された理由を公開したいサーバーは、レスポンスコンテンツ（ある場合）でその理由を記述できます。

リクエストに認証資格情報が提供された場合、サーバーはそれらがアクセスを許可するには不十分であると考えています。クライアントは、同じ資格情報を使用してリクエストを自動的に繰り返すべきではありません (SHOULD NOT)。クライアントは、新しいまたは異なる資格情報を使用してリクエストを繰り返してもかまいません (MAY)。ただし、資格情報に関係のない理由でリクエストが禁止される場合があります。

禁止されたターゲットリソースの現在の存在を「隠す」ことを望むオリジンサーバーは、代わりに404 (Not Found) のステータスコードでレスポンスしてもかまいません (MAY)。

15.5.5. 404 Not Found (見つかりません)​

404 (Not Found) ステータスコードは、オリジンサーバーがターゲットリソースの現在の表現を見つけられなかったか、それが存在することを開示する意思がないことを示します。404ステータスコードは、この表現の欠如が一時的なものか恒久的なものかを示しません。オリジンサーバーが、おそらく何らかの構成可能な手段を通じて、条件が恒久的である可能性が高いことを知っている場合、410 (Gone) ステータスコードが404よりも優先されます。

404レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.5.6. 405 Method Not Allowed (メソッドが許可されていません)​

405 (Method Not Allowed) ステータスコードは、リクエスト行で受信されたメソッドがオリジンサーバーによって認識されているが、ターゲットリソースによってサポートされていないことを示します。オリジンサーバーは、ターゲットリソースの現在サポートされているメソッドのリストを含むAllowヘッダーフィールドを405レスポンスで生成しなければなりません (MUST)。

405レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.5.7. 406 Not Acceptable (受理不可)​

406 (Not Acceptable) ステータスコードは、リクエストで受信されたプロアクティブネゴシエーションヘッダーフィールド（セクション12.1）に従って、ターゲットリソースに、ユーザーエージェントに受け入れ可能な現在の表現がなく、サーバーがデフォルトの表現を提供する意思がないことを示します。

サーバーは、ユーザーまたはユーザーエージェントが最も適切なものを選択できる、利用可能な表現特性と対応するリソース識別子のリストを含むコンテンツを生成すべきです (SHOULD)。ユーザーエージェントは、そのリストから最も適切な選択肢を自動的に選択してもかまいません (MAY)。ただし、セクション15.4.1で説明されているように、この仕様では、そのような自動選択の標準は定義されていません。

15.5.8. 407 Proxy Authentication Required (プロキシ認証が必要)​

407 (Proxy Authentication Required) ステータスコードは401 (Unauthorized) に似ていますが、このリクエストのためにプロキシを使用するためにクライアントが自分自身を認証する必要があることを示します。プロキシは、リクエストのためにそのプロキシに適用可能なチャレンジを含むProxy-Authenticateヘッダーフィールド（セクション11.7.1）を送信しなければなりません (MUST)。クライアントは、新しいまたは置き換えられたProxy-Authorizationヘッダーフィールド（セクション11.7.2）を使用してリクエストを繰り返してもかまいません (MAY)。

15.5.9. 408 Request Timeout (リクエストタイムアウト)​

408 (Request Timeout) ステータスコードは、サーバーが待機する準備ができていた時間内に完全なリクエストメッセージを受信しなかったことを示します。

クライアントが転送中の未処理のリクエストを持っている場合、そのリクエストを繰り返してもかまいません (MAY)。現在の接続が使用できない場合（例えば、リクエストの区切りが失われるため、HTTP/1.1の場合のように）、新しい接続が使用されます。

15.5.10. 409 Conflict (競合)​

409 (Conflict) ステータスコードは、ターゲットリソースの現在の状態との競合のため、リクエストを完了できなかったことを示します。このコードは、ユーザーが競合を解決してリクエストを再送信できる可能性がある状況で使用されます。サーバーは、ユーザーが競合の原因を認識するのに十分な情報を含むコンテンツを生成すべきです (SHOULD)。

競合は、PUTリクエストへのレスポンスで発生する可能性が最も高いです。例えば、バージョン管理が使用されており、PUTされている表現に、以前の（サードパーティの）リクエストによって行われた変更と競合するリソースへの変更が含まれている場合、オリジンサーバーは、リクエストを完了できないことを示すために409レスポンスを使用する可能性があります。この場合、レスポンス表現には、リビジョン履歴に基づいて差異をマージするのに役立つ情報が含まれている可能性があります。

15.5.11. 410 Gone (消滅)​

410 (Gone) ステータスコードは、ターゲットリソースへのアクセスがオリジンサーバーで利用できなくなり、この条件が恒久的である可能性が高いことを示します。オリジンサーバーが条件が恒久的であるかどうかを知らない、または判断する機能を持っていない場合は、代わりに404 (Not Found) ステータスコードを使用すべきです (ought to)。

410レスポンスは主に、リソースが意図的に利用できなくなり、サーバー所有者がそのリソースへのリモートリンクを削除することを望んでいることを受信者に通知することにより、Web保守のタスクを支援することを目的としています。このようなイベントは、期間限定のプロモーションサービスや、オリジンサーバーのサイトに関連付けられなくなった個人に属するリソースで一般的です。すべての恒久的に利用できないリソースを「gone」としてマークする必要はなく、マークを任意の期間保持する必要もありません - それはサーバー所有者の裁量に委ねられています。

410レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.5.12. 411 Length Required (長さが必要)​

411 (Length Required) ステータスコードは、サーバーが定義されたContent-Length（セクション8.6）なしでリクエストを受け入れることを拒否することを示します。クライアントは、リクエストコンテンツの長さを含む有効なContent-Lengthヘッダーフィールドを追加する場合、リクエストを繰り返してもかまいません (MAY)。

15.5.13. 412 Precondition Failed (前提条件の失敗)​

412 (Precondition Failed) ステータスコードは、リクエストヘッダーフィールドで指定された1つ以上の条件が、サーバーでテストされたときにfalseと評価されたことを示します（セクション13）。このレスポンスステータスコードにより、クライアントは現在のリソース状態（その現在の表現とメタデータ）に前提条件を設定でき、したがって、ターゲットリソースが予期しない状態にある場合にリクエストメソッドが適用されるのを防ぐことができます。

15.5.14. 413 Content Too Large (コンテンツが大きすぎる)​

413 (Content Too Large) ステータスコードは、リクエストコンテンツがサーバーが処理する意思または能力を超えるサイズであるため、サーバーがリクエストの処理を拒否していることを示します。使用中のプロトコルバージョンが許可する場合、サーバーはリクエストを終了してもかまいません (MAY)。それ以外の場合、サーバーは接続を閉じてもかまいません (MAY)。

条件が一時的である場合、サーバーは、それが一時的であり、クライアントがいつ再試行できるかを示すRetry-Afterヘッダーフィールドを生成すべきです (SHOULD)。

15.5.15. 414 URI Too Long (URIが長すぎる)​

414 (URI Too Long) ステータスコードは、ターゲットURIがサーバーが解釈する意思がある長さよりも長いため、サーバーがリクエストの処理を拒否していることを示します。このまれな条件は、クライアントが長いクエリ情報を持つPOSTリクエストをGETリクエストに不適切に変換した場合、クライアントがリダイレクトの無限ループに陥った場合（例：それ自体のサフィックスを指すリダイレクトされたURIプレフィックス）、またはサーバーが潜在的なセキュリティホールを悪用しようとするクライアントによる攻撃を受けている場合にのみ発生する可能性があります。

414レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.5.16. 415 Unsupported Media Type (サポートされていないメディアタイプ)​

415 (Unsupported Media Type) ステータスコードは、コンテンツがターゲットリソースのこのメソッドでサポートされていない形式であるため、オリジンサーバーがリクエストの処理を拒否していることを示します。

形式の問題は、リクエストの示されたContent-TypeまたはContent-Encoding、またはデータを直接検査した結果による可能性があります。

問題がサポートされていないコンテンツコーディングによって引き起こされた場合、Accept-Encodingレスポンスヘッダーフィールド（セクション12.5.3）を使用して、リクエストで受け入れられていたであろうコンテンツコーディング（ある場合）を示すべきです (ought to)。

一方、原因がサポートされていないメディアタイプである場合、Acceptレスポンスヘッダーフィールド（セクション12.5.1）を使用して、リクエストで受け入れられていたであろうメディアタイプを示すことができます。

15.5.17. 416 Range Not Satisfiable (範囲が満足できない)​

416 (Range Not Satisfiable) ステータスコードは、リクエストのRangeヘッダーフィールド（セクション14.2）内の範囲のセットが、要求された範囲のいずれも満足できないため、またはクライアントが過度の数の小さなまたは重複する範囲（潜在的なサービス拒否攻撃）を要求したために拒否されたことを示します。

各範囲単位は、独自の範囲セットが満足可能であるために必要なものを定義します。例えば、セクション14.1.2は、バイト範囲セットを満足可能にするものを定義しています。

バイト範囲リクエストへの416レスポンスを生成するサーバーは、選択された表現の現在の長さを指定するContent-Rangeヘッダーフィールドを生成すべきです (SHOULD)（セクション14.4）。

例：

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

| 注意: サーバーはRangeを無視することができるため、多くの実装は | 200 (OK) レスポンスで選択された表現全体でレスポンスします。 | それは部分的に、ほとんどのクライアントがタスクを完了するために | 200 (OK) を受信する準備ができているため（効率は低いですが）、 | そして部分的に、クライアントが完全な表現を受信するまで無効な範囲 | リクエストの作成を停止しない可能性があるためです。したがって、 | クライアントは、最も適切な場合でも、416 (Range Not Satisfiable) | レスポンスを受信することに依存できません。

15.5.18. 417 Expectation Failed (期待の失敗)​

417 (Expectation Failed) ステータスコードは、リクエストのExpectヘッダーフィールド（セクション10.1.1）で指定された期待が、少なくとも1つのインバウンドサーバーによって満たされなかったことを示します。

15.5.19. 418 (Unused) (未使用)​

[RFC2324] は、HTTPが乱用されるさまざまな方法を風刺した4月1日のRFCでした。そのような乱用の1つは、アプリケーション固有の418ステータスコードの定義であり、これは冗談として十分頻繁にデプロイされ、コードが将来の使用に使用できなくなっています。

したがって、418ステータスコードはIANA HTTPステータスコードレジストリで予約されています。これは、ステータスコードが現在他のアプリケーションに割り当てることができないことを示します。将来の状況がその使用を必要とする場合（例：4NNステータスコードの枯渇）、別の用途に再割り当てできます。

15.5.20. 421 Misdirected Request (誤ったリクエスト)​

421 (Misdirected Request) ステータスコードは、リクエストが、ターゲットURIに対して権威あるレスポンスを生成できない、または生成する意思がないサーバーに向けられたことを示します。オリジンサーバー（またはオリジンサーバーの代わりに動作するゲートウェイ）は、サーバーが構成されているオリジンと一致しない（セクション4.3.1）、またはリクエストが受信された接続コンテキストと一致しない（セクション7.4）ターゲットURIを拒否するために421を送信します。

421 (Misdirected Request) レスポンスを受信するクライアントは、リクエストメソッドが冪等であるかどうかに関係なく、ターゲットリソースのオリジンに固有の新しい接続、または代替サービス [ALTSVC] を介してなど、別の接続でリクエストを再試行してもかまいません (MAY)。

プロキシは421レスポンスを生成してはなりません (MUST NOT)。

15.5.21. 422 Unprocessable Content (処理不可能なコンテンツ)​

422 (Unprocessable Content) ステータスコードは、サーバーがリクエストコンテンツのコンテンツタイプを理解している（したがって、415 (Unsupported Media Type) ステータスコードは不適切である）、およびリクエストコンテンツの構文は正しいが、含まれている命令を処理できなかったことを示します。例えば、このステータスコードは、XMLリクエストコンテンツに整形式（つまり、構文的に正しい）だが意味的に誤ったXML命令が含まれている場合に送信できます。

15.5.22. 426 Upgrade Required (アップグレードが必要)​

426 (Upgrade Required) ステータスコードは、サーバーが現在のプロトコルを使用してリクエストを実行することを拒否するが、クライアントが別のプロトコルにアップグレードした後にそうする意思がある可能性があることを示します。サーバーは、必要なプロトコルを示すために、426レスポンスでUpgradeヘッダーフィールドを送信しなければなりません (MUST)（セクション7.8）。

例：

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.

15.6. Server Error 5xx (サーバーエラー)​

5xx (Server Error) クラスのステータスコードは、サーバーがエラーを起こしたこと、または要求されたメソッドを実行できないことを認識していることを示します。HEADリクエストへのレスポンスの場合を除き、サーバーは、エラー状況の説明、およびそれが一時的なものか恒久的なものかを含む表現を送信すべきです (SHOULD)。ユーザーエージェントは、含まれている表現をユーザーに表示すべきです (SHOULD)。これらのステータスコードは、任意のリクエストメソッドに適用できます。

15.6.1. 500 Internal Server Error (内部サーバーエラー)​

500 (Internal Server Error) ステータスコードは、サーバーがリクエストの実行を妨げる予期しない条件に遭遇したことを示します。

15.6.2. 501 Not Implemented (未実装)​

501 (Not Implemented) ステータスコードは、サーバーがリクエストを満たすために必要な機能をサポートしていないことを示します。これは、サーバーがリクエストメソッドを認識せず、どのリソースに対してもそれをサポートできない場合の適切なレスポンスです。

501レスポンスは、ヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御（[CACHING] のセクション4.2.2を参照）によって特に示されない限り。

15.6.3. 502 Bad Gateway (不正なゲートウェイ)​

502 (Bad Gateway) ステータスコードは、サーバーがゲートウェイまたはプロキシとして動作している間に、リクエストを実行しようとしてアクセスしたインバウンドサーバーから無効なレスポンスを受信したことを示します。

15.6.4. 503 Service Unavailable (サービス利用不可)​

503 (Service Unavailable) ステータスコードは、一時的な過負荷または予定されたメンテナンスのため、サーバーが現在リクエストを処理できないことを示します。これは、ある程度の遅延の後に軽減される可能性があります。サーバーは、クライアントがリクエストを再試行する前に待機すべき適切な時間量を示唆するために、Retry-Afterヘッダーフィールド（セクション10.2.3）を送信してもかまいません (MAY)。

| 注意: 503ステータスコードの存在は、サーバーが過負荷になったときに | それを使用しなければならないことを意味するものではありません。 | 一部のサーバーは、単に接続を拒否する場合があります。

15.6.5. 504 Gateway Timeout (ゲートウェイタイムアウト)​

504 (Gateway Timeout) ステータスコードは、サーバーがゲートウェイまたはプロキシとして動作している間に、リクエストを完了するためにアクセスする必要があったアップストリームサーバーからタイムリーなレスポンスを受信しなかったことを示します。

15.6.6. 505 HTTP Version Not Supported (HTTPバージョンがサポートされていません)​

505 (HTTP Version Not Supported) ステータスコードは、サーバーがリクエストメッセージで使用されたHTTPのメジャーバージョンをサポートしていない、またはサポートすることを拒否することを示します。サーバーは、セクション2.5で説明されているように、このエラーメッセージ以外で、クライアントと同じメジャーバージョンを使用してリクエストを完了できない、または完了する意思がないことを示しています。サーバーは、そのバージョンがサポートされていない理由と、そのサーバーによってサポートされている他のプロトコルを説明する505レスポンスの表現を生成すべきです (SHOULD)。

に最終更新