[4] 4xx
は、クライアント側の誤りを表す状態符号です。
[9] 4xx
は、クライアント (要求)
に起因する誤りのため要求の処理に失敗したことを表します。
[10] ここでクライアント起因というのは、
サーバー起因の 5xx
との対比です。
サーバーの予期せぬ不具合やサーバー側ネットワークの異常などの例外的な場合に
5xx
を使いますが、それ以外のほとんどの処理失敗は
4xx
を使います。
クライアントが要求を修正して再実行することで成功する可能性もありますが、
また失敗する可能性もあります。
クライアント起因とはいえ、失敗の責任がクライアントにあるとは限りません。
[5] サーバーは、 HEAD
要求の場合を除き、
誤りの状況と、状況が一時的か永続的かを説明した表現を送信するべきです
>>2。
[12] その具体的な形式は、規定されていません。 多くのサーバーは、自然言語で誤りを説明した短めの HTML を応答本体として送信します。
[13] 特定目的のサーバーは、独自の機械可読な形式を採用していることがあります。
[15] RFC 7807 は JSON 形式で誤りを説明する方法
application/problem+json
を定義しています。
[7] エラー時の状態符号は、次のように決定できます。 (それぞれの詳細な意味は、それぞれの項を参照。)
207
とします。451
とします。421
とします。[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>