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

10. Status Code Definitions (ステータスコード定義)

以下では、各ステータスコードについて説明します。これには、どのメソッドに続くことができるかの説明と、レスポンスに必要なメタ情報が含まれます。

10.1 Informational 1xx (情報)​

このクラスのステータスコードは、Status-Lineとオプションのヘッダのみで構成され、空行で終了する一時的なレスポンスを示します。このクラスのステータスコードには必須のヘッダはありません。HTTP/1.0は1xxステータスコードを定義していないため、サーバーは、実験的な条件下でない限り、HTTP/1.0クライアントに1xxレスポンスを送信してはなりません (MUST NOT)。

クライアントは、100 (Continue) ステータスメッセージを期待していない場合でも、通常のレスポンスの前に1つ以上の1xxステータスレスポンスを受け入れる準備をしなければなりません (MUST)。ユーザーエージェントは、予期しない1xxステータスレスポンスを無視できます (MAY)。

プロキシは、プロキシとそのクライアント間の接続が閉じられている場合、またはプロキシ自体が1xxレスポンスの生成を要求した場合を除き、1xxレスポンスを転送しなければなりません (MUST)。（たとえば、プロキシがリクエストを転送する際に"Expect: 100-continue"フィールドを追加した場合、対応する100 (Continue) レスポンスを転送する必要はありません。）

10.1.1 100 Continue​

クライアントはリクエストを続行すべき (SHOULD) です。この一時的なレスポンスは、リクエストの初期部分が受信され、まだサーバーによって拒否されていないことをクライアントに通知するために使用されます。クライアントはリクエストの残りを送信し続けるべき (SHOULD) です。リクエストがすでに完了している場合は、このレスポンスを無視します。サーバーは、リクエストが完了した後に最終レスポンスを送信しなければなりません (MUST)。このステータスコードの使用と処理の詳細については、セクション8.2.3を参照してください。

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

サーバーは、Upgradeメッセージヘッダフィールド（セクション14.42）を介したクライアントの要求を理解し、この接続で使用されるアプリケーションプロトコルを変更することに同意します。サーバーは、101レスポンスを終了する空行の直後に、レスポンスのUpgradeヘッダフィールドで定義されたプロトコルに切り替えます。

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

10.2 Successful 2xx (成功)​

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

10.2.1 200 OK​

リクエストは成功しました。レスポンスとともに返される情報は、リクエストで使用されたメソッドに依存します。例：

  • GET - リクエストされたリソースに対応するエンティティがレスポンスで送信されます；
  • HEAD - リクエストされたリソースに対応するエンティティヘッダフィールドが、メッセージボディなしでレスポンスで送信されます；
  • POST - 操作の結果を記述または含むエンティティ；
  • TRACE - 終端サーバーが受信したリクエストメッセージを含むエンティティ。

10.2.2 201 Created (作成済み)​

リクエストが完了し、新しいリソースの作成につながりました。新しく作成されたリソースは、レスポンスエンティティで返されたURIで参照でき、リソースの最も具体的なURIはLocationヘッダフィールドで提供されます。レスポンスには、リソースの特性と場所のリストを含むエンティティを含めるべき (SHOULD) で、ユーザーまたはユーザーエージェントはそこから最も適切なものを選択できます。エンティティ形式は、Content-Typeヘッダフィールドで指定されたメディアタイプによって指定されます。オリジンサーバーは、201ステータスコードを返す前にリソースを作成しなければなりません (MUST)。操作を即座に実行できない場合、サーバーは代わりに202 (Accepted) レスポンスで応答すべき (SHOULD) です。

201レスポンスには、作成されたばかりのリクエストバリアントのエンティティタグの現在の値を示すETagレスポンスヘッダフィールドを含めることができます (MAY)。セクション14.19を参照してください。

10.2.3 202 Accepted (受理済み)​

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

202レスポンスは意図的に非コミッタルです。その目的は、サーバーが他のプロセス（おそらく1日に1回だけ実行されるバッチ指向プロセス）のリクエストを受け入れることを許可することです。ユーザーエージェントとサーバーの接続をプロセスが完了するまで持続させる必要はありません。このレスポンスとともに返されるエンティティには、リクエストの現在のステータスの指示と、ステータスモニタへのポインタ、またはユーザーがリクエストがいつ完了するかを期待できる何らかの推定を含めるべき (SHOULD) です。

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

