HTTPステータスコード:リストされたすべての可能なコード

開示: あなたのサポートはサイトの運営を維持するのに役立ちます!このページで推奨する一部のサービスについては、紹介料を稼ぎます.


Contents

HTTPステータスコードの基本

ほとんどの人は、Webページに移動したときに実際に何が起こるかについて、それほど深く考えていません。彼らはブラウザを開いて何かをクリックするだけで、私の画面に表示されます!

特定のコードをお探しですか?右側の目次をご覧ください!

私たちは、ウェブサイトのシステム管理者やITスタッフからさえ(通常は)見えない、データセンター内のコンピューターのウェブブラウザーとサーバーの間で発生する要求と応答の複雑なダンスについて考えないことを好みます。.

しかし、時々、エラーが発生します。面白い画像のある404 Not Foundページが表示されます。または、いくつかの不明な501エラーについて私たちのブラウザーからメモが記載された空白のページを取得します.

カジュアルなウェブサイトの訪問者として、これは単に迷惑です。通常は再試行します—更新、戻る、もう一度クリックします。時々それは機能します—私たちはそれをグリッチと呼び、すぐにそれを忘れます。うまくいかない場合もあります。これを「悪いWebサイト」と呼び、通常はすぐに忘れてしまいます.

しかし、実際にウェブサイトを運営している場合は、すべてが変わります。 HTTPエラーは煩わしいものではありません。彼らは狂っています。彼らは恥ずかしいです.

特に技術に精通している場合、または優れたITチームがある場合は、それほど大きな問題ではないかもしれません。そのようなほとんどの問題は簡単に修正できます。しかし、あなたが中小企業の経営者であれば、自分のウェブサイトを運営していると、HTTPステータスとエラーコードはあなたを狂わせることができます.

HTTPエラーをどのように修正しますか? HTTPエラーをどのように回避しますか?これらすべてのHTTPステータスコードはどういう意味ですか?

このガイドがカバーする内容は、次の情報です。

  • 適切なHTTPステータスコード(通常は表示されないもの)
  • 便利なHTTPステータスコード
  • 使用する必要があるリダイレクトのタイプ(およびその理由).

しかし、最初に、HTTPステータスコードを理解するには、最初にHTTPがどのように機能するかを理解する必要があります。.

HTTPリクエストとレスポンス

HTTPは「HyperText Transfer Protocol」の略です。

プロトコルとは?

海軍の船に乗るとき、物事を行う特定の方法があります。最初に旗に敬礼し、次に当直の将校に敬礼し、次に搭乗の許可を求めます.

それはプロトコルです.

プロトコルは、特定のタイプの対話のための一連のルールです.

時々プロトコルは非常に厳格で定義されています:

  • 船に乗るには:
    • 敬礼フラグ
    • 勤務中の敬礼役員
    • 搭乗許可を求める.

時々プロトコルは少しゆるくて書かれていませんが、それでもよく知られています:

  • バースデーケーキが届いたとき:
    • みんなが歌うのを待つ
    • 願い事をする
    • ろうそくを吹き飛ばし、できれば一気に.

コンピュータの相互作用はすべてプロトコルに関するものです。 2台のコンピューター(またはコンピューターのネットワーク)が相互に通信する場合、それらは通信のための明確に定義された一連のルールを持っている必要があります。.

ローカルコンピューターのWebブラウザーが、見ようとしているサイトをホストしているWebサーバーと通信するためのルールは、HTTP(ハイパーテキスト転送プロトコル)です。.

ハイパーテキストを転送する理由?

もともと、Webページは主にドキュメントでした。 「ウェブページ」は実際の「ページ」と考えられていました。サイトはドキュメントのコレクションでした。サイトのメインページは、利用可能なドキュメントの「インデックス」でした。.

どのような種類のドキュメントですか?ハイパーテキストドキュメント.

ハイパーテキストは、ドキュメントが「ハイパーリンク」で相互にリンクすることを意味します。今日、私たちはそれらを昔ながらの「リンク」と呼んでいます—それらは今では「ハイパー」と呼ぶことはないほど一般的です.

テキスト内のクリック可能な「ハイパー」リンク—現在一般的であるこのアイデアは、インナーネットが最初に作成されたときに非常に革新的であり、すべてにちなんで名付けられました.

これらのドキュメントを作成するための言語は?ハイパーテキストマークアップ言語(HTML)。そして、これらのドキュメントを要求および受信するためのプロトコルは? HTTP.

HTTPは…

HTTPは、Webブラウザー(または他の「クライアント」)が別のコンピューター(「サーバー」)にリソースを要求する方法と、他のコンピューターがそれらの要求に応答する方法に関する一連のルールと手順です。.

HTTPリクエスト

したがって、アドレスを入力したり、リンクをクリックしたり、その他の方法でWebページを開いたりすると、ブラウザは他のサーバーにリクエストを送信します.

