Loading article…
これは、ハイパーテキスト転送プロトコル(HTTP) 応答ステータス コードのリストです。ステータス コードは、サーバーに対して行われたクライアントの要求に応じてサーバーによって発行されます。これには、IETF のRequest for Comments (RFC)、その他の仕様からのコード、および HTTP の一般的なアプリケーションで使用される追加のコードが含まれます。ステータス コードの最初の桁は、5 つの標準応答クラスのいずれかを指定します。示されているオプションのメッセージ フレーズは一般的なものですが、人間が判読できる代替フレーズを提供したり、まったく提供しなかったりすることもできます。
特に明記しない限り、ステータスコードはHTTP標準の一部です。[1]
Internet Assigned Numbers Authority (IANA)はHTTPステータスコードの公式レジストリを管理しています。[2]
すべての HTTP 応答ステータス コードは、5 つのクラスまたはカテゴリに分けられます。ステータス コードの最初の桁は応答のクラスを定義しますが、最後の 2 桁には分類またはカテゴリ化の役割はありません。標準では 5 つのクラスが定義されています。
- 1xx 情報応答– リクエストを受信し、処理を続行します
- 2xx 成功– リクエストが正常に受信され、理解され、受け入れられました
- 3xx リダイレクト– リクエストを完了するには、さらにアクションを実行する必要があります
- 4xx クライアント エラー– リクエストに不正な構文が含まれているか、リクエストを満たすことができません
- 5xx サーバー エラー– サーバーは有効なリクエストを処理できませんでした
1xx 情報応答
情報応答は、リクエストが受信され、理解されたことを示します。これは、リクエスト処理が続行されている間に暫定的に発行されます。これは、クライアントに最終応答を待つように警告します。メッセージは、ステータス行とオプションのヘッダー フィールドのみで構成され、空行で終了します。HTTP/1.0 標準では 1xx ステータス コードが定義されていないため、サーバーは、実験的な状況を除き、HTTP/1.0 準拠のクライアントに 1xx 応答を送信してはなりません[注 1]。
- 100 続行
- サーバーはリクエスト ヘッダーを受信し、クライアントはリクエスト ボディの送信に進む必要があります (ボディの送信が必要なリクエストの場合、たとえばPOSTリクエスト)。不適切なヘッダーのためにリクエストが拒否された後に、大きなリクエスト ボディをサーバーに送信するのは非効率的です。サーバーにリクエスト ヘッダーをチェックさせるには、クライアントは
Expect: 100-continue最初のリクエストでヘッダーとして送信し、100 Continueボディを送信する前に応答でステータス コードを受信する必要があります。クライアントが 403 (禁止) や 405 (メソッドが許可されていません) などのエラー コードを受け取った場合は、リクエスト ボディを送信しないでください。応答は、サーバーが期待をサポートしていないことを示しているため、ヘッダー417 Expectation Failedなしでリクエストを繰り返す必要があることを示しExpectています (たとえば、HTTP/1.0 サーバーの場合)。[1] : §10.1.1 - 101 スイッチング プロトコル
- 要求者はサーバーにプロトコルの切り替えを要求し、サーバーはそれに同意しました。
- 102 処理 ( WebDAV ; RFC 2518)
- WebDAV リクエストには、ファイル操作を伴う多くのサブリクエストが含まれる場合があり、リクエストの完了には長い時間がかかります。このコードは、サーバーがリクエストを受信して処理しているが、まだ応答がないことを示します。[3]これにより、クライアントがタイムアウトしてリクエストが失われたと想定することがなくなります。このステータス コードは非推奨です。[4]
- 103 初期ヒント (RFC 8297)
- 最終的なHTTPメッセージの前にいくつかの応答ヘッダーを返すために使用されます。[5]
2xx 成功
このクラスのステータスコードは、クライアントが要求したアクションが受信され、理解され、受け入れられたことを示します。[2]
- 200 大丈夫です
- 成功した HTTP リクエストに対する標準応答。実際の応答は、使用されるリクエスト メソッドによって異なります。GET リクエストの場合、応答には、要求されたリソースに対応するエンティティが含まれます。POST リクエストの場合、応答には、アクションの結果を記述または含むエンティティが含まれます。
- 201 作成済み
- リクエストが満たされ、新しいリソースが作成されました。[6]
- 202 承認済み
- リクエストは処理のために受け入れられましたが、処理は完了していません。リクエストは最終的に実行される場合と実行されない場合があり、処理が行われると拒否される可能性があります。
- 203 非権威情報 (HTTP/1.1 以降)
- サーバーは、オリジンから200 OKを受信した変換プロキシ（ Webアクセラレータなど）ですが、オリジンの応答を変更したバージョンを返します。 [1] ：§15.3.4 [1] ：§7.7
- 204 コンテンツなし
- サーバーはリクエストを正常に処理しましたが、コンテンツを返していません。
- 205 コンテンツをリセット
- サーバーはリクエストを正常に処理し、リクエスト元にドキュメント ビューをリセットするように要求しましたが、コンテンツを返していません。
- 206 部分的なコンテンツ
- クライアントから送信された範囲ヘッダーが原因で、サーバーはリソースの一部のみを配信しています (バイト サービング)。範囲ヘッダーは、HTTP クライアントが中断されたダウンロードを再開したり、ダウンロードを複数の同時ストリームに分割したりするために使用されます。
- 207 マルチステータス (WebDAV; RFC 4918)
- これに続くメッセージ本文はデフォルトではXMLメッセージであり、サブリクエストの数に応じて複数の個別の応答コードが含まれることがあります。[7]
- 208 すでに報告済み (WebDAV; RFC 5842)
- DAV バインディングのメンバーは、(マルチステータス) 応答の前の部分ですでに列挙されており、再度含められることはありません。
- 226 IM 使用 (RFC 3229)
- サーバーはリソースの要求を満たし、応答は現在のインスタンスに適用された1つ以上のインスタンス操作の結果を表します。[8]
3xx リダイレクト
このステータスコードのクラスは、クライアントがリクエストを完了するために追加のアクションを実行する必要があることを示します。これらのステータスコードの多くは、URLリダイレクトで使用されます。[2]
ユーザーエージェントは、2番目のリクエストで使用されたメソッドがGETまたはHEADである場合に限り、ユーザーの介入なしに追加のアクションを実行できる。ユーザーエージェントはリクエストを自動的にリダイレクトすることができる。ユーザーエージェントは循環的なリダイレクトを防ぐためにそれを検出し介入する必要がある。[1] ：§15.4
- 300 複数選択問題
- クライアントが選択できるリソースの複数のオプションを示します（エージェント駆動型コンテンツネゴシエーション経由）。たとえば、このコードを使用して、複数のビデオ形式のオプションを提示したり、異なるファイル名拡張子を持つファイルを一覧表示したり、単語の意味の曖昧さ回避を提案したりできます。
- 301 永久に移動
- このリクエストと今後のすべてのリクエストは、指定されたURIに送信する必要があります。
- 302 件見つかりました (以前は「一時的に移動」でした)
- クライアントに別の URL を参照 (参照) するように指示します。HTTP/1.0 仕様では、クライアントが同じ方法で一時的なリダイレクトを実行することを要求していました (元の説明フレーズは「一時的に移動」でした) [9]が、一般的なブラウザはメソッドを GET に変更して 302 リダイレクトを実装しました。そのため、HTTP/1.1 では、2 つの動作を区別するためにステータス コード 303 と 307 が追加されました。[1] : §15.4
- 303 その他を参照(HTTP/1.1 以降)
- リクエストへの応答は、GET メソッドを使用して別のURIで見つけることができます。POST (または PUT/DELETE) への応答として受信された場合、クライアントはサーバーがデータを受信したと想定し、指定された URI に新しい GET リクエストを発行する必要があります。
- 304 変更されていません
- リクエスト ヘッダーIf-Modified-Since または If-None-Matchで指定されたバージョン以降、リソースが変更されていないことを示します。このような場合、クライアントには以前にダウンロードしたコピーがまだあるため、リソースを再送信する必要はありません。
- 305 プロキシを使用する (HTTP/1.1 以降)
- 要求されたリソースはプロキシ経由でのみ利用可能であり、そのアドレスは応答で提供されます。セキュリティ上の理由から、多くのHTTPクライアント（ Mozilla FirefoxやInternet Explorerなど）はこのステータスコードに従いません。[10]
- 306 スイッチプロキシ
- 現在は使用されていません。元々は「後続のリクエストでは指定されたプロキシを使用する必要があります」という意味でした。
- 307 一時リダイレクト (HTTP/1.1 以降)
- この場合、リクエストは別の URI で繰り返す必要がありますが、今後のリクエストでは元の URI を使用する必要があります。302 がこれまで実装されていた方法とは対照的に、元のリクエストを再発行するときにリクエスト メソッドを変更することはできません。たとえば、POST リクエストは別の POST リクエストを使用して繰り返す必要があります。
- 308 永久リダイレクト
- このリクエストと今後のすべてのリクエストは、指定されたURIに送信される必要があります。308 は 301 の動作に似ていますが、HTTP メソッドの変更を許可しません。そのため、たとえば、永続的にリダイレクトされたリソースにフォームを送信すると、スムーズに続行される可能性があります。
4xx クライアント エラー
このステータス コードのクラスは、エラーがクライアントによって発生したと思われる状況を対象としています。HEAD 要求に応答する場合を除き、サーバーはエラー状況の説明と、それが一時的か永続的かを示すエンティティを含める必要があります。これらのステータス コードは、どの要求メソッドにも適用できます。ユーザー エージェントは、含まれているエンティティをユーザーに表示する 必要があります。
- 400 不正なリクエスト
- 明らかなクライアント エラー (例: 不正な要求構文、サイズが大きすぎる、要求メッセージのフレーミングが無効、要求ルーティングが不正) が原因で、サーバーは要求を処理できないか、処理しません。
- 401 権限がありません
- 403 Forbidden に似ていますが、認証が必要で認証が失敗したか、まだ提供されていない場合に特に使用されます。応答には、要求されたリソースに適用可能なチャレンジを含む WWW-Authenticate ヘッダー フィールドが含まれている必要があります。基本アクセス認証およびダイジェスト アクセス認証を参照してください。401 は意味的に「認証されていない」ことを意味し、ユーザーは対象リソースに対する有効な認証資格情報を持っていません。
- 402 支払いが必要です
- 将来の使用のために予約されています。当初の意図は、このコードが、たとえばGNU Taler [11] によって提案されているような、何らかの形のデジタルキャッシュまたはマイクロペイメントスキームの一部として使用されることでしたが、それはまだ実現しておらず、このコードは広く使用されていません。Google Developers APIは、特定の開発者がリクエストの1日あたりの制限を超えた場合にこのステータスを使用します。[12] Sipgateは、アカウントに通話を開始するのに十分な資金がない場合にこのコードを使用します。[13] Shopifyは、ストアが料金を支払わず、一時的に無効になっている場合にこのコードを使用します。[14] Stripeは、パラメータが正しいのに支払いが失敗した場合、たとえば不正な支払いをブロックした場合にこのコードを使用します。[15]
- 403 禁止
- リクエストには有効なデータが含まれており、サーバーによって認識されましたが、サーバーはアクションを拒否しています。これは、ユーザーがリソースに必要な権限を持っていないか、何らかのアカウントを必要としているか、または禁止されているアクションを試みている (たとえば、1 つしか許可されていないのに重複レコードを作成している) ことが原因である可能性があります。このコードは、リクエストが WWW-Authenticate ヘッダー フィールド チャレンジに応答して認証を提供したが、サーバーがその認証を受け入れなかった場合にも通常使用されます。リクエストを繰り返すことはできません。
- 404 見つかりません
- 要求されたリソースは見つかりませんでしたが、将来利用可能になる可能性があります。クライアントによる後続の要求は許可されます。
- 405 メソッドは許可されていません
- 要求されたリソースでは、要求メソッドがサポートされていません。たとえば、POST経由でデータを提示する必要があるフォームでの GET 要求や、読み取り専用リソースでの PUT 要求などです。
- 406 受け入れられません
- 要求されたリソースは、要求で送信された Accept ヘッダーに従って受け入れられないコンテンツのみを生成できます。コンテンツネゴシエーションを参照してください。
- 407 プロキシ認証が必要です
- クライアントはまずプロキシで自身を認証する必要があります。
- 408 リクエストタイムアウト
- サーバーは要求を待機中にタイムアウトしました。HTTP 仕様によると、「クライアントは、サーバーが待機する準備ができた時間内に要求を生成しませんでした。クライアントは、後で変更せずに要求を繰り返すことができます。」
- 409 紛争
- 複数の同時更新間の編集競合など、リソースの現在の状態の競合が原因で要求を処理できなかったことを示します。
- 410 消えた
- 要求されたリソースは以前使用されていたが、現在は使用できず、今後は使用できないことを示します。これは、リソースが意図的に削除され、リソースを消去する必要がある場合に使用します。410 ステータス コードを受け取ったクライアントは、今後そのリソースを要求しないでください。検索エンジンなどのクライアントは、インデックスからリソースを削除する必要があります。ほとんどのユース ケースでは、クライアントと検索エンジンがリソースを消去する必要はなく、代わりに「404 Not Found」を使用できます。
- 411 長さが必要です
- リクエストでは、要求されたリソースに必要なコンテンツの長さが指定されていません。
- 412 前提条件が失敗しました
- サーバーは、要求者が要求ヘッダー フィールドに設定した前提条件の 1 つを満たしていません。
- 413 ペイロードが大きすぎます
- リクエストがサーバが処理できるサイズを超えています。以前は「リクエストエンティティが大きすぎます」と呼ばれていました。[16] ：§10.4.14
- 414 URI が長すぎます
- 提供されたURIはサーバが処理するには長すぎます。これはGETリクエストのクエリ文字列としてエンコードされたデータが多すぎることが原因であることが多く、その場合はPOSTリクエストに変換する必要があります。以前は「Request-URI Too Long」と呼ばれていました。[16] ：§10.4.15
- 415 サポートされていないメディアタイプ
- リクエスト エンティティには、サーバーまたはリソースがサポートしていないメディア タイプがあります。たとえば、クライアントはimage/svg+xmlとして画像をアップロードしますが、サーバーは画像に別の形式を使用することを要求します。
- 416 範囲が満たされない
- クライアントはファイルの一部を要求しましたが（バイトサービング）、サーバーはその部分を提供できません。たとえば、クライアントがファイルの末尾を超える部分を要求した場合などです。以前は「要求された範囲が満たされない」と呼ばれていました。[16] ：§10.4.17
- 417 期待に応えられなかった
- サーバーはExpectリクエストヘッダーフィールドの要件を満たすことができません。[17]
- 418 私はティーポットです(RFC 2324、RFC 7168)
- このコードは、1998年にIETFの伝統的な エイプリルフールのジョークの1つとしてRFC 2324、ハイパーテキストコーヒーポット制御プロトコルで定義されましたが、実際のHTTPサーバーで実装されることは想定されていません。RFCでは、コーヒーを淹れるように要求されたティーポットがこのコードを返す必要があると規定されています。[18]このHTTPステータスは、Google.comの「私はティーポットです」イースターエッグなど、一部のWebサイトでイースターエッグとして使用されています。 [19] [20] [21]このステータスコードは、より適切な403 Forbiddenの代わりに、ブロックされたリクエストへの応答としても使用されることがあります。[22] [23]
- 421 誤ったリクエスト
- 要求は、応答を生成できないサーバーに送信されました (たとえば、接続の再利用のため)。
- 422 処理できないコンテンツ
- リクエストは適切にフォーマットされていた（つまり、構文的に正しい）が、処理できなかった。[1] ：§15.5.21
- 423 ロックされています (WebDAV; RFC 4918)
- アクセスされているリソースはロックされています。[7]
- 424 依存関係の失敗 (WebDAV; RFC 4918)
- リクエストが失敗したのは、別のリクエストに依存しており、そのリクエストが失敗したためです（例：PROPPATCH）。[7]
- 425 早すぎる (RFC 8470)
- サーバーが、再生される可能性のあるリクエストを処理するリスクを負うことを望まないことを示します。
- 426 アップグレードが必要です
- クライアントは、 Upgrade ヘッダーフィールドで指定されたTLS/1.3などの別のプロトコルに切り替える必要があります。
- 428 前提条件が必要 (RFC 6585)
- オリジンサーバーは、リクエストが条件付きであることを要求します。これは、クライアントがリソースの状態をGETし、それを変更し、それをサーバーにPUTする一方で、第三者がサーバー上の状態を変更し、競合を引き起こす「更新の損失」問題を防ぐことを目的としています。[24]
- 429 リクエストが多すぎます (RFC 6585)
- ユーザーが一定時間内に送信したリクエストが多すぎます。レート制限スキームで使用することを目的としています。[24]
- 431 リクエスト ヘッダー フィールドが大きすぎます (RFC 6585)
- 個々のヘッダーフィールドまたはすべてのヘッダーフィールドが大きすぎるため、サーバーはリクエストを処理できません。[24]
- 451 法的な理由により利用不可(RFC 7725)
- サーバー運営者は、リソースまたは要求されたリソースを含むリソースセットへのアクセスを拒否するよう求める法的要求を受け取りました。[25]コード451は、小説「華氏451度」を参考に選択されました（RFCの謝辞を参照）。
5xx サーバーエラー
サーバーはリクエストを処理できませんでした。
数字「5」で始まる応答ステータス コードは、サーバーがエラーが発生したか、またはリクエストを実行できないことを認識している場合を示します。HEAD リクエストに応答する場合を除き、サーバーはエラー状況の説明を含むエンティティを含め、それが一時的な状態か永続的な状態かを示す必要があります。同様に、ユーザー エージェントは含まれているエンティティをユーザーに表示する必要があります。これらの応答コードは、どのリクエスト メソッドにも適用できます。
- 500 内部サーバーエラー
- 予期しない状況が発生し、これ以上具体的なメッセージが適切でない場合に表示される一般的なエラー メッセージ。
- 501 実装されていません
- サーバーはリクエスト メソッドを認識しないか、リクエストを実行する能力がありません。通常、これは将来的に利用可能になることを意味します (例: Web サービス API の新機能)。
- 502不正なゲートウェイ
- サーバーはゲートウェイまたはプロキシとして機能しており、アップストリーム サーバーから無効な応答を受信しました。
- 503 サービスは利用できません
- サーバーがリクエストを処理できない（過負荷またはメンテナンスのためダウンしている）。通常、これは一時的な状態です。[26]
- 504 ゲートウェイタイムアウト
- サーバーはゲートウェイまたはプロキシとして機能しており、アップストリーム サーバーからタイムリーな応答を受信しませんでした。
- 505 HTTP バージョンがサポートされていません
- サーバーはリクエストで使用された HTTP バージョンをサポートしていません。
- 506 バリアントもネゴシエートします (RFC 2295)
- リクエストに対する透過的なコンテンツネゴシエーションは循環参照をもたらす。[27]
- 507 ストレージ不足 (WebDAV; RFC 4918)
- サーバーはリクエストを完了するために必要な表現を保存できません。[7]
- 508 ループが検出されました (WebDAV; RFC 5842)
- サーバーは、リクエストの処理中に無限ループを検出しました (208 Already Reported の代わりに送信されました)。
- 510 拡張なし (RFC 2774)
- サーバーが要求を満たすためには、要求をさらに拡張する必要がある。[28]
- 511 ネットワーク認証が必要 (RFC 6585)
- クライアントはネットワークにアクセスするために認証する必要があります。ネットワークへのアクセスを制御するために使用される傍受プロキシによって使用されることを目的としています（例：Wi-Fiホットスポット経由で完全なインターネットアクセスを許可する前に利用規約への同意を要求するために使用される「キャプティブポータル」）。[24]
非公式コード
以下のコードはどの標準でも指定されていません。
- 218 これは問題ありません ( Apache HTTP Server )
- Apacheサーバーで使用されます。設定が有効になっている場合、メッセージ本文がサーバーを通過できる包括的なエラー状態
ProxyErrorOverride。この状況では、4xxまたは5xxエラーメッセージの代わりに表示されます。[29] - 419 ページ期限切れ ( Laravelフレームワーク)
- CSRFトークンが見つからないか期限切れの場合にLaravelフレームワークによって使用されます。[30]
- 420 メソッド失敗 ( Spring Framework )
- WebDAV [31]の開発中に提案された非推奨の応答ステータス。メソッドが失敗したときにSpring Frameworkで使用されます。[32]
- 420 落ち着きを高める ( Twitter )
- クライアントがレート制限を受けている場合にTwitter Search and Trends APIのバージョン1で返されます。バージョン1.1以降では、代わりに429 Too Many Requests応答コードが使用されます。[33]「Enhance your calm」というフレーズは1993年の映画『 デモリションマン』に由来しており、この数字との関連はおそらく大麻への言及です。[要出典]
- 430 リクエスト ヘッダー フィールドが大きすぎます ( Shopify )
- 一定時間内にリクエストされたURLが多すぎる場合に、429 Too Many Requestsレスポンスコードの代わりにShopifyで使用される非推奨のレスポンス。 [34]
- 430 Shopify セキュリティ拒否 ( Shopify )
- Shopifyがリクエストが悪意のあるものであると判断されたことを通知するために使用されます。[35]
- 450 Windows ペアレンタルコントロールによってブロックされました (Microsoft)
- Windowsのペアレンタルコントロールがオンになっていて、要求されたWebページへのアクセスをブロックしているときに表示されるMicrosoft拡張コード。[36]
- 498 無効なトークン (Esri)
- ArcGIS for Serverによって返されます。コード498は、期限切れまたは無効なトークンを示します。[37]
- 499 トークンが必要 (Esri)
- ArcGIS for Serverによって返されます。コード499はトークンが必要であるが送信されなかったことを示します。[37]
- 509 帯域幅制限を超えました ( Apache Web サーバー/ cPanel )
- サーバーはサーバー管理者によって指定された帯域幅を超えました。これは、共有ホスティングプロバイダーが顧客の帯域幅を制限するためによく使用されます。[38]
- 529 サイトが過負荷です
- SSLLabsサーバーテストAPIでQualysによって使用され、サイトがリクエストを処理できないことを通知します。[39]
- 530 サイトが凍結されました
- Pantheon Systemsのウェブプラットフォームで、非アクティブのために凍結されたサイトを示すために使用されます。[40]
- 530 オリジン DNS エラー ( Shopify )
- Shopifyが、Cloudflareが要求されたDNSレコードを解決できないことを示すために使用します。[35]
- 540 一時的に無効 ( Shopify )
- Shopifyが要求されたエンドポイントが一時的に無効になっていることを示すために使用します。[35]
- 598 (非公式規約) ネットワーク読み取りタイムアウト エラー
- 一部のHTTPプロキシでは、プロキシの背後のネットワーク読み取りタイムアウトをプロキシの前のクライアントに通知するために使用されます。[41]
- 599 ネットワーク接続タイムアウト エラー
- 一部の HTTP プロキシによって使用されるエラーで、プロキシの背後のネットワーク接続タイムアウトをプロキシの前のクライアントに通知します。
- 783 予期しないトークン ( Shopify )
- ShopifyがリクエストにJSON構文エラーが含まれていることを示すために使用します。[35]
- 999 非標準
- エラー999はLinkedInで使用され、ブロック/ウォールされたり、サインインしないとWebページにアクセスできないことに関連しています。[42]
インターネット情報サービス
Microsoft のインターネット インフォメーション サービス(IIS) Web サーバーは、4xx エラー領域を拡張して、クライアントの要求に関するエラーを通知します。
- 440 ログインタイムアウト
- クライアントのセッションが期限切れになったため、再度ログインする必要があります。[43]
- 449 再試行
- ユーザーが必要な情報を提供していないため、サーバーはリクエストに応じることができません。[44]
- 451 リダイレクト
- Exchange ActiveSyncでは、より効率的なサーバーが利用できる場合、またはサーバーがユーザーのメールボックスにアクセスできない場合に使用されます。[45]クライアントは、より適切なサーバーを見つけるためにHTTP自動検出操作を再実行する必要があります。[46]
IISは、より具体的な情報を提供するために追加の10進サブコードを使用することがありますが[47]、これらのサブコードは応答ペイロードとドキュメントにのみ表示され、実際のHTTPステータスコードの代わりには表示されません。
nginx
nginxウェブサーバーソフトウェアは4xxエラースペースを拡張して、クライアントのリクエストに関する問題を通知します。[ 48] [49]
- 444 応答なし
- 内部的に使用され[50]、サーバーにクライアントに情報を返さず、接続を直ちに閉じるように指示します。
- 494 リクエストヘッダーが大きすぎます
- クライアントが大きすぎるリクエストまたは長すぎるヘッダー行を送信しました。
- 495 SSL証明書エラー
- 400 Bad Request 応答コードの拡張であり、クライアントが無効なクライアント証明書を提供した場合に使用されます。
- 496 SSL証明書が必要です
- 400 Bad Request 応答コードの拡張。クライアント証明書が必要であるが提供されていない場合に使用されます。
- 497 HTTP リクエストが HTTPS ポートに送信されました
- 400 Bad Request 応答コードの拡張版。クライアントが HTTPS 要求をリッスンしているポートに HTTP 要求を送信したときに使用されます。
- 499 クライアントがリクエストをクローズしました
- サーバーが応答を送信する前にクライアントが要求を閉じた場合に使用されます。
クラウドフレア
Cloudflareのリバースプロキシサービスは、5xxシリーズのエラースペースを拡張して、オリジンサーバーの問題を通知します。[51]
- 520 Web サーバーが不明なエラーを返しました
- オリジンサーバーはCloudflareに空、不明、または予期しない応答を返しました。[52]
- 521 Webサーバーがダウンしています
- オリジン サーバーが Cloudflare からの接続を拒否しました。オリジンのセキュリティ ソリューションが、特定の Cloudflare IP アドレスからの正当な接続をブロックしている可能性があります。
- 522 接続がタイムアウトしました
- Cloudflare がオリジン サーバーへの接続でタイムアウトしました。
- 523 オリジンにアクセスできません
- Cloudflare はオリジン サーバーに到達できませんでした。たとえば、オリジン サーバーのDNS レコードが正しくないか、欠落している場合などです。
- 524 タイムアウトが発生しました
- Cloudflare はオリジン サーバーへの TCP 接続を完了できましたが、タイムリーな HTTP 応答を受信できませんでした。
- 525 SSL ハンドシェイクに失敗しました
- Cloudflare はオリジン サーバーとのSSL/TLS ハンドシェイクをネゴシエートできませんでした。
- 526 無効なSSL証明書
- Cloudflare は、オリジン Web サーバーの SSL 証明書を検証できませんでした。Cloud Foundryの gorouter でも使用されます。
- 527 レールガン エラー (廃止)
- エラー527は、CloudflareとオリジンサーバーのRailgunサーバー間の接続が中断されたことを示しています。[53] CloudflareがRailgunを廃止したため、このエラーは廃止されました。
- 530
- エラー530は1xxxエラーとともに返されます。[54]
AWS エラスティックロードバランシング
Amazon Web ServicesのElastic Load Balancingは、クライアントリクエストまたはオリジンサーバーの問題を通知するためのカスタムリターンコードをいくつか追加します。[55]
- 000
- いずれかのヘッダーの圧縮長が8Kバイトを超える場合、または1つの接続で10Kを超えるリクエストが処理された場合、HTTP/2 GOAWAYフレームで返されます。[55]
- 460
- クライアントはアイドルタイムアウト期間が経過する前にロードバランサーとの接続を閉じました。通常、クライアントのタイムアウトがElastic Load Balancerのタイムアウトよりも早い場合です。[55]
- 463
- ロードバランサーは30を超えるIPアドレスを含むX-Forwarded-Forリクエストヘッダーを受信しました。[55]
- 464
- クライアントとオリジンサーバー間のプロトコルバージョンに互換性がありません。[55]
- 561 許可されていません
- ロードバランサーに登録されたサーバーから返された認証に関するエラー。リスナールールはユーザーを認証するように設定されていますが、アイデンティティプロバイダー（IdP）はユーザーを認証するときにエラーコードを返しました。[55]
キャッシュ警告コード（廃止）
以下のキャッシュ関連の警告コードは、RFC 7234 で規定されています。上記の他のステータス コードとは異なり、これらは HTTP プロトコルの応答ステータスとしてではなく、「Warning」HTTP ヘッダーの一部として送信されました。[56] [57]
この「警告」ヘッダーはサーバーから送信されず、クライアントからも確認されないことが多いため、このヘッダーとそのコードは2022年にHTTPワーキンググループによってRFC 9111で廃止されました。[58]
- 110 応答が古い
- キャッシュによって提供された応答が古くなっています (コンテンツの経過時間が、Cache-Control ヘッダーまたはヒューリスティックに選択された有効期間によって設定された最大経過時間を超えています)。
- 111 再検証に失敗しました
- 元のサーバーに到達できないため、キャッシュは応答を検証できませんでした。
- 112 切断された操作
- キャッシュはネットワークの残りの部分から意図的に切断されます。
- 113 ヒューリスティック有効期限
- キャッシュは経験的に 24 時間を超える鮮度有効期間を選択し、応答の経過時間は 24 時間を超えています。
- 199 その他の警告
- 任意の、特定されない警告。警告テキストはログに記録されるか、ユーザーに表示される場合があります。
- 214 変換を適用
- コンテンツのエンコーディングやメディア タイプなどの変更など、表現に何らかの変換を適用する場合にプロキシによって追加されます。
- 299 その他 持続警告
- 199 と同じですが、永続的な警告を示します。
参照
注記
- ^強調された単語やフレーズ （mustやshouldなど）は、 RFC 2119で示されている解釈ガイドラインを表します。
参考文献
- ^ abcdefg R. Fielding ; M. Nottingham; J. Reschke 編 (2022 年 6 月)。HTTP セマンティクス。インターネット エンジニアリング タスク フォース。doi : 10.17487 / RFC9110。ISSN 2070-1721。STD 97。RFC 9110。 インターネット標準 97。RFC 2818、7230、7231、7232、7233、7235、7538、7615、および 7694 を 廃止します。RFC 3864 を更新します。
- ^ abc 「Hypertext Transfer Protocol (HTTP) Status Code Registry」。Iana.org。2011年12月11日時点のオリジナルよりアーカイブ。2015年1月8日閲覧。
- ^ Goland, Yaronn; Whitehead, Jim ; Faizi, Asad; Carter, Steve R.; Jensen, Del (1999 年 2 月). 分散オーサリングのための HTTP 拡張 – WEBDAV. ネットワーク ワーキング グループ. doi : 10.17487/RFC2518 . RFC 2518. 提案された標準。RFC 4918 によって廃止されました。
- ^ 「102 処理 – HTTP MDN」。2023年7月25日。102 ステータスコードは非推奨です
- ^ 奥 一穂 (2017年12月). ヒントを示すHTTPステータスコード. IETF . doi : 10.17487/RFC8297 . RFC 8297. 実験的。
- ^ Stewart, Mark; djna. 「レスポンスコード 200 または 201 とコンテンツを含む POST でリクエストを作成する」。Stack Overflow。2016年 10 月 11 日時点のオリジナルよりアーカイブ。2015 年10 月 16 日閲覧。
- ^ abcd Dusseault, Lisa編 (2007 年 6 月)。Web 分散オーサリングおよびバージョン管理 (WebDAV) の HTTP 拡張。ネットワーク ワーキング グループ。doi : 10.17487/ RFC4918。RFC 4918 。 提案された標準。RFC 5689 によって更新されました。RFC 2518 は廃止されました。
- ^ Hoff, Arthur van ; Douglis, Fred; Krishnamurthy, Balachander; Goland, Yaron Y.; Hellerstein, Daniel M.; Feldmann, Anja; Mogul, Jeffrey (2002 年 1 月)。HTTP における Delta エンコーディング。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3229。RFC 3229 。 提案された標準。
- ^ T Berners-Lee ; R. Fielding ; H. Frystyk (1996 年 5 月). ハイパーテキスト転送プロトコル -- HTTP/1.0. ネットワークワーキンググループ. doi : 10.17487/RFC1945 . RFC 1945. 情報提供。
- ^ 「Mozilla Bugzilla Bug 187996: 305 リダイレクトでの奇妙な動作、コメント 13」。2003 年 3 月 3 日。2014 年 4 月 21 日時点のオリジナルよりアーカイブ。2009年5 月 21 日閲覧。
- ^ 「PHP Web ショップ開発者向け GNU Taler チュートリアル 0.4.0」。docs.taler.net。2017年 11 月 8 日時点のオリジナルよりアーカイブ。2017 年10 月 29 日閲覧。
- ^ 「Google API 標準エラー応答」。2016 年。2017 年 5 月 25 日時点のオリジナルよりアーカイブ。2017 年6 月 21 日閲覧。
- ^ 「Sipgate API ドキュメント」。2018 年 7 月 10 日時点のオリジナルよりアーカイブ。2018 年7 月 10 日閲覧。
- ^ “Shopify Documentation”. 2018年7月25日時点のオリジナルよりアーカイブ。2018年7月25日閲覧。
- ^ 「Stripe API リファレンス – エラー」。stripe.com。2019年10月 28 日閲覧。
- ^ abc R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; L. Masinter ; P. Leach; T. Berners-Lee (1999 年 8 月). ハイパーテキスト転送プロトコル -- HTTP/1.1. ネットワークワーキンググループ. doi : 10.17487/RFC2616 . RFC 2616. 廃止。RFC 7230、7231、7232、7233、7234、7235 により廃止。RFC 2068 は廃止。RFC 2817、5785、6266、6585 により更新。
- ^ TheDeadLike. 「HTTP/1.1 ステータス コード 400 と 417、どちらを選択できない」。serverFault。2015年 10 月 10 日時点のオリジナルよりアーカイブ。2015 年10 月 16 日閲覧。
- ^ L. Masinter (1998 年 4 月 1 日). ハイパーテキストコーヒーポット制御プロトコル (HTCPCP/1.0). ネットワークワーキンググループ. doi : 10.17487/RFC2324 . RFC 2324. 情報提供。RFC 7168 により更新。これはエイプリルフールのコメント要求です。
ティーポットでコーヒーを淹れようとすると、エラー コード「418 私はティーポットです」が表示されます。結果として得られるエンティティ本体は短くて太いものになる場合があります。
- ^ 私はティーポットです
- ^ Barry Schwartz (2014年8月26日). 「SEOオタクのための新しいGoogleイースターエッグ：サーバーステータス418、私はティーポットです」。Search Engine Land。2015年11月15日時点のオリジナルよりアーカイブ。 2015年11月4日閲覧。
- ^ 「Google's Teapot」。2017年10月23日閲覧。
- ^ 「ウェブサイトで追加のウェブセキュリティを有効にする」DreamHost . 2022年12月18日閲覧。
- ^ 「ロシアのウェブサイトにアクセスしたら、このひどいティーポットしか表示されなかった」PCMag 。 2022年12月18日閲覧。
- ^ abcd M. Nottingham; R. Fielding (2012 年 4 月). 追加のHTTPステータス コード。インターネットエンジニアリング タスク フォース。doi : 10.17487/ RFC6585。ISSN 2070-1721。RFC 6585 。 提案された標準。RFC 2616 を更新します。
- ^ Bray, T. (2016 年 2 月). 「法的障害を報告するための HTTP ステータス コード」. ietf.org . 2016 年 3 月 4 日時点のオリジナルよりアーカイブ。2015 年3 月 7 日閲覧。
- ^ alex. 「サイトがメンテナンスのためにダウンしているときに送信すべき正しい HTTP ステータス コードは何ですか?」Stack Overflow。 2016 年 10 月 11 日時点のオリジナルよりアーカイブ。 2015 年10 月 16 日閲覧。
- ^ Holtman, Koen; Mutz, Andrew H. ( 1998 年 3 月)。HTTP における透過的なコンテンツネゴシエーション。ネットワークワーキンググループ。doi : 10.17487/ RFC2295。RFC 2295 。 実験的。
- ^ Nielsen, Henrik Frystyk ; Leach, Paul; Lawrence, Scott (2000 年 2 月). HTTP 拡張フレームワーク. ネットワークワーキンググループ. doi : 10.17487/RFC2774 . RFC 2774. 歴史的。
- ^ 「218 これは問題ありません - HTTP ステータス コードの説明」。HTTP.dev。2023年7 月 25 日閲覧。
- ^ “framework/src/Illuminate/Foundation/Exceptions/Handler.php”. GitHub . 2023年12月12日閲覧。
- ^ 「draft-ietf-webdav-protocol-05: World Wide Web 上の分散オーサリングの拡張機能 -- WEBDAV」。
- ^ 「Enum HttpStatus」。Spring Framework。org.springframework.http。2015年10月25日時点のオリジナルよりアーカイブ。 2015年10月16日閲覧。
- ^ 「Twitter エラーコードと応答」。Twitter。2014年。2017 年 9 月 27 日時点のオリジナルよりアーカイブ。2014 年1 月 20 日閲覧。
- ^ 「 HTTPステータスコードとSEO：知っておくべきこと」。ContentKing 。 2019年8月9日閲覧。
- ^ abcd 「Shopify API レスポンス ステータスとエラー コード」 。2023年12 月 12 日閲覧。
- ^ 「エラーページのスクリーンショット」。 2013年5月11日時点のオリジナル(bmp)からアーカイブ。2009年10月11日閲覧。
- ^ ab 「トークンベースの認証の使用」。ArcGIS Server SOAP SDK。2014年 9 月 26 日時点のオリジナルよりアーカイブ。2014年9 月 8 日閲覧。
- ^ 「HTTP エラー コードとクイック フィックス」。Docs.cpanel.net。2015 年 11 月 23 日時点のオリジナルよりアーカイブ。2015 年10 月 15 日閲覧。
- ^ 「SSL Labs API v3 ドキュメント」. github.com .
- ^ 「プラットフォームに関する考慮事項 | Pantheon Docs」。pantheon.io。2017年1月6日時点のオリジナルよりアーカイブ。2017年1月5日閲覧。
- ^ 「HTTP ステータス コード – ascii-code.com」www.ascii-code.com。 2017 年 1 月 7 日時点のオリジナルよりアーカイブ。2016 年12 月 23 日閲覧。
- ^ 2017年と2024年の例
- ^ 「 Outlook Web Access を使用して Exchange 2007 にログオンしようとすると、エラー メッセージ「440 ログイン タイムアウト」が表示される」。Microsoft . 2010 . 2013 年11 月 13 日閲覧。
- ^ 「2.2.6 449 ステータス コードによる再試行」。Microsoft 2009年。2009 年 10 月 5 日時点のオリジナルよりアーカイブ。2009 年10 月 26 日閲覧。
- ^ 「MS-ASCMD、セクション 3.1.5.2.2」。Msdn.microsoft.com。2015 年 3 月 26 日時点のオリジナルよりアーカイブ。2015 年1 月 8 日閲覧。
- ^ "Ms-oxdisco". Msdn.microsoft.com. 2014年7月31日時点のオリジナルよりアーカイブ。2015年1月8日閲覧。
- ^ 「IIS 7.0 の HTTP ステータス コード」。Microsoft。2009年 7 月 14 日。2009 年 4 月 9 日時点のオリジナルよりアーカイブ。2009年4 月 1 日閲覧。
- ^ "ngx_http_request.h". nginx 1.9.5 ソースコード. nginx inc. 2017年9月19日時点のオリジナルよりアーカイブ。 2016年1月9日閲覧。
- ^ "ngx_http_special_response.c". nginx 1.9.5 ソースコード. nginx inc. 2018年5月8日時点のオリジナルよりアーカイブ。 2016年1月9日閲覧。
- ^ 「return」ディレクティブは、Wayback Machine (http_rewrite モジュール) ドキュメントで 2018 年 3 月 1 日にアーカイブされています。
- ^ 「トラブルシューティング: エラーページ」。Cloudflare。2016年3月4日時点のオリジナルよりアーカイブ。2016年1月9日閲覧。
- ^ 「エラー 520: Web サーバーが不明なエラーを返します」。Cloudflare。
- ^ 「527 エラー: Railgun Listener から origin へのエラー」。Cloudflare。2016年 10 月 13 日時点のオリジナルよりアーカイブ。2016 年10 月 12 日閲覧。
- ^ 「エラー 530」。Cloudflare 。 2019年11月1日閲覧。
- ^ abcdef 「アプリケーションロードバランサーのトラブルシューティング – Elastic Load Balancing」。docs.aws.amazon.com 。 2023年5月17日閲覧。
- ^ R. Fielding、M. Nottingham、J. Reschke (2014 年 6 月)。ハイパーテキスト転送プロトコル (HTTP/1.1): キャッシュ。インターネット技術タスク フォース(IETF)。doi : 10.17487 / RFC7234。RFC 7234 。 提案された標準。セクション 5.5。RFC 9111によって廃止されました。RFC 2616 を廃止します。
- ^ 「警告 – HTTP | MDN」。developer.mozilla.org 。 2021年8月15日閲覧。 この記事には、CC BY-SA 2.5 ライセンスに基づいて利用可能なテキストが組み込まれています。
- ^ 「警告」。HTTP キャッシュ。2022 年 6 月。sec. 5.5。doi : 10.17487/ RFC9111。RFC 9111 。
外部リンク
Wikimedia Commons には、HTTP ステータス コードに関連するメディアがあります。
- インターネット割り当て番号局のハイパーテキスト転送プロトコル (HTTP) ステータス コード レジストリ
- http-statuscode.comの HTTP ステータス コード
- mozilla.orgの MDN ステータス コード リファレンス