エンティティヘッダで返されるメタ情報は、オリジンサーバーからの最終セットではなく、ローカルまたはサードパーティのコピーから収集されたものです。提示されたセットは、元のバージョンのサブセットまたはスーパーセットである可能性があります (MAY)。たとえば、リソースに関するローカル注釈情報を含めると、オリジンサーバーが知っているメタ情報のスーパーセットになる可能性があります。このレスポンスコードの使用は必須ではなく、レスポンスが本来200 (OK) である場合にのみ適切です。

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

サーバーはリクエストを完了しましたが、エンティティボディを返す必要はなく、更新されたメタ情報を返すことを希望する場合があります。レスポンスには、エンティティヘッダ形式の新しいまたは更新されたメタ情報を含めることができ (MAY)、存在する場合は、リクエストされたバリアントに関連付けられるべき (SHOULD) です。

クライアントがユーザーエージェントである場合、リクエストを送信させたビュー（ドキュメントビュー）を変更すべきではありません (SHOULD NOT)。このレスポンスは主に、ユーザーエージェントのアクティブなドキュメントビューを変更せずに、アクションの入力を発生させることを目的としていますが、新しいまたは更新されたメタ情報は、ユーザーエージェントのアクティブビューに現在あるドキュメントに適用されるべき (SHOULD) です。

204レスポンスはメッセージボディを含んではならず (MUST NOT)、常にヘッダフィールドの後の最初の空行で終了します。

10.2.6 205 Reset Content (コンテンツリセット)​

サーバーはリクエストを完了し、ユーザーエージェントはリクエストを送信させたドキュメントビューをリセットすべき (SHOULD) です。このレスポンスは主に、ユーザー入力によるアクションの入力を許可し、その後、入力が与えられたフォームをクリアして、ユーザーが別の入力アクションを簡単に開始できるようにすることを目的としています。レスポンスにはエンティティを含んではなりません (MUST NOT)。

10.2.7 206 Partial Content (部分的コンテンツ)​

サーバーはリソースの部分的GETリクエストを完了しました。リクエストには、希望する範囲を示すRangeヘッダフィールド（セクション14.35）が含まれていなければならず (MUST)、リクエストを条件付きにするためにIf-Rangeヘッダフィールド（セクション14.27）が含まれていた可能性があります (MAY)。

レスポンスには以下のヘッダフィールドを含めなければなりません (MUST)：

  • このレスポンスに含まれる範囲を示すContent-Rangeヘッダフィールド（セクション14.16）、または各部分のContent-Rangeフィールドを含むmultipart/byteranges Content-Type。レスポンスにContent-Lengthヘッダフィールドが存在する場合、その値はメッセージボディで転送されるオクテットの実際の数と一致しなければなりません (MUST)。

  • Date

  • ETagおよび/またはContent-Location（同じリクエストへの200レスポンスでヘッダが送信される場合）

  • Expires、Cache-Control、および/またはVary（フィールド値が、そのバリアントの以前のレスポンスで送信されたフィールド値と異なる可能性がある場合）

206レスポンスが強力なキャッシュバリデータを使用する条件付きリクエストの結果である場合（セクション13.3.3を参照）、レスポンスには他のエンティティヘッダを含めるべきではありません (SHOULD NOT)。これにより、キャッシュされたエンティティボディと更新されたヘッダ間の不整合が防止されます。それ以外の場合、レスポンスには、同じリクエストへの200 (OK) レスポンスで返されるすべてのエンティティヘッダを含めなければなりません (MUST)。

ETagまたはLast-Modifiedヘッダが、以前にオリジンサーバーから受信した値と一致しない場合、キャッシュは206レスポンスを他の以前にキャッシュされたコンテンツと組み合わせてはならず (MUST NOT)、部分的なレスポンスを完全なものとして扱わなければなりません (MUST)。

RangeおよびContent-Rangeヘッダをサポートしないキャッシュは、206 (Partial) レスポンスをキャッシュしてはなりません (MUST NOT)。