リクエストのターゲットは、URLとDNSシステムによって定義されます。 DNSシステムは別の日の主題ですが、基本的にはDNSはドメイン名を特定のコンピューターのIPアドレスと照合するアドレス帳です.

リクエストのターゲットはドメイン名によって定義され、URL全体がリクエストの最も重要な部分です。ドメイン名の後のすべてが、リクエストされている特定のリソースをサーバーに伝えます。リクエストには、次のような他の情報も含まれています。

  • リクエストのタイプ。最も一般的な2つは次のとおりです。
    • GET —「このリソースを送ってください。」
    • POST —「ここに処理するデータがあります。」
  • ヘッダーフィールド—サーバーにクライアントについて通知するために使用されるオプションのメタデータフィールド(たとえば、ブラウザーのタイプ).
  • 本文—クライアントが送信したデータ(POSTで使用).

サーバーはこのリクエストを受け取り、(何らかの処理の後に)レスポンスを送信します.

HTTP応答

応答の最初の行は HTTPステータス.

ステータス行には、番号コード(200など)とテキスト説明(Successなど)の2つの部分があります。.

すべてが正常に機能すると、200:成功ステータス(人間のユーザーとしては決して表示されない)、次にいくつかのヘッダーデータ(これも表示されない)、および要求されたリソース(表示されるもの)を取得します).

リソースは、Webページ全体、画像、ビデオ、サウンドファイルなどです。また、JavaScriptファイルやスタイルシートなど、表示されない場合もあります。.

うまくいかない場合は、ステータスに関するメッセージが表示されることがあります。通常、これは404または501コードのようなものを取得したときに発生します。これらはエラーコードです。問題が発生しました.

エラーコード404または501のレスポンスでは、リクエストしたリソースが返されません。ときどき、別のリソース(賢い404ページなど)が表示されることがあります。リソースがまったくない場合があります(その場合、ブラウザの空白ページとデフォルトのエラーメッセージが表示されます).

また、301リダイレクトのように、ブラウザに別の場所を探すように指示するステータスコードもあります。これらの応答には、要求されたリソースも含まれません.

代わりに、ヘッダーデータは、他のURLを使用して新しいリクエストを行うようブラウザに指示します。ブラウザーは通知された内容を実行し、2番目の要求を行うだけなので、通常はいつ発生しても気になりません。.

次に、何が起こったかを告げることなく、2番目の応答からのリソースを表示します。リダイレクトレスポンスコードは通常、エンドユーザーには関係ありませんが、ウェブサイト管理者には非常に重要です。.

ステータスコードクラス

すべてのステータスコードが3桁の数字であることにお気づきでしょう。最初の桁は常に1から5の間であることに気づきましたか?

ステータスコードは、コードの5つの「クラス」にグループ化されます。 404:Not Foundエラーは、ステータスコードの400(場合によっては4xx)クラスの一部です。各クラスには特定の範囲の問題または状態が含まれます.

  • 1xx —情報—これらは、サーバーが要求の処理を続行する間に使用されることを目的とした暫定的な応答です。彼らはめったに使用されません.
  • 2xx —成功—物事が想定どおりに機能するときに使用されるコード。具体的には、リクエストが実行しようとしていたことに基づいて、さまざまな成功コードが返されます.
  • 3xx —リダイレクト—要求されたリソースを他の場所で探すようにクライアントに指示するために使用されるコード.
  • 4xx —クライアントエラー—これらのコードは、クライアントに問題があったことを通知します.
  • 5xx —サーバーエラー—サーバー上の何かが期待どおりに動作しない場合のコード.

各クラスの特定のコードについては、それぞれのセクションで詳しく説明します.

HTTPステータス(およびエラー)コードの処理

このガイドでは、一般的なものから未使用のものまで、考えられるすべてのHTTPステータスとHTTPエラーコードについて説明します。各コードの意味、コードが生成される理由、コードが問題になる可能性がある場合、および問題への対処方法について説明します.

HTTPステータスコード1xx —情報

知識は力である。情報は解放されています.

—コフィ・アナン

1xxクラスのHTTPステータスコードは暫定的なものであり、完全な2番目の応答が送信される前にサーバーによって送信されます。.

それらはHTTP / 1.1で導入されたので、HTTP / 1.0を実装する初期のブラウザはそれらを処理できず、サーバーはそのような場合に1xxコードを終了するべきではありません.

HTTP 100続行

通常、要求と応答のシーケンスは単純です。 1つのリクエストが作成、受信、応答されます.

ただし、リクエストを部分に分割する必要がある場合があります。これは、リクエストが大きすぎる場合に発生する可能性があります。リクエスターがヘッダーが適切にフォーマットされているかどうかを確認する必要がある場合、またはサーバーが実際にリクエストを受信する準備ができている場合に発生する可能性があります.

これらの場合、クライアント(ブラウザ)は、Expect:100-continueを含むヘッダーを含む最初のリクエストを送信する場合があります。.

