この頁では、HTTP/1.1や、それに関連する仕様書にて定義されているHTTPステータスコードについて、その意味や使用例について解説します。
HTTPは、HTTP クライアントからのリクエストと、それに対する HTTP サーバからのレスポンスというメッセージの送受信によって成立しています。
レスポンスの1行目は、サーバが対応しているHTTPのバージョン, Status-Code, Reason-Phrase の3つから成り、Status-Line」と呼ばれます。
(※) レスポンスの2行目以降は、HTTP ヘッダ、CRLFを挟んで、もし存在すればメッセージボディが続きます。
Status-CodeとReason-Phraseについては、RFC 2616 の section 6.1.1 に記されています。
ステータスコード要素とは、リクエストを理解し満足するための試行についての三桁の数字による結果コードである。 これらのコードは、section 10 にて完全に定義されている。 説明句は、ステータスコードについて短いテキスト記述を与える目的を持つ。 ステータスコードは自動処理によって、また説明句は人間によってそれぞれ使われる事を意図している。 クライアントは、説明句を調べたり表示したりする必要はない。
ステータスコードの最初の数字はレスポンスのクラスを定義する。 後ろの二つの数字はどんな分類規定も持たない。 最初の数字には五つの値がある。
- 1xx: Informational - リクエストは受け入れられ、処理を続けている
- 2xx: Success - 動作は正常に受信され、理解され、受け入れられた
- 3xx: Redirection - リクエストを完了するためには、さらに動作を行わなければならない
- 4xx: Client Error - リクエストは間違った構文か、果たす事のできないものを含んでいる
- 5xx: Server Error - サーバは明白に明らかにリクエストを果たすのに失敗した
ステータスコードと説明句は、それぞれユーザエージェントとそれを利用している人間に対して、そのレスポンスの意味を理解させるためのものです。 この場合のレスポンスの意味とは、以下のようなものです。
このステータスコードという概念は、HTTP が元祖というわけではなく、HTTP のアイデアの元になっている FTP にあったものです。 FTP の仕様書であるFILE TRANSFER PROTOCOL (FTP)をご覧ください。
FTP 応答は、(三文字の英数字として送信される) 三桁の十進数といくらかの文章から成る。 数値の方は、その次に進むために今がどんな状態かを決定するためにコンピュータによって使用されるためのものである; これに対し、文書の方は、人間のユーザのためのものである。 三桁の数値は、ユーザ側プロセス (ユーザ側プロトコルインタプリタ) が文書を解析する必要もなく、またそれを破棄したり、ユーザに渡したりを適切に行えるような十分な情報を含むように意図されている。 特に、この文書はサーバ依存であってもよいので、各応答コードについて文書が変化しているかもしれない。
但し、FTP レスポンスコードでは、一桁目と二桁目にそれぞれ意味がありますが、HTTP ステータスコードでは一桁目にしか意味がないという点が異なります。 以下は、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ステータスコードは厳密に定義されたものですが、その説明句は推奨に過ぎないので、サーバ管理者は適宜これを変更してもかまいません。 例えば、ユーザのほとんどがフランス人であるとわかっている場合は、説明句をフランス語にする事は理解を助けるでしょう。 これも FTP と同様です。
(※) 但し、日本語の場合は少々事情が異なります。
例えば、文字セットにISO-2022-JPを使用しようとしても、エスケープシーケンス中のESC (0x1B)がTEXTの範囲には含まれていないので、使用する事ができません。
また、ステータスコードは拡張する事ができるので、例えば 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 から使用されているステータスコードで、そのレスポンスにはボディ部が含まれません。
クライアントは、そのリクエストを続けるべきである。 この暫定的レスポンスは、リクエストの始めの部分は受け取られ、サーバによって拒否されたものではないという事をクライアントに知らせるために使用される。 クライアントは、リクエストの残りを送り続けるか、もし既にリクエストが完了していれば、このレスポンスを無視すべきである。 サーバは、リクエストが完了した後に最終的なレスポンスを送らなければならない。 このステータスコードの使用・処理の詳細な議論のために section 8.2.3 参照。
100 (Continue) ステータス (section 10.1.1 参照) は、オリジンサーバがクライアントがリクエストボディを送る前に (リクエストヘッダに基づいた) リクエストを受け入れようとする場合に、リクエストボディを伴ったリクエストメッセージを送る事をクライアントに決めさせるという目的を持つ。 いくつかのケースでは、サーバがボディを見る事も無くメッセージを受けつけていない場合にクライアントがボディを送る事は、不適切でひどく効率が悪くなる事がある。
クライアントは、とても大きなリクエストボディをもつリクエストを発行する前に、それが受け入れられるかどうかを確かめたい場合があります。 例えば、以下の場合、そのリクエストは受け入れられません。
このような場合、大きなリクエストボディを送る前に、リクエストを拒否された方が無駄に帯域を使用せずに済みます。 そこで、HTTP/1.1 に対応したクライアントは、この時にまずリクエストボディを除いたリクエストだけを送ります。 サーバは、それが受け入れられないリクエストの場合はその時点で 4xx レスポンスを、また受け入れられる場合は 100 レスポンスを返します。 もし 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 リクエストを受け入れた。 リクエストは、望む範囲を示すための Range ヘッダフィールド (section 14.35) を含めなければならないし、またリクエストを条件付きにしたいければ If-Range ヘッダフィールド (section 14.27) を含んだ方がよい。
リソースの部分的 GET、いわゆるレジュームが成功した時に見られるステータスコードです。 返されるレスポンスボディは、Content-Range にて指定された範囲のエンティティになります。 部分的 GET とレンジ単位 も合わせてご覧下さい。
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 を伴っているので、これを適切に扱う必要があります。
リクエストされたリソースは、表現セットの一つに対応し、各々が特有の場所にあり、エージェント駆動型ネゴシエーション情報 (section 12) が、ユーザ (あるいはユーザエージェント) が望む表現を選択でき、その位置にリクエストをリダイレクトできるように供給されている。
もし HEAD リクエストでなければ、レスポンスはエンティティにユーザかユーザエージェントが最も適切なものを選択するためのリソースの特徴と場所のリストを含むべきである。 エンティティのフォーマットは、Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定される。 データフォーマットやユーザエージェントの能力に依存する事なので、最も適切な選択は自動的に行われるかもしれない。 しかし、この仕様書ではそのような自動選択に対してどのような標準も定義しない。
サーバが選択された表現を持っているのであれば、Location フィールド内にその表現のための具体的な URI を含むべきである。 ユーザエージェントは、自動リダイレクションのためにその Location フィールドの値を使う事ができる。 このレスポンスは、別のものを示しているのでなければキャッシュ可能である。
サーバ駆動型ネゴシエーションが行われましたが、返すのに適したリソースが複数あるので、ユーザに望むものを選択させる場合にこのステータスコードを返します。 但し、ユーザエージェントの能力によっては、内部で処理され、エンドユーザがそれを意識する事はないかもしれません。 (クライアント駆動型ネゴシエーション参照)
リクエストされたリソースは新しい恒久的な URI に割り当てられたので、以降そのリソースへの参照は返された URI の一つを使用すべきである。 リンク編集機能を持つクライアントは、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべきである。 このレスポンスは、別のものを示しているのでなければキャッシュ可能である。
新しい恒久的 URI は、レスポンス内の Location フィールドによって与えられるべきである。 リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキス トの注釈を含むべきである。
リソースの恒久的移動を意味します。 従って、例えばもしブックマークをしているような場合は、URL を Location で与えられた値に変更しましょう。
301 が発生する場合の多くに、ディレクトリを指定しているのに最後のスラッシュ ("/") が無いというものがあります。 これは、例えば http://www.studyinghttp.net/ 以下に "example" というディレクトリがある時、 Request-URI として http://www.studyinghttp.net/example のように最後のスラッシュを付けないという事であり、この場合レスポンスは以下のようになります。
HTTP/1.1 301 Moved Permanently Date: Sat, 01 Jan 2000 10:00:00 GMT Server: Apache/1.3.6 Location: http://www.studyinghttp.net/example/ Connection: close Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>301 Moved Permanently</TITLE> </HEAD><BODY> <H1>Moved Permanently</H1> The document has moved <A HREF="http://www.studyinghttp.net/example/">here</A>.<P> </BODY></HTML>
レスポンスヘッダを見ればわかるように、レスポンスを受け取った時点で一旦接続は切断され、その後改めて Location ヘッダにて示された 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 へのハイパーリンクを持った短いハイパーテキストの注釈を含んでおくとよいでしょう。
このステータスコードは、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 の時はこれを示さずに、アカウントとパスワードを入力させるダイアログが表れます。
HTTP 認証について、詳しくは HTTP Authorization をご覧下さい。
このコードは、将来の使用のため予約されている。
402 は、「有料ページへのアクセス」を想定して、初期の HTTP ドラフトから予約されているステータスコードですが、実際にその中身が定義された事はありません。
サーバはリクエストを理解したが、それを実行する事を拒否した。 認証は役に立たないであろうから、リクエストは繰り返されるべきではない。 リクエストメソッドが HEAD で無い時に、サーバはなぜリクエストが実行されなかったかを公にしたいならば、エンティティにおいて拒否の理由を記すべきである。 サーバはこの情報をクライアントに利用されたくないならば、ステータスコードとして 404 (Not Found) を代わりに使う事が出来る。
メソッドの実行は、サーバによって禁止されています。 禁止の理由を明かす必要はありませんが、明かしたければエンティティボディにて記述する事ができます。
サーバが、 Request-URI に一致するものを見つけられなかった。 その状態が一時的か恒久的かに拘わらず、与えられる指示はない。 もしサーバが、ある内部に組み込まれているメカニズムを通して、古いリソースが恒久的に利用できず、それを転送するためのアドレスも無いという事を知っていたら、410 (Gone) ステータスコードが使用されるべきである。 このステータスコードは一般に、サーバが何故リクエストが拒否したかを正確には表したく無い時、あるいは他に適切なレスポンスが無い時に使われる。
サーバがリソースを見つけられなかった場合に発生します。 それ以外にも、リクエストは拒否したいがその理由は明かしたくない場合や、リクエストは拒否したいが他に適切なレスポンスが無い場合にも使用可能です。
リクエストラインに記述されたメソッドは、 Request-URI によって識別されるリソースに許可されていない。 レスポンスは、リクエストされたリソースへ適用できるメソッドのリストを含む Allow ヘッダを含まなければならない。
その Request-URI にあるリソースは、使用されたメソッドを許可していません。 例えば、GETしか許可されていないリソースにPOSTでリクエストした場合、このステータスコードが返されます。 なお、この時に使用可能なメソッドはレスポンス中のAllowヘッダに含まれます。
似たようなステータスコードとして、501 Not Implementedがありますが、405は「実装はされてはいるが実行は禁止」という意味であることに対し、501は「機能が実装されていないので実行不能」という意味であるので、注意が必要です。
リクエストによって識別されるリソースは、リクエスト中に送られた Accept ヘッダによれば、受け入れられない内容特性を持つレスポンスエンティティを生成する事ができるのみである。
もし HEAD リクエストでなければ、レスポンスはエンティティにユーザかユーザエージェントが最も適切なものを選択するためのリソースの特徴と場所のリストを含むべきである。 エンティティのフォーマットは、Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定される。 データフォーマットやユーザエージェントの能力に依存する事なので、最も適切な選択は自動的に行われるかもしれない。 しかし、この仕様書ではそのような自動選択に対してどのような標準も定義しない。
注: HTTP/1.1 サーバは、リクエスト中に送られた Accept ヘッダによれば受け入れる事ができないとされるレスポンスを返す事を許されている。 そのような場合、406 レスポンスを送る事が望ましい。 ユーザエージェントは、もしそれを受け入れられるなら、それを決定するために送られてきたレスポンスのヘッダを詳しく調べる事が推奨される。
もしレスポンスが受け入れる事ができなければ、ユーザエージェントはそれ以上のデータの受信を一時的に中止し、それ以降の動作を決定するためユーザに尋ねるべきである。
クライアントは、受け入れ可能なリソースのメディアタイプを Accept ヘッダで指定できますが、サーバはそれらのメディア以外のエンティティしか生成できません。
なお、クライアントが受け入れ可能である事を示していないタイプのエンティティでも、サーバは返す事はできます。 但し、その場合でもステータスコードは 406 を返すべきです。 また、ユーザエージェントもそれを全て受け入れる前に、ユーザにそれを行うかどうかを尋ねるべきでしょう。
このコードは、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 Authorizationをご覧下さい。
クライアントは、サーバの待ち時間内にリクエストを発行しなかった。 クライアントは、それ以降に修正しないでリクエストを繰り返してもよい。
リクエストが時間以内に完了していない場合に返されます。
このレスポンスは、例えばリクエストの終末に 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 ヘッダフィールドを含むべきである。
リクエストエンティティが大きすぎます。 この大きさの最大値は、サーバに依存します。
サーバが中間処理をするために想定している Request-URI より長いため、サーバはリクエストのサービスを拒否している。 このまれな状態は、クライアントが長いクエリ情報を伴った POST リクエストを GET リクエストに不適当に変換した時、クライアントがリダイレクションの URI "ブラックホール" (例えば、リダイレクトされた URI が自身の末尾を指すようなものを自身の前に置いてしまうような状態) に陥った時、あるいはサーバが Request-URI の読み出しや操作のために固定長バッファを使用しているいくつかのサーバに存在する当面のセキュリティホールを利用しようとしているクライアントからアタックを受けている時にのみ起こる傾向がある。
リクエストURI が大きすぎます。 この大きさの最大値は、サーバに依存します。
リクエストのエンティティは、リクエストされたメソッドに対してリクエストされたリソースがサポートしていないフォーマットであるため、サーバはリクエストのサービスを拒否している。
サーバは、そのリクエストエンティティのフォーマットをサポートしていません。 このタイプの種類は、サーバに依存します。
リクエストが Range ヘッダフィールド (section 14.35) を含み、このフィールドの範囲指定値が選ばれたリソースの現在の範囲に重なっていなくて、リクエストに If-Range リクエストヘッダフィールドを含んでいなかったら、サーバはこのステータスコードを含むレスポンスを返すべきである。 (バイトレンジの場合、これはすべての
byte-range-spec値でのfirst-bytes-posが、現在選択されているリソースの長さを超えている事を意味する。)このステータスコードをバイトレンジのリクエストで返す場合、レスポンスには選ばれたリソースの現在のサイズを特定するために Content-Range ヘッダフィールドを含むべきである (section 14.16 参照)。 このレスポンスは、
content-typeがmultipart/byterangesのものに使用してはならない。
例えば、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 Upgrade Required" ステータスコードを使用して、クライアントのリクエストは TLS なしでは完了できないという事を示す事ができ、これには要求される TLS バージョンのトークンを規定している Upgrade ヘッダフィールドを含まなければならない。
HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgradeサーバは、426 レスポンス中に、人間が読める形式でエラーの理由を示し、ユーザが利用可能であるようなあらゆる代替方法を記述したメッセージボディを含むべきである。
ステータスコード 426 は、Upgrading to TLS Within HTTP/1.1 で定義されています。
クライアントのリクエストには、Upgrade ヘッダにある TLS の使用が必要です。 TLS は、Netscape 社が開発した SSL が元になっているトランスポート層 (OSI 参照モデルの第 4 層) のセキュアなプロトコルです。
数字 "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をご覧ください。
収集との結合が輪(「サイクル」)をもたらすことができる、「深さ:。」(処理するとき、サーバは、輪を検出しなければなりません)。 「無限」要求。 輪の存在にもかかわらず、操作を完了するのは、時々可能です。 例えば、サーバがセクション7.1で定義された新しいステータスコード208(既にReported)を使用するなら、PROPFINDはまだ成功できます。 コレクションへのバインディングはループ（“サイクル”）となる可能性があるので、サーバは“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 を返します。
, All Rights Reserved.