10.3 Redirection 3xx (リダイレクト)​

このクラスのステータスコードは、リクエストを完了するためにユーザーエージェントがさらにアクションを実行する必要があることを示します。必要なアクションは、第2のリクエストで使用されるメソッドがGETまたはHEADである場合にのみ、ユーザーとのやり取りなしにユーザーエージェントによって実行できます (MAY)。クライアントは無限のリダイレクトループを検出すべき (SHOULD) です。これらのループは、各リダイレクトに対してネットワークトラフィックを生成するためです。

注：この仕様の以前のバージョンでは、最大5回のリダイレクトを推奨していました。コンテンツ開発者は、この推奨に従わないクライアントが存在する可能性があることに注意すべきです。

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

リクエストされたリソースは、それぞれ独自の特定の場所を持つ表現のセットのいずれかに対応し、エージェント駆動のネゴシエーション情報（セクション12）が提供されるため、ユーザー（またはユーザーエージェント）が優先表現を選択し、そのリクエストをその場所にリダイレクトできます。

HEADリクエストでない限り、レスポンスには、リソースの特性と場所のリストを含むエンティティを含めるべき (SHOULD) で、ユーザーまたはユーザーエージェントはそこから最も適切なものを選択できます。エンティティ形式は、Content-Typeヘッダフィールドで指定されたメディアタイプによって指定されます。ユーザーエージェントの形式と機能に応じて、最も適切な選択が自動的に選択される場合があります。ただし、この仕様では、このような自動選択の標準を定義していません。

サーバーに優先表現の選択がある場合、Locationフィールドにその表現の特定のURIを含めるべき (SHOULD) です。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用できます (MAY)。別段の指示がない限り、このレスポンスはキャッシュ可能です。

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

リクエストされたリソースには新しい恒久的なURIが割り当てられており、そのリソースへの今後の参照では、返されたURIの1つを使用すべき (SHOULD) です。リンク編集機能を持つクライアントは、可能であれば、Request-URIへの参照をサーバーが返した1つ以上の新しい参照に自動的に再リンクすべき (SHOULD) です。別段の指示がない限り、このレスポンスはキャッシュ可能です。

新しい恒久的なURIは、レスポンスのLocationフィールドで提供されるべき (SHOULD) です。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクと簡単な注釈を含めるべき (SHOULD) です。

GETまたはHEAD以外のリクエストへのレスポンスで301ステータスコードが受信された場合、ユーザーエージェントは、ユーザーが確認できない限り、リクエストを自動的にリダイレクトしてはなりません (MUST NOT)。これは、リクエストが発行された条件を変更する可能性があるためです。

注：POSTリクエストへのレスポンスで自動リダイレクトする場合、一部の既存のHTTP/1.0ユーザーエージェントは誤ってそれをGETリクエストに変更します。

10.3.3 302 Found​

リクエストされたリソースは一時的に異なるURIの下に存在します。リダイレクトが時々変更される可能性があるため、クライアントは今後のリクエストにRequest-URIを使用し続けるべき (SHOULD) です。このレスポンスは、Cache-ControlまたはExpiresヘッダフィールドで示される場合にのみキャッシュ可能です。

一時的なURIは、レスポンスのLocationフィールドで提供されるべき (SHOULD) です。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクと簡単な注釈を含めるべき (SHOULD) です。

GETまたはHEAD以外のリクエストへのレスポンスで302ステータスコードが受信された場合、ユーザーエージェントは、ユーザーが確認できない限り、リクエストを自動的にリダイレクトしてはなりません (MUST NOT)。これは、リクエストが発行された条件を変更する可能性があるためです。

注：RFC 1945およびRFC 2068は、クライアントがリダイレクトリクエストのメソッドを変更することを許可していませんでした。ただし、ほとんどの既存のユーザーエージェント実装は、302を303レスポンスとして扱い、元のリクエストメソッドに関係なく、Locationフィールド値に対してGETを実行します。ステータスコード303および307は、クライアントにどのような反応が期待されるかを明確にしたいサーバー用に追加されました。

10.3.4 303 See Other (他を参照)​

