標準コード IETFによって定義されたステータスコードを以下に示します。強調表示されている「must」 、「must not」 、「should」は、 RFC 2119で示されている解釈ガイドラインです。
情報応答は、リクエストが受信され、理解され、処理中であることを示します。クライアントには最終応答を待つように通知します。このメッセージには本文は含まれません。HTTP/1.0 標準では 1xx ステータスコードが定義されていないため、サーバーは実験的な条件下を除き、HTTP/1.0 準拠のクライアントに 1xx 応答を送信してはなりません。
サーバーはリクエストヘッダーを受信しており、クライアントはリクエストボディの送信に進む必要があります（POST リクエストなど、ボディの送信が必要なリクエストの場合）。不適切なヘッダーのためにリクエストが拒否された後に、大きなリクエストボディをサーバーに送信するのは非効率的です。サーバーにリクエストヘッダーをチェックさせるには、クライアントはExpect: 100-continue最初のリクエストでヘッダーとして送信し、100 Continueボディを送信する前にレスポンスでステータスコードを受け取る必要があります。クライアントが403（Forbidden）や405（Method Not Allowed）などのエラーコードを受け取った場合は、リクエストボディを送信してはなりません。レスポンスは、サーバーが期待値をサポートしていないことを示しているため、ヘッダー417 Expectation Failedなしでリクエストを繰り返す必要があることを示していますExpect（これは、たとえばHTTP/1.0サーバーの場合です）。[ 2 ] ： リクエスト元はサーバーに対しプロトコルの切り替えを要求し、サーバーはこれに同意した。 WebDAV ；RFC 2518）WebDAVリクエストには、ファイル操作を含む多くのサブリクエストが含まれる場合があり、リクエストの完了に時間がかかることがあります。このコードは、サーバーがリクエストを受信して処理しているが、まだ応答がないことを示します。[ 3 ] [ 4 ] 最終的な HTTP メッセージの前にいくつかのレスポンス ヘッダーを返すために使用されます。[ 5 ]
2xx 成功 成功ステータスは、クライアントから要求されたアクションが受信され、理解され、承認されたことを示します。[ 1 ]
HTTPリクエストが成功した場合の標準レスポンスです。実際のレスポンスは、使用されたリクエストメソッド によって異なります。GETリクエストの場合、レスポンスにはリクエストされたリソースに対応するエンティティが含まれます。POSTリクエストの場合、レスポンスにはアクションの結果を記述または含むエンティティが含まれます。 リクエストは完了し、新しいリソースが作成されました。[ 6 ] リクエストは処理のために受理されましたが、処理は完了していません。リクエストは最終的に処理される場合もあれば、されない場合もあり、処理が行われた際に却下される可能性もあります。 サーバーは、オリジンから200 OKを受け取った変換プロキシ（Webアクセラレータ [ 2 ] ： [ 2 ] ： サーバーはリクエストを正常に処理しましたが、コンテンツを返していません。 サーバーはリクエストを正常に処理し、リクエスト元にドキュメントビューのリセットを要求していますが、コンテンツは返していません。 サーバーは、クライアントから送信された範囲ヘッダーのため、リソースの一部（バイト単位 ）のみを配信しています。範囲ヘッダーは、HTTPクライアントが中断されたダウンロードを再開したり、ダウンロードを複数の同時ストリームに分割したりするために使用されます。 続くメッセージ本文はデフォルトではXML メッセージであり、サブリクエストの数に応じて複数の個別の応答コードが含まれる場合があります。[ 7 ] DAVバインディングのメンバーは、（マルチステータス）レスポンスの前の部分ですでに列挙されているため、再度含める必要はありません。 サーバーはリソースの要求を処理し、応答は現在のインスタンスに適用された 1 つ以上のインスタンス操作の結果を表します。[ 8 ]
3xxリダイレクト 3xxステータスは、クライアントがリクエストを完了するために追加のアクション（一般的にはURLリダイレクト）を実行する必要があることを示します。 [ 1 ] [ 2 ] :
クライアントが選択できるリソースの複数のオプションを示します（エージェント主導のコンテンツネゴシエーションによる）。たとえば、このコードは、複数のビデオフォーマットオプションを提示したり、異なる ファイル名拡張子を持つファイルを一覧表示したり、 単語の意味の曖昧性解消を 提案したりするために使用できます。 リンク先が移動されたため、リクエストおよび今後同様のリクエストは指定されたURI にリダイレクトされます。クライアントにリンク編集機能がある場合は、リクエストURLへの参照を更新する必要があります。特に指定がない限り、レスポンスはキャッシュ可能です。GETリクエストを除き、ボディには新しいURLへのハイパーリンクが含まれている必要があります。GETまたはHEADリクエストを除き、クライアントはリダイレクトする前にユーザーに確認する必要があります。[ 9 ]
このコードは、ユーザーを HTTP からHTTPS にアップグレードするためのベスト プラクティスと考えられています。BingとGoogle の 両方が、検索エンジンの結果に表示されるページの URL を変更するためにこのコードを使用することを推奨しています。ただし、その URL が永続的に変更され、近いうちに再び変更される予定がない場合に限ります。[ 10 ] [ 11 ] リソースがLocation ヘッダー フィールドで指定された別の URL を介してアクセスできることを示します。HTTP/1.0 仕様 (理由フレーズ「Moved Temporarily」を使用) では、クライアントが同じ方法でリダイレクトすることを要求していましたが、[ 12 ] [ 13 ] RFC 2616 ) では、リクエストを GET に変更することを要求し、元のリクエスト タイプを保持する 307 という 2 つのステータス コードが追加されました。この曖昧さの解消により明確さが増したにもかかわらず、HTTP/1.1 をサポートしていないブラウザとの互換性を維持するために、Web フレームワークでは 302 コードがまだ使用されています。[ 14 ] [ 2 ] : §15.4 RFC 7231 ( RFC 2616の更新) では、ユーザー エージェントが POST を GET に書き換えることができるように定義が変更されました。[ 15 ] サーバーがPOSTリクエストまたはその他の冪等性のないリクエストに対してこのコードとlocation ヘッダーフィールドで応答した場合、クライアントは指定された場所に対してGETリクエストを発行することが想定されます。同じ方法でターゲットリソースへのリクエストをトリガーするために、サーバーは代わりに307で応答します。 このコードの使用は、セマンティック Web 理論に従って現実世界のオブジェクトを識別するURI の要求に応答する 1 つの方法として提案されています[ 16 ] (もう 1 つはハッシュ URI の使用です)。[ 17 ] [ 16 ] [ 16 ] http://www.example.com/id/alice このコードは、呼び出し元に即座に応答する必要があるが、長時間かかる画像変換など、非同期で実行を継続する必要がある HTTP ベースのWeb API を提供する場合に使用されます。Web API は、クライアントが操作のステータスを確認できるステータスチェック URI を提供します。完了すると、応答にはこのステータスコードと最終結果へのリダイレクト URI が含まれる場合があります。[ 18 ] リクエストヘッダー のIf-Modified-SinceまたはIf-None-Matchで指定されたバージョン以降、リソースが変更されていないことを示します。この場合、クライアントは既にダウンロード済みのコピーを保持しているため、リソースを再送信する必要はありません。要求されたリソースはプロキシ経由でのみ利用可能であり、そのアドレスはレスポンスで提供されます。セキュリティ上の理由から、多くのHTTPクライアント（Mozilla Firefox やInternet Explorer など）はこのステータスコードに従いません。[ 19 ] 現在は使用されていません。元々は「以降のリクエストでは、指定されたプロキシを使用する必要があります」という意味でした。 この場合、リクエストは別のURIで再度送信する必要がありますが、以降のリクエストでは元のURIを使用する必要があります。従来の302の実装方法とは異なり、元のリクエストを再送信する際にリクエストメソッドを変更することはできません。例えば、POSTリクエストは別のPOSTリクエストを使用して再度送信する必要があります。 このリクエストおよび今後のすべてのリクエストは、指定されたURI に送信される必要があります。308は301と同様の動作をしますが、HTTPメソッドの変更は許可しません 。そのため、たとえば、恒久的にリダイレクトされたリソースへのフォーム送信はスムーズに継続できます。
ウィキメディアで404エラーが発生しています 4xxステータスコードは、エラーがクライアント側で発生したと思われる場合に使用されます。HEADリクエストへの応答時を除き、サーバーはエラー状況の説明と、それが一時的なものか永続的なものかを示す情報を含むエンティティを含める必要があります。これらのステータスコードは、あらゆる リクエストメソッド に適用可能です。ユーザーエージェントは、含まれているエンティティをユーザーに表示する必要があります。
クライアント側の明らかなエラー（例えば、リクエスト構文の不正、サイズが大きすぎる、リクエストメッセージのフレーミングが無効、または不正なリクエストルーティングなど）により、サーバーはリクエストを処理できないか、処理しません。 403 Forbidden と似ていますが、認証が必要で、認証が失敗したか、まだ提供されていない場合に特に使用されます。レスポンスには、要求されたリソースに適用可能なチャレンジを含む WWW-Authenticate ヘッダーフィールドを含める必要があります。基本アクセス認証 とダイジェストアクセス認証 を参照してください。401 は意味的には「認証されていない」ことを意味し、ユーザーは対象リソースに対する有効な認証資格情報を持っていません。 将来の使用のために予約されています。当初の意図は、このコードが、たとえばGNU Taler [ 20 ] によって 提案されたような、何らかの形のデジタル キャッシュ またはマイクロ ペイメント スキームの一部として使用される可能性があるということでしたが、それはまだ実現しておらず、このコードは広く使用されていません。Google Developers API は、特定の開発者がリクエストの 1 日の制限を超えた場合にこのステータスを使用します。[ 21 ] Sipgate は 、アカウントに呼び出しを開始するのに十分な資金がない場合にこのコードを使用します。[ 22 ] Shopify は 、ストアが料金を支払っておらず、一時的に無効になっている場合にこのコードを使用します。[ 23 ] Stripe は 、たとえば不正な支払いをブロックした場合など、パラメーターが正しかったにもかかわらず支払いが失敗した場合にこのコードを使用します。[ 24 ] Cloudflare Turnstile は、 cURL を使用してリソースを要求するときにこのコードを使用します。x402は 、HTTP 402「支払いが必要」ステータス コードを再利用するオープン スタンダードです。 リクエストは有効でしたが、サーバーが処理を拒否しました。これは、ユーザーがリソースへのアクセス権限を持っていない、何らかのアカウントが必要である、または禁止されている操作（例えば、1つのレコードしか許可されていない場所で重複レコードを作成するなど）を試みたことが原因である可能性があります。このコードは通常、リクエストがWWW-Authenticateヘッダーフィールドのチャレンジに応答して認証を行ったにもかかわらず、サーバーがその認証を受け入れなかった場合にも使用されます。このリクエストは繰り返さないでください。 このコードは401とは異なり、401はクライアントが認証されていない場合に返され、有効な認証後には正常な応答が返される可能性があることを示唆するのに対し、403は認証されたアカウントの権限が不十分であるなど、認証情報を提供したにもかかわらずクライアントがリソースへのアクセスを許可されない場合に返されます。 Apache Web サーバーは、 ディレクトリ一覧が無効になっており、ブラウザーに返す既存のファイルを指定するDirectory Index ディレクティブがない場合、ファイルシステム ディレクトリ に対応するURL [ 25 ] Mod プロキシ 拡張機能を構成しており、これも 403 を返します。IISも 、そのサーバーでディレクトリ一覧が拒否されている場合は同じように応答します。WebDAV では、 クライアントが PROPFIND 要求を発行したが、必要な Depth ヘッダーも発行しなかった場合、または Depth ヘッダーが infinity の場合、403 が返されます。[ 25 ] 要求されたリソースは見つかりませんでしたが、将来的に利用可能になる可能性があります。クライアントからの再リクエストは許可されています。 要求されたリソースに対して、指定されたリクエストメソッドはサポートされていません（たとえば、POST を介してデータを提示する必要があるフォームに対する GET リクエスト、または読み取り専用リソースに対する PUT リクエストなど）。 要求されたリソースは、リクエストで送信された Accept ヘッダーに従って受け入れられないコンテンツのみを生成する能力を持っています。コンテンツネゴシエーションを 参照してください。 クライアントはまずプロキシ で認証を行う必要があります。 サーバーはリクエストを待機中にタイムアウトしました。HTTP仕様によると、「クライアントは、サーバーが待機する準備が整った時間内にリクエストを送信しませんでした。クライアントは、後でいつでも変更を加えることなくリクエストを再度送信できます。」 リソースの現在の状態に競合があるため、要求を処理できなかったことを示します。たとえば、複数の同時更新間の編集競合 などです。[ 26 ] 要求されたリソースは以前使用されていたが、現在は利用できず、今後も利用できないことを示します。これは、リソースが意図的に削除され、リソースをパージする必要がある場合に使用します。410 ステータスコードを受け取った場合、クライアントは今後そのリソースを要求してはなりません。検索エンジンなどのクライアントは、インデックスからリソースを削除する必要があります。ほとんどのユースケースでは、クライアントと検索エンジンがリソースをパージする必要はなく、代わりに「404 Not Found」を使用できます。 リクエストにはコンテンツの長さが指定されていませんでしたが、リクエストされたリソースにはコンテンツの長さが必要です。 サーバーは、リクエスト元がリクエストヘッダーフィールドに設定した前提条件のいずれかを満たしていません。 リクエストがサーバーが処理できるサイズを超えています。以前は「リクエストエンティティが大きすぎます」および「ペイロードが大きすぎます」と呼ばれていました。[ 27 ] ： [ 2 ] ： 指定されたURIが 長すぎてサーバーが処理できませんでした。これは多くの場合、GETリクエストのクエリ文字列としてエンコードされたデータが多すぎることが原因であり、その場合はPOSTリクエストに変換する必要があります。以前は「Request-URI Too Long」と呼ばれていました。[ 27 ] ： リクエストエンティティのメディアタイプ が、サーバーまたはリソースでサポートされていません。たとえば、クライアントがimage/svg+xml形式 で画像をアップロードしたが、サーバーは画像に別の形式を要求する場合などです。 クライアントはファイルの一部（バイト単位 ）を要求しましたが、サーバーはその部分を提供できません。例えば、クライアントがファイルの末尾を超える部分を要求した場合などです。以前は「要求範囲が満たされません」と呼ばれていました。[ 27 ] ： サーバーは、Expectリクエストヘッダーフィールドの要件を満たすことができません。[ 28 ] このコードは、1998 年にIETF の伝統的な エイプリルフールのジョーク の 1 つですが、RFC 2324、「ハイパーテキストコーヒーポット制御プロトコル」 [ 29 ] Google.com の 「私はティーポットです」イースターエッグなど、一部の Web サイトでイースターエッグとして使用されています。 [ 30 ] [ 31 ] [ 32 ] [ 33 ] リクエストは、応答を生成できないサーバー（例えば、接続の再利用など）に送信されました。 要求は形式的に正しかった（つまり、構文的に正しかった）が、処理できなかった。[ 2 ] ： アクセスしようとしているリソースはロックされています。[ 7 ] リクエストが失敗したのは、別のリクエストに依存しており、そのリクエストが失敗したためです（例：PROPPATCH）。[ 7 ] サーバーが、リプレイされる可能性のあるリクエストを処理するリスクを冒したくないことを示しています。 クライアントは、 Upgradeヘッダー フィールドで指定されているTLS/1.3 などの別のプロトコルに切り替える必要があります。 オリジンサーバーは、リクエストが条件付きであることを要求します。これは、クライアントがリソースの状態を取得し、それを変更してサーバーにPUTで送信した際に、その間に第三者がサーバー上の状態を変更してしまい、競合が発生する「更新の消失」問題を防止することを目的としています。[ 34 ] ユーザーが一定時間内に送信したリクエスト数が多すぎます。レート制限 スキームでの使用を想定しています。[ 34 ] サーバーは、個々のヘッダーフィールド、またはすべてのヘッダーフィールドの合計が大きすぎるため、リクエストを処理することを拒否します。[ 34 ] サーバーオペレーターは、要求されたリソースを含むリソースまたはリソースセットへのアクセスを拒否するよう法的要求を受けました。[ 35 ] コード451は、小説『華氏451度』 [ 36 ]
5xxステータスは、サーバーがエラーが発生したことを認識しているか、またはリクエストを実行できないことを示します。HEADリクエストへの応答時を除き、サーバーはエラー状況の説明を含むエンティティを含め、それが一時的な状態か永続的な状態かを示す必要があります。同様に、ユーザーエージェントは含まれているエンティティをユーザーに表示する 必要があります。これらの応答コードは、すべての リクエストメソッド に適用できます。
予期せぬ事態が発生し、より具体的なメッセージを提示できない場合に表示される、一般的なエラーメッセージ。 サーバーがリクエストメソッドを認識しないか、リクエストを処理する機能がありません。通常、これは将来的に利用可能になることを意味します（例：WebサービスAPIの新機能）。 サーバーはゲートウェイ またはプロキシとして機能しており、上流サーバーから無効な応答を受信しました。 サーバーがリクエストを処理できません（過負荷状態またはメンテナンスのため）。通常、これは一時的な状態です。[ 37 ] サーバーはゲートウェイまたはプロキシとして機能しており、上流サーバーからタイムリーな応答を受信しませんでした。 サーバーは、リクエストで使用されているHTTPバージョンをサポートしていません。 リクエストに対する透明なコンテンツネゴシエーションの結果、 循環参照 が発生します。[ 38 ] サーバーはリクエストを完了するために必要な表現を保存できません。[ 7 ] サーバーはリクエストの処理中に無限ループを検出しました（208 Already Reported の代わりに送信されました）。 サーバーが要求を満たすためには、要求のさらなる拡張が必要です。[ 39 ] クライアントはネットワークアクセスを取得するために認証を行う必要があります。これは、ネットワークへのアクセスを制御するために使用されるプロキシを傍受することによって使用されることを意図しています（たとえば、Wi -Fiホットスポット 経由で完全なインターネットアクセスを許可する前に利用規約への同意を要求するために使用される「キャプティブポータル」）。[ 34 ]
非標準コード 以下のコードは様々なWebサーバーで使用されていますが、IETF標準では規定されていません。
Microsoft のInternet Information Services (IIS) Web サーバーは、クライアントのリクエストのエラーを通知するために 4xx エラー空間を拡張します。IIS は、より詳細な情報のために追加の 10 進サブコードを使用することがありますが、[ 40 ]
クライアントのセッションが期限切れになったため、再度ログインする必要があります。[ 41 ] ユーザーが必要な情報を提供していないため、サーバーはリクエストに応じることができません。[ 42 ] Windowsのペアレンタルコントロールが要求されたウェブページへのアクセスをブロックしていることを示します。[ 43 ] Exchange ActiveSync では、より効率的なサーバーが利用可能な場合、またはサーバーがユーザーのメールボックスにアクセスできない場合に使用されます。[ 44 ] [ 45 ]
nginx nginxウェブサーバーソフトウェアは、 クライアントのリクエストの問題を通知するために4xxエラーの範囲を拡張します。[ 46 ] [ 47 ]
Used internally[ 48] Client sent too large request or too long header line. An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate . An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided. An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests. Used when the client has closed the request before the server could send a response.
Cloudflare Cloudflare 's reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.[ 49]
The origin server returned an empty, unknown, or unexpected response to Cloudflare.[ 50] The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.[ 51] Cloudflare timed out contacting the origin server.[ 52] Cloudflare could not contact the origin server.[ 53] Cloudflare was able to complete a TCP connection to the origin server, but the origin did not provide a timely HTTP response.[ 54] Cloudflare could not negotiate a SSL/TLS handshake with the origin server.[ 55] [ 56] Cloudflare could not validate the SSL certificate on the origin web server.[ 57] [ 58] Cloud Foundry 's gorouter. Error 527 indicated an interrupted connection between Cloudflare and the origin server's Railgun server.[ 59] Cloudflare was unable to resolve the origin hostname, preventing it from establishing a connection to the origin server. The body of the response contains an 1xxx error.[ 60] [ 61]
AWS Elastic Load Balancing Amazon Web Services のElastic Load Balancing は、 クライアントのリクエストまたはオリジン サーバーの問題を示すために、いくつかのカスタム リターン コードを追加します。[ 62 ]
いずれかのヘッダーの圧縮長が 8K バイトを超える場合、または 1 つの接続を通じて 10K を超えるリクエストが処理される場合、HTTP/2 GOAWAY フレームとともに返されます。[ 62 ] クライアントはアイドルタイムアウト期間が経過する前にロードバランサーとの接続を閉じました。通常、クライアントのタイムアウトがElastic Load Balancerのタイムアウトよりも早い場合に発生します。[ 62 ] ロードバランサーは、30 を超える IP アドレスを含む X-Forwarded-For リクエスト ヘッダーを受信しました。[ 62 ] クライアントとオリジンサーバー間でプロトコルバージョンが互換性がありません。[ 62 ] ロードバランサーに登録されているサーバーから返された認証に関するエラー。リスナールールはユーザーを認証するように構成されていますが、IDプロバイダー（IdP）がユーザー認証時にエラーコードを返しました。[ 62 ]
アパッチ Apache HTTPサーバー で使用されます。
サーバーがサーバー管理者によって指定された帯域幅を超えました。これは、共有ホスティングプロバイダーが顧客の帯域幅を制限するためによく使用されます。[ 63 ] cPanel でも使用されます。
Laravelフレームワーク Laravel フレームワークで使用されています。
CSRFトークンが欠落しているか、期限切れです。[ 64 ]
Shopify Shopify で使用されています。
430 リクエストヘッダーフィールドが大きすぎます Shopify が一定時間内にリクエストされた URL が多すぎる場合に、429 Too Many Requests レスポンス コードの代わりに使用していた非推奨のレスポンス。 [ 68 ] 430 Shopifyセキュリティ拒否 Shopify は、リクエストが悪意のあるものと判断されたことを示すためにこれを使用します。[ 69 ] 530 オリジンDNSエラー Cloudflare が要求された DNS レコードを解決できないことを示しています。[ 69 ] 要求されたエンドポイントが一時的に無効になっていることを示します。[ 69 ] リクエストにJSON構文エラーが含まれていることを示します。[ 69 ]
ArcGIS Server ArcGIS Server で使用されます。
有効期限切れまたはその他の理由で無効なトークンであることを示します。[ 70 ] トークンが必要であるが、送信されていないことを示します。[ 70 ]
cPanel cPanel で使用されます。
サーバーのアカウントが、CPU/RAM 使用量や同時実行プロセス数など、割り当てられたリソースを超過した場合に、503 の代わりに使用されます。 [ 71 ]
SSLLabsサーバーテストAPI Qualys がSSLLabsサーバーテストAPIで使用しています。
サイトがリクエストを処理できないことを示すシグナル。[ 72 ]
LinkedIn LinkedIn で使用されています。
ログインしないとウェブページにアクセスできない、またはブロックされていることに関連しています。[ 74 ]
その他 非公式な包括的なエラー状態であり、設定がProxyErrorOverride有効になっている場合にメッセージ本文をサーバー経由で通過させるために、広くApache HTTPサーバーに起因するものとされているが、ステータスコードと動作は公式のApache仕様の一部ではない。このステータスコードとApacheの関連性は、出典不明のWikipediaへの追加に起因しており、その後他の参照資料に取り上げられ、循環参照 が生じた。[ 75 ] HTTPプロキシの一部が、プロキシの背後にあるネットワーク読み取りタイムアウトをプロキシの前のクライアントに通知するために使用する非公式な慣習。[ 76 ] 一部のHTTPプロキシが、プロキシの背後にあるネットワーク接続タイムアウトを、プロキシの前面にいるクライアントに通知するために使用するエラー。
参考文献 1 2 3 「ハイパーテキスト転送プロトコル（HTTP）ステータスコードレジストリ」 。Iana.org。 2011年12月11日のオリジナルから アーカイブ。 2015年 1月8日 取得 。 1 2 3 4 5 6 7 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 ↑ Goland, Yaronn; Whitehead, Jim ; Faizi, Asad; Carter, Steve R.; Jensen, Del (1999 年 2 月). HTTP Extensions for Distributed Authoring – WEBDAV . Network Working Group. doi : 10.17487/RFC2518 . RFC 2518 . 提案された標準規格。RFC ↑ 「102 処理 – HTTP MDN」 。2023年7月25日。 ↑ 奥和穂（2017年12月）。 ヒントを示すためのHTTPステータスコード 。 インターネット 技術 タスクフォース 。doi : 10.17487/ RFC8297。RFC 8297 。 実験的。 ↑ スチュワート、マーク; djna。 「POST でリクエストを作成し、レスポンス コード 200 または 201 とコンテンツを取得する」 。Stack Overflow。2016 年 10 月 11 日のオリジナルから アーカイブ済み 。2015 年 10 月 16 日 取得 。 1 2 3 4 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 エンコーディング . Network Working Group. doi : 10.17487/RFC3229 . RFC 3229 . 提案された規格。 ↑ Fielding 他 (1999 年 6 月)。10.3.2 301 Moved Permanently。IETF。p . 61。sec . 10.3.2。doi : 10.17487 / RFC2616。RFC 2616 。 ↑ 「サイト移動ツール」 。Bing ウェブマスターヘルプ＆ハウツー 。 ↑ 「301リダイレクト」 。Google ウェブマスターツールヘルプ 。 ↑ T. バーナーズ＝リー 、 R. フィールディング 、 H. フリスティック (1996 年 5 月)。ハイパーテキスト 転送 プロトコル -- HTTP/1.0 。ネットワークワーキング グループ。doi : 10.17487/ RFC1945。RFC 1945 。 参考情報。 ↑ Lawrence, Eric. "HTTP メソッドとリダイレクト ステータス コード" . EricLaw の IEInternals ブログ. 2011 年 8 月 20 日 取得 . ↑ 「リクエストとレスポンスのオブジェクト | Django ドキュメント | Django」 。Docs.djangoproject.com。2014 年 6 月 23 日 取得 。 ↑ Fielding, Roy T.; Reschke, Julian (2014年6月)。 「ハイパーテキスト転送プロトコル（HTTP/1.1）：意味論と内容」 。Tools.ietf.org 。 2019年 1月5日 取得 。 1 2 3 Bouquet, Paolo; Stoermer, Heiko; Vignolo, Massimiliano (2011年1月12日). "Web of Data and Web of Entities: Identity and Reference in Interlinked Data in the Semantic Web". Philosophy & Technology . 25 . Springer Nature : 5– 26. doi : 10.1007/s13347-010-0011-6 . ISSN 2210-5441 . ↑ Halpin, Harry; Presutti, Valentina (2011). "Web上のリソースのアイデンティティ：Webアーキテクチャのためのオントロジー". Applied Ontology . 6 (3). IOS Press : 263– 293. doi : 10.3233/AO-2011-0095 . ISSN 1875-8533 . ↑ アラマラジュ、スブブ。スブラマニヤム州アラマラジュ（2010 年 3 月）。 RESTful Web サービス クックブック 。 オライリーメディア 。 ISBN 9780596801687 。↑ 「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 ドキュメント」 。2018 年 7 月 25 日のオリジナルから アーカイブ済み。2018 年 7 月 25 日 取得 。 ↑ 「 Stripe API リファレンス – エラー」 。stripe.com。2019 年 10 月 28 日 取得 。 1 2 「Web 分散オーサリングおよびバージョン管理のための HTTP 拡張機能 (WebDAV)」 . IETF . 2007 年 6 月。2016年 3 月 3 日の オリジナル からアーカイブ済み 。2016 年 1 月 12 日 に取得。 ↑ 「409 Conflict」 。MDN Web Docs 。2025年3月13日。 2025年 6月11日 取得 。 1 2 3 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 ↑ TheDeadLike. "HTTP/1.1 ステータスコード 400 と 417、どちらを選択できるかわかりません" . serverFault . 2015 年 10 月 10 日のオリジナルから アーカイブ済み。2015 年 10 月 16 日 取得 。 ↑ L. Masinter (1998 年 4 月 1 日). Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) . Network Working Group. 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日 取得 。 ↑ 「エラー418（私はティーポットです）！？」 。 2025年 12月17日 取得 。 ↑ 「ウェブサイトで追加のウェブセキュリティを有効にする」 。DreamHost 。 2022年 12月18日 取得 。 ↑ 「ロシアのウェブサイトにアクセスしたら、こんなひどいティーポットしか手に入らなかった」 . PCMag . 2022年2月25日. 2022年 12月18日 閲覧 . 1 2 3 4 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日 取得 。 ↑ Paul, Ian (2015年12月21日). 「エラー451は、オンライン検閲のためのレイ・ブラッドベリにインスパイアされた新しいHTTPコードです」 . PC World . 2025年 7月18日 閲覧 。 ↑ alex. 「サイトがメンテナンスのためにダウンしているときに送信する正しい HTTP ステータス コードは何ですか？」 . Stack Overflow . 2016 年 10 月 11 日のオリジナルから アーカイブ済み. 2015 年 10 月 16 日 取得 . ↑ K. Holtman; AH Mutz (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 . 歴史的。 ↑ 「IIS 7.0 の HTTP ステータス コード」 。 マイクロソフト 。2009 年 7 月 14 日。2009 年 4 月 9 日のオリジナルから アーカイブ。2009 年 4 月 1 日 取得 。 ↑ Outlook Web Access を使用して Exchange 2007 にログオンしようとしたときに表示されるエラー メッセージ: "440 ログイン タイムアウト" マイクロソフト . 2010 . 2013年 11月13日 取得 .↑ "2.2.6 449 ステータスコード付き再試行" . Microsoft . 2009. 2009年10月5日のオリジナルから アーカイブ済み 。 2009年 10月26日 取得。 ↑ 「エラーページのスクリーンショット」 。 2013年5月11日に オリジナル （bmp） からアーカイブされました 。 2009年 10月11日 に取得。 ↑ 「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日 取得 。 ↑ "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" ディレクティブ2018年3月1日に Wayback Machine (http_rewrite モジュール) のドキュメントにアーカイブされました。 ↑ 「トラブルシューティング：エラーページ」 。Cloudflare 。 2016年3月4日の オリジナル からアーカイブ済み 。 2016年 1月9日 取得 。 ↑ 「エラー520：ウェブサーバーが不明なエラーを返しました」 。Cloudflare。2025年5月29日。 ↑ 「エラー521：ウェブサーバーがダウンしています」 。Cloudflare。2025年4月29日。 ↑ 「エラー522：接続タイムアウト」 。Cloudflare。2025年5月5日。 ↑ 「エラー523：オリジンに到達できません」 。Cloudflare。2025年4月29日。 ↑ 「エラー524：タイムアウトが発生しました」 。Cloudflare。2025年8月6日。 ↑ 「エラー525：SSLハンドシェイクに失敗しました」 。Cloudflare。2025年4月29日。 ↑ 「Cloudflare サポート ドキュメント」 。developers.cloudflare.com。2025 年 4 月 29 日。2025 年 9 月 14 日 取得 。 ↑ 「エラー526：無効なSSL証明書」 。Cloudflare。2025年8月11日。 ↑ 「Cloudflare サポート ドキュメント」 。developers.cloudflare.com。2025 年 8 月 11 日。2025 年 9 月 14 日 取得 。 ↑ "527 エラー: Railgun Listener to origin エラー" . Cloudflare . 2016 年 10 月 13 日の オリジナルからアーカイブ済み . 2016 年 10 月 12 日 取得 . ↑ 「エラー530」 。Cloudflare 。 2019年 11月1日 取得 。 ↑ 「Cloudflare サポート ドキュメント」 。developers.cloudflare.com。2025 年 4 月 29 日。2025 年 9 月 14 日 取得 。 1 2 3 4 5 6 「アプリケーションロードバランサーのトラブルシューティング - Elastic Load Balancing」 。docs.aws.amazon.com 。 2023年 5月17日 取得 。 ↑ 「HTTP エラー コードとクイック フィックス」 。Docs.cpanel.net。2015 年 11 月 23 日の オリジナルからアーカイブ済み。2015 年 10 月 15 日 取得 。 ↑ "framework/src/Illuminate/Foundation/Exceptions/Handler.php" . GitHub . 2023年 12月12日 取得 . ↑ "draft-ietf-webdav-protocol-05: ワールドワイドウェブ上の分散オーサリングのための拡張機能 -- 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日 取得 。 1 2 3 4 「Shopify API の応答ステータスとエラーコード」 。2023 年 12 月 12 日 に取得。 1 2 「トークンベース認証の使用」 ArcGIS Server SOAP SDK 。2014 年 9 月 26 日の オリジナルからアーカイブ済み。2014 年 9 月 8 日 取得 。 ↑ 「CloudLinux でサイトを閲覧中に「508 リソース制限に達しました」エラーが表示される」 2021 年 9 月 28 日。2025 年 7 月 19 日の オリジナルからアーカイブ。2025 年 7 月 19 日 取得 。 ↑ "SSL Labs API v3 ドキュメント" . github.com . ↑ 「プラットフォームに関する考慮事項 | Pantheon ドキュメント」 。pantheon.io。2017 年 1 月 6 日の オリジナル からアーカイブ済み。2017 年 1 月 5 日 取得 。 ↑ 2017年、 2024年 、 2025年の例 で確認 ↑ "218 これは問題ありません – HTTP ステータス コードの説明" . HTTP.dev . 2023 年 7 月 25 日 取得 . ↑ 「HTTPステータスコード – ascii-code.com」 。www.ascii -code.com 。 2017年1月7日に オリジナル からアーカイブ済み 。 2016年 12月23日 に取得。
外部リンク インターネット割り当て番号局 のハイパーテキスト転送プロトコル（HTTP）ステータスコードレジストリmozilla.org のMDNステータスコードリファレンス