これが発生すると、サーバーは最初の要求を受け取り、すべてが問題なければ、100:続行ステータスで応答します。これは、リクエストを完了するようにクライアントに通知します.

すべてがうまくいかない場合、サーバーは417 Expectation Failedを送り返します.

HTTP 101スイッチングプロトコル

クライアントはサーバーにプロトコルを切り替えるように要求できます(例:HTTP / 1.1からHTTP / 2.0へ).

サーバーがその要求に応じる用意がある場合、サーバーは応答101:Switching Protocolsと、使用されている新しいプロトコルの名前を含むヘッダーデータを返信します。.

HTTP 102処理

このコードは、ファイル操作機能を提供するHTTPの拡張であるWebDAVでのみ使用されます。FTPに多少似ています(実際の実装では非常に異なります)。.

WebDAVリクエストには、多くのサブリクエストが含まれる場合があります。 102:処理ステータスは、サーバーがリクエストを受信して​​処理中であるが、まだ処理する必要があることをクライアントに通知します。これにより、リクエストが失われたとクライアントが判断してタイムアウトするのを防ぎます。.

HTTPステータスコード2xx —成功

この人生で必要なのは無知と自信であり、それから成功は確かです.

-マーク・トウェイン

2xxクラスのHTTPステータスコードは、リクエストが意図したとおりに完了したときに使用することを目的としています.

これらのコードの多くは、実際に使用されることはなく、実際に使用されることも、実装されることもない.

HTTP 200 OK

これは、成功したリクエストに対する標準的な応答です。これは、通常必要とするステータスコードです。.

要求がGET(リソースを要求する)の場合、応答にはリソースが含まれます。リクエストがPOST(またはその他のタイプ)の場合、レスポンスにはアクションの結果を説明または含むリソースが含まれます.

HTTP 201が作成されました

一部のリクエストは、新しいリソースを作成することを目的としています。これらが正常に完了すると、201ステータスが送信され、新しいリソースが作成されたことを示します。これは通常、PUT要求タイプと組み合わせて使用​​されます.

受け入れられるHTTP 202

要求は受け入れられましたが、実行されませんでした。リクエストが処理される場合とされない場合があります.

HTTP 203の信頼できない情報

応答には要求されたリソースが含まれていますが、そのリソースは別のソースから取得されている可能性があるため、信頼できない可能性があります—サーバーはリソースの有効性または信頼性を保証していません.

HTTP 204コンテンツなし

これは、サーバーがリクエストを正常に処理したときに送信されますが、コンテンツを返す必要はありません。ほとんどの場合、これはDELETE要求の結果として発生します.

204リクエストが送信されると、ユーザーエージェント(クライアントまたはWebブラウザー)は、そのビューを変更することは特に想定されていません。.

たとえば、リクエストがページのフォームを介して送信された場合、レスポンスによってフォームが更新されたり、ブラウザが別のページにアクセスしたりすることはありません。ユーザーの既存のコンテンツを置き換えるリクエストに新しいコンテンツはありません見る.

HTTP 205リセットコンテンツ

205応答は204に似ていますが、ユーザーエージェントはビューを更新して現在のドキュメントのデフォルト状態に戻すことになっています。.

HTTP 206部分コンテンツ

これは、ユーザーがリソースの一部のみの受信を要求したため、サーバーがリクエストされたリソースの一部のみを送信している場合に使用されます。.

これは、図に示すように、ユーザーエージェントがリソースを一連の「チャンク」リクエストに分割したいほどリソースが大きいか、接続の信頼性が十分でない場合に発生します。

  • クライアント:最初の1/4をください.
    • サーバー:206部分コンテンツ
  • クライアント:2番目をください

    1/4.

    • サーバー:206部分コンテンツ.
  • 等々…
    • …など.

これらの部分的な要求は、範囲ヘッダーを使用してクライアントによって行われます。これらは、ダウンロードの失敗を防ぐために次々に発生する場合と、ダウンロードを高速化するために複数のスレッドで同時に発生する場合があります。.

HTTP 207マルチステータス

103と同様に、これはWebDAVでのみ使用されます.

WebDAV要求には複数のサブ要求があり、それぞれに独自のステータスと応答があります。 207ステータスは、応答の本文に、各サブリクエストのステータスと応答を詳述するXMLドキュメントが含まれることを示します.

HTTP 208はすでに報告されています

別のWebDAVのみのステータスコード。これは、DAVバインディングのメンバーが現在の要求に対する以前の応答ですでに列挙されており、再度含まれていないことを意味します.

HTTP 226 IMを使用

サーバーはリソースの要求を満たし、応答は現在のインスタンスに適用された1つまたは複数のインスタンス操作の結果の表現です.

HTTPステータスコード3xx —リダイレクト

あなたが何かをあきらめるときはいつでも、あなたはそれを何かと取り替えなければなりません.