リクエストへのレスポンスは、異なるURIの下で見つけることができ、そのリソースへのGETメソッドを使用して取得すべき (SHOULD) です。このメソッドは主に、POST起動スクリプトの出力がユーザーエージェントを選択されたリソースにリダイレクトできるようにすることを目的としています。新しいURIは、元のリクエストされたリソースの代替参照ではありません。303レスポンスはキャッシュしてはなりませんが (MUST NOT)、第2の（リダイレクト）リクエストへのレスポンスはキャッシュ可能である可能性があります。

異なるURIは、レスポンスのLocationフィールドで提供されるべきです。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクと簡単な注釈を含めるべき (SHOULD) です。

注：多くのHTTP/1.1以前のユーザーエージェントは303ステータスを理解しません。このようなクライアントとの相互運用性が問題となる場合、302ステータスコードを代わりに使用できます。ほとんどのユーザーエージェントは、303レスポンスに必要な方法で302レスポンスに反応するためです。

10.3.5 304 Not Modified (未変更)​

クライアントが条件付きGETリクエストを実行し、アクセスが許可されているが、ドキュメントが変更されていない場合、サーバーはこのステータスコードで応答すべき (SHOULD) です。304レスポンスはメッセージボディを含んではならず (MUST NOT)、常にヘッダフィールドの後の最初の空行で終了します。

レスポンスには以下のヘッダフィールドを含めなければなりません (MUST)：

  • Date（セクション14.18.1のルールに従って、その省略が必須である場合を除く）

クロックソースを持たないオリジンサーバーがこれらのルールに従い、プロキシとクライアントが送信するDateヘッダに独自のDateを追加する場合、キャッシュは正しく動作します。

  • ETagおよび/またはContent-Location（同じリクエストへの200レスポンスでそれらが含まれる場合）
  • Expires、Cache-Control、および/またはVary（フィールド値が、そのバリアントの以前のレスポンスで送信された値と異なる可能性がある場合）

条件付きGETが強力なキャッシュバリデータを使用している場合（セクション13.3.3を参照）、レスポンスには他のエンティティヘッダを含めるべきではありません (SHOULD NOT)。それ以外の場合（つまり、条件付きGETが弱いバリデータを使用している場合）、レスポンスには他のエンティティヘッダを含んではなりません (MUST NOT)。これにより、キャッシュされたエンティティボディと更新されたヘッダ間の不整合が防止されます。

304レスポンスが現在キャッシュされていないエンティティを示している場合、キャッシュはレスポンスを無視し、条件を使用せずにリクエストを繰り返さなければなりません (MUST)。

キャッシュが304レスポンスを受信し、現在キャッシュしているキャッシュエントリを更新する場合、キャッシュはレスポンスで与えられた新しいフィールド値を反映するようにエントリを更新しなければなりません (MUST)。

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

リクエストされたリソースは、Locationフィールドで指定されたプロキシを介してアクセスしなければなりません (MUST)。Locationフィールドは、プロキシのURIを提供します。受信者は、この単一のリクエストをプロキシ経由で繰り返すことが期待されます。305レスポンスは、オリジンサーバーによってのみ生成されなければなりません (MUST)。

注：RFC 2068は、305が単一のリクエストをプロキシにリダイレクトすることを意図していることを明確に指定していませんでした。305レスポンスの不適切なキャッシュにより、後続のリクエストがそのプロキシに向けられることで、重大なセキュリティ問題が発生しました。

10.3.7 306 (Unused) (未使用)​

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

10.3.8 307 Temporary Redirect (一時的リダイレクト)​

リクエストされたリソースは一時的に異なるURIの下に存在します。リダイレクトが時々変更される可能性があるため、クライアントは今後のリクエストにRequest-URIを使用し続けるべき (SHOULD) です。このレスポンスは、Cache-ControlまたはExpiresヘッダフィールドで示される場合にのみキャッシュ可能です。

一時的なURIは、レスポンスのLocationフィールドで提供されるべき (SHOULD) です。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクと簡単な注釈を含めるべき (SHOULD) です。多くのHTTP/1.1以前のユーザーエージェントは307ステータスを理解しないためです。したがって、注釈には、ユーザーが新しいURIで元のリクエストを繰り返すために必要な情報を含めるべき (SHOULD) です。

