この頁では、HTTP/1.1仕様書などで定義されているHTTPステータスコードについて、その意味や使用例について解説します。
RFC 2616のsection 6.1.1には、「ステータスコード」と「説明句{Reason Phrase}」について記述されています。
ステータスコード要素とは、リクエストを理解し満足するための試行についての三桁の数字による結果コードである。 これらのコードは、section 10 にて完全に定義されている。 説明句は、ステータスコードについて短いテキスト記述を与える目的を持つ。 ステータスコードは自動処理によって、また説明句は人間によってそれぞれ使われる事を意図している。 クライアントは、説明句を調べたり表示したりする必要はない。
ステータスコードと説明句は、HTTPユーザエージェントからのリクエストに対して、HTTPサーバがレスポンスを返す際に、その「レスポンスの意味」を伝えるための情報です。 この概念は、HTTPが元祖というわけではなく、HTTPのアイデアの元になっているFTPにもありました。 FTPの仕様書であるFILE TRANSFER PROTOCOL (FTP)をご覧ください。
FTP 応答は、(三文字の英数字として送信される) 三桁の十進数といくらかの文章から成る。 数値の方は、その次に進むために今がどんな状態かを決定するためにコンピュータによって使用されるためのものである; これに対し、文書の方は、人間のユーザのためのものである。 三桁の数値は、ユーザ側プロセス (ユーザ側プロトコルインタプリタ) が文書を解析する必要もなく、またそれを破棄したり、ユーザに渡したりを適切に行えるような十分な情報を含むように意図されている。
ステータスコードは、ユーザエージェントが文書を解析することなく、その「レスポンスの意味」を解釈し、自動的に処理できるようにするために、3桁の数値で表現されます。 （人間が理解するための情報は説明句に含まれています。） この場合の「レスポンスの意味」とは、たとえば以下のようなものを表します。
HTTPステータスコードの性質について、引き続きRFC 2616のsection 6.1.1をご覧ください。
ステータスコードの最初の数字はレスポンスのクラスを定義する。 後ろの二つの数字はどんな分類規定も持たない。 最初の数字には五つの値がある。
- 1xx: Informational - リクエストは受け入れられ、処理を続けている
- 2xx: Success - 動作は正常に受信され、理解され、受け入れられた
- 3xx: Redirection - リクエストを完了するためには、さらに動作を行わなければならない
- 4xx: Client Error - リクエストは間違った構文か、果たす事のできないものを含んでいる
- 5xx: Server Error - サーバは明白に明らかにリクエストを果たすのに失敗した
ステータスコードは、一桁目が上記のような意味を持つコードで、二桁目からはただの通し番号です。
（※） HTTPステータスコードは一桁目にしか意味がありませんが、FTPのレスポンスコードは一桁目と二桁目にそれぞれ意味があります。
以下は、RFC 2616で定義されている HTTPステータスコード一覧です。
HTTP/1.1 で定義された個々のステータスコード数値、及びそれに相当する説明句のセットの例の値を以下に示す。 ここでリストされた説明句は推奨に過ぎない。 すなわち、これらはプロトコルに影響が出ないローカルな範囲で、それに相当するものに置き換えてもよい。
Status-Code= "100" ; Section 10.1.1: Continue | "101" ; Section 10.1.2: Switching Protocols | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created | "202" ; Section 10.2.3: Accepted | "203" ; Section 10.2.4: Non-Authoritative Information | "204" ; Section 10.2.5: No Content | "205" ; Section 10.2.6: Reset Content | "206" ; Section 10.2.7: Partial Content | "300" ; Section 10.3.1: Multiple Choices | "301" ; Section 10.3.2: Moved Permanently | "302" ; Section 10.3.3: Found | "303" ; Section 10.3.4: See Other | "304" ; Section 10.3.5: Not Modified | "305" ; Section 10.3.6: Use Proxy | "307" ; Section 10.3.8: Temporary Redirect | "400" ; Section 10.4.1: Bad Request | "401" ; Section 10.4.2: Unauthorized | "402" ; Section 10.4.3: Payment Required | "403" ; Section 10.4.4: Forbidden | "404" ; Section 10.4.5: Not Found | "405" ; Section 10.4.6: Method Not Allowed | "406" ; Section 10.4.7: Not Acceptable | "407" ; Section 10.4.8: Proxy Authentication Required | "408" ; Section 10.4.9: Request Time-out | "409" ; Section 10.4.10: Conflict | "410" ; Section 10.4.11: Gone | "411" ; Section 10.4.12: Length Required | "412" ; Section 10.4.13: Precondition Failed | "413" ; Section 10.4.14: Request Entity Too Large | "414" ; Section 10.4.15: Request-URI Too Large | "415" ; Section 10.4.16: Unsupported Media Type | "416" ; Section 10.4.17: Requested range not satisfiable | "417" ; Section 10.4.18: Expectation Failed | "500" ; Section 10.5.1: Internal Server Error | "501" ; Section 10.5.2: Not Implemented | "502" ; Section 10.5.3: Bad Gateway | "503" ; Section 10.5.4: Service Unavailable | "504" ; Section 10.5.5: Gateway Time-out | "505" ; Section 10.5.6: HTTP Version not supported | extension-code extension-code = 3DIGIT Reason-Phrase = *<CR, LF を含まない TEXT>HTTP ステータスコードは拡張可能である。 HTTP アプリケーションは、登録されたすべてのステータスコードを明確に理解できる事が望ましいが、それらのすべての意味を理解する必要はない。 しかし、アプリケーションは最初の数字によって示されるステータスコードのクラスはすべて理解しなければならないし、理解できないレスポンスはキャッシュしてはならないという例外を除いて、すべての理解できないレスポンスをそのクラスの x00 ステータスコードと同等に扱わなければならない。 例えば、431 という理解できないステータスコードがクライアントに受信されたなら、そのリクエストに何か誤りがあると安全に推測ができ、それが 400 ステータスコードを受信したかのようにレスポンスを扱う事ができる。このような場合、エンティティはこの異常なステータスを説明しているであろう人間が読める情報を含んでいると思われるから、ユーザエージェントはレスポンスと共に返されたエンティティをユーザに見せるべきである。
ステータスコードは上記に定義されているもの以外にも、独自に拡張ができます。 たとえば、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レスポンスにはメッセージボディを含みません。
クライアントは、そのリクエストを続けるべきである。 この暫定的レスポンスは、リクエストの始めの部分は受け取られ、サーバによって拒否されたものではないという事をクライアントに知らせるために使用される。 クライアントは、リクエストの残りを送り続けるか、もし既にリクエストが完了していれば、このレスポンスを無視すべきである。 サーバは、リクエストが完了した後に最終的なレスポンスを送らなければならない。 このステータスコードの使用・処理の詳細な議論のために section 8.2.3 参照。
100 (Continue) ステータス (section 10.1.1 参照) は、オリジンサーバがクライアントがリクエストボディを送る前に (リクエストヘッダに基づいた) リクエストを受け入れようとする場合に、リクエストボディを伴ったリクエストメッセージを送る事をクライアントに決めさせるという目的を持つ。 いくつかのケースでは、サーバがボディを見る事も無くメッセージを受けつけていない場合にクライアントがボディを送る事は、不適切でひどく効率が悪くなる事がある。
クライアントがリクエストを発行しようとした時、そのリクエストがサーバに受け入れられるかどうかを、先に確かめておきたいと思うかもしれません。 たとえば、以下の場合、サーバはそのリクエストは受け入れることができません。
このような場合、クライアントがリクエストを送る前に、サーバによってリクエストを拒否された方が、無駄に帯域を使用せずに済みます。 そこで、HTTP/1.1に対応したクライアントは、この時にまずリクエストボディを除いたリクエストだけを送ります（リクエストヘッダは本来送るべきものを送ります）。 サーバは、それを見て、受け入れられないリクエストだとわかったら、その時点で4xxレスポンスを返します。 また、受け入れられる場合は100レスポンスを返しますが、クライアントはそれに対し、元々送るつもりであったリクエストボディをそのまま送ればよいのです。 そして、サーバは、リクエストが完全に終了した後で、そのリクエストに従って本来返すべきレスポンスを返します。
なお、通信しているサーバが100レスポンスに対応していない場合があるので、クライアントはExpect: 100-continueというヘッダをリクエストに含めておく必要があります。
この時、100に対応していないHTTP/1.1サーバは、417レスポンスを返します。
サーバは理解し、Upgrade メッセージヘッダフィールド (section 14.42) を使って、この接続で使用されているアプリケーションプロトコルを変更する事でクライアントのリクエストに従おうとしている。 サーバは 101 レスポンスを終了する空行のあと、直ちにレスポンスの Upgrade ヘッダフィールドによって定義されたプロトコルに変更するだろう。
プロトコルは、変更した方が有益な場合にのみ変更されるべきである。 例えば、HTTP のより新しいバージョンに変更するという事は、古いバージョン以上に有益だし、リアルタイムに、同期するプロトコルを変更する事はそのような機能を使うリソースを配布するときに都合が良いだろう。
使用されているプロトコルを HTTP/1.1 からアップグレードする際のステータスコードです。 Upgrade ヘッダも合わせて参照して下さい。
102 (Processing) ステータスコードは、サーバは完全なるリクエストを受信したが、未だそれが完了していないという事をクライアントに知らせるために使用される暫定的レスポンスである。 このステータスコードは、リクエストが完了するには著しく時間がかかるであろうという根拠のある見込みがサーバにある時にのみ送られるべきである。 指針として、メソッドが処理するために 20 秒 (これが妥当であるが、任意の値) より長くかかっている場合、 サーバは 102 (Processing) レスポンスを返すべきである。 サーバは、リクエストが完了した後に最終的なレスポンスを送らなければならない。
メソッドは、潜在的に、特に Depth ヘッダをサポートするメソッドについて、処理をするために長い時間がかかる可能性がある。 そのような場合、クライアントはレスポンスを待っている間にタイムアウトするかもしれない。 これを回避するために、サーバがまだメソッドを処理しているという事をクライアントに示すために、サーバは 102 (Processing) ステータスコードを返す事ができる
ステータスコード 102 は、WebDAV について記述されている RFC 2518 内で定義されています。
サーバは、その処理を完了させるのに長い時間 (仕様書では 20 秒を推奨) かかるような場合に、クライアントがタイムアウトエラーと判断する前に「現在処理中である」という事を知らせたい場合、102 を返します。
(※) RFC 2518 は、その後 RFC 4918 によって置き換えられましたが、102 はその中から削除されています。
このステータスコードのクラスは、クライアントのリクエストがうまく受信され、理解され、そして受け入れられた事を示す。
2xxレスポンスは、クライアントのリクエストが成功したことを示します。
リクエストは成功した。 レスポンスと共に返される情報はリクエストに使用されたメソッドに依存し、例えば以下の様になる。
- GET
- リクエストされたリソースに対応するエンティティがレスポンスとして送られる。
- HEAD
- リクエストされたリソースに対応するエンティティヘッダフィールドがメッセージボディを伴わずにレスポンスとして送信される。
- POST
- 動作の結果を記述もしくは含んでいるエンティティ
- TRACE
- 端末サーバによって受信されたリクエストメッセージを含んでいるエンティティ
リクエストの成功を意味します。 レスポンスボディとして返されるものの意味は、メソッドによって異なります。
リクエストは果たされ、結果として新しいリソースが作成された。 新しく作成されたリソースは Location ヘッダにより与えられるリソースに対する最も明確な URI を伴って、レスポンスのエンティティにおいて返される URI によって参照される。 レスポンスは、ユーザあるいはユーザエージェントが最も適切なものを選択するために、リソースの特徴と場所のリストをエンティティとして含むべきである。 エンティティのフォーマットは、Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定される。 オリジンサーバは、201 ステータスコードを返す前にリソースを作成しなければならない。 もし動作がすぐに実行できないのであれば、サーバは代わりに 202 (Accepted) レスポンスを返すべきである。
PUT メソッドによって、リソースが新たに生成された場合に使用されます。 202 レスポンスとの違いに注意して下さい。
リクエストは処理のために受け入れられたが、処理は完了されていない。 このリクエストは、実際に処理される時に拒否されるかもしれないので、最終的に動作されるかどうかは不明である。 このような非同期操作からステータスコードを再送信するための機能は存在しない。
202 レスポンスは、意図的に責任を持たない{non-committal}。 これはサーバが、プロセスが完了されるまでユーザエージェントとの接続を持続させる事無く、他のいくつかのプロセス (多分一日に一度しか実行されないバッチ指向プロセス{batch-oriented process}) のためのリクエストを受け入れる事を可能にするという目的を持つ。 このレスポンスによって返されるエンティティは、リクエストの現在の状態を表すものと、状態モニタへのポインタ、あるいはそのリクエストがいつ果たされるかをユーザが予期できる見積もりのどちらかを含むべきである。
このレスポンスも、PUT メソッドへのレスポンスですが、201 と異なる点は、リクエストを受け付けた時点ではまだサーバ上にリソースが生成されておらず、またリソースが生成される事が保証されてもいない (すなわち、最終的にはそのリクエストが拒否されるかもしれない) ので、注意が必要です。 但し、レスポンスのエンティティボディには、生成されるかどうかを確認するためのモニタ (あるいはそれがある URL) や、いつ頃までにリクエストが生成されるか、あるいはそれを過ぎても実現していなければ、そのリクエストは破棄されたと考える事ができるような時間等が返されるでしょう。
エンティティヘッダにおいて返された外部情報は、オリジンサーバから利用できるような決定的なセットではなく、ローカルもしくはサードパーティコピーから集められたものである。 提示されたセットは元のバージョンのサブセットかスーパーセットであろう。 例えば、リソースについてのローカルな注釈情報を含む事はオリジンサーバによって知らされる外部情報のスーパーセットとなるかもしれない。 そのレスポンスが 200 (OK) とは別の方法で示したい場合、このレスポンスコードを使用する必要はないが、そのような場合にのみ適切である。
このレスポンスヘッダは、オリジンサーバが発行したものではなく、ローカルあるいはプロクシなどからもたらされたものです。 このような場合でも、通常であれば200をもって応答することは可能ですが、特にプロクシからの応答であると明示したい場合のみ203を使用してもかまいません。
サーバはリクエストを受け入れたが、エンティティボディを送り返す必要は無く、更新された外部情報を返す事を望むだろう。 レスポンスは、エンティティヘッダ形式の中に、新規あるいは更新された外部情報を含む事ができ、もしあればリクエストされたバリアントが関連付けられるべきである。
もしクライアントがユーザエージェントなら、リクエストの送信をもたらした状態からその文書画面{view} を変えるべきではない。 このレスポンスは主に、ユーザエージェントの現在の{active} 文書画面ビューを変える事無く、動作を起こすための入力をさせる意図を持つが、どんな新規あるいは更新された外部情報もユーザエージェントの現在の画面中にある現在の文書に適用されるべきである。
204 レスポンスは メッセージボディを含んではならない ので、常にヘッダフィールドの後の最初の空行で終了する。
リクエストそのものは成功しましたが、返すべきレスポンスボディは存在しませんし、またいかなるレスポンスボディも返してはいけません。 そのリクエストがブラウザ等から送られたものである場合、レスポンスを受信してもその表示画面は変更されないでしょう。
サーバはリクエストを受け入れたので、ユーザエージェントは送信されたリクエストをもたらした現在の画面をリセットすべきである。 このレスポンスは主に、ユーザが別の入力動作を簡単に始められるように、入力が与えられたフォームをクリアして、ユーザの入力経由で動作を起こすための入力をさせる意図を持つ。 レスポンスはエンティティを含んではならない。
リクエストは成功しました。 サーバは、ユーザエージェントがその後の操作を始め易いように、このレスポンスをもって、現在の画面をリセットするように薦める事ができます。 但し、この時、サーバはいかなるレスポンスボディも返してはいけません。
リソースの範囲リクエスト（部分的GETリクエスト，レジューム）が成功した時に見られるステータスコードです。 返されるレスポンスボディは、Content-Rangeにて指定された範囲のエンティティになります。 詳しくは、部分的レスポンスに成功した場合をご覧ください。
207 (Multi-Status) ステータスコードは、複数の独立した操作についてのステータスを提供する (詳細については section 13 を参照)。
Multi-Status レスポンスは、複数のステータスコードが適切であろう状況における複数のリソースについての情報を運ぶ。 既定の Multi-Status レスポンスボディは、'multistatus' ルートエレメントを含む text/xml あるいは application/xml 型の HTTP エンティティである。 それらの要素として含まれるのは、メソッド発動中に生成される 200, 300, 400, 500 系のステータスコードである。 100 系のステータスコードは、'response' XML 要素中には記録されるべきではない。
ステータスコード 207 は、WebDAV について記述されている RFC 4918 内で定義されています。
このコードは、複数の独立したステータスコードを XML で返します。 RFC 4918 中にある例をご覧下さい。
>>Request
PROPFIND /file HTTP/1.1
Host: www.example.com
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
>>Response
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:R="http://ns.example.com/boxschema/">
<D:href>http://www.example.com/file</D:href>
<D:propstat>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the DingALing property.
</D:responsedescription>
</D:propstat>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>
この例は、リソースに関する情報 (プロパティ) を見るためのメソッドである PROPFIND リクエストとそれに対するレスポンスです。 ここでは、<bigbox>, <author>, <DingALing>, <Random> という 4 つのプロパティを見ようとしていますが、先の 2 つについてはそれが取得できているので 200 というステータスが返されていますが、後の 2 つについてはそれを取得するための権限がないので 403 というステータスが返されています。
ステータスコード208は、Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)で定義されています。
208 (Already Reported) ステータスコードは、複数のバインディング{binding}を持つ内部のメンバを同じコレクションに繰り返して数え上げることを避けるために、DAV:propstatレスポンス要素の中で使用することができる。 リクエストの範囲に含まれるコレクションへの各バインディングに対しては、一つだけが200ステータスコードをもって報告されるが、以降の他の全てのバインディングについてのDAV:response要素は208ステータスコードを使うであろうし、それらの子孫についてのDAV:response要素は含まれない。
WebDAVでいう「バインディング{Binding}」とは、あるリソースに対して別の名前を結びつけることであり、Unixで言うところの「シンボリックリンク」に相当します。 また、コレクションとは、Unixで言うところの「ディレクトリ」に相当します。 208レスポンスは、このような「バインディング」を複数回見つけた時に返されるステータスコードです。 例として、RFC 5842のSection 7.1.1をご覧ください。
>> Request:
PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
DAV: bind
Content-Type: application/xml; charset="utf-8"
Content-Length: 152
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:displayname/>
<D:resource-id/>
</D:prop>
</D:propfind>
>> Response:
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 1241
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/Coll/</D:href>
<D:propstat>
<D:prop>
<D:displayname>Loop Demo</D:displayname>
<D:resource-id>
<D:href>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/Coll/Foo</D:href>
<D:propstat>
<D:prop>
<D:displayname>Bird Inventory</D:displayname>
<D:resource-id>
<D:href>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/Coll/Bar</D:href>
<D:propstat>
<D:prop>
<D:displayname>Loop Demo</D:displayname>
<D:resource-id>
<D:href>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 208 Already Reported</D:status>
</D:propstat>
</D:response>
</D:multistatus>
この例では、http://www.example.com/Coll/が指し示すリソースと、http://www.example.com/Coll/Barが指し示すリソースが、URIが異なるものの実体が同一であるため、後に列挙されたhttp://www.example.com/Coll/Barに対して、208が返されています。 （なお、「HTTPレスポンスそのもののステータスコード」としては207レスポンスが返されている点に注意）
サーバはそのリソースに対する GET リクエストを実行し、そのレスポンスは現在のインスタンスに適用された一つ以上のインスタンス操作の結果の表現である。 実際の現在のインスタンスは、特定のインスタンス操作に対して適切なように、このレスポンスを他の以前のあるいは以後のレスポンスと組み合わせる場合以外は利用可能ではないかもしれない。 その場合、生成されたインスタンスのヘッダは、HTTP/1.1 仕様書の section 13.5.3 の規則に従って、ステータス 226 レスポンスのものと他のインスタンスからのものを組み合わせたヘッダとなる。
リクエストは、少なくとも一つの
instance-manipulationを列挙した A-IM ヘッダフィールドを含んでいなければならない。 レスポンスは、現在のインスタンスのエンティティタグを与える Etag ヘッダフィールドを含んでいなければならない。
ステータスコード 226 は、Delta encoding in HTTP で定義されています。
サーバは、現在のインスタンス (現時点でのエンティティ) に差分コーディングを行い、その差分を返しました。 実際に、どのようなインスタンス操作が行われたかは IM ヘッダフィールドに記述されています。
このステータスコードのクラスは、リクエストを果たすためにはユーザエージェントによって更なる動作が行われる必要がある事を示す。 二番目のリクエストで使われたメソッドが GET か HEAD である場合にのみ、ユーザとの相互動作無しに、ユーザエージェントによって要求された動作を実行する事ができる。 リダイレクションループによって各々のリダイレクションはネットワーク渋滞を生み出す事になるので、クライアントは無限リダイレクションループを発見すべきである。
注: この仕様書の前のバージョンでは、5 回のリダイレクションを最大として推奨している。 内容開発者{Content developers} は、そのような修正された制限を実装したクライアントがあるであろう事を意識すべきである。
3xx レスポンスは、リクエストを完了するために、クライアントは更なる動作を行うことが必要である事を示しています。 このレスポンスでは、多くの場合 Location を伴っているので、これを適切に扱う必要があります。
サーバは、リクエストに含まれるユーザ情報からサーバ駆動型ネゴシエーションを行いましたが、ユーザ情報が足りないため、該当するリソースが複数ヒットしています。 そのため、クライアントがリクエストを完了するためには、該当リソースのうちどれが欲しいかを選択する必要があります。 詳しくは、レスポンスとして、複数のリソースから選択を要求する場合をご覧ください。
リクエストされたリソースは新しい恒久的な 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を正しく指定することで、このような無駄な通信が発生することはなくなりますので、このような場合のリクエストやリンクを記述する場合、「最後のスラッシュがついているか」の確認をするようにしてください。
リクエストされたリソースは、一時的に別の 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 は Location に示される URL にリソースが恒久的に移動している事を示しているのに対し、302 はそのリソースが保存されている現時点の URL を Location で示しています。
301 の場合と違い、Location の値はあくまで現時点でのリソースの場所であり、すなわち将来は変更される可能性があるので、将来のリクエスト、例えばもしブックマークをしているような場合でも、現時点の URL にリクエストすべきです。
ユーザエージェントは、エンドユーザに確認せずにリクエストをリダイレクトできますが、その際にはメソッドを変えてはならないし、また GET や HEAD といった安全なメソッド以外は、エンドユーザへの確認なしにリダイレクトしてはなりません。 しかし、実際にはこれらの規則は守られていないのが現状なので、新たに 303 と 307 というステータスコードが追加されました。
リクエストに対するレスポンスは別の 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 を使用すべきです。
クライアントが条件付き GET リクエストを実行し、アクセスは許可されたがその文書は更新されていなかった場合、サーバはこのステータスコードもって応答すべきである。 304 レスポンスはレスポンスボディを含んではならないので、いつもヘッダフィールドの後の最初の空行で終了する。
クライアントが条件付き GET を行った場合に、リソースが更新されていなければ、このステータスコードが返されます。 304 レスポンスでは、いかなるレスポンスボディも返してはいけません。
リクエストされたリソースは Location フィールドによって与えられるプロクシを通してアクセスされなければならない。 Location フィールドはプロクシの URI を与える。 受信側はプロクシ経由で単一のリクエストを再送信する事を期待する。 305 レスポンスはオリジンサーバによってのみ生成されなければならない。
注: RFC 2068 では、305 は単一リクエストをリダイレクトさせようとする事、またオリジンサーバによってのみ生成される事は明確にしていない。 これらの制限がセキュリティの上で重要な意味を持つという事を認識していなかったためである。
305 レスポンスの場合、Location の値はリダイレクト先の URI ではなく、使用するプロクシの URI となります。 そのリソースがあるオリジンサーバ上の場所が変更されているわけではないという事に注意して下さい。
306 ステータスコードは前のバージョンの仕様書では使われていたが、もはや使われておらず、将来のために予約されている。
ステータスコード 306 は、現在の HTTP/1.1 仕様書では定義されていませんが、HTTP Status Code Registry で予約されていますので、勝手に利用する事はできません。
(※) 過去のインターネットドラフトにて 306 Switch Proxy というステータスコードが提案された事がありますが、現在は期限切れとなっています。
リクエストされたリソースは、一時的に別の 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 へのハイパーリンクを持った短いハイパーテキストの注釈を含んでおくとよいでしょう。
このステータスコードは、現在作成中のインターネットドラフト“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.8では、HTTPはステータスコード307の恒久的なバリアントを定義しないと述べている; 本仕様書ではステータスコード308を追加し、この失われたバリアントを定義する（Section 3）。
対象のリソースは新たな恒久的URIを割り当てられたので、そのリソースへの以降の参照は返されるURIの一つを使用すべきである。 リンク編集機能を持つクライアントは、可能であればサーバから返される新たな参照のうち一つ以上の有効なリクエストURI（[draft-ietf-httpbis-p1-messaging]のSection 4.3参照）の参照へ自動的に再リンクすべきである。
（中略）
新たな恒久的URIは、レスポンス内のLocationフィールドによって与えられるべきである（[draft-ietf-httpbis-p2-semantics], Section 9.5）。 レスポンスの内容には、新たなURIへのハイパーリンクを持つ短いハイパーテキストの注釈を含むことができる。
つまり、ステータスコード308とは「301 (Moved Permanently)と同じく『リソースが恒久的に移動したこと』を表し、特に『リダイレクト時にHTTPメソッドを変更してはならない』ことを通知する場合に使用する」ものとして、現在提案されています。
しかしながら、現在多くのユーザエージェントはステータスコード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>
このステータスコードは、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 レスポンスは、クライアント側に原因のあるエラーがある事を示しています。
リクエストは、不正な構文のためサーバに理解されなかった。 クライアントは、修正しないままでそのリクエストを再送信すべきではない。
リクエストの構文が間違っています。 このエラーが出た場合は、発行されたリクエストをもう一度見直してみて下さい。
リクエストはユーザ認証を必要とする。 レスポンスは、リクエストされたリソースに適用できる
challengeを含む WWW-Authenticate ヘッダフィールド (section 14.47) を含まなければならない。 クライアントは、適切な Authorization ヘッダフィールド (section 14.8) を伴うリクエストを繰り返す事ができる。 もしリクエストがすでに Authorizationcredentialsを含んでいるのであれば、この 401 レスポンスは認証がそれらのcredentialsに対して拒否された事を示す。 もし 401 レスポンスが前のレスポンス時と同じchallengeを含み、ユーザエージェントが既に最低一回認証を試みているならば、そのエンティティに関連する診断情報を含んでいるであろうから、ユーザエージェントはレスポンスで与えられたエンティティを表示すべきである。 HTTP アクセス認証は、"HTTP Authentication: Basic and Digest Access Authentication" において説明されている。
このステータスコードは、オリジンサーバへのユーザ認証が必要である場合に返されます。 あるいは、ユーザ認証を含むリクエストが一度以上行われていてそれが失敗した場合にもこのステータスコードが返されます。 401レスポンスでは、WWW-Authenticateヘッダが送られなければなりません。 多くのブラウザの場合、401レスポンスを受け取った場合は、ユーザIDとパスワードを入力させるダイアログを表示します。
HTTP認証については、HTTP Authenticationを参照ください。
このコードは、将来の使用のため予約されている。
402 は、「有料ページへのアクセス」を想定して、初期の HTTP ドラフトから予約されているステータスコードですが、実際にその中身が定義された事はありません。
サーバはリクエストを理解したが、それを実行する事を拒否した。 認証は役に立たないであろうから、リクエストは繰り返されるべきではない。 リクエストメソッドが HEAD で無い時に、サーバはなぜリクエストが実行されなかったかを公にしたいならば、エンティティにおいて拒否の理由を記すべきである。 サーバはこの情報をクライアントに利用されたくないならば、ステータスコードとして 404 (Not Found) を代わりに使う事が出来る。
メソッドの実行は、サーバによって禁止されています。 禁止の理由を明かす必要はありませんが、明かしたければエンティティボディにて記述する事ができます。
サーバが、 Request-URI に一致するものを見つけられなかった。 その状態が一時的か恒久的かに拘わらず、与えられる指示はない。 もしサーバが、ある内部に組み込まれているメカニズムを通して、古いリソースが恒久的に利用できず、それを転送するためのアドレスも無いという事を知っていたら、410 (Gone) ステータスコードが使用されるべきである。 このステータスコードは一般に、サーバが何故リクエストが拒否したかを正確には表したく無い時、あるいは他に適切なレスポンスが無い時に使われる。
サーバがリソースを見つけられなかった場合に発生します。 それ以外にも、リクエストは拒否したいがその理由は明かしたくない場合や、リクエストは拒否したいが他に適切なレスポンスが無い場合にも使用可能です。
リクエストラインに記述されたメソッドは、 Request-URI によって識別されるリソースに許可されていない。 レスポンスは、リクエストされたリソースへ適用できるメソッドのリストを含む Allow ヘッダを含まなければならない。
その Request-URI にあるリソースは、使用されたメソッドを許可していません。 例えば、GETしか許可されていないリソースにPOSTでリクエストした場合、このステータスコードが返されます。 なお、この時に使用可能なメソッドはレスポンス中のAllowヘッダに含まれます。
似たようなステータスコードとして、501 Not Implementedがありますが、405は「実装はされてはいるが実行は禁止」という意味であることに対し、501は「機能が実装されていないので実行不能」という意味であるので、注意が必要です。
リクエストに含まれるユーザ情報からサーバ駆動型ネゴシエーションを行ったものの、該当するリソースがない場合に返すステータスコードです。 詳しくは、レスポンスとして、ふさわしいリソースを保持していないと判断した場合をご覧ください。
このコードは、401 (Unauthorized) と似ているが、クライアントが最初にプロクシに認証されなければならない事を示す。 プロクシは、リクエストされたリソースのためのプロクシに適用できる
challengeを含んだ Proxy-Authenticate ヘッダフィールド (section 14.33) を返さなければならない。 クライアントは、適切な Proxy-Authorization ヘッダフィールド (section 14.34) を伴うリクエストを繰り返す事ができる。 HTTP アクセス認証は、"HTTP Authentication: Basic and Digest Access Authentication" [43] において説明されている。
401レスポンスの場合はオリジンサーバへの認証が必要なことを表していますが、407レスポンスはプロクシへのユーザ認証が必要であることを表しています。
HTTP認証については、HTTP Authenticationを参照ください。
クライアントは、サーバの待ち時間内にリクエストを発行しなかった。 クライアントは、それ以降に修正しないでリクエストを繰り返してもよい。
リクエストが時間以内に完了していない場合に返されます。
このレスポンスは、例えばリクエストの終末に CRLF がない場合に見られます。
リクエストは、リソースの現在の状態との矛盾のため完了できなかった。 このコードは、ユーザが矛盾を解決し、リクエストを再提出できる事が期待できる状況のみに許される。 レスポンスボディには、ユーザが矛盾の原因を認識するための十分な情報を含むべきである。 理論的には、そのレスポンスエンティティはユーザやユーザエージェントが問題を修正するための十分な情報を含んでいるであろうが、実際それは不可能だろうしその必要もない。
矛盾は、PUT リクエストへのレスポンス時に最も発生しやすい。 例えば、もしバージョン処理{versioning} が使用され、PUT されているエンティティが初期 (サードパーティ) のリクエストによって作られたものと矛盾しているリソースに変わるものを含んでいるならば、サーバはリクエストが完了できない事を示す 409 レスポンスを使用できる。 この場合、レスポンスエンティティにはおそらく、レスポンスの Content-Type によって定義されるフォーマット中で二つのバージョンの違いについてのリストを含むであろう。
そのリクエストがリソースの現在の状態と矛盾している場合に使用します。 このレスポンスは、WebDAV でよく見られます。 WebDAV における、PUT メソッド使用時の 409 レスポンス発生例について、RFC 4918 の Section 9.7.1 をご覧下さい。
既存のリソースへ実行される PUT は、リソースの GET レスポンスエンティティを置き換える。 そのリソース上で定義されるプロパティは PUT 処理時に再計算されるであろうが、他の部分は影響を受けないであろう。 例えば、サーバがリクエストボディの内容のタイプを認識する場合、プロパティとして有益に見られる情報を自動的に抜き出す事ができるだろう。
適切に範囲指定される親コレクションがなくリソースの作成をしようとする PUT は、409 (Conflict) をもって、失敗しなければならない。
これは例えば、「サーバ上に "/put/" というディレクトリがない」という状況で、PUT http://www.studyinghttp.net/put/hoge.html HTTP/1.1 というリクエストを送っても、そのようなディレクトリがないのでエラーとなります。 この時に返されるステータスコードが 409 です。
(※) なお、この場合はディレクトリ (WebDAV では「コレクション」と呼ぶ) を作成するためのメソッドである MKCOL によって、一旦 "/put/" というディレクトリ (コレクション) を作成する事で解決できます。
また、Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol の Section 6.2. では、Position ヘッダを使用した場合の発生状況について述べられています。
>> Request: MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1 Host: example.org Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt Position: first >> Response: HTTP/1.1 409 Conflict Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:collection-must-be-ordered/> </D:error>この場合、/~user/dav/ コレクションは順序付けされない {unordered} コレクションであるという理由から、サーバは 409 (Conflict) ステータスコードを返す。 その結果、サーバは Position ヘッダを満足する事はできなかった。
この例における /~user/dav/ コレクションは、あらかじめ順序付けされている必要があります。 <D:collection-must-be-ordered/> タグがそれを示しています。 そして、あらかじめ決定された順序は外部から変更する事はできません。 よって、この場合は「矛盾」を表す 409 ステータスコードが返されるのです。
(※) この用法は、かつて 「WebDAV Ordered Collections Protocol」の最初のドラフトで、425 Unordered Collection として定義された用法と同一です。
リクエストされたリソースは、もはやそのサーバでは利用できないし、転送先のアドレスも分からない。 この状況は、恒久的なものとみなされるであろう。 リンク編集機能を持つクライアントは、ユーザから承認を得た後にリクエスト URI の参照を削除すべきである。 サーバがその状況が恒久的なものかどうかを、知らないか、あるいはそれを決定するための能力が無いのであれば、代わりにステータスコード 404 (Not Found) が使用されるべきである。 別の方法が示されなければ、このレスポンスはキャッシュできる。
410 レスポンスは主に、リソースが故意に利用不可能であったり、サーバのオーナーがリソースへのリモートリンクを削除したい事を受信者に通知する事でウェブメンテナンスの作業を補助する意図を持つ。 そのような事は、期間限定の宣伝サービスや、サーバのサイト内でもはや働いていない個人が所有していたリソースに対して一般的である。 "無くなった{gone}" ような恒久的に利用できないすべてのリソースをマークしたり、いつまでもそのマークを維持しておく必要はないが、これをいつ破棄するかはサーバオーナーの判断にまかされる。
リクエストされたリソースは、サーバ上から完全に消え去り{gone}、またそれと同等のサービスが与えられるアドレスも知り得ない状態にあります。 その意味合いは 404 (Not Found) よりも強く、もしブックマーク等からリクエストを行った場合、ユーザエージェントはそれを完全に消去するよう通知するべきでしょう。
サーバは、定義された Content-Length の無いリクエストを受け入れる事を拒否した。 リクエストメッセージにメッセージボディの長さを含んでいる妥当な Content-Length ヘッダフィールドを追加すれば、クライアントはリクエストを繰り返す事ができる。
リクエストボディを伴うリクエストにおいて Content-Length ヘッダがありません。 適切な Content-Length を追加して、リクエストを再試行して下さい。
一つ以上のリクエストヘッダフィールドで与えられた前提条件は、それがサーバでテストされたときに偽であると評価された。このレスポンスコードはクライアントが現在のリソースの外部情報 (ヘッダフィールドデータ) を前提条件として置けるようにし、それによってリクエストされたメソッドを目的以外のリソースに適用されないようにする。
リクエスト中の If-Match, If-None-Match, If-Unmodified-Since ヘッダで与えられる条件の一つ以上が偽である事を示しています。 クライアントは、自身が持っていた条件をレスポンスヘッダにあるように変更する必要があります。
リクエストエンティティがサーバが想定、あるいは処理可能なものより大きいため、サーバはリクエストの処理を拒否している。 サーバは、クライアントにリクエストを続けさせないため接続を閉じてよい。
もしその状態が一時的なものであれば、サーバはそれが一時的であるという事と、クライアントが再試行してもよい経過時間を示す Retry-After ヘッダフィールドを含むべきである。
リクエストエンティティが大きすぎます。 この大きさの最大値は、サーバに依存します。
リクエストURIが長すぎるとサーバが判断した時に返すステータスコードです。 詳しくは、HTTP URIの長さをご覧ください。
リクエストのエンティティは、リクエストされたメソッドに対してリクエストされたリソースがサポートしていないフォーマットであるため、サーバはリクエストのサービスを拒否している。
サーバは、そのリクエストエンティティのフォーマットをサポートしていません。 このタイプの種類は、サーバに依存します。
リソースの範囲リクエスト（部分的GETリクエスト，レジューム）が失敗した時に見られるステータスコードです。
たとえば、1000バイトのリソースに対して、Range: 2000-というリクエストを送った場合、このステータスコードが返されます。
詳しくは、部分的レスポンスに失敗した場合をご覧ください。
Expect リクエストヘッダフィールド (section 14.20 参照) によって与えられるこの拡張は、このサーバでは受け入れる事は出来ないし、あるいはサーバがプロクシであったなら、次に到達するサーバがそのリクエストを受け入れる事ができないという明白な証拠を持っている。
クライアントは、希望する拡張をExpectヘッダによって与えることができますが、サーバがそれを実行できない時には417レスポンスを返します。
HTTP/1.1では、100というステータスコードを扱えないHTTP/1.1サーバが使用する状況が想定されています。 逆に言うと、それ以外のExpectに対する値は定義されていません。
ステータスコード 418 は、HTTP Status Code Registry には登録されていません。 従って、HTTP 仕様書にて定義された「HTTP ステータスコード 418」というものは存在しません。
しかしながら、過去の HTTP に関するドラフトや、あるいは HTTP/1.1 を拡張したプロトコルである HTCPCP/1.0 において 418 が定義された事があるので、HTTP の拡張によってこのステータスコードの使用を考える場合には多少の注意を払った方が良いかもしれません。
ティーポットへコーヒーを淹れさせようとするあらゆる試行は、エラーコード "418 I'm a teapot" という結果に終わるべきである。 その場合のエンティティボディは酷く簡単なものであってもよい。
(※) HTCPCP/1.0 とはいわゆる「エイプリルフール RFC (ジョーク RFC)」であり、厳密には「HTTP ステータスコード」と捉える必要はありません。
ステータスコード 420 及び 421 は、HTTP Status Code Registry で予約されていますので、勝手に利用する事はできません。 HTTP Status Code Registry によれば、このステータスコードは WebDAV のために予約されていると書かれていますが、WebDAV に関する RFC において、現在このステータスコードは定義されていません。
420 番台のステータスコードは、過去様々なプロトコルのドラフト (草案) において、暫定的に定義されてきた過去があります。 例えば、1995 年頃から、W3C は「HTTP/1.2 を開発するためのプロトコル」である PEP の開発を始めますが、その中で新たなステータスコードが提案されています。
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 や http://ietfreport.isoc.org/all-ids/draft-ietf-http-pep-05.txt で確認する事ができます) では、420 Policy Not Fulfilled と 421 Bad Mapping のみが定義されています。
(※) しかし、このドラフトは 1998 年 5 月 21 日付で期限切れとなり、それ以降 PEP に関するドラフトは提出されておりません。
422 (Unprocessable Entity) ステータスコードは、サーバはリクエストエンティティの内容タイプは理解でき (そのため 415 (Unsupported Media Type) ステータスコードは不適切である)、リクエストエンティティの構文は正しい (従って 400(Bad Request) ステータスコードは不適切である) が、含まれる命令を処理できないという事を意味する。 例えば、XML リクエストボディが well-formed である (すなわち、構文的に正しい) が、意味的に誤った XML 命令を含む場合、このエラー状態が生じるであろう。
ステータスコード 422 は、WebDAV について記述されている RFC 4918 内で定義されています。
リクエストに同封されるエンティティが処理できない場合に、このステータスコードが返されます。 例えば、上の文にあるように、エンティティ中の XML が妥当{valid} でない場合が考えられます。
423 (Locked) ステータスコードは、メソッドのソースまたは目的先リソースがロックされている事を意味する。 このレスポンスは、例えば 'lock-token-submitted' あるいは 'no-conflicting-lock' のような、適切な事前条件{precondition} または事後条件{postcondition} コードを含むべきである。
ステータスコード 423 は、WebDAV について記述されている RFC 4918 内で定義されています。
例えば、ロックされているリソースを MOVE で移動させようとしたり、ロックされているリソースに COPY で上書きしようとしたりすると、このステータスコードが返されます。
424 (Failed Dependency) ステータスコードは、リクエストされた動作は他の動作に依存しており、その動作は失敗したので、メソッドはそのリソースに操作されなかったという事を意味する。 例えば、PROPPATCH メソッド中のコマンドが失敗したら、少なくとも、残りのコマンドも失敗し、424 (Failed Dependency) ステータスを返すであろう。
ステータスコード 424 は、WebDAV について記述されている RFC 4918 内で定義されています。
ある動作が失敗した事により、関連する他の動作が失敗した状態になると、このステータスコードが返されます。
ステータスコード 425 は、HTTP Status Code Registry で予約されていますので、勝手に利用する事はできません。
2008 年 4 月現在、ステータスコード 425 が定義された最新の文書は、「WebDAV Ordered Collections Protocol」の最初のドラフトで、Section 11.1 において以下のように記述されています。
ステータスコード 425 (Unordered Collection) は、順不同のコレクションあるいはサーバで保持された順のコレクションにおいて、クライアントが内部のコレクションメンバの位置を設定しようと試みた事を示す。
WebDAV における「コレクション」とは、ファイルシステムにおけるディレクトリ（フォルダ）に相当します。 ステータスコード 425 とは、外部からはコレクション内に置かれるメンバの並び順を決定できないのに、それを操作しようとした際に返されるステータスコードです。 ファイルシステムに例えて言えば、ディレクトリ（フォルダ）内のファイルの順序はあらかじめ、例えば「更新順」や「名前順」等と決められており、これをユーザが勝手に変更はできないような仕組みだと考えられます。
(※) 但し、上記のドラフトは、2000 年 2 月 20 日で期限切れとなっており、既にその効果はありません。
次版のドラフトでは、"Unordered Collection" は 418 として定義され、更にその次のドラフトでは、409 に統合されました。 結局、このドラフトの完成形である Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol でもそのまま定義されたため、現在 425 は 409 と同義であると考える事ができます。 いずれにしても、今後 HTTP を拡張する際は、勝手にこのステータスコードを使用する事はできません。
ステータスコード426は、Upgrading to TLS Within HTTP/1.1の中で定義されています。
サーバは、"426 Upgrade Required" ステータスコードを使用して、クライアントのリクエストは TLS なしでは完了できないという事を示す事ができ、これには要求される TLS バージョンのトークンを規定している Upgrade ヘッダフィールドを含まなければならない。
HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgradeサーバは、426 レスポンス中に、人間が読める形式でエラーの理由を示し、ユーザが利用可能であるようなあらゆる代替方法を記述したメッセージボディを含むべきである。
クライアントのリクエストには、UpgradeヘッダにあるTLSの使用が必要です。 TLSとは、Netscape社が開発したSSLが元になっているトランスポート層（OSI参照モデルの第4層）のセキュアなプロトコルです。
このステータスコードは、現在作成中のインターネットドラフト“Additional HTTP Status Codes”の中で提案されているステータスコードです。
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リクエストを送信することを望んでいます。 その具体例として、「サーバからリソースを取得して、それを編集後サーバに返すまでに、他の誰かに更新されてしまうというリスクを防ぐために使う」というものが挙げられています。
このステータスコードは、現在作成中のインターネットドラフト“Additional HTTP Status Codes”の中で提案されているステータスコードです。
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を使うのかなど、いくつかの方法がありますが、この仕様書では定義されていません。
このステータスコードは、現在作成中のインターネットドラフト“Additional HTTP Status Codes”の中で提案されているステータスコードです。
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)をそれぞれ使用します。
数字 "5" で始まるレスポンスステータスコードは、サーバがエラー状態にあるか、リクエストを実行する能力が無いと気づいた場合を表す。 HEAD リクエストに応答する場合以外は、サーバはそのエラー状況と、それが一時的か恒久的なのかの説明を含むエンティティを返すべきである。 ユーザエージェントは、ユーザに返されたあらゆるエンティティを表示すべきである。 これらのレスポンスコードは、あらゆるリクエストメソッドにも適用できる。
5xx レスポンスは、サーバ側に原因のあるエラーがある事を示しています。
サーバは、リクエストの実行を妨げる予測しない状態に遭遇した。
サーバ内部でエラーが発生した場合に返されます。 500 が発生する原因として、CGI スクリプトのエラーがあげられます。 ただし、スクリプトにおけるエラーの原因は 500 というコードからはわかりません。
サーバは、リクエストを実行するのに必要な機能をサポートしていない。 これは、サーバがリクエストメソッドを認識できない時の適切なレスポンスであり、どんなリソースに対してもそれをサポートする能力がない。
サーバが、実装していないメソッドやHTTPヘッダを送信された場合に返します。 405 (Method Not Allowed)との違いは、上記項目を参照してください。
ゲートウェイやプロクシとして動作しているようなサーバが、リクエストを実行しようと呼び出しているアップストリームサーバから不正なレスポンスを受け取った。
プロクシが、その上流のサーバへリクエストを送った際に不正なレスポンスを受信しました。 そのリソースへのアクセスには、別のプロクシを使うべきです。 504 レスポンスとの違いに注意して下さい。
サーバは、一時的な過負荷かあるいはサーバのメンテナンスのため、現在リクエストを扱う事ができない。 これは、いくらか遅延された後に軽減されるであろうという一時的な状態も含む。 もし分かるなら、遅延時間の長さを Retry-After ヘッダで示す事ができる。 もし Retry-After が与えられなければ、クライアントはそれを 500 レスポンスと同様に処理すべきである。
注: 503 ステータスコードの存在は、サーバが過負荷状態になった時には常にそれを使わなければならないという事を暗黙的に意味するものではない。 単に接続の拒否を望むサーバもあるだろう。
サーバは現在、サーバ側の都合によりリクエストを処理できません。 それがメンテナンスによるもの等、その状態が解消される時刻が明確にわかっている場合には Retry-After ヘッダを使ってクライアントにその遅延時間の長さを知らせる事ができますが、必須ではありません。 また、サーバが過負荷になったからといって必ずこのステータスコードを使わなければならないわけでもありません。
ゲートウェイやプロクシとして動作するサーバは、URI によって特定されるアップストリームサーバ (例えば HTTP, FTP, LDAP) や、リクエストを完了させようとするためにアクセスに必要な他の補助のサーバ (例えば DNS) から適時のレスポンスを受信しなかった。
プロクシが、その上流のサーバへリクエストを送りましたが、レスポンスを受信できませんでした。 502 レスポンスとの違いに注意して下さい。
サーバは、リクエストメッセージで使用された HTTP プロトコルバージョンをサポートしていない、あるいはサポートを拒否している。 サーバは、このエラーメッセージ以外は、section 3.1 で表されるように、クライアントと同じメジャーバージョンを使用してリクエストを完了させる事は不可能、 あるいはそれを望んでいないという事を示している。 レスポンスは、何故このバージョンがサポートされていないか、どんな別のプロトコルがこのサーバによってサポートされているかを記述したエンティティを含むべきである。
サーバは、クライアントが使用した HTTP バージョンをサポートしていません。 クライアントは、リクエスト中に使用される HTTP 技術を、高くてもレスポンスの HTTP バージョン程度まで落とした後で、リクエストを行って下さい。
506 ステータスコードは、サーバが内部配置上のエラーがある事を示す: 選択されたバリアントリソースは、透過的内容ネゴシエーション自体に関与するために形成されたものであり、従ってネゴシエーションプロセスにおける適切な終点ではない。
ステータスコード 506 は、Transparent Content Negotiation in HTTP で定義されています。
サーバ内部で透過的内容ネゴシエーションが使用されていますが、そこで選択されたリソース先がユーザが取り出して利用できるようなものではないので、リソースを返す事ができません。
507 (Insufficient Storage) ステータスコードは、サーバはそのリクエストが正常に完了するために必要な情報を保存する事ができないので、メソッドはそのリソースに操作されなかったという事を意味する。 この状態は、一時的なものであると考えられる。 このステータスコードを受け取ったリクエストがユーザの操作の結果であった場合、そのリクエストは各ユーザ操作によって試行されるまで、リクエストを繰り返してはならない。
ステータスコード 507 は、WebDAV について記述されている RFC 4918 内で定義されています。
リクエストを処理するためにサーバにある程度の容量が必要であるが、それを確保する事ができない場合に、このステータスコードが返されます。
ステータスコード508は、Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)で定義されています。
508 (Loop Detected) ステータスコードは、サーバが“Depth: infinity”を持つリクエストを処理している時に無限ループに遭遇したので、処理を終了したことを示す。 このステータスコードは、その操作全体が失敗したことを示す。
このステータスコードは、無限に深くまで検索するための指示子であるDepth: infinityを伴うWebDAVリクエストにおいて、検索結果が無限ループになるような場合に返されます。 まず、RFC 5842のSection 2.1.1をご覧ください。
コレクションへのバインディングはループ（“サイクル”）となる可能性があるので、サーバは“Depth: infinity”リクエストを処理する際にそれを検出しなければならない。 ループが存在するにもかかわらず操作を完了することが可能な場合もある。 たとえば、サーバがSection 7.1にて定義される新たなステータスコード208 (Already Reported)を使用する場合、PROPFINDは成功させることができる。
しかし、ループに遭遇したために処理を中断するという状況で使用するため、508 (Loop Detected)ステータスコードをSection 7.2にて定義する。
ループについてのサポートはOPTIONALである: すなわち、サーバはバインドによるループの生成につながるようなリクエストは拒絶することができる（Section 4にて定義されるDAV:cycle-allowed前提条件を参照）。
たとえば、ステータスコード208での例をご覧ください。 この例では、(a) http://www.example.com/Coll/が指し示すリソースと、(b) http://www.example.com/Coll/Barが指し示すリソースの実態が同一です。 では、もし(c) http://www.example.com/Coll/Bar/BarというURIがあったとしたら、どうなるでしょうか？ (b)は(a)に等しいので、(c)のURIはhttp://www.example.com/Coll/Barと置き換えることができます。 しかし、これは(b)と同一のURIであるため、結局(a)と同一のリソースを指し示すものとなってしまいます。 すなわち、再帰的に考えるとhttp://www.example.com/Coll/Bar/Barも、http://www.example.com/Coll/Bar/Bar/Barも、http://www.example.com/Coll/Bar/Bar/Bar/Barも、すべて同じリソースを指し示すということになり、リソースの検索時に無限ループに陥ってしまいます。 そこで、この(a)と(b)のように、ループになるようなバインディングを発見した場合に、サーバは検索をストップし、508レスポンスにてクライアントに知らせることができるようになっています。
リソースを呼び出すための方針がリクエスト中には表れていない。 サーバはクライアントが拡張されたリクエストを発行するために必要な全ての情報を送り返すべきである。 どのように拡張をクライアントに知らせるかを詳述する事はこの仕様書の範囲を超える。
ステータスコード 510 は、An HTTP Extension Framework で定義されています。
RFC 2774 にあるように、強制的 HTTP リクエスト (メソッドが M- で始まるもの) を送る際に、必要な Man ヘッダが同封されていない場合にこのステータスコードが返されます。
そもそも、強制的 HTTP リクエストが解釈できない場合は 501 を返します。
このステータスコードは、現在作成中のインターネットドラフト“Additional HTTP Status Codes”の中で提案されているステータスコードです。
511ステータスコードは、クライアントがそのネットワークにアクセスするために認証が必要なことを示す。
レスポンスの表現には、ユーザが証明書を投稿できるような（たとえば、HTMLフォームを含む）リソースへのリンクを含むべきである。
511レスポンスに誰何{challenge}やログインのインタフェースそのものを含むと、ブラウザがログインのインタフェースを元々のリクエストしたURLに関連したものとして示し、ユーザが混乱するだろうから、そこに含むべきでないことに注意せよ。
511ステータスはオリジンサーバによって生成されるべきでない; なぜならば、それはネットワークへのアクセスを制御するために間に入っているプロクシが傍受することによる使用を意図しているからである。
511ステータスコードを含むレスポンスは、キャッシュによって保存されてはならない。
このステータスコードは、その“ネットワーク”への認証が必要な場合に返されることを想定しています。
（※） リクエストを送るサーバや、それを中継するプロクシへの認証ではないことに注意してください。 それらを示すためのステータスコードは401 (Unauthorized)や407 (Proxy Authentication Required)といったものがすでに用意されています。