—ルーホルツ

3xxクラスのステータスは、リクエストを完了するためにクライアント側で追加のアクションが必要な場合に送信されます。これは、URLを別のURLにリダイレクトする場合に最もよく使用されますが、常にではありません.

GETリクエストの場合、ブラウザは通常、ユーザーからの入力や追加の対話なしで2番目のリクエストを実行します。その他の場合、追加のユーザー介入が必要です.

無限のリダイレクトループを回避するために、ブラウザは通常、同じリクエストの5つを超える連続したリダイレクトをたどらない.

HTTP 300複数の選択肢

リクエストの結果、リソースに複数のオプションが含まれる場合、ブラウザは300ステータスを返します。理論的には、これは、異なるファイル形式のオプション、同じコンテンツの異なるメディアプレゼンテーション、または単語の意味の明確化に使用できます。.

300マルチプルチョイスステータスには多くの可能性がありますが、あまり使用されません.

HTTP 301が永続的に移動しました

このステータスは、リソースがURLを永続的に変更したことを示します.

検索エンジンはこれに基づいてインデックスを更新します。通常、元のURLから新しいURLにランキングを割り当てます.

ブラウザや他のタイプのクライアントは、新しいURLをキャッシュし、元のURLが手動で提供された場合でも、後続の要求について元のURLを直接チェックすることなく自動的にリダイレクトURLに従います。保存されたブックマークも通常は更新されます.

一般に、URL構造のドメイン名が変更されたためにリダイレクトを設定する場合は、301を使用する必要があります。.

これらは、サーバーの.htaccessファイルまたはhttpd.confファイル、または多くの場合コンテンツ管理システムで設定できます。 (たとえば、301リダイレクトを管理するためのWordPressプラグインがいくつかあります。)

Webサイトが再設計され、URL構造が変更された場合、元のサイトからのすべてのURLに対して301リダイレクトを設定することが非常に重要です。そうしないと、リンク切れや失望した訪問者が発生します.

HTTP 302が見つかりました

302ステータスコードは、一時的なリダイレクトに一般的に使用されます。 301リダイレクトを使用する業界の慣習は元の仕様とは異なり、仕様は業界の慣習に合わせて進化しました.

元々、仕様では、302ステータスがブラウザに2番目の同一のリクエストを新しいURLに対して行うようにする必要があると述べていました。ただし、多くの第1世代のWebブラウザーは、POST要求がGET要求として書き換えられるように実装しました。.

状況を明確にするために、更新された仕様HTTP / 1.1では、303と307の2つのステータスコードが追加されました。.

302 Foundは、実装された「GETへの切り替え」動作を模倣するはずでしたが、307 Temporary Redirectは、元の302予期された動作を置き換えることを目的としていました.

ただし、ほとんどのサーバーとWebフレームワークは、新しい標準を実装していないブラウザーとの下位互換性のために、302を使用し続けました.

標準の慣習に準拠した後のHTTP仕様により、ブラウザーはPOST要求をGET要求に書き換えることができます。.

これらすべての結果、POSTデータを受け入れるはずのURLで302リダイレクトを使用している場合、そのデータは2番目のリクエストに含まれない可能性があります。.

このため、サーバーが送信されたデータを元のURLで実際に受け入れ、データが受け入れられた後にリダイレクトを使用してページを配信できる場合、302はPOSTデータ(Webフォーム)を受け入れるURLでのみ使用する必要があります。.

これらすべては、実際には303を冗長にします.

通常、302リダイレクトは使用しないでください

HTTP 303 See Other

実際には、これは302ステータスと同じです。つまり、GETメソッドを使用して、応答またはリソースを別のURLで見つけることができます。 POSTリクエストへの応答として受信した場合、ブラウザはデータが受信されたと想定する必要があります.

変更されていないHTTP 304

Webブラウザーは、特定の日時以降にリソースが変更されたかどうかを確認するヘッダーを含むリクエストを送信できます。これは、ブラウザーが以前にリソースを既にダウンロードして保存している場合に行われます.

それ以降に変更されている場合、サーバーはリソースと200成功ステータスで応答します.

ただし、リソースが変更されていない場合、サーバーはステータス304 Not Modifiedを送信し、リソースも送信しません。保存されたバージョンのリソースは変更されていないため、ブラウザはそれを提供する必要があります.

HTTP 305プロキシを使用

リクエストされたリソースはプロキシ経由でのみ利用できます。プロキシのアドレスは応答で提供されます。 Webブラウザーは、プロキシーを介して要求を再試行することが期待されています。セキュリティ上の理由により、すべてのクライアントが標準に従ってこれを実装するわけではありません.

HTTP 306スイッチプロキシ

306ステータスはもともと「後続のリクエストは指定されたプロキシを使用する必要がある」という意味でした。もう使われていません.

HTTP 307一時リダイレクト