GETまたはHEAD以外のリクエストへのレスポンスで307ステータスコードが受信された場合、ユーザーエージェントは、ユーザーが確認できない限り、リクエストを自動的にリダイレクトしてはなりません (MUST NOT)。これは、リクエストが発行された条件を変更する可能性があるためです。

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

4xxクラスのステータスコードは、クライアントがエラーを起こしたと思われる場合に使用されます。HEADリクエストへの応答である場合を除き、サーバーは、エラー状況の説明と、それが一時的な条件か恒久的な条件かを含むエンティティを含めるべき (SHOULD) です。これらのステータスコードは、任意のリクエストメソッドに適用されます。ユーザーエージェントは、含まれているエンティティをユーザーに表示すべき (SHOULD) です。

クライアントがデータを送信している場合、TCPを使用するサーバー実装は、サーバーが入力接続を閉じる前に、クライアントがレスポンスを含むパケットの受信を確認することを注意深く確認すべき (SHOULD) です。クライアントが閉じた後もサーバーにデータを送信し続ける場合、サーバーのTCPスタックはクライアントにリセットパケットを送信します。これにより、HTTPアプリケーションがそれを読み取って解釈する前に、クライアントの未確認入力バッファがクリアされる可能性があります。

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

構文が不正な形式であるため、サーバーはリクエストを理解できませんでした。クライアントは、修正なしでリクエストを繰り返すべきではありません (SHOULD NOT)。

10.4.2 401 Unauthorized (未認証)​

リクエストにはユーザー認証が必要です。レスポンスには、リクエストされたリソースに適用されるチャレンジを含むWWW-Authenticateヘッダフィールド（セクション14.47）を含めなければなりません (MUST)。クライアントは、適切なAuthorizationヘッダフィールド（セクション14.8）を使用してリクエストを繰り返すことができます (MAY)。リクエストに既にAuthorization資格情報が含まれている場合、401レスポンスは、それらの資格情報に対する承認が拒否されたことを示します。401レスポンスに以前のレスポンスと同じチャレンジが含まれ、ユーザーエージェントが既に少なくとも1回認証を試みている場合、レスポンスで与えられたエンティティをユーザーに提示すべき (SHOULD) です。そのエンティティには関連する診断情報が含まれる可能性があるためです。HTTPアクセス認証は、"HTTP Authentication: Basic and Digest Access Authentication" [43] で説明されています。

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

このコードは将来の使用のために予約されています。

10.4.4 403 Forbidden (禁止)​

サーバーはリクエストを理解しましたが、それを実行することを拒否しています。認証は役に立たず、リクエストを繰り返すべきではありません (SHOULD NOT)。リクエストメソッドがHEADでなく、サーバーがリクエストが実行されなかった理由を公開したい場合、エンティティで拒否の理由を説明すべき (SHOULD) です。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータスコード404 (Not Found) を使用できます。

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

サーバーは、Request-URIに一致するものを何も見つけませんでした。条件が一時的か恒久的かの指示はありません。サーバーが、内部で構成可能なメカニズムを介して、古いリソースが恒久的に使用できず、転送アドレスがないことを知っている場合、410 (Gone) ステータスコードを使用すべき (SHOULD) です。このステータスコードは、サーバーがリクエストが拒否された理由を正確に明らかにしたくない場合、または他のレスポンスが適用されない場合によく使用されます。

10.4.6 405 Method Not Allowed (許可されないメソッド)​

Request-Lineで指定されたメソッドは、Request-URIで識別されるリソースには許可されていません。レスポンスには、リクエストされたリソースの有効なメソッドのリストを含むAllowヘッダを含めなければなりません (MUST)。

10.4.7 406 Not Acceptable (受理不可)​

リクエストで識別されたリソースは、リクエストで送信されたAcceptヘッダに従って受理不可能なコンテンツ特性を持つレスポンスエンティティのみを生成できます。

