Client Error

Edit New

状態符号群 4xx (HTTP)

[4] 4xx は、クライアント側の誤りを表す状態符号です。

仕様書

意味

[9] 4xx は、クライアント (要求) に起因する誤りのため要求の処理に失敗したことを表します。

[10] ここでクライアント起因というのは、 サーバー起因の 5xx との対比です。 サーバーの予期せぬ不具合やサーバー側ネットワークの異常などの例外的な場合に 5xx を使いますが、それ以外のほとんどの処理失敗は 4xx を使います。 クライアントが要求を修正して再実行することで成功する可能性もありますが、 また失敗する可能性もあります。 クライアント起因とはいえ、失敗の責任がクライアントにあるとは限りません。

[11] 例えば次のような状況が考えられます。

  • 認証に失敗した場合
  • 要求頻度制限を超過した場合
  • 要求に指定するべき引数が不足している場合
  • 要求に構文エラーが含まれる場合
  • 指定された前提条件をサーバー側で満たしていない場合
  • 指定されたファイルが存在しない場合
  • 新規作成を指示されたオブジェクトが既に存在する場合
  • 編集対象のファイルがロックされていて変更できない場合

構文

[5] サーバーは、 HEAD 要求の場合を除き、 誤りの状況と、状況が一時的か永続的かを説明した表現を送信するべきです >>2。

[12] その具体的な形式は、規定されていません。 多くのサーバーは、自然言語で誤りを説明した短めの HTML を応答本体として送信します。

[13] 特定目的のサーバーは、独自の機械可読な形式を採用していることがあります。

[14] 例えば、 WebDAV は XML の語彙を用意しています (DAV:error 参照)。

[15] RFC 7807 は JSON 形式で誤りを説明する方法 application/problem+json を定義しています。

[16] OAuth 2.0 は JSON 形式で誤りを報告する方法を規定しています。 error参照。

[17] その他いろいろな Web API が、それぞれの誤りの報告方法を用意しています。 特定のサーバー向けではない、汎用的な誤り報告用の形式を定めようとする試みも無くはないのですが、 誤りの状況や報告できる詳細情報が多種多様で、 HTTP の状態符号以上に細かな報告を標準化するのは中々難しいようです。

処理

[6] 利用者エージェントは、含まれている表現を利用者に表示するべきです >>2。

状態符号の決定