このステータスは、302ステータスの元の意図を複製するために作成されました(上記を参照).

307:Temporary Redirectステータスは、今回は別のURLでリクエストを繰り返す必要があることを意味しますが、将来的にはリクエストで元のURLを使用する必要があります.

302がこれまでクライアントによって実装されてきた方法とは対照的に、2番目の要求を送信するときに要求メソッドを変更しないでください。たとえば、POSTリクエストは別のPOSTリクエストを使用して繰り返され、元のすべてのPOSTデータが含まれている必要があります.

HTTP 308永久リダイレクト

現在のリクエストは別のURLを使用して繰り返される必要があり、今後のすべてのリクエストもそのURLに送信される必要があります.

307や302と同様に、このステータスは301の元の仕様で指定された機能を複製します。ただし、308の場合(307と同様)、2番目のリクエストは元のリクエストと同じで、同じメソッドを使用し、同じデータを含みます.

HTTP 308の再開が不完全です

このステータスコードは作成され、Googleによって使用されます。これは再開可能なHTTPリクエストの提案の一部であり、中止されたPUTまたはPOSTリクエストを再開するために使用されます.

HTTPステータスコード4xx —クライアントエラー

誰でも間違いをすることができますが、馬鹿だけがエラーで持続します.

—マーカス・トゥリウス・シセロ

HTTPステータスコードの5つのクラスのうち、実際に「エラーコード」であるのは2つだけで、4xxおよび5xxクラスです。.

4xxシリーズのHTTPエラーは、エラーがクライアントから発生しているように見える場合に使用することを目的としています。つまり、リクエストに問題があります.

エラーステータスやその他のヘッダー情報とともに、サーバーはユーザーに表示されるはずの完全な応答(「リソース」ではなく「エンティティ」と呼ばれますが、それ以外は同じ)を提供することがよくあります。.

これは、クライアントエラーが何であっても修正する方法をユーザーに提供することを目的としています。これらのエンティティの最も一般的に見られる形式は、以下で説明する404ページです。.

HTTP 400不正リクエスト

これは、問題のあるリクエストに対する一般的な応答です。問題は、不正な構文、無効なフォーマット、または不正なリクエストルーティングである可能性があります。サーバーは多くの場合、リクエストで特に問題となったものに関する追加情報を提供します.

HTTP 401無許可

これは、リソースが特定の認証済みユーザーに制限されている場合に使用されます。ステータスは、認証が行われなかったか、認証が失敗したことを意味します。標準によると、このコードを含む応答には、認証の手段が含まれているはずです。.

HTTP 402支払いが必要

仕様では現在の実装に十分な情報が提供されていないため、一般的には使用されていません(名前が付けられ、将来の使用のために予約されていますが、完全な仕様は採用されていません)。.

意図は、このコードをある種のデジタル現金またはマイクロペイメントシステムの一部として使用することです.

YouTubeは、単一のIPアドレスから受信したリクエストが多すぎる場合にこのステータスを使用します。応答には、ユーザーが人間であることを確認するためのキャプチャが必要です.

HTTP 403 Forbidden

401と同様に、これはリクエストは有効でしたが、ユーザーにはリソースを表示する権限がないため、サーバーはリクエストに応答しません。 401:Unauthorized errorとは異なり、認証しても違いはありません.

HTTP 404が見つかりません

これは、最も一般的に見られる4xxクラスエラーであり、おそらく平均的なユーザーの最も一般的に気づくHTTPステータスです.

リクエストは有効ですが、リクエストされたリソースがサーバー上で見つからない場合、404が返されます.

ほとんどのウェブフレームワークでは、ウェブサイト管理者が「404ページ」を作成できるようになっています。これは、404エラーが発生したときにユーザーに表示されるページです.

通常、これはユーザーに問題を通知し、不便をお詫びし、検索など、ユーザーが探しているコンテンツを見つけるための代替方法を提供します.

一部のWebサイトは、リクエストURLのキーワードを調べて、ユーザーが探していた可能性のあるページまたはリソースを判別し、代替ページに1つ以上のオプションを提供します.

4xxエラーは技術的には「クライアントエラー」ですが、404エラーは多くの場合、デッドリンク(以前はコンテンツがあったが現在は変更されているURL)の結果です。.

このため、404ページを配信しなければならないことは、適切なURLリダイレクトを提供できないことを意味することが多いため、Webサイトにとって少し厄介なものになる可能性があります。 「あなたが要求を台無しにした」という意味ではなく、「あなたが探しているものを失った」という意味です。

このため、ウェブサイトが404ページをユーモアの場に変えることは非常に一般的です.

HTTP 405メソッドは許可されていません

これは、要求が整形式であり、要求するリソースは存在するが、要求メソッド(GETまたはPOSTなど)がリソースに適切でない場合に使用されます.

たとえば、フォームデータを受け取ったURLには、POSTリクエストでアクセスする必要があります。 GETリクエストにより、405:Method Not Allowedレスポンスが返される場合があります。読み取り専用リソースでPUTを使用すると、このような応答が発生する場合もあります.

HTTP 406は受け入れられません

リクエストは、MIMEタイプを使用して、探しているコンテンツのタイプを指定できます。.

要求されたリソースのタイプが、要求のAcceptヘッダーにリストされているタイプと一致しない場合、サーバーは406:Not Acceptableエラーを返します.

HTTP 407プロキシ認証が必要

要求されたリソースへのアクセス権を付与される前に、クライアントは最初に、応答で指定されたプロキシで自身を認証する必要があります.

HTTP 408リクエストのタイムアウト

このエラーは、リクエストの待機中にサーバーがタイムアウトしたときに発生します.

仕様から:

サーバーが待機する準備ができている時間内に、クライアントが要求を生成しませんでした。クライアントは、いつでも変更なしで要求を繰り返すことができます(MAY).

HTTP 409の競合

それ自体と競合するため、要求を処理できなかったことを示します。これは、たとえば、相互に編集の競合を引き起こす複数の更新の場合に発生する可能性があります.

HTTP 410 Gone

このエラーは404エラーに似ていますが、リクエストされたリソースが意図的に削除され、どのURLでも利用できなくなることを示すことを目的としています.

クライアントは、リソースをパージすることによってこの応答に対応する必要があります—ブックマークを削除し、検索エンジンがインデックスからリソースを削除する必要があります.

ほとんどのユースケースではこれは必要なく、404は通常より適切なエラーです.

HTTP 411の長さが必要です

リクエストされたリソースでは、リクエストで長さを指定する必要がありますが、リクエストでは指定されていません.

HTTP 412前提条件が失敗しました

要求者が前提条件または要件を要求のヘッダーに入れましたが、サーバーはそれらの要件の1つ以上を満たすことができません.

HTTP 413リクエストエンティティが大きすぎます

リクエストがサーバーが処理できるよりも大きい.

HTTP 414リクエスト-URIが長すぎます

指定されたURI(URL)は長すぎてサーバーで処理できません.

これは、不適切な量のデータがGETリクエストのクエリ文字列としてURL内で伝達されている場合によく発生します。通常の解決策は、リクエストをPOSTに変換し、データをリクエストの本文に配置することです.

HTTP 415サポートされていないメディアタイプ

これは通常、リクエストエンティティ(アップロードされるファイル)がサーバーでサポートされていないタイプである場合に、ファイルのアップロードに使用されます。.

HTTP 416要求された範囲は満足できません

これは、リクエストが範囲ヘッダーを使用してファイルの一部を要求しているが、リクエストされた部分が存在しない場合に返されます。たとえば、リクエストがファイルの終わりを超えているファイルの一部を要求する場合.

HTTP 417の予想に失敗しました

このステータスは、リクエストのexpectヘッダーで設定された期待に応えられない場合にサーバーから返されます.

expectヘッダーは、100続行ステータスをサーバーに要求するために最も一般的に使用されます.

HTTP 418私はティーポットです

このエラーコードは、コーヒーのリクエストが送信された場合に、インターネットに接続されたティーポットから返されます。.

HTTP 419認証タイムアウト

これは実際にはHHTP標準の一部ではありませんが、一部のクライアントとサーバーはこれを使用しています。認証されたユーザーを必要とするリクエストが、認証の有効期限が切れたリクエスタによって送信されたときに返されます.

HTTP 420メソッドの失敗(Spring Framework)

HTTP標準の一部ではありませんが、メソッドが失敗したときに使用するために、SpringのWebフレームワークで定義されています。廃止予定です.

HTTP 420で心を落ち着かせる(Twitter)

HTTP標準の一部ではありませんが、Twitterによって導入されました。これは、特定のクライアントからのリクエストがレート制限されているときにAPIのバージョン1で使用されていました.

このような状況のより標準的なステータスは429です。リクエストが多すぎます.

HTTP 421誤ったリクエスト

このステータスはHTTP / 2で導入されました。現在応答を生成できないサーバーに要求が向けられたときに使用されます.

HTTP 422処理できないエンティティ

これは、WedDAV拡張機能に関連しています。セマンティックエラーによりリクエストが処理不能になったときに返されます.

HTTP 423ロック

WedDAVで使用されます。リクエストされたリソースがロックされていることを意味します.

HTTP 424の依存関係の失敗

WebDavで使用されます。現在の要求が依存している前の要求が失敗したため、要求は失敗しました.

HTTP 426のアップグレードが必要

クライアントは、アップグレードヘッダーで指定されている別のプロトコルに切り替える必要があります。.

HTTP 428前提条件が必要です

これは、リクエストが条件付きであることをサーバーが要求する場合に使用されます.

たとえば、サーバーでは、特定の日時以降にリソースが更新されていない場合にのみリクエストを処理するという条件をリクエストに含めることが必要になる場合があります。条件が指定されていない場合、リクエストは失敗し、このステータスが返されます.

仕様によれば、このステータスは、「サードパーティがサーバーの状態を変更しているときに、クライアントがリソースの状態を取得し、それを変更し、サーバーにPUTして戻す「「失われた更新」」の問題を防ぐことを目的としています。 、紛争につながる。」

HTTP 429要求が多すぎます

クライアント(通常はIPアドレスで定義)が指定した期間内に送信した要求が多すぎます.

HTTP 431リクエストヘッダーフィールドが大きすぎます

これは、単一のヘッダーフィールド、またはそれらすべてをまとめて、サーバーが処理するには大きすぎる場合に返されます.

HTTP 440ログインタイムアウト(Microsoft)

標準の一部ではありませんが、Microsoftによって使用されています。セッションの有効期限が切れたことを示します.

HTTP 444応答なし(Nginx)

標準の一部ではありません。実際に使用されている応答ステータスではない.

これは、通常はマルウェアの攻撃の疑いがある場合に、サーバーが単に応答を送信せずに接続を閉じた時期を示すために、サーバーログ用にNginxによって導入されました。.

HTTP 449 Retry With(Microsoft)

標準には含まれていませんが、Microsoftによって使用されています.

応答に記述されているアクションを実行した後、要求を再試行する必要があります.

Windowsペアレンタルコントロール(Microsoft)によってブロックされたHTTP 450

標準には含まれていませんが、Microsoftによって使用されています.

このエラーは、Windowsの保護者による制限がオンになっていて、特定のWebページへのアクセスをブロックしている場合に発生します。エラーの原因はサーバーではなくWPCアプリケーションです。.

法的理由によりHTTP 451を使用できない(ドラフト)

このステータスはまだ標準には含まれていませんが、ドラフト形式で利用できます.

使用目的は、検閲またはその他の法的な理由によりリソースを提供できない場合です。コード番号は、Farenheit 451という本への参照です。.

HTTP 451リダイレクト(Microsoft)

標準の一部ではありませんが、Microsoftによって使用されています。より効率的なサーバーを使用するか、サーバーがユーザーのメールボックスにアクセスできない場合、Exchange ActiveSyncで発生します.

HTTP 494リクエストヘッダーが大きすぎます(Nginx)

標準の一部ではありませんが、Nginxによって使用されました。廃止予定.

これは431と同じ意味でしたが、そのステータスがHTTP標準の一部になる前に導入されました.

HTTP 495証明書エラー(Nginx)

標準の一部ではありません。実際には使用されている応答ステータスではありませんが、SSLクライアント証明書エラーが発生するとNginxログに表示されます.

HTTP 496証明書なし(Nginx)

標準の一部ではありません。実際には使用された応答ステータスではありませんが、クライアントが証明書を提供しなかった場合、Nginxログに表示されます.

HTTP 497 HTTPからHTTPS(Nginx)

標準の一部ではありません。実際には使用されている応答ステータスではありませんが、プレーンなHTTPリクエストがHTTPSポートに送信されるとNginxログに表示されます.

HTTP 498トークンの期限切れ/無効(Esri)

ArcGIS for Serverによって返されます。コード498は、期限切れまたは無効なトークンを示します.

HTTP 499クライアントクローズリクエスト(Nginx)

標準の一部ではありません。実際には使用される応答ステータスではありませんが、サーバーがリクエストを処理している間にクライアントによって接続が閉じられ、サーバーがステータスコードを返送できない場合、Nginxログに表示されます.

HTTP 499トークンが必要(Esri)

ArcGIS for Serverによって返されます。コード499は、トークンが必要であることを示します(トークンが送信されなかった場合)。.

HTTPステータスコード5xx —サーバーエラー

私の心がどれほど弱く、間違いが起こりやすいかを考えると、私は本当に驚いています.

—ルネ・デカルト

4xxシリーズと同様に、HTTPステータスコードの5xxクラスはエラーコードであり、問​​題が発生したときに発行されます。 5xxエラーコードはサーバーエラーコードです。つまり、問題がクライアントではなくサーバー上にあるときに返されます。.

可能な場合はいつでも、サーバーはエラーをクライアントに説明する応答エンティティを返す必要があります。ユーザーエージェント(Webブラウザー)は、この情報をユーザーに表示する必要があります.

HTTP 500内部サーバーエラー

これは最も一般的なサーバーエラーであり、不確定な問題が発生したときにWebサーバーによって発行されます.

一般に、Webサイトまたはサーバーの構成を変更した後は、徹底的なテストを行って、500:内部サーバーエラーが発生しないことを確認する必要があります。.

500エラーが生成された場合、サーバーログを確認すると、エラーの原因の特定に役立つ場合があります。多くの場合、.htaccessファイルのタイプミスと同じくらい簡単です。.