HEADリクエストでない限り、レスポンスには、利用可能なエンティティの特性と場所のリストを含むエンティティを含めるべき (SHOULD) で、ユーザーまたはユーザーエージェントはそこから最も適切なものを選択できます。エンティティ形式は、Content-Typeヘッダフィールドで指定されたメディアタイプによって指定されます。ユーザーエージェントの形式と機能に応じて、最も適切な選択が自動的に選択される場合があります。ただし、この仕様では、このような自動選択の標準を定義していません。

注：HTTP/1.1サーバーは、受理可能なレスポンスを提供できない場合、受理不可能なレスポンスを返すことが許可されています。この場合、ユーザーエージェントは、エンティティがユーザーにとって有用かどうかを判断するためにエンティティを検査すべき (SHOULD) です。

レスポンスが受理不可能である可能性がある場合、ユーザーエージェントは、一時的にさらなるデータの受信を停止し、さらなるアクションを決定するためにユーザーに問い合わせるべき (SHOULD) です。

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

このコードは401 (Unauthorized) と似ていますが、クライアントが最初にプロキシで認証する必要があることを示します。プロキシは、リクエストされたリソースのプロキシに適用されるチャレンジを含むProxy-Authenticateヘッダフィールド（セクション14.33）を返さなければなりません (MUST)。クライアントは、Proxy-Authorizationヘッダフィールド（セクション14.34）を使用してリクエストを繰り返すことができます (MAY)。HTTPアクセス認証は、"HTTP Authentication: Basic and Digest Access Authentication" [43] で説明されています。

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

クライアントは、サーバーが待機する準備ができている時間内にリクエストを生成しませんでした。クライアントは、後で変更なしでリクエストを繰り返すことができます (MAY)。

10.4.10 409 Conflict (競合)​

リソースの現在の状態との競合により、リクエストを完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。レスポンスボディには、ユーザーが競合のソースを識別するのに十分な情報を含めるべき (SHOULD) です。理想的には、レスポンスエンティティには、ユーザーまたはユーザーエージェントが問題を解決するのに十分な情報が含まれますが、これは不可能である場合があり、必須ではありません。

競合は、PUTリクエストへのレスポンスで最も発生する可能性があります。たとえば、バージョニングが使用されており、PUTされているエンティティに、以前の（サードパーティ）リクエストによって行われた変更と競合するリソースへの変更が含まれている場合、サーバーは409レスポンスを使用してリクエストを完了できないことを示す場合があります。この場合、レスポンスエンティティには、レスポンスContent-Typeで定義された形式の2つのバージョン間の差異のリストが含まれる可能性があります。

10.4.11 410 Gone (消失)​

リクエストされたリソースはサーバーで利用できなくなり、転送アドレスはわかりません。この条件は恒久的であると予想されます。リンク編集機能を持つクライアントは、ユーザーの承認後、可能であれば、Request-URIへの参照を削除すべき (SHOULD) です。サーバーが条件が恒久的かどうかを知らない、または判断する機能を持たない場合、代わりにステータスコード404 (Not Found) を使用すべき (SHOULD) です。別段の指示がない限り、このレスポンスはキャッシュ可能です。

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

10.4.12 411 Length Required (長さが必要)​

サーバーは、定義されたContent-Lengthなしではリクエストを受け入れることを拒否します。クライアントが、メッセージボディの長さを含む有効なContent-Lengthヘッダフィールドをリクエストメッセージに追加する場合、リクエストを繰り返すことができます (MAY)。

10.4.13 412 Precondition Failed (前提条件失敗)​

サーバーでテストされたとき、リクエストヘッダフィールドで指定された前提条件はfalseと評価されました。このステータスコードにより、クライアントは現在のリソースメタ情報（ヘッダフィールドデータ）に前提条件を設定し、意図したリソース以外のリソースにリクエストメソッドが適用されるのを防ぐことができます。

10.4.14 413 Request Entity Too Large (リクエストエンティティが大きすぎます)​

サーバーは、リクエストエンティティがサーバーが処理したい、または処理できるサイズよりも大きいため、リクエストの処理を拒否しています。サーバーは、クライアントがリクエストを続行するのを防ぐために接続を閉じることができます (MAY)。

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

10.4.15 414 Request-URI Too Long (Request-URIが長すぎます)​