[7] エラー時の状態符号は、次のように決定できます。 (それぞれの詳細な意味は、それぞれの項を参照。)

  1. 複数の操作の一部がエラーなら、 207 とします。
  2. 検閲のため続行できないなら、 451 とします。
  3. サーバーが中間器なら、
    1. クライアントのアクセス権限の問題なら、
      1. HTTP認証上の問題なら、407 とします。
      2. それ以外の問題なら、 511 とします。
    2. HTTPキャッシュから結果を返す上での問題なら、 504 とします。
    3. 障害であれ予定されたメンテナンスであれ、上流に接続できないなら、 503 とします。
    4. 上流から応答を得られないなら、 504 とします。
    5. 上流からの得た応答が壊れているなら、 502 とします。
  4. 実効要求URLの URL scheme や authority がサーバー側の想定と異なるものなら、 421 とします。
  5. 対象となる資源が存在していないなら、
    1. 以前は存在していて、それを明らかにしても構わないなら、 410 とします。
    2. それ以外なら、 404 とします。
  6. クライアントのアクセス権限に問題があるなら、
    1. 理由や資源の存在自体を隠したいなら、 404 とします。
    2. HTTP認証上の問題があるなら、 401 とします。
    3. 課金上の問題があるなら、 402 とします。
    4. アクセス過多なら、 429 とします。
    5. その他の問題があるなら、 403 とします。
  7. 要求の解釈上の問題なら、
    1. 要求受信のタイムアウトなら、 408 とします。
    2. プロトコルの版の問題なら、 505 とします。
    3. 要求URLが長すぎるなら、 414 とします。
    4. Content-Length: が指定されていない (のをサーバーが処理できない) なら、 411 とします。
    5. ヘッダーが長すぎるなら、 431 とします。
    6. payload body が大きすぎるなら、 413 とします。
    7. payload body の MIME型や内容符号化に対応できないなら、 415 とします。
    8. payload body の構文解析上の問題なら、 400 とします。
    9. XML 外部実体の読み込みをサーバーが拒否したいなら、 403 とします。
  8. 要求の指定する処理の問題なら、
    1. プロトコル選択の問題なら、 426 とします。
    2. Expect: の要求に対応できないなら、 417 とします。
    3. 条件付き要求的に結果を返せ(さ)ない場合、 412 または 304 とします (条件付き要求参照)。
    4. 条件付き要求でなければならないのにそうでないなら、 428 とします。
    5. 範囲要求的に結果を返せない場合、 416 とします。
    6. 内容折衝的に結果を返せない場合、 406 とします。
    7. 要求メソッドを適用できないなら、
      1. 本資源には適用できない既知のメソッドなら、 405 とします。
      2. そうでないなら、 501 とします。
    8. 未知の指示が含まれているなら、 501 とします。
    9. 実装上の都合で実施できない操作なら、 502 とします。
    10. その他適用できない操作なら、 418 とします。
  9. 対象となる資源の現状と要求との不整合が問題なら、
    1. payload body で指定された処理の指示に問題があるなら、 422 とします。
    2. ロックのため処理できないなら、423 とします。
    3. その他処理に必要な事前の条件が整わないなら、 424 とします。
    4. 処理中に無限ループが発生するなら、 508 とします。
    5. その他の問題があるなら、 409 とします。
  10. 以上のいずれも該当しないなら、
    1. サーバーの透過内容折衝の設定に問題があるなら、 506 とします。
    2. サーバーのディスク容量の問題なら、 507 とします。
    3. その他サーバーのトラブルなら、 500 とします。
    4. それ以外なら、 400 とします。
[8] 複数該当するものがある場合、多くの場合には、サーバーの判断でどれを返すか決定できます。

歴史

[3] RFC 1945 (HTTP/1.0) 9.4; RFC 2068 & 2616 (HTTP/1.1) 10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to have erred. {1945} If the client has not completed the request when a 4xx code is received, it should immediately cease sending data to the server. Except when responding to a HEAD request, the server {1945} should {2068} SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. {2068} User agents SHOULD display any included entity to the user.

4xx 級の状態符号は、クライアントが誤っていると思われる場合に使うことを意図しています。 クライアントが 4xx 符号を受信した時に要求が完了していなければ、クライアントは即座にサーバーへのデータの送信を止めるべきです。 HEAD 要求に対する応答の場合を除き、サーバーは誤り状況の説明と、 一時的条件なのか永続的条件なのかを含んだ実体を含めるべきです。 これらの状態符号はどの要求 method についても適用できます。 ル容赦エージェントは含まれている実体を利用者に表示するべきです。

{1945,2068} Note: If the client is sending data, {2068} a server implementations {1945} on {2068} using TCP {1945,2068} should {2616} SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, {1945} prior to closing {2068} before the server closes the input connection. If the client continues sending data to the server after the close, the server's {1945} controller {2068} TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application.

クライアントがデータを送信している時、 TCP を使っているサーバー実装は、サーバーが入力接続を閉じる前にクライアントが応答を含んでいるパケットの受信に確実に肯定応答するよう注意するべきです。 閉じた後もクライアントがサーバーにデータを送り続けるなら、 サーバーの TCP スタックはクライアントに再設定 (リセット) パケットを送信することとなり、 クライアントの否定応答入力バッファを HTTP 応用により読んで解釈することが出来る前に消去してしまうかもしれません。

[1] Extended HTTP Error Codes ( ( 版)) <http://www.gumbyware.com/~eric/http-errors.html>

関連

[432] 4xx はクライアントの要求に関するエラーを表し、 5xx が鯖側のエラーを表します。

Updated: