この頁では、HTTP/1.1仕様書などで定義されているHTTPステータスコードについて、その意味や使用例について解説します。
400 Bad Request401 Unauthorized402 Payment Required403 Forbidden404 Not Found405 Method Not Allowed406 Not Acceptable407 Proxy Authentication Required408 Request Timeout409 Conflict410 Gone411 Length Required412 Precondition Failed413 Request Entity Too Large414 Request-URI Too Long415 Unsupported Media Type416 Requested Range Not Satisfiable417 Expectation Failed418420, 421422 Unprocessable Entity423 Locked424 Failed Dependency425 (Reserved for WebDAV advanced collections expired proposal)426 Upgrade Required428 Precondition Required429 Too Many Requests431 Request Header Fields Too Large451 Unavailable For Legal ReasonsHTTP通信（リクエスト-レスポンス一覧の流れ）と、その中で使われる「(HTTP)ステータスコード」については、以下の図のような関係になっています。
HTTPの仕様書であるRFC 2616の中では、「(HTTP)ステータスコード」について説明がされています。 section 6.1.1をご覧ください。
ステータスコード要素とは、リクエストを理解し満足するための試行についての三桁の数字による結果コードである。 これらのコードは、section 10 にて完全に定義されている。 説明句は、ステータスコードについて短いテキスト記述を与える目的を持つ。 ステータスコードは自動処理によって、また説明句は人間によってそれぞれ使われる事を意図している。
HTTPステータスコードとは、リクエストに対する「レスポンスの意味」を、文書を解析することなく、コンピュータが自動的に処理できるようにする（※）ための3桁の値です。 この場合の「レスポンスの意味」とは、たとえば以下のようなものを表します。
（※）人間が理解するための情報は説明句に含まれています。
ここからは、HTTPステータスコードの構成について、より詳しく見ていくことにしましょう。 RFC 2616のsection 6.1.1を引き続きご覧ください。
ステータスコードの最初の数字はレスポンスのクラスを定義する。 後ろの二つの数字はどんな分類規定も持たない。 最初の数字には五つの値がある。
- 1xx: Informational - リクエストは受け入れられ、処理を続けている
- 2xx: Success - 動作は正常に受信され、理解され、受け入れられた
- 3xx: Redirection - リクエストを完了するためには、さらに動作を行わなければならない
- 4xx: Client Error - リクエストは間違った構文か、果たす事のできないものを含んでいる
- 5xx: Server Error - サーバは明白に明らかにリクエストを果たすのに失敗した
HTTPステータスコードは、一桁目が1〜5になっており、それぞれ意味が異なります。 このような意味づけ方法は、なにもHTTPが元祖というわけではなく、たとえばHTTPのアイデアの元になっているFTPにもあります。 FTPの仕様書であるRFC 959をご覧ください。
FTP 応答は、(三文字の英数字として送信される) 三桁の十進数といくらかの文章から成る。 数値の方は、その次に進むために今がどんな状態かを決定するためにコンピュータによって使用されるためのものである; これに対し、文書の方は、人間のユーザのためのものである。 三桁の数値は、ユーザ側プロセス (ユーザ側プロトコルインタプリタ) が文書を解析する必要もなく、またそれを破棄したり、ユーザに渡したりを適切に行えるような十分な情報を含むように意図されている。
ただし、FTPのレスポンスコードは、三桁のうち一桁目と二桁目にそれぞれ意味がありますが、HTTPステータスコードは一桁目にしか意味がないところが異なっていることがわかります。
また、section 6.1.1には、RFC 2616で定義されているすべてのHTTPステータスコード、およびそれ以外のステータスコードを拡張することについても記載されています。
HTTP/1.1 で定義された個々のステータスコード数値、及びそれに相当する説明句のセットの例の値を以下に示す。 ここでリストされた説明句は推奨に過ぎない。 すなわち、これらはプロトコルに影響が出ないローカルな範囲で、それに相当するものに置き換えてもよい。
（略）
HTTP ステータスコードは拡張可能である。 HTTP アプリケーションは、登録されたすべてのステータスコードを明確に理解できる事が望ましいが、それらのすべての意味を理解する必要はない。 しかし、アプリケーションは最初の数字によって示されるステータスコードのクラスはすべて理解しなければならないし、理解できないレスポンスはキャッシュしてはならないという例外を除いて、すべての理解できないレスポンスをそのクラスの x00 ステータスコードと同等に扱わなければならない。 例えば、431 という理解できないステータスコードがクライアントに受信されたなら、そのリクエストに何か誤りがあると安全に推測ができ、それが 400 ステータスコードを受信したかのようにレスポンスを扱う事ができる。このような場合、エンティティはこの異常なステータスを説明しているであろう人間が読める情報を含んでいると思われるから、ユーザエージェントはレスポンスと共に返されたエンティティをユーザに見せるべきである。
HTTPステータスコードは、仕様書に定義されているもの以外にも、独自に拡張ができます。 たとえば、HTTP/1.1の拡張であるWebDAVでは、RFC 2616で定義されていないステータスコードが独自に定義されています。 そのため、将来的なHTTPを拡張するプロトコルが、過去に定義済みのステータスコードを使用しないように、IANAが“HTTP Status Code Registry”を用意して、重複がないように管理をしています。
この頁では、「HTTP Status Code Registryに登録されているHTTPステータスコード」および「過去に定義・提案されたことのあるHTTP/1.1（あるいはその拡張の）ステータスコード」について、解説します。
（※） 但し、過去に提案されたものの中には、現在は既に利用されていないものも含みます。
このステータスコードのクラスは一時的なレスポンスを示し、ステータスラインとオプション的なヘッダからのみなり、空行で終了する。 このステータスコードのクラスのための必要なリクエストヘッダは無い。 HTTP/1.0 では、どんな 1xx ステータスコードも定義していないので、サーバは実験的な状況下以外では HTTP/1.0 クライアントに 1xx レスポンスを送ってはならない。
クライアントは、例え 100 (Continue) ステータスメッセージを期待していなかったとしても、通常のレスポンスの前の一つ以上の 1xx レスポンスを受け入れるよう準備されていなければならない。 ユーザエージェントは、期待していない 1xx レスポンスを無視する事ができる。
プロクシは、もしプロクシとクライアント間の接続が切断されている、あるいはプロクシ自身が 1xx レスポンスの生成を要求したという場合以外は、1xx レスポンスを転送しなければならない。 (例えば、プロクシがリクエストを転送する時に
"Expect: 100-continue"というフィールドを付け加えた時には、それに相当する 100 (Continue) レスポンスを転送する必要はない。)
1xxレスポンスは、HTTP/1.1以降のみで使用されるステータスコードです。 1xxレスポンスにはメッセージボディを含みません。
100 Continueリクエストヘッダだけを受け取ったサーバが、引き続きリクエストボディを受け取ることを表明するときに使うステータスコードです。 詳しくは、「リクエスト継続」を認める場合をご覧ください。
101 Switching Protocols通信のために使用するプロトコルを、HTTP/1.1から他のものへ「アップグレード」する際に使うステータスコードです。 詳しくは、通信プロトコルをHTTPから切り替える場合をご覧ください。
102 ProcessingWebDAVのために定義されたステータスコードで、「リクエストは受け付けたが、まだ処理が終わっていない」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
このステータスコードのクラスは、クライアントのリクエストがうまく受信され、理解され、そして受け入れられた事を示す。
2xxレスポンスは、クライアントのリクエストが成功したことを示します。
200 OKリクエストは成功した。 レスポンスと共に返される情報はリクエストに使用されたメソッドに依存し、例えば以下の様になる。
GET- リクエストされたリソースに対応するエンティティがレスポンスとして送られる。
HEAD- リクエストされたリソースに対応するエンティティヘッダフィールドがメッセージボディを伴わずにレスポンスとして送信される。
POST- 動作の結果を記述もしくは含んでいるエンティティ
TRACE- 端末サーバによって受信されたリクエストメッセージを含んでいるエンティティ
リクエストの成功を意味します。 レスポンスボディとして返されるものの意味は、HTTPメソッドによって異なります。
201 Createdリクエストは果たされ、結果として新しいリソースが作成された。 新しく作成されたリソースは Location ヘッダにより与えられるリソースに対する最も明確な URI を伴って、レスポンスのエンティティにおいて返される URI によって参照される。 レスポンスは、ユーザあるいはユーザエージェントが最も適切なものを選択するために、リソースの特徴と場所のリストをエンティティとして含むべきである。 エンティティのフォーマットは、Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定される。 オリジンサーバは、201 ステータスコードを返す前にリソースを作成しなければならない。 もし動作がすぐに実行できないのであれば、サーバは代わりに 202 (Accepted) レスポンスを返すべきである。
PUTメソッドによって、リソースが新たに生成された場合に使用されます。 202レスポンスとの違いに注意して下さい。
202 Acceptedリクエストは処理のために受け入れられたが、処理は完了されていない。 このリクエストは、実際に処理される時に拒否されるかもしれないので、最終的に動作されるかどうかは不明である。 このような非同期操作からステータスコードを再送信するための機能は存在しない。
202 レスポンスは、意図的に責任を持たない{non-committal}。 これはサーバが、プロセスが完了されるまでユーザエージェントとの接続を持続させる事無く、他のいくつかのプロセス (多分一日に一度しか実行されないバッチ指向プロセス{batch-oriented process}) のためのリクエストを受け入れる事を可能にするという目的を持つ。 このレスポンスによって返されるエンティティは、リクエストの現在の状態を表すものと、状態モニタへのポインタ、あるいはそのリクエストがいつ果たされるかをユーザが予期できる見積もりのどちらかを含むべきである。
このレスポンスも、PUTメソッドへのレスポンスですが、201ステータスと異なる点は、リクエストを受け付けた時点ではまだサーバ上にリソースが生成されておらず、またリソースが生成される事が保証されてもいない (すなわち、最終的にはそのリクエストが拒否されるかもしれない) ので、注意が必要です。
ただし、レスポンスのエンティティボディには、生成されるかどうかを確認するためのモニタ（たとえばURL）や、いつ頃までにリクエストが生成されるか、あるいはそれを過ぎても実現していなければ、そのリクエストは破棄されたと考えることができるような時間などが返されるでしょう。
203 Non-Authoritative Informationエンティティヘッダにおいて返された外部情報は、オリジンサーバから利用できるような決定的なセットではなく、ローカルもしくはサードパーティコピーから集められたものである。 提示されたセットは元のバージョンのサブセットかスーパーセットであろう。 例えば、リソースについてのローカルな注釈情報を含む事はオリジンサーバによって知らされる外部情報のスーパーセットとなるかもしれない。 そのレスポンスが 200 (OK) とは別の方法で示したい場合、このレスポンスコードを使用する必要はないが、そのような場合にのみ適切である。
このレスポンスヘッダは、オリジンサーバが発行したものではなく、ローカルあるいはプロクシなどからもたらされたものです。
このような場合でも、通常であれば200レスポンスをもって応答することは可能ですが、特にプロクシからの応答であると明示したい場合のみ203を使用してもかまいません。
204 No Contentサーバはリクエストを受け入れたが、エンティティボディを送り返す必要は無く、更新された外部情報を返す事を望むだろう。 レスポンスは、エンティティヘッダ形式の中に、新規あるいは更新された外部情報を含む事ができ、もしあればリクエストされたバリアントが関連付けられるべきである。
もしクライアントがユーザエージェントなら、リクエストの送信をもたらした状態からその文書画面{view} を変えるべきではない。 このレスポンスは主に、ユーザエージェントの現在の{active} 文書画面ビューを変える事無く、動作を起こすための入力をさせる意図を持つが、どんな新規あるいは更新された外部情報もユーザエージェントの現在の画面中にある現在の文書に適用されるべきである。
204 レスポンスは メッセージボディを含んではならない ので、常にヘッダフィールドの後の最初の空行で終了する。
リクエストそのものは成功しましたが、返すべきレスポンスボディは存在しませんし、またいかなるレスポンスボディも返してはいけません。 そのリクエストがブラウザ等から送られたものである場合、レスポンスを受信してもその表示画面は変更されないでしょう。
205 Reset Contentサーバはリクエストを受け入れたので、ユーザエージェントは送信されたリクエストをもたらした現在の画面をリセットすべきである。 このレスポンスは主に、ユーザが別の入力動作を簡単に始められるように、入力が与えられたフォームをクリアして、ユーザの入力経由で動作を起こすための入力をさせる意図を持つ。 レスポンスはエンティティを含んではならない。
リクエストは成功しました。 サーバは、ユーザエージェントがその後の操作を始め易いように、このレスポンスをもって、現在の画面をリセットするように薦める事ができます。 但し、この時、サーバはいかなるレスポンスボディも返してはいけません。
206 Partial Contentリソースの範囲リクエスト（部分的GETリクエスト，レジューム）が成功した時に見られるステータスコードです。 返されるレスポンスボディは、Content-Rangeにて指定された範囲のエンティティになります。 詳しくは、部分的レスポンスに成功した場合をご覧ください。
207 Multi-StatusWebDAVのために定義されたステータスコードで、「リクエストの結果は、複数の終了ステータスを持っている」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
208 Already ReportedWebDAVのために定義されたステータスコードで、「リクエスト先は複数のバインディング{binding}を持っており、リクエストのステータスは既に応答済みである」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
226 IM Used
RFC 3229で定義されたステータスコードで、「サーバが『インスタンス（現時点でのエンティティ）』に対して差分コーディングを行い、その差分を返した」ことを表します。
詳しくは、差分コーディングを含むレスポンス（226レスポンス）をご覧ください。
このステータスコードのクラスは、リクエストを果たすためにはユーザエージェントによって更なる動作が行われる必要がある事を示す。 二番目のリクエストで使われたメソッドが GET か HEAD である場合にのみ、ユーザとの相互動作無しに、ユーザエージェントによって要求された動作を実行する事ができる。 リダイレクションループによって各々のリダイレクションはネットワーク渋滞を生み出す事になるので、クライアントは無限リダイレクションループを発見すべきである。
注: この仕様書の前のバージョンでは、5 回のリダイレクションを最大として推奨している。 内容開発者{Content developers} は、そのような修正された制限を実装したクライアントがあるであろう事を意識すべきである。
3xxレスポンスは、リクエストを完了するために、クライアントは更なる動作を行うことが必要であることを示しています。 このレスポンスでは、多くの場合Locationを伴っているので、これを適切に扱う必要があります。
300 Multiple Choicesサーバは、リクエストに含まれるユーザ情報からサーバ駆動型ネゴシエーションを行いましたが、ユーザ情報が足りないため、該当するリソースが複数ヒットしています。 そのため、クライアントがリクエストを完了するためには、該当リソースのうちどれが欲しいかを選択する必要があります。 詳しくは、レスポンスとして、複数のリソースから選択を要求する場合をご覧ください。
301 Moved Permanentlyリクエストされたリソースは新しい恒久的な URI に割り当てられたので、以降そのリソースへの参照は返された URI の一つを使用すべきである。 リンク編集機能を持つクライアントは、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべきである。 このレスポンスは、別のものを示しているのでなければキャッシュ可能である。
新しい恒久的 URI は、レスポンス内の Location フィールドによって与えられるべきである。 リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキス トの注釈を含むべきである。
リソースの恒久的な移動を意味します。 たとえば、もしURIをブックマークをしているような場合、そのリソースはLocationで与えられた先に移動してしまったので、ブックマークを更新しましょう。
（※）なお、ステータスコードが302だった場合は、「一時的な移動」という意味であり、いずれ現在のURIに復帰するはずなので、ブックマークを変更しない方がよいでしょう。
301レスポンスは、本来ディレクトリ（フォルダ）を指定するURIなのに、最後の“/”（スラッシュ）がないリクエストの場合に発生します。
たとえば、http://www.studyinghttp.net/ 以下の“example”というディレクトリにアクセスする際に、リクエストURIとしてhttp://www.studyinghttp.net/exampleのように「最後のスラッシュを付けないリクエストを行う」場合です。
この場合、通信シーケンスは以下のようになります。
図中の(2)〜(4)は、明らかに無駄な処理であることがわかります。 ほとんどのユーザエージェントは、(3)を受け取ってもユーザに見せることなく、(4)を発行してしまうので、このような仕組みに気がつかれない方も多いかもしれませんが、通信経路への負荷、あるいは対象サーバへの負荷を少しでも下げるために、ディレクトリにリクエストする場合、あるいはHTML内にディレクトリへのリンクを記述する場合は、必ず最後のスラッシュを付けましょう。
（※） 図中の(3)で、たとえばConnection: closeといったヘッダが付加されていた場合、(3)の終了後に一度TCP接続が切断されています。 この後、図中(4)で、再びTCP接続を確立しようとするわけですが、TCPにおいては「接続を確立する」という作業が、通信の一連の流れにおいて最も大きく時間を割くものであり、またサーバに大きな負荷を与える原因となります。 URIを正しく指定することで、このような無駄な通信が発生することはなくなりますので、このような場合のリクエストやリンクを記述する場合、「最後のスラッシュがついているか」の確認をするようにしてください。
302 Foundリクエストされたリソースは、一時的に別の URI に属している。このリダイレクションは場合によって変更されるかもしれないので、クライアントは将来のリクエストではその Request-URI を使い続けるべきである。 このレスポンスは Cache-Control か Expires のどちらかのヘッダフィールドによって期限が示されている場合にのみキャッシュ可能である。
一時的 URI は、レスポンス内の Location フィールドによって与えられるべきである。 リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの注釈を含むべきである。
もし 302 ステータスコードが GET や HEAD 以外のリクエストのレスポンスとして受信されたら、リクエストが発行された時点の条件から変わっているかもしれないため、ユーザエージェントはユーザに確認されなければ、リクエストを自動的にリダイレクトしてはならない。
注: RFC 1945 や RFC 2068 では、クライアントはリダイレクトするリクエストのメソッドを変えてはならないと明確に述べられている。 しかしながら、多くの既存ユーザエージェントは 302 レスポンスをまるで 303 レスポンスのようにみなし、元々のリクエストメソッドにかかわらず Location フィールド値へと GET を行う。 ステータスコード 303 と 307 は、クライアントが期待する反応の種類を明確にしたいというサーバのために加えられた。
302の説明句は、RFC 2068ではMoved Temporarilyと定義されていました。
301との違いですが、301では「そのリソースは『恒久的に』移動しており、その保存先はLocationに示されるURI」というのに対し、302では「そのリソースが『現時点で』保存されているのは、Locationに示されるURI」ということを示しています。
301の場合と違い、Locationの値はあくまで現時点でのリソースの場所でしかなく、将来は変更される可能性があるので、たとえばもしブックマークをしているような場合でも、リクエストは現時点のURIに対して発行すべきです。
ユーザエージェントは、エンドユーザに確認せずにリクエストをリダイレクトできますが、その際にはメソッドを変えてはならないし、またGETやHEADといった安全なメソッド以外は、エンドユーザへの確認なしにリダイレクトしてはなりません。
しかし、実際にはこれらの規則は守られていないのが現状なので、新たに303と307、さらに308というステータスコードが追加されました。
303 See Otherリクエストに対するレスポンスは別の URI の元から発見でき、このリソースを GET メソッドを使用して回収すべきである。 このメソッドは、主に POST によって活性化される {POST-activated} スクリプトの出力が選択されたリソースへユーザエージェントをリダイレクトできるようにするために存在する。 新しい URI は元々リクエストされたリソースに対する代わりの参照ではない。 303 レスポンスはキャッシュ可能してはならない が、二番目の (リダイレクトされた) リクエストへのレスポンスはキャッシュ可能である。
異なる URI は、レスポンス内の Location フィールドによって与えられるべきである。 リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの注釈を含むべきである。
注: 多くの HTTP/1.1 以前のユーザエージェントは 303 ステータスを理解できない。 そのようなクライアントと相互通信する時、ほとんどのユーザエージェントは 302 レスポンスを 303 レスポンスのように扱うので、302 レスポンスコードが代わりに使われるであろう。
たとえば、「bbs.cgiという掲示板に投稿した後で、log.htmlというログファイルにリダイレクトさせたい」とします。
こういう場合には、典型的に302というステータスコードが使用されていました。
しかし、こういう場合に302を使用してしまうのは、本来は不適切な使い方なのです。
何故なら、bbs.cgiには投稿すべきデータを投稿するためにPOSTメソッドを使用しますが、log.htmlには投稿すべきデータはなく、ただデータを回収するためにGETメソッドを使用することになるからです。
そこで、HTTP/1.1では、新たに303というステータスコードを用意しました。
302では、リダイレクトの際にリクエストメソッドを変更してはいけないとされているので、このような使い方のためには新たなステータスコードを用意する必要があったのです。
上のような例の場合は303を使用すべきです。
304 Not Modifiedクライアントが条件付き GET リクエストを実行し、アクセスは許可されたがその文書は更新されていなかった場合、サーバはこのステータスコードもって応答すべきである。
304レスポンスはレスポンスボディを含んではならないので、いつもヘッダフィールドの後の最初の空行で終了する。
クライアントが条件付きGETを行った場合に、リソースが更新されていなければ、このステータスコードが返されます。
304レスポンスでは、いかなるレスポンスボディも返してはいけません。
305 Use Proxyリクエストされたリソースは Location フィールドによって与えられるプロクシを通してアクセスされなければならない。 Location フィールドはプロクシの URI を与える。 受信側はプロクシ経由で単一のリクエストを再送信する事を期待する。 305 レスポンスはオリジンサーバによってのみ生成されなければならない。
注: RFC 2068 では、305 は単一リクエストをリダイレクトさせようとする事、またオリジンサーバによってのみ生成される事は明確にしていない。 これらの制限がセキュリティの上で重要な意味を持つという事を認識していなかったためである。
305レスポンスの場合、Locationの値は「リダイレクト先のURI」ではなく、「使用するプロクシのURI」となります。
そのリソースがあるオリジンサーバ上の場所が変更されているわけではないということに注意して下さい。
306 (Unused)306 ステータスコードは前のバージョンの仕様書では使われていたが、もはや使われておらず、将来のために予約されている。
ステータスコード306は、現在のHTTP/1.1仕様書では定義されていませんが、HTTP Status Code Registryで予約されていますので、勝手に利用することはできません。
（※） 過去のインターネットドラフトでは、306 Switch Proxyというステータスコードが提案されたことがありますが、現在は期限切れとなっています。
307 Temporary Redirectリクエストされたリソースは、一時的に別の URI に属している。 このリダイレクションは場合によって変更する事ができるので、クライアントは将来のリクエストではその Request-URI を使い続けるべきである。 このレスポンスは Cache-Control か Expires のヘッダフィールドによって期限が示される場合にのみキャッシュ可能である。
一時的 URI は、レスポンス内の Location フィールドによって与えられるべきである。 多くの HTTP/1.1 以前のユーザエージェントは 307 ステータスを理解できないので、リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの注釈を含むべきである。 それ故に、その注釈にはユーザが新しい URI に元々のリクエストを繰り返すために必要な情報を含むべきである。
もし 307 ステータスコードが GET や HEAD 以外のリクエストのレスポンスとして受信されたら、リクエストが発行された時点の条件から変わっているかもしれないため、ユーザエージェントはユーザに確認されなければ、リクエストを自動的にリダイレクトしてはならない。
上の文をよく読んでいただけるとわかるかと思いますが、これは302と全く同じ意味を持ちます。
すなわち、「本来302が持つべき意味を持つ」あるいは「典型的に使用されている意味の302とは明確に区別したい」場合に特に307を使用することができます。
古いユーザエージェントは、307を理解できないかもしれません。
そのような場合、そのユーザエージェントは300レスポンスと同様に扱うはずですので、レスポンスのエンティティに新しいURIへのハイパーリンクを持った短いハイパーテキストの注釈を含んでおくとよいでしょう。
308 Permanent Redirectこのステータスコードは、インターネットドラフト“The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)”の中で提案されているステータスコードです。
HTTPは、異なるURI（[RFC3986]）へリクエストを転送する目的で一組のステータスコードを定義する。 これらのステータスコードの歴史は、[draft-ietf-httpbis-p2-semantics]のSection 7.3に要約されているが、既存のステータスコードを4つのカテゴリーに分類する。
このカテゴリーの1番目にはステータスコード301 (Moved Permanently), 302 (Found), 307 (Temporary Redirect)を含んでおり、以下のように分類することができる。
恒久的 一時的 リクエストメソッドをPOSTからGETに変更することを認める 301 302 リクエストメソッドをPOSTからGETに変更することを認めない - 307 [draft-ietf-httpbis-p2-semantics]のSection 7.3.7では、HTTPはステータスコード307の恒久的なバリアントを定義しないと述べている; 本仕様書ではステータスコード308を追加し、この失われたバリアントを定義する（Section 3）。
対象のリソースは新たな恒久的URIを割り当てられたので、そのリソースへの以降の参照は返されるURIの一つを使用すべきである。 リンク編集機能を持つクライアントは、可能であればサーバから返される新たな参照のうち一つ以上の有効なリクエストURI（[draft-ietf-httpbis-p1-messaging]のSection 5.5参照）の参照へ自動的に再リンクすべきである。
（中略）
新たな恒久的URIは、レスポンス内のLocationフィールドによって与えられるべきである（[draft-ietf-httpbis-p2-semantics], Section 10.5）。 レスポンスの内容には、新たなURIへのハイパーリンクを持つ短いハイパーテキストの注釈を含むことができる。
注: このステータスコードは、301 Moved Permanently ([draft-ietf-httpbis-p2-semantics]のSection 7.3.2)と似ているが、リクエストメソッドをPOSTからGETに書き換えることを許していない点が異なる。
つまり、ステータスコード308とは「301 (Moved Permanently)と同じく『リソースが恒久的に移動したこと』を表し、特に『リダイレクト時にHTTPメソッドをPOSTからGETに変更してはならない』ことを通知する場合に使用する」ものとして、現在提案されています。
しかしながら、現在多くのユーザエージェントはステータスコード308は理解できず、300 (Multiple Choices)のように扱ってしまうはずですので、レスポンスボディには以下のようなHTMLを含むべきとされています。
クライアントのリクエスト:
GET / HTTP/1.1
Host: example.com
サーバのレスポンス:
HTTP/1.1 308 Permanent Redirect
Content-Type: text/html; charset=UTF-8
Location: http://example.com/new
Content-Length: 454
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Permanent Redirect</title>
<meta http-equiv="refresh" content="0; url=http://example.com/new">
</head>
<body>
<p>
The document has been moved to <a href="http://example.com/new">http://example.com/new</a>.
</p>
</body>
</html>
（※） ただし、このインターネットドラフトの最新版は、2012年9月27日で期限切れとなっています。
350このステータスコードは、WIREというプロトコルで提案されたものです。 WIREでは、あるURIを別のURIに変換するものを「リゾルバ」と呼び、このリゾルバを複数組み合わせることで、URIの永続性を確保するためのプロトコルとして提案されました。
（※） WIREについてのインターネットドラフトの最新版は、1998年9月18日で期限切れとなっています。
WIREでは、URIに引数を伴うか、hint: "hint"というヘッダを用いて、リゾルバへGETリクエストを行います。
この時、リゾルバが別のリゾルバへのリクエストを促すようなレスポンスを返したい時に350レスポンスを返します。
_____________________
GET | | Standard
URI[?argument] --->| Right Resolver? | Yes ---> HTTP
[hint: "hint"] |_____________________| Response
^ | No | Error
| | |
| v v
+------- 350 Redirect 400 Bad Request
通信例を以下に示します。
> Request; GET urn:cid:9802032044@thebe.lcs.mit.edu HTTP/1.0 Host: urn.org Optional: "urn:specs:WIRE/0.0" > Response; HTTP/1.0 350 Resolution Delegated Resolver-Location: "";"res-hint:http://thebe.lcs.mit.edu/;scope=urn:cid:"
（※）通信例から見て、このプロトコルはURNを想定して提案されたものだと考えられます。
ステータスコードの 4xx クラスは、クライアントが間違えているような場合を示す。 HEAD リクエストへのレスポンスを除き、サーバはエラー状況が一時的か恒久的かに拘わらず、エラー状況の説明を含むエンティティを返すべきである。 これらのステータスコードは、あらゆるリクエストメソッドに適用されうる。 ユーザエージェントは、含まれるエンティティすべてをユーザに表示すべきである。
もしクライアントがデータを送信している最中ならば、TCP を使用しているサーバ実装は、サーバが入力接続を切断する前に、レスポンスを含んでいるパケットの受領をクライアントが認識できる事を保証するために気を配るべきである。 もし切断後にもクライアントがサーバにデータを送信し続けていたら、サーバの TCP スタックはクライアントにリセットパケットを送り、これによって、HTTP アプリケーションがリクエストを読み出して中間処理する前に、クライアントの認識されない入力バッファを消去するだろう。
4xxレスポンスは、クライアント側に原因のあるエラーがあることを示しています。
400 Bad Requestリクエストは、不正な構文のためサーバに理解されなかった。 クライアントは、修正しないままでそのリクエストを再送信すべきではない。
リクエストの構文が間違っています。 たとえば、リクエストヘッダの中にHostヘッダがない場合に、このレスポンスが返されます。
401 UnauthorizedHTTPアクセス認証において、オリジンサーバへのユーザ認証が必要な場合に返すステータスコードです。 詳しくは、オリジンサーバへのユーザ認証が必要な場合をご覧ください。
402 Payment Requiredこのコードは、将来の使用のため予約されている。
402は、「有料ページへのアクセス」を想定して、初期のHTTPドラフトから予約されているステータスコードですが、実際にその中身が定義されたことはありません。
403 Forbiddenサーバはリクエストを理解したが、それを実行する事を拒否した。 認証は役に立たないであろうから、リクエストは繰り返されるべきではない。 リクエストメソッドが HEAD で無い時に、サーバはなぜリクエストが実行されなかったかを公にしたいならば、エンティティにおいて拒否の理由を記すべきである。 サーバはこの情報をクライアントに利用されたくないならば、ステータスコードとして 404 (Not Found) を代わりに使う事が出来る。
メソッドの実行は、サーバによって禁止されています。 禁止の理由を明かす必要はありませんが、明かしたければエンティティボディにて記述することができます。
404 Not Foundサーバが、 Request-URI に一致するものを見つけられなかった。 その状態が一時的か恒久的かに拘わらず、与えられる指示はない。 もしサーバが、ある内部に組み込まれているメカニズムを通して、古いリソースが恒久的に利用できず、それを転送するためのアドレスも無いという事を知っていたら、410 (Gone) ステータスコードが使用されるべきである。 このステータスコードは一般に、サーバが何故リクエストが拒否したかを正確には表したく無い時、あるいは他に適切なレスポンスが無い時に使われる。
サーバがそのリクエストに対応するリソースを見つけられなかった場合に返すステータスコードです。 ですが、それ以外にも、リクエストは拒否したいがその理由は明かしたくない場合や、リクエストは拒否したいが他に適切なレスポンスが無い場合にも使用可能です。
405 Method Not Allowedリクエストラインに記述されたメソッドは、 Request-URI によって識別されるリソースに許可されていない。 レスポンスは、リクエストされたリソースへ適用できるメソッドのリストを含む Allow ヘッダを含まなければならない。
そのRequest-URIにあるリソースは、使用されたメソッドを許可していません。
例えば、GETでのリクエストしか許可されていないリソースに、POSTでリクエストした場合、このステータスコードが返されます。
なお、この時に使用可能なメソッドはレスポンス中のAllowヘッダに含まれます。
また、これに似たステータスコードとして、501 Not Implementedがありますが、405は「実装はされてはいるが実行は禁止」という意味であることに対し、501は「機能が実装されていないので実行不能」という意味でそれぞれ定義されていますので、正しく使い分けましょう。
406 Not Acceptableリクエストに含まれるユーザ情報からサーバ駆動型ネゴシエーションを行ったものの、該当するリソースがない場合に返すステータスコードです。 詳しくは、レスポンスとして、ふさわしいリソースを保持していないと判断した場合をご覧ください。
407 Proxy Authentication RequiredHTTPアクセス認証において、プロクシへのユーザ認証が必要な場合に返すステータスコードです。。 詳しくは、プロクシへのユーザ認証が必要な場合をご覧ください。
408 Request Timeoutクライアントは、サーバの待ち時間内にリクエストを発行しなかった。 クライアントは、それ以降に修正しないでリクエストを繰り返してもよい。
リクエストが時間以内に完了していない場合に返されます。
このレスポンスは、例えばリクエストの終末に CRLF がない場合に見られます。
409 Conflictリクエストは、リソースの現在の状態との矛盾のため完了できなかった。 このコードは、ユーザが矛盾を解決し、リクエストを再提出できる事が期待できる状況のみに許される。 レスポンスボディには、ユーザが矛盾の原因を認識するための十分な情報を含むべきである。 理論的には、そのレスポンスエンティティはユーザやユーザエージェントが問題を修正するための十分な情報を含んでいるであろうが、実際それは不可能だろうしその必要もない。
矛盾は、PUT リクエストへのレスポンス時に最も発生しやすい。 例えば、もしバージョン処理{versioning} が使用され、PUT されているエンティティが初期 (サードパーティ) のリクエストによって作られたものと矛盾しているリソースに変わるものを含んでいるならば、サーバはリクエストが完了できない事を示す 409 レスポンスを使用できる。 この場合、レスポンスエンティティにはおそらく、レスポンスの Content-Type によって定義されるフォーマット中で二つのバージョンの違いについてのリストを含むであろう。
そのリクエストがリソースの現在の状態と矛盾している場合に使用します。 このステータスコードは、HTTPの仕様書であるRFC 2616の中で定義されていますが、WebDAVでよく使われています。 詳しくは、WebDAVステータスコードをご覧ください。
410 Goneリクエストされたリソースは、もはやそのサーバでは利用できないし、転送先のアドレスも分からない。 この状況は、恒久的なものとみなされるであろう。 リンク編集機能を持つクライアントは、ユーザから承認を得た後にリクエスト URI の参照を削除すべきである。 サーバがその状況が恒久的なものかどうかを、知らないか、あるいはそれを決定するための能力が無いのであれば、代わりにステータスコード 404 (Not Found) が使用されるべきである。 別の方法が示されなければ、このレスポンスはキャッシュできる。
410 レスポンスは主に、リソースが故意に利用不可能であったり、サーバのオーナーがリソースへのリモートリンクを削除したい事を受信者に通知する事でウェブメンテナンスの作業を補助する意図を持つ。 そのような事は、期間限定の宣伝サービスや、サーバのサイト内でもはや働いていない個人が所有していたリソースに対して一般的である。 "無くなった{gone}" ような恒久的に利用できないすべてのリソースをマークしたり、いつまでもそのマークを維持しておく必要はないが、これをいつ破棄するかはサーバオーナーの判断にまかされる。
リクエストされたリソースは、サーバ上から完全に消え去り{gone}、またそれと同等のサービスが与えられるアドレスも知り得ない状態にあります。 その意味合いは 404 (Not Found) よりも強く、もしブックマーク等からリクエストを行った場合、ユーザエージェントはそれを完全に消去するよう通知するべきでしょう。
411 Length Requiredサーバは、定義された Content-Length の無いリクエストを受け入れる事を拒否した。 リクエストメッセージにメッセージボディの長さを含んでいる妥当な Content-Length ヘッダフィールドを追加すれば、クライアントはリクエストを繰り返す事ができる。
リクエストボディを伴うリクエストにおいて Content-Length ヘッダがありません。 適切な Content-Length を追加して、リクエストを再試行して下さい。
412 Precondition Failed一つ以上のリクエストヘッダフィールドで与えられた前提条件は、それがサーバでテストされたときに偽であると評価された。このレスポンスコードはクライアントが現在のリソースの外部情報 (ヘッダフィールドデータ) を前提条件として置けるようにし、それによってリクエストされたメソッドを目的以外のリソースに適用されないようにする。
リクエスト中の If-Match, If-None-Match, If-Unmodified-Since ヘッダで与えられる条件の一つ以上が偽である事を示しています。 クライアントは、自身が持っていた条件をレスポンスヘッダにあるように変更する必要があります。
413 Request Entity Too Largeリクエストエンティティがサーバが想定、あるいは処理可能なものより大きいため、サーバはリクエストの処理を拒否している。 サーバは、クライアントにリクエストを続けさせないため接続を閉じてよい。
もしその状態が一時的なものであれば、サーバはそれが一時的であるという事と、クライアントが再試行してもよい経過時間を示す Retry-After ヘッダフィールドを含むべきである。
リクエストエンティティが大きすぎます。 この大きさの最大値は、サーバに依存します。
414 Request-URI Too LongリクエストURIが長すぎるとサーバが判断した時に返すステータスコードです。 詳しくは、HTTP URIの長さをご覧ください。
415 Unsupported Media Typeリクエストのエンティティは、リクエストされたメソッドに対してリクエストされたリソースがサポートしていないフォーマットであるため、サーバはリクエストのサービスを拒否している。
サーバは、そのリクエストエンティティのフォーマットをサポートしていません。 このタイプの種類は、サーバに依存します。
416 Requested Range Not Satisfiableリソースの範囲リクエスト（部分的GETリクエスト，レジューム）が失敗した時に見られるステータスコードです。 たとえば、1000バイトのリソースに対して、Range: 2000-というリクエストを送った場合、このステータスコードが返されます。 詳しくは、部分的レスポンスに失敗した場合をご覧ください。
417 Expectation Failedクライアントは、希望する拡張をExpectヘッダによって与えることができますが、サーバがそれを実行できない時にはこのレスポンスを返します。 詳しくは、「リクエスト継続」を認めない場合をご覧ください。
418
ステータスコード418は、HTTP Status Code Registryは登録されていません。
したがって、HTTP仕様書にて定義された「HTTPステータスコード 418」というものは存在しません。
しかしながら、過去のHTTPに関するドラフトや、あるいはHTTP/1.1を拡張したプロトコルで、このステータスコードを独自に使っている場合があるので、注意が必要です。 有名なものに、RFC 2324での定義、“I'm a teapot”というものがあります。（※）
ティーポットへコーヒーを淹れさせようとするあらゆる試行は、エラーコード "418 I'm a teapot" という結果に終わるべきである。 その場合のエンティティボディは酷く簡単なものであってもよい。
（※） ただし、このRFC 2324という文書は、1998年4月1日に発行された、いわゆる「エイプリルフールRFC」と呼ばれるもので、内容はジョーク的性質を持ったものです。
したがって、この文書を持って「HTTPステータスコード 418」が定義されていると考える必要はありません。
420, 421
ステータスコード420及び421は、HTTP Status Code Registryで予約されていますので、勝手に利用することはできません。
HTTP Status Code Registryによれば、このステータスコードは「WebDAVのために予約されている」と書かれていますが、WebDAVに関するRFCにおいて、現在このステータスコードは定義されていません。
420番台のステータスコードは、過去様々なプロトコルのドラフト（草案）において、暫定的に定義されてきた過去があります。 たとえば、1995年頃から、W3Cは「HTTP/1.2を開発するためのプロトコル」であるPEPというプロトコルの開発を始めていますが、その中で420番台を含むいくつかの新たなステータスコードが提案されています。
PEP は、HTTP 応答のためにいくつかの新たなステータスコードを定義する。 HTTP/1.0 仕様書 [3] が Section 6.1.1 にて述べる事に注意せよ:
ステータスコードの最初の数字は、レスポンスのクラスを定義する。 後の二つの数字は、いかなる分類上の役割も持たない。 PEP に従うレスポンスコードを非公式に区別するために、PEP は x2z コードを使用する。
- 200 Class
- 220 Uses Protocol Extensions
- 400 Class
- 420 Bad Protocol Extension Request
- 421 Protocol Extension Unknown
- 422 Protocol Extension Refused
- 423 Bad Protocol Extension Parameters
- 500 Class
- 520 Protocol Extension Error
- 521 Protocol Extension Not Implemented
- 522 Protocol Extension Parameters Not Acceptable
このうち 400 及び 500 クラスのレスポンスでは、エラーの説明、及びその問題が一時的かそれとも永続的なものかを示す文書を含むエンティティボディを含むかもしれない。
この中で“x2z”というステータスコードは、「HTTP/1.2に拡張されたプロトコルについて知らせるため」に使用されています。 PEPのドラフトは、その後第6版まで作成され、この中で“x2z”系統は何度か見直されました。 しかし、現時点での最終版（http://www.w3.org/TR/WD-http-pepで確認することができます）では、420 Policy Not Fulfilled と 421 Bad Mappingのみが定義され、さらにそのドラフトも1998年5月21日付で期限切れとなったため、現時点でこのステータスコードを定義する正式な文書は存在しておりません。
422 Unprocessable EntityWebDAVのために定義されたステータスコードで、「HTTPリクエストとしては、そのボディに含むエンティティ（XML）が意味的に間違っている」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
423 LockedWebDAVのために定義されたステータスコードで、「リソースはロックされているため、リクエスト実行不可である」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
424 Failed DependencyWebDAVのために定義されたステータスコードで、「あるリクエストに関連したリクエストが失敗したため、依存関係が保てない」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
425 (Reserved for WebDAV advanced collections expired proposal)
ステータスコード425は、HTTP Status Code Registryにて「Reserved for WebDAV advanced collections expired proposal」として予約されていますので、勝手に利用することはできません。
2012年4月現在、ステータスコード425が定義された最新の文書は、「WebDAV Ordered Collections Protocol」の最初のドラフトで、Section 11.1において以下のように記述されています。
ステータスコード 425 (Unordered Collection) は、順不同のコレクションあるいはサーバで保持された順のコレクションにおいて、クライアントが内部のコレクションメンバの位置を設定しようと試みた事を示す。
WebDAVにおける「コレクション」とは、ファイルシステムにおけるディレクトリ（フォルダ）に相当します。
ステータスコード425とは、外部からはコレクション内に置かれるメンバの並び順を決定できないのに、それを操作しようとした際に返されるステータスコードです。
ファイルシステムにたとえて言えば、ディレクトリ（フォルダ）内のファイルの順序はあらかじめ、例えば「更新順」や「名前順」などと決められており、これをユーザが勝手に変更はできないような仕組みだと考えられます。
（※） ただし、上記のドラフトは、2000年2月20日で期限切れとなっており、すでにその効果はありません。
「WebDAV Ordered Collections Protocol」の次版のドラフトでは、“Unordered Collection”は418として定義され、さらにその次のドラフトでは、409に統合されました。
結局、このドラフトの完成形であるRFC 3648でも409として定義されたため、現在425は欠番となっています。
いずれにしても、今後HTTPを拡張する際は、勝手にこのステータスコードを使用することはできません。
426 Upgrade Required通信のために使用するプロトコルを、HTTP/1.1から他のものへ「アップグレード」することを強制する際に使うステータスコードです。 詳しくは、通信プロトコルをHTTPから切り替えることを強制する場合をご覧ください。
428 Precondition Requiredこのステータスコードは、RFC 6585の中で新たに定義されたHTTP/1.1ステータスコードです。
428ステータスコードは、オリジンサーバが条件付きリクエストを要求することを示す。
このステータスコードの代表的な使用局面は、クライアントがあるリソースの状態をGETし、それをサーバにPUTで返す間に、第三者がサーバ上の状態を修正するという“失われた更新”問題を回避することである。 条件付きリクエストの要求によって、サーバはクライアントが正しいコピーを使って動作していることを保証することができる。
このステータスコードを使用するレスポンスは、そのリクエストを正しく再投稿する方法を説明すべきである。 例えば:
HTTP/1.1 428 Precondition Required Content-Type: text/html <html> <head> <title>Precondition Required</title> </head> <body> <h1>Precondition Required</h1> <p>このリクエストは条件付きリクエストを要求する; "If-Match"を使ってリクエストせよ。</p> </body> </html>428ステータスコードを含むレスポンスは、キャッシュによって保存されてはならない。
サーバは、ユーザエージェントに対し、条件付きGETリクエストを送信することを望んでいます。 その具体例として、「サーバからリソースを取得して、それを編集後サーバに返すまでに、他の誰かに更新されてしまうというリスクを防ぐために使う」というものが挙げられています。
429 Too Many Requestsこのステータスコードは、RFC 6585の中で新たに定義されたHTTP/1.1ステータスコードです。
429ステータスコードは、ユーザが与えられる量の時間内であまりにも多くのリクエストを送ったこと（“帯域制限{rate limiting}”）を示す。
レスポンスの表現では、その条件について説明する詳細を含むべきであり、新たなリクエストを生成する前にどれくらい待つか示すRetry-Afterヘッダを含むことができる。
例:
HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600 <html> <head> <title>Too Many Requests</title> </head> <body> <h1>Too Many Requests</h1> <p>このWebサイトはユーザ一人あたり1時間に50リクエストまでに制限しております。時間を空けて再実行してください。</p> </body> </html>本仕様書では、オリジンサーバがどのようにユーザを識別するかも、どのようにリクエストを数えるのかも定義しないことに注意せよ。 例えば、リクエストの帯域を制限しているオリジンサーバは、リクエスト数のカウントについて、各リソース単位でも、サーバ全体を通じてでも、あるいは、あるサーバ群とすることさえもできる。 同様に、サーバはユーザの識別についても、サーバ自身の認証証明書によってでも、あるいは状態値を持つクッキーによってでもよい。
429ステータスコードを含むレスポンスは、キャッシュによって保存されてはならない。
このステータスコードは、同一のユーザが短い間隔内にサーバに対して大量のリクエストを送った場合に、レスポンスを返せないことを伝えるためのものです。
同様のレスポンスとして503（Service Unavailable）がありますが、503はレスポンスを返せない原因がサーバ側にあるのに対し、このステータスコードは「大量のリクエスト」という明らかにクライアント側に原因がある場合にのみ返すという点で使い分けます。
「同一のユーザ」をどう判定するかについては、たとえばIPアドレスで区別するのか、それともHTTP Cookiesを使うのかなど、いくつかの方法がありますが、この仕様書では定義されていません。
431 Request Header Fields Too Largeこのステータスコードは、RFC 6585の中で新たに定義されたHTTP/1.1ステータスコードです。
431ステータスコードは、リクエスト内のヘッダフィールドが長すぎるので、サーバはそれを処理したくないということを示す。 そのリクエストは、リクエストヘッダフィールドのサイズを縮めた後で再投稿することができる。
このレスポンスは、あるリクエストヘッダフィールドの集合全体が長すぎる時にも、単一のリクエストヘッダフィールドが長すぎる時にも使用することができる。 後者の場合、レスポンス表現は、どのヘッダフィールドが長すぎたのかを明示すべきである。
例:
HTTP/1.1 431 Request Header Fields Too Large Content-Type: text/html <html> <head> <title>Request Header Fields Too Large</title> </head> <body> <h1>Request Header Fields Too Large</h1> <p>“Example”ヘッダが長すぎました。</p> </body> </html>431ステータスコードを含むレスポンスは、キャッシュによって保存されてはならない。
このステータスコードは、「リクエストヘッダ」が長すぎる場合に返されます。
（※） リクエストボディ部が長すぎる場合は413（Request Entity Too Large）を、またリクエストURIが長すぎる場合は414（Request-URI Too Long）をそれぞれ使用します。
451 Unavailable For Legal Reasonsこのステータスコードは、A New HTTP Status Code to Report Legal Obstaclesというインターネットドラフトの中で新たに提案されたHTTP/1.1ステータスコードです。
このステータスコードは、サーバが法的請求に応じてリソースへのアクセスを拒否していることを示す。
このような請求は、通常、法的権限の管轄区域内のすべての処理に対して適用されるので、問題のサーバは、オリジンサーバであってもなくてもよい。 一般的にそのような請求は、ISPや検索エンジンの処理に最も直接的な影響を与える。
このステータスコードを使用したレスポンスは、法的請求の詳細、すなわちどのような法的権限がそれを行ったのか、そしてそれが適用されるのはどのような種別のリソースなのかについて、レスポンスボディ内に説明を含むべきである。
このステータスコードは、リクエストに対応するリソースの内容が「それを閲覧する地域では違法である」場合に返すとされています。 その内容がどのような法に触れるのか、およびどのような法的権限がそれを規制しているのかについては、レスポンスボディに説明が含まれるでしょう。
ちなみに、同文書の「謝辞」の節では、このような記述があります。
Terence Edenに感謝する。 彼は既存のステータスコード403がこの状況ではふさわしくないということを発見し、新たなステータスコードの創造を提案してくれた。
また、Ray Bradburyにも感謝する。
Ray Bradbury（レイ・ブラッドベリ）とは、アメリカのSF作家のことで、有名な著作に「華氏451度」という作品があります。 この作品は、「焚書（学問・思想を権力によって弾圧するための手段として、書物を焼き捨てること）」を題材にした作品で、タイトルの華氏451度（＝摂氏232.8度）という温度は、本が書かれている紙の自然発火する温度からとられています。 既存のステータスコードには、「法的機関からの検閲により、リソースの取得を禁止する」という内容のものはなかったので、有名なSF小説の題名にあやかって、このステータスコードを定義したのでしょう。
数字 "5" で始まるレスポンスステータスコードは、サーバがエラー状態にあるか、リクエストを実行する能力が無いと気づいた場合を表す。 HEAD リクエストに応答する場合以外は、サーバはそのエラー状況と、それが一時的か恒久的なのかの説明を含むエンティティを返すべきである。 ユーザエージェントは、ユーザに返されたあらゆるエンティティを表示すべきである。 これらのレスポンスコードは、あらゆるリクエストメソッドにも適用できる。
5xx レスポンスは、サーバ側に原因のあるエラーがある事を示しています。
500 Internal Server Errorサーバは、リクエストの実行を妨げる予測しない状態に遭遇した。
サーバ内部でエラーが発生した場合に返されます。
500エラーは、CGIなどのサーバサイドスクリプトの構文エラーの場合によく見られます。
ただし、スクリプトにおけるエラーの原因は500というコードからはわかりません。
501 Not Implementedサーバは、リクエストを実行するのに必要な機能をサポートしていない。 これは、サーバがリクエストメソッドを認識できない時の適切なレスポンスであり、どんなリソースに対してもそれをサポートする能力がない。
サーバが、実装していないメソッドやHTTPヘッダを送信された場合に返します。 405 (Method Not Allowed)との違いは、上記項目を参照してください。
502 Bad Gatewayゲートウェイやプロクシとして動作しているようなサーバが、リクエストを実行しようと呼び出しているアップストリームサーバから不正なレスポンスを受け取った。
プロクシが、その上流のサーバへリクエストを送った際に不正なレスポンスを受信しました。 そのリソースへのアクセスには、別のプロクシを使うべきです。 504 レスポンスとの違いに注意して下さい。
503 Service Unavailableサーバは、一時的な過負荷かあるいはサーバのメンテナンスのため、現在リクエストを扱う事ができない。 これは、いくらか遅延された後に軽減されるであろうという一時的な状態も含む。 もし分かるなら、遅延時間の長さを Retry-After ヘッダで示す事ができる。 もし Retry-After が与えられなければ、クライアントはそれを 500 レスポンスと同様に処理すべきである。
注: 503 ステータスコードの存在は、サーバが過負荷状態になった時には常にそれを使わなければならないという事を暗黙的に意味するものではない。 単に接続の拒否を望むサーバもあるだろう。
サーバは現在、サーバ側の都合によりリクエストを処理できません。 それがメンテナンスによるもの等、その状態が解消される時刻が明確にわかっている場合には Retry-After ヘッダを使ってクライアントにその遅延時間の長さを知らせる事ができますが、必須ではありません。 また、サーバが過負荷になったからといって必ずこのステータスコードを使わなければならないわけでもありません。
504 Gateway Timeoutゲートウェイやプロクシとして動作するサーバは、URI によって特定されるアップストリームサーバ (例えば HTTP, FTP, LDAP) や、リクエストを完了させようとするためにアクセスに必要な他の補助のサーバ (例えば DNS) から適時のレスポンスを受信しなかった。
プロクシが、その上流のサーバへリクエストを送りましたが、レスポンスを受信できませんでした。 502 レスポンスとの違いに注意して下さい。
505 HTTP Version Not Supportedサーバは、リクエストメッセージで使用された HTTP プロトコルバージョンをサポートしていない、あるいはサポートを拒否している。 サーバは、このエラーメッセージ以外は、section 3.1 で表されるように、クライアントと同じメジャーバージョンを使用してリクエストを完了させる事は不可能、 あるいはそれを望んでいないという事を示している。 レスポンスは、何故このバージョンがサポートされていないか、どんな別のプロトコルがこのサーバによってサポートされているかを記述したエンティティを含むべきである。
サーバは、クライアントが使用したHTTP バージョンをサポートしていません。 クライアントは、リクエスト中に使用されるHTTPのバージョンを、高くてもレスポンスのHTTPバージョン程度まで落とした後で、リクエストを行って下さい。
506 Variant Also Negotiatesリクエストに含まれるユーザ情報からサーバ駆動型ネゴシエーションを行ったものの、サーバ上の設定ミスなどにより、ネゴシエーションに失敗したことを表すステータスコードです。 詳しくは、サーバ側の原因でネゴシエーションに失敗した場合をご覧ください。
507 Insufficient StorageWebDAVのために定義されたステータスコードで、「サーバ側で記憶領域が不足しているため、リクエストが完了できなかった」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
508 Loop DetectedWebDAVのために定義されたステータスコードで、「サーバがリクエスト処理中に無限ループに陥ったため、リクエストが完了できなかった」ことを表します。 詳しくは、WebDAVステータスコードをご覧ください。
510 Not Extended
ステータスコード510は、RFC 2774で定義されています。
HTTP拡張フレームワークという仕組みを使って「強制的HTTPリクエスト」を発行しようとしましたが、それに必要なManヘッダが同封されていません。
詳しくは、サーバ側でHTTP拡張フレームワークを強制的に利用させたい場合（510レスポンス）をご覧ください。
511 Network Authentication Requiredこのステータスコードは、RFC 6585の中で新たに定義されたHTTP/1.1ステータスコードです。
511ステータスコードは、クライアントがそのネットワークにアクセスするために認証が必要なことを示す。
レスポンスの表現には、ユーザが証明書を投稿できるような（たとえば、HTMLフォームを含む）リソースへのリンクを含むべきである。
511レスポンスに誰何{challenge}やログインのインタフェースそのものを含むと、ブラウザがログインのインタフェースを元々のリクエストしたURLに関連したものとして示し、ユーザが混乱するだろうから、そこに含むべきでないことに注意せよ。
511ステータスはオリジンサーバによって生成されるべきでない; なぜならば、それはネットワークへのアクセスを制御するために間に入っているプロクシが傍受することによる使用を意図しているからである。
511ステータスコードを含むレスポンスは、キャッシュによって保存されてはならない。
このステータスコードは、「その“ネットワーク”への認証」が必要な場合に返されることを想定しています。
（※） リクエストを送るサーバや、それを中継するプロクシへの認証ではないことに注意してください。
それらを示すためのものは、それぞれ401（Unauthorized）や407（Proxy Authentication Required）といったステータスコードがすでに用意されています。