実装されていないHTTP 501

これは、HTTPリクエストメソッド(PUTやDELETEなど)、場合によってはAPIメソッドがまだ実装されていない場合に返されます。これは、WebサービスAPIに使用されます。通常、501エラーの意味は、リクエストメソッドが将来の実装のために計画されていることです。.

HTTP 502 Bad Gateway

これは、サーバーがプロキシまたはゲートウェイとして機能していて、上位サーバーから無効な応答を受け取ったときに発生します.

HTTP 503サービスを利用できません

サーバーは現在利用できません。たとえば、メンテナンスのために過負荷またはダウンしているため.

503エラーの意味は、停止が一時的なものであることです。.

HTTP 504ゲートウェイタイムアウト

このエラーは、サーバーがプロキシまたはゲートウェイとして機能していて、割り当てられた時間内に上流サーバーからの応答を受信しない場合に返されます.

サポートされていないHTTP 505 HTTPバージョン

このエラーは、サーバーがリクエストで使用されているHTTPプロトコルのバージョンをサポートしていないことを意味します.

HTTP 506バリアントも交渉

506エラーを理解するには、透過的なコンテンツネゴシエーションを理解する必要があります.

コンテンツネゴシエーションでは、1つのURLで同じリソースまたは情報を複数の形式で配信できます。たとえば、同じ画像がJPEGおよびGIFとしてエンコードされる場合があります。.

このコンテンツネゴシエーションがループを引き起こすと、506エラーが発生します。例:リクエストされたリソースAには、BとCの2つのバリエーションがあります。どちらもバリアントとしてAを持っています.

これをより技術的な言葉で表現すると、仕様では506エラーが次のように記述されます。

リクエストの透過的なコンテンツネゴシエーションは循環参照になります.

HTTP 507 Insufficient Storage(WebDAV; RFC 4918)

このステータスは、WebDAVプロトコルで使用されます。サーバーがリクエストを完了するために必要な表現を保存できない場合に返されます.

HTTP 508ループが検出されました

リクエストされたリソースを提供しようとしたときに、サーバーで無限ループが発生しました.

HTTP 509帯域幅制限を超えました(Apache)

HTTP標準の一部ではありませんが、Apacheによって導入および使用されています。サーバーの帯域幅制限を超えたときに発行されます.

HTTP 510が拡張されていません

このエラーは、サーバーが要求を実行するために、要求に対する追加の拡張が必要であることを意味します.

HTTP 511ネットワーク認証が必要

クライアントがネットワークアクセスを取得するために認証する必要がある場合、511エラーが返されます.

このステータスは、ネットワークへのアクセスを制御するために使用されるプロキシ(つまり、WiFiポータル経由でインターネットへのアクセスを許可する前にログインまたは利用規約の同意を要求するために使用される「キャプティブポータル」をインターセプトするときに使用することを目的としています.

(空港やホテルでインターネットに接続しようとしたことがある場合は、511エラーが発生している可能性があります。)

HTTP 520不明なエラー

このエラーコードはHTTP標準の一部ではありませんが、CloudFlareなどのサービスとしてのサーバーインフラストラクチャのいくつかの大規模プロバイダーによって使用されています。リクエストが満たされない原因となる不明な問題の一般的な「キャッチオール」エラーとして使用されます.

HTTP 598ネットワーク読み取りタイムアウトエラー(Microsoft)

このエラーコードはHTTP標準の一部ではありませんが、Microsoft HTTPプロキシによって使用され、プロキシの背後のネットワーク読み取りタイムアウトをプロキシの前のクライアントに通知します.

HTTP 599ネットワーク接続タイムアウトエラー(Microsoft)

このエラーコードはHTTP標準の一部ではありませんが、Microsoft HTTPプロキシによって使用され、プロキシの背後のネットワーク接続タイムアウトをプロキシの前のクライアントに通知します.

資源

  • IANA:Internet Assigned Numbers Authorityのウェブサイト.
  • HTTPステータスコードレジストリ:各コードのRFCへのリンクを含む公式のIANAページ.

参考文献

Web開発に関連するガイド、チュートリアル、およびインフォグラフィックが他にもあります。

  • 私は腰を下ろします?トップホスティングプロバイダー50社のステータスページ:最高のサーバーでさえ時々ダウンします。この記事は、上位のホスティング会社50社のステータスページのリストを提供します.
  • インターネットソケットを使用したネットワークプログラミング:ハードコアネットワーキングを学びたい場合、これはあなたを始めるための記事です.
  • ウェブマスターツールA〜Zの究極のリスト:コーディングからホスティング、マーケティングまで、この記事にはすべてが含まれています.

ウェブホスティングの究極のガイド

究極のウェブホスティングガイドをご覧ください。情報に基づいた選択を行うために知っておく必要があるすべてのことを説明します.

ウェブホスティングの究極のガイド
ウェブホスティングの究極のガイド

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map