サーバーは、Request-URIがサーバーが解釈したい長さよりも長いため、リクエストの処理を拒否しています。このまれな条件は、クライアントがPOSTリクエストを長いクエリ情報を持つGETリクエストに誤って変換した場合、クライアントがリダイレクトの「ブラックホール」（たとえば、自身のサフィックスを指すリダイレクトプレフィックス）に陥った場合、またはサーバーが、一部のサーバーに存在するセキュリティホールを悪用しようとするクライアントによる攻撃を受けている場合にのみ発生する可能性があります。これらのサーバーは、固定長バッファを使用してRequest-URIを読み取りまたは操作します。

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

サーバーは、リクエストのエンティティの形式が、リクエストされたメソッドのリクエストされたリソースでサポートされていないため、リクエストの処理を拒否しています。

10.4.17 416 Requested Range Not Satisfiable (リクエストされた範囲が満たせません)​

このステータスコードは、リクエストにRange要求ヘッダフィールド（セクション14.35）が含まれ、範囲指定子値のいずれの範囲値も選択されたリソースの現在の範囲と重ならず、リクエストにIf-Range要求ヘッダフィールドが含まれていない場合に返されるべき (SHOULD) です。（バイト範囲の場合、これは、すべてのbyte-range-spec値の最初のバイト位置が、選択されたリソースの現在の長さよりも大きいことを意味します。）

バイト範囲に対してこのステータスコードが返される場合、レスポンスには、選択されたリソースの現在の長さを指定するContent-Rangeエンティティヘッダフィールドを含めるべき (SHOULD) です（セクション14.16を参照）。このレスポンスはmultipart/byteranges content-typeを使用してはなりません (MUST NOT)。

10.4.18 417 Expectation Failed (期待失敗)​

Expect要求ヘッダフィールド（セクション14.20を参照）で指定された期待は、このサーバーでは満たすことができません。サーバーがプロキシである場合、リクエストが次のホップサーバーによって満たされないという明確な証拠がサーバーにあります。

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

数字"5"で始まるレスポンスステータスコードは、サーバーがエラーを起こしたことを認識しているか、リクエストを実行できない場合を示します。HEADリクエストへの応答である場合を除き、サーバーは、エラー状況の説明と、それが一時的な条件か恒久的な条件かを含むエンティティを含めるべき (SHOULD) です。ユーザーエージェントは、含まれているエンティティをユーザーに表示すべき (SHOULD) です。これらのレスポンスコードは、任意のリクエストメソッドに適用されます。

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

サーバーは、リクエストを完了できない予期しない条件に遭遇しました。

10.5.2 501 Not Implemented (未実装)​

サーバーは、リクエストを完了するために必要な機能をサポートしていません。これは、サーバーがリクエストメソッドを認識せず、任意のリソースに対してサポートできない場合の適切なレスポンスです。

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

サーバーは、ゲートウェイまたはプロキシとして動作しているときに、リクエストを完了しようとしてアクセスした上流サーバーから無効なレスポンスを受信しました。

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

サーバーの一時的な過負荷またはメンテナンスのため、サーバーは現在リクエストを処理できません。これは一時的な条件であり、一定の遅延の後に緩和されることを意味します。遅延の長さがわかっている場合、Retry-Afterヘッダで示すことができます (MAY)。Retry-Afterが指定されていない場合、クライアントは、500レスポンスの場合と同じようにレスポンスを処理すべき (SHOULD) です。

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

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

サーバーは、ゲートウェイまたはプロキシとして動作しているときに、リクエストを完了するためにアクセスする必要があった上流サーバーから、タイムリーにレスポンスを受信しませんでした。

注：このステータスコードと408 (Request Timeout) を区別することに注意してください。

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

サーバーは、リクエストメッセージで使用されたHTTPプロトコルバージョンをサポートしていない、またはサポートを拒否しています。サーバーは、このエラーメッセージを使用することを除いて、セクション3.1で説明されているように、クライアントと同じメジャーバージョンを使用してリクエストを完了できない、または完了する意思がないことを示しています。レスポンスには、そのバージョンがサポートされていない理由と、そのサーバーがサポートする他のどのプロトコルを記述するエンティティを含めるべき (SHOULD) です。

に最終更新