HTTP ステータス コード リスト |HTTP エラー コードの説明

監視対象デバイスでタスクを実行するたびに、ターゲット サーバーは HTTP ステータス コードを返して、サーバーからの応答の状態を示します。

これらの HTTP ステータス コード、または ネットワーク エラー コードは、監視セッションの結果とアラート通知にも表示されます。 これらのステータスコードは インターネット割り当て番号局 (IANA)によって維持されており、最新のコードリスト はこちらからご覧いただけます。

フィルタを使用すると、タスク、アラート、およびレポートから特定のステータス コードを含む結果を削除できます。 ステータスコードの詳細については、以下のリストにある RFC 参照文書をクリックしてください。

HTTP プロトコルは、

ユーザーが Web サイトを訪問するたびに、ブラウザ/クライアントから要求されたリソースで応答するサーバーに要求を行います。 . これらの要求はすべて HTTP (ハイパーテキスト転送プロトコル) 標準に従います。 The HTTP インターネット プロトコルスイート内のアプリケーション 層の技術的な一部であるプロトコルは、1 つだけです。 IP スイートの下の多くのプロトコル。 HTTP プロトコルは、クライアントとサーバー間の通信およびデータ送信に使用されるインターネットのバックボーンです。 その他の一般的なインターネット プロトコルのいくつか 多くの人が出くわしたのは次のとおりです。

アプリケーション層

プロトコル

ザ アプリケーションラt人 によって使用されるプロトコルとインターフェイス メソッドを指定します クライアントとサーバー. それ です 層wここで 人とコンピュータの間の相互作用が起こる ひとつのd 情報 サーバーからやり取り可能 クライアント/ブラウザを介して ユーザー向けに解釈および表示されます。

• DNS: DNS ( ドメイン ネームシステム)プロトコルは、リソースを読み込むことができるように、ブラウザのユーザーが読める IP アドレスにドメイン名を変換します。
• FTP: FTP (ファイル転送プロトコル)プロトコルは、ブラウザとサーバーの間でファイルを転送するために使用されます。
• SMTP: SMTP (簡易メール転送プロトコル)プロトコルは、ネットワーク上の送信者と受信者の間でnd receive 電子メールを送信するために使用されます。
• TLS/SSL: SSL (セキュアソケットレイヤー)プロトコルは、201 5 年に正式に廃止されました。TLS (トランスポート層セキュリティ) は、ネットワークを介して通信するための安全な方法を提供するために、その代わりに導入されました。
• IMAP: IMAP (インターネット メッセージ アクセス プロトコル) プロトコルは、 管理し、電子メール サーバーからメッセージを受信します。 SMTP とは異なり、IMAP プロトコルを使用して電子メール メッセージを送信することはできません。
• POP: POP (ポスト オフィス プロトコル) プロトコルは IMAP に似ていますが、POP プロトコルが電子メール サーバーからメッセージを受信できる点が異なっています。 メッセージは電子メール サーバーから削除されます。 IMAP プロトコルは、複数のデバイス間でメッセージを同期できます。 実際には、ユーザーが自分のメールにアクセスする方法によって異なります。
• SIP: The SIP(セッション開始プロトコル)プロトコルはリアルタイム音声で使用されるシグナリングプロトコルです。 ビデオ、およびメッセージング アプリケーションを使用できます。 SIP はプロトコルです。 VoIP (Voice over インターネットプロトコル) を有効にして使用します。 サービス。 一口 セッションデータやメディアを伝送するために、SD P(セッション記述プロトコル)、UDP、TCP、および TLS などの他のプロトコルと組み合わせて使用することもできます。

トランスポート層

プロトコル

トランスポート層は、TCP および UDP を含むデータの伝送を処理します。 プロトコル、およびデータの送受信を正しく 、かつ迅速に行います。

• TCP: TCP (トランスポート制御プロトコル) プロトコルは、クライアントとサーバー間の通信を安全に行うために使用されます。 そして、 通信全体が処理されました. 例えば いつ サーバーがクライアント要求のためにファイルを送り返すと、HTTP 層はトランスポート層と通信して、 ファイルが要求されました. TCP プロトコル 組み立てと送信のプロセスを管理します (必要に応じて再送信する場合もあります) データパケットを確実に すべてのパケットが送信され、配信されています。
• UDP: UDP (ユーザ データグラム プロトコル) プロトコルを使用すると、アプリケーションはデータグラムと呼ばれるメッセージをネットワーク上の他のホストに送信できます。

インターネット層

プロトコル

ネットワーク層とも呼ばれるインターネット層は、ネットワークアドレス/IPアドレスを使用してパケットを宛先に送信する最も効率的な方法で、ネットワークpアケットを送信および再構成する任務を負っています。

• IP: IP (インターネット プロトコル) protocolはTCP プロトコルと共に、インターネット上でのデータの送信方法を定義する一連の要件です。
• ICMP: ICMP (インターネット制御メッセージ プロトコル) プロトコルは、ネットワーク デバイス (ルーターなど) が通信の問題を診断できるようにするネットワーク プロトコルです。. ICMP プロトコルは交換に関係ありません データは、むしろその目的は確かだ データが目的の宛先に到達しているかどうか。

リンク層

プロトコル

リンク層は、物理デバイスとネットワーク間のデータの伝送を管理する通信方法のグループである。

• ARP: IP ネットワーク アドレスを物理ハードウェア デバイスのアドレスにマッピングするための ARP (アドレス解決プロトコル) プロトコル/プロシージャです。
• MAC: MAC (中レベルアクセス制御) プロトコル ハードウェア デバイスに固有の識別番号を指定します。 これは、ネットワークが接続するための方法を提供しますct とデバイスと通信します。
• Wi-Fi: Wi-Fi (ワイヤレスフィデリティ) プロトコルは、私たち全員が日常生活のために頼るプロトコルの1 つであり、インターネット アクセスとLAN (ローカル エリア ネットワーク) への接続に使用されるワイヤレス ネットワーク プロトコルのグループです。

ステータスコードとは何か、なぜ重要なのか?

拡張機能もあります の HTTP プロトコル ( include s) HTTPS (ハイパーテキスト転送プロトコルセキュア)および WebDAV (Web ベースの分散オーサリングとバージョン管理) をHTTP ステータスコード内で詳しく説明します。 以下に。 クライアントがサーバーに要求を送信すると、要求が成功したか失敗したか、または何か違いがあったかをステータス コードで知らせます。 ステータスコードは、 インターネット割り当て番号機関、または IANA を含み、インターネット技術標準化委員会 (IETF) およびインターネット協会 (ISOC) のステータス コードが含まれています。 IANA によって定義されたとおり 組織、tHTTP ステータス タラの 5 つの分類を次に示します。es:

1xx: 情報提供 – 要求を受信し、プロセスを継続
2xx: 成功 – アクションは正常に受信され、理解され、受け入れられました
3xx: リダイレクト – 要求を完了するためにさらにアクションを実行する必要があります。
4xx: クライアント エラー – 要求に不適切な構文が含まれているか、または応答できません
5xx: サーバー エラー – サーバーは、明らかに有効な要求を実行できませんでした

個人および エンジニアは 定期的に 提案 Co の要求を介して新しい状態コードメンツ (RFC), そしてIETFは、レビューします 採用し、 引退 地位 コード 必要に応じて。

 

HTTP ステータス コードの説明

以下の情報は、最も一般的なすべての HTTP ステータス コードの概要と、ほとんどのユーザーがめったに見ないか、存在することさえ知らない HTTP 状態コードの概要を提供します。 前述したように、多くの応答コードは決して見られない ユーザーが表示できるのはネットワーク内でのみ表示されます。

ステータスコードの最初の桁はクラスを識別しますが、2番目の2桁の数字は、ステータスコードをさらに特定のタイプのメッセージ/応答に定義する際には何の役割も果たしません。 これらの分類グループ内には、複数の状態コードが存在する可能性があり、一部のグループは他のグループよりも多くの状態コードを持っています。 そして、正式には60以上のユニークなステータスコードがありますが、ほとんどの人は定期的にしか表示しません 時間の経過とともに一握りまたは2つの遭遇。

これらのステータスコードのほとんどは、バックグラウンドで解釈され、処理されます。 また、「未割り当て」と表示されるコードのグループが存在することがわかります。 現在見ているステータスコードのほとんどは標準化され、 時間の経過に応じて変更されない場合、これらの割り当てられていない番号は、必要に応じて追加のステータスコードを作成する余地を残します。また、割り当てられていないユーザー コードの一部は、以前はHTTP (ハイパーテキスト転送プロトコル)標準の一部ではなかったにもかかわらず、次のように使用する企業があります。 ユーザーに対するカスタマイズされたサーバー応答により、企業はユーザーが経験している可能性のある問題をより適切にトラブルシューティングできます。特定の HTTP ステータス コードの詳細については、以下のリストにある RFC 参照ドキュメントのリンクをクリックしてください。

 

完全なリストと HTTP ステータスコードの概要

1xxステータスコードs: 情報提供

1xx-レベル HTTP ステータスコードは、ユーザに要求を 彼らが 有る 作られた 受け取りましたが、 まだ処理中です。 1xx ステータスコードは じゃない 必ずしも問題があることを意味し、 私何かがまだ完了の過程にあるように、sはちょうどそこにあります. 含ま このグループでは、ほんの一握りの1ですxx ユーザーが遭遇する可能性のあるコード を意識する必要があります。

100: 続行 Sタタスコード100 Continueは、要求の一部が問題なく受信されたことを示します。 で この点は、すべてが OKですが、 まだです プロセス中です。 場合は、 の残りの部分 要求は拒否されず、サーブr 要求が完了すると、最終応答が送信されます拘束形態素。 HTTP ヘッダーが拒否された場合、クライアントは じゃない 本文の要求を送信する. ただし、要求 did

ヘッダーフィールドを使用しない場合、ブラウザは単にレスプを無視します。 詳細については、を参照してください。

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

インターネットの謙虚な始まり以来、多くのHTTPプロトコルが作成されています. HTTP プロトコルの最初のドキュメント化されたバージョンは HTTP 0.9 でした。 現在のイテレーションは HTTP 2.0 です または HTTP/2. ステータスコード 101 スイッチング プロトコルは、次の サーバーが受け入れる クライアントからの要求から、別の HTTP プロトコルに切り替える をクリックして、アップグレード ヘッダー フィールドを使用します。 ブラウザがページを要求すると、ブラウザはページを受信する ザ HTTP ステータス コード 101、次にアップグレード ヘッダー、which 示す この場合、別の HTTP バージョンに切り替えています。 最後に、サーバーは、新しいプロトコルと古いプロトコルへのアップグレード/切り替えなど、有益な場合にのみプロトコルを切り替えることに同意すると仮定しています。詳細については、RFC7231、セクション6.2.2

を参照してください。

102: 処理 ステータス cオード 102 処理は WebDAV (Web 分散オーサリングとバージョン管理) でのみ使用されます。ほとんどのページは読み取り専用です。 WebDAV は HTTP の拡張機能です。 クライアントにリモートでコンテンツを編集したり、ファイルを転送したりする機能を与えるプロトコル. ザ ウェブダヴ プロトコルは、ユーザーがする能力を与えるために作成されました コラボレーション他のユーザーとファイルを e する, という感じで ドロップボックスまたはグーグルドライブ. 状態コード 102 はn 中間応答コードで、サーバーが完全な要求を受け入れたことをクライアントに伝えますが、 要求を完了していません。 この HTTP ステータス コードは送信されるだけです。 サーバーによって もし a 要求に 20 秒以上かかります。 見る RFC2518, セクション 10.2

の詳細については、

 

103: 初期のヒント

ステータスコード 103 初期のヒントは現在評価中/ 実験段階。 このステータスコード 外部コンテンツ/リソースをプリロードする際に使用されます. HTTP/2プロトコルは、配信を高速化するためにコンテンツをプッシュすることができます そのため、Web 開発者は、他の外部リソースの読み込みを待っている間に特定のコンテンツをプッシュできます. これは、エンドユーザーの観点から有益です。 を使用すると、知覚される読み込み時間を最小化できます。 T彼の HTTP 応答コードは 示す サーバーがブラウザに 最終的な応答を送信し、応答

に含まれるヘッダー フィールドを送信します。

See RFC8297、セクション2

の詳細については

104-199: 未割り当て

ステータス コード 104 から 199 は現在 割り当てられていません。

2xx ステータスコード: 成功

2xx レベルの HTTP ステータス コード サーバーからのクライアントの要求が成功を示す場合は、 が受け取られ、処理されたことを示します。4xx ステータスコードとは異なり、2xx ステータスコードは、あなたが取得したいものです。 1xx ステータスコードと同様に、2xx ステータスコードは、開発者や SEO ツールを使用してページのすべての HTTP 応答を表示しない限り、バックグラウンドで処理され、ユーザーにはほとんど見られない。

200: OK

ほとんど広く使用されている HTTP ステータス コードの 1 つであるステータス コード 200 OKは、要求が受信され、処理され、成功したことを示すために使用されます。ただし、使用する要求方法 (GET、ヘッド、ポスト、プット、削除、オプション、トレース) に応じて. たとえば、要求が GET 要求の場合、応答にはリソースが含まれます。 もしそうなら です 他の re のいずれかクエスト、応答は、アクションの結果が含まれます。 ザ 200 ステータス コードは 1 です 10を超える他の応答コード また、キャッシュ可能であり、保存できることを意味します を介して取得し、 クライアント、サーバーに別の要求を行う必要がないように 未来。 See RFC7231, セクション 6.3.1 詳細については、次の情報を参照してください。.

201: 作成済み

201作成済みステータスコードは、200 OKステータスコードのようなものです。 ただし、201 ステータスコードは、要求が正常に処理され、プロセス内のリソースまたは resourcesを返した、または作成されたことを意味します。. A 通常、201 ステータス コード は PUT 要求 に使用されます。 たとえば、 PUT要求が使用されると、URL に新しいリソースが作成されます 。 要求で指定されます。POST 要求に 201 ステータスコードがある場合、リソースが別のAPI エンドポイント/ロケーションで作成されたことを意味します。 See RFC7231、セクション 6.3.2

詳細については、を参照してください。

202: 受け入れ済み

ザ 202 受け入れ られる 地位 コード サーバが 処理の要求を受信し、 そしてそれ 私は受け入れられましたが、 要求は じゃない 完了しました。 また、それは じゃない 要求が最終的に受け入れられるという意味です。 は、実際の処理がいつ行われるかによって異なります。 このタイプの要求は、通常 API で見られます。 バッチ処理は 1 日に 1 回実行されます。 から そこ です HTTP が後に通信する方法はありません。 要求は成功しました またはユーザーの接続が閉じられましたAPI が、ユーザー n に電子メールを送信する場合があります。タテイング それら プロセスが成功したことを確認します。 See RFC7231, Section 6.3.3 詳細については、を参照してください。

203: 権限のない情報

203 の権限のない情報状態コードは、通常、 HTTP プロキシまたはサード パーティ. クライアントとサーバーの間に置くプロキシ は、クライアントに到達する前に応答を変更する可能性があります。 宛先 示す その間に何かが変わった 処理する場合は、ステータスコード203が使用されます。 ただし、この方法の欠点は、 it 私元のステータスコードが何であったかを知る不可能 プロキシが応答内の何かを変更した場合。 推奨される回避策は、 警告ヘッダーを使用する と一緒に 214 ステータス コード 使用される 宛先 レスプに変更または変更があったことを示すオンス。 w を使用するアーニングヘッダは元のステータスコードを 詳細については、s ee RFC7231、S ection 6.3.4

を渡しました。

204: コンテンツなし

ステータスコード204 コンテンツなし 示す 応答がサーバーによって正常に配信され、満たされ、それ以上の不備が起きていないent は応答の本文で送信されます。 例として、 要求がページ上のフォームで送信された場合、一度 response が送信され、クライアント/ブラウザ はビューを変更するはずではなく、フォームが変更する必要があります じゃない リフレッシュまたはダイレクト ユーザー 新しいページにe. いいえ 追加コンテンツは、ユーザーの視点で置き換えられるか、表示する必要があります。詳細については、SE RFC7231、S ection 6.3.5

を参照してください。

205: コンテンツをリセットする

204コンテンツなしステータス codeと同様に、ステータスコード 205 コンテンツのリセット サーバーが要求を正常に送信したことを示し、ユーザー エージェントがビューをその要求またはi に更新/リセットする必要があることを示しますジナル状態。 ページ上のフォームの例を使用する場合は、ユーザーが を完了し、 フォームを送信する場合、クライアント/ブラウザはフォームを元の状態に戻して、ユーザーが彼女のアクションを実行できるようにする必要があります. A 205 ステータスコードは、それ以上のコンテンツが提供されることを前提としています。See RFC7231、 セクション 6.3.6

の詳細については、 を参照してください。

206:コンテンツの一部

A 206 部分 コンテンツ ステータス コード は、さまざまな要求に使用でき、通常は 示す サーバーが を果たしてきました。 パーシャル リソースの要求。 たとえば、クライアントが特定のクライアントを検索する場合 部分、または範囲、 の a 特定 資源 またはページ. ある場所の別の例 206 ステータス 使用されているコードは、 ビデオで。 クライアントはロードするだけ ビデオがバッファリングまたはロードするのを待つ必要がない、ユーザーが長く待つ必要がある負のユーザーエクスペリエンスを回避するのに役立ちます ビデオが再生される前に。 これは、HTTPビデオプレーヤーの間で通常のベストプラクティスです帯域幅と知覚遅延の問題を回避するため。詳細については、RFC7233、セクション4.1

を参照してください。

207: マルチステータス

ザ 207 マルチステータス 地位 コード 提供する 複数の独立したプロセスのステータス WebDAV サーバーで使用されます。 デフォルトのメッセージ/応答はテキスト/XMLメッセージです。 それ 示す 複数の操作が行われ、各操作の状態をレスプの本体で表示できることオンス. ステータス コードは、5 つのカテゴリのどれでも異なる場合があります。 応答コードは、サブ要求の数によって異なります。 他の200スタトゥとは異なりs コード、207 ステータスコードは プロセスが正常に完了したことを確認します。 クライアントは、各要求の本文を表示する必要があります。 成功したかどうかを判断します。See RFC4918、 セクション 11.1

の詳細については、 を参照してください。

208: すでに報告済み

ザ 208 既に報告済み 地位 コードは、WebDAV 拡張内で使用されるもう 1 つのステータス コードです. という感じで ザ 207 ステータス コード、それを クライアント/ブラウザが 示す サーバーに リソースは既に処理されています。 クライアントがリソースを要求すると、応答に重複するリソースが含まれる可能性があります。つまり、同じリソースが複数回送信されます。 ザ 208ステータスレスポンスは、処理と繰り返しの可能性を回避します 同じ応答。 208 ステータスコード 応答 は応答の本文にのみ表示され、実際の HTTP 応答としては表示されません。See RFC5842、 セクション 7.1

の詳細については、 を参照してください。

209-225: 未割り当て

状況コード 209 から 225 は現在割り当てられていません。

226:使用される IM

226 IM (インスタンス操作) 使用済み状態コードは、サーバーがリソースに対する GET 要求を完了したことを示すために使用されますが、応答は、現在のインスタンスに適用された 1 つまたは複数のインスタンス操作を表します。 HTTP プロトコル内には、サーバー側でサポートされている HTTP でのデルタ エンコードという拡張機能があります。 これが暗示的な場合クライアントはキャッシュされたバージョンへの変更を要求することができ、サーバーは再び再送信する代わりに変更を送信します。この機能を実装するには、クライアント/ブラウザ要求が必要です。 サポートされている IM タイプを指定します。 サーバーがこの機能をサポートしている場合は、 226 ステータス コード 変更を加えます。 場合 200 ステータスコードが返送され、この機能がサポートされないことを示します。 詳細については、RFC3229、セクション10.4.1

を参照してください。

227-299: 未割り当て

状況コード 227 から 299 は現在割り当てられていません。

3xx: リダイレクト

3xx ステータスコードは、URL リダイレクトの場合に使用されます。ウェブサイトは常に変化し、進化しているので、マーケターが更新された、または別のページにユーザーを誘導する必要がある場合があります.リダイレクトは、ユーザーが探しているものを検索し、維持する必要がないようにするのに役立ちます 検索エンジンでのランキング.リダイレクトアクションは、ブラウザによって自動的に実行されるか、またはユーザーからの追加の相互作用を必要とする場合があります。 3xx HTTP ステータスコードは、SEO (検索エンジン最適化) とユーザーエクスペリエンスに不可欠です。 また、検索エンジンにクロールやインデックスを作成するコンテンツを伝えます。 私f が適切に実装されていない、 ユーザー は 意図しない場所 に誘導され、4xx ステータス コードが発生 し 、SEO 品質スコアに影響を与える可能性があります。

300: 複数の選択肢

300 複数の選択肢の状態コードは、resource が移動し、リダイレクトできることを示します 複数の場所に移動します。 この場合、ユーザ 使用するリソースを決定する必要があります。 サーバーは、 示す 好ましい選択肢と それはあるべきだ 示さ れた ヘッダー内 畑 ユーザー エージェントが自動的に優先選択にリダイレクトできる. 実用化では、複数の回答から選択する標準化された方法がないため、彼のステータスコードはほとんど使用されません。 See RFC7231, セクション 6.4.1 詳細については、を参照してください。

301: 完全に移動

301移動永続的状態コードは、ターゲット・リソースが永続的な場所に移動されたことを示すために使用されます。 301 ステータスコードは、ヘッダー内でこの新しい場所または URL を使用するようにブラウザ/クライアントに指示します。. と一緒に 301 地位 コードを作成すると、新しい URL が 与えられた 応答で また、URL を更新する 先の 場所(s)、新しい URL への更新と共に. See RFC7231, セクション 6.4.2 詳細については、を参照してください。

302: 見つかりました

302 が見つかりましたステータスコード アクセスしているリソースが一時的であることをクライアント/ブラウザに示します 位置 別の場所の下に.301 ステータスコードとは異なり、 302 ステータスコードは一時的な移動を示すため、クライアントは 自動的に その更新 リンクス 新しい場所へをもう一度考え、 私s 一時的な意味を持つ。 その例を示す 302 ステータス コードが存在する場合は、コードを使用する必要があります アール 倍数 URLですが、彼らは で提供することができます 異なる言語。 ユーザーが特定の URL に到着する可能性がありますが、クライアントはリダイレクトする可能性があります 自動的に彼は、ブラウザの設定に基づいて適切なページにし、このo nを使用します その後の 訪問。 それは 私のです 場合によっては、ブラウザが要求を POST から GET に変更する可能性があることを指摘しました。 このアクションが 307ステータスコードを使用する必要があります。詳細については、RFC7231、セクション6.4.3

を参照してください。

303: その他を参照

ステータス コード 303 他を参照すると、サーバーがリダイレクトされることを示します。 クライアント/ブラウザを別のリソースに対して行います。 リソースは次の場合 ヘッダー フィールドを URL として示します. 301 および 302 ステータス コードとは異なり、このコードは じゃない リソースにテンポラが含まれますリly または永久に移動する、s の目的は、 URL への応答の場所に 指定する値私c 要求は可能 設立する GET 要求を介して。 303 ステータスコードは、必要があります じゃない ただし、キャッシュに入れ 後続 要求がキャッシュされる可能性があります. の典型的な使用 303 ステータス コードは、ユーザー d を確認することですo ない 誤って再送信 フォーム データ POST 要求を介して。 新しいページに移動する必要があります。 そうでなければ、彼らは知らないうちに ブラウザの戻るボタンをクリックすると、再送信を求める場合があり、これはunnecessaryにつながる 複製e提出物。 詳細については
、RFC7231、セクション6.4.4
を参照してください。

304: 変更されていません

ステータスコード 304 変更されていないは、条件付き GET または HEAD 要求に応答して送信されます。クライアント/ブラウザは、次のような条件付き要求を送信できます。 If-match

, If-None-一致, 変更された – 変更された場合– 次の値を変更しない、 、 特定の

リソースが変更されたかどうかを確認する場合は、範囲を指定します。 特定の日付/時刻以降。 これ です クライアントが以前にリソースにアクセス、ダウンロード、および保存した場合にのみ実行されます。 もしも その特定の日付/時刻が最後にアクセスされた後に変更されると、サーバーは 200 OK ステータス コードを返します. もし じゃない その日付/時刻以降に変更され、 304 ステータス コードが送信されます 応答として, 示す 保存されたリソースは、それが持っているので、提供されるべきであることを じゃない されて 変更 前回アクセス以降。 See RFC7232、セクション4.1 詳細については、を参照してください。

305: プロキシを使用する

305 プロキシの状態コードを使用する Iは、セキュリティ上の考慮事項のために使用されなくなった非推奨の状態コードです。. それ 私は、彼らがアクセスしていたresourceがプロキシを介してアクセスされなければならないことをクライアントに黙示するために使用されました。305 プロキシの使用ステータスコードの詳細については、RFC7231、 セクション 6.4.5 を参照してください。

306:未使用

305 ステータスコードと同様に、306 未使用ステータス もともとスイッチ プロキシとして知られていました。 ザ 306 ステータスコードが以前に使用されました 仕様。 その意図は、のように使用されることでした 後続のリソースへの requests が指定されたプロキシを使用する必要があることをクライアントに指示します。 これはセキュリティ上の問題と見なされるため、使用されなくなりました。 306 未使用ステータスコードの詳細については、RFC7231、セクション6.4.6を参照してください。

307: 一時的なリダイレクト

という感じで 302 が見つかったリダイレクトステータスコード、t彼 307 一時的なリダイレクト 地位 コード 示す リソースまたはドキュメントが別のリソースまたはドキュメントで使用可能であることをクライアント/ブラウザに一時的 URL を指定して、その URL を返します。 リダイレクトは一時的なものであり、変更される可能性があるため、 ブラウザ/クライアントは、現在の URL に引き続きアクセスする必要があります 後続 要求。 の主な違い 302 ステータス コードと 307 ステータス コードは、 307 ステータス コードでは、要求の変更は許可されていません a 投稿 に要求する 取得 依頼クライアントが POST 要求を要求した場合は、リダイレクトされ、 始める POST 要求を再度実行します。 See RFC7231, セクション 6.4.7

308: 永続的なリダイレクト

308 Permanent Redirect ステータスコードは、ターゲット リソースが永続的な URL に配置され、equentが配置されていることを示す、キャッシュ可能な状態コード (キャッシュ制御が実装されていない場合を除く)です。 要求は、その URL にも送信する必要があります. さらに、クライアントは、任意の 新しい場所への古いブックマーク。 308 ステータスコードは301 ステータス コードと非常によく似ていますが、308 ステータスコードが送信された場合は、次の 始める をクリックし、ターゲットの場所に同じ要求を送信します。 A 301 ステータスコードはt を実行しません これを行う必要があります。 ほとんどのブラウザ/クライアントは、POST要求を GET 要求に変更します。詳細については、rfc7238、セクション3

を参照してください。

309-399: 未割り当て

ステータス コード 309 ~ 399 は現在割り当てられていません。

4xx: クライアント エラー

最も HTTP ステータス コードを持つ分類、 4xx HTTP ステータスコードは、ユーザーに表示させたくないものです。4で始まるステータスコードは、クライアントに問題があることを意味します。 4xx ステータスコードは、通常、ページが削除されてリダイレクトされなかった場合、またはURLまたはリンク内に誤って入力された場合に生成されます。 ユーザーが恐ろしい4xxステータスコードを取得した場合、それは私が問題があることを意味します クライアント/ブラウザがサーバーから情報を受信します。 これら は、ユーザーが画面にポップアップ表示するエラーです。 否定的なユーザーエクスペリエンスを作成し、少しの欲求不満を引き起こし、それら どこか別の場所を探して. 検索エンジンがサイトをクロールして 404 エラーを受け取った場合、レポートにエラーとして表示されます。 A 少数の404エラーは罰金であり、検索エンジンは必ずしも否定的なものとしてこれらを見ていないが、404にリダイレクトする404は、可能性があります SEO に悪影響を及ぼします。 それだけでなく、問題のページがトラフィックや売上を促進するために使用される場合、これは 潜在的な収益の損失につながる可能性があります。

400: 不正な要求

400 不正なリクエスト エラー状態コードは、サーバーが要求を処理できないことを意味します クライアントからの問題が原因で発生します。 これは可能性があります ファイルが大きすぎる、構文が正しくないなど、さまざまな理由で、 無効なURL、またはサードパーティ製アプリケーションで使用されるその他の問題の CAは、サーバー側に問題がある場合でも、400 ステータスコードがキャッチ オール ステータス コードとして使用される場合があります。 これにより、トラブルシューティングが行える 400 ステータス もう少し時間がかかり、難しいコードを記述するただし、 400 地位 コード エラーとヘッダー情報、t彼 サーバーは、提供することができます 余分な 機知に沿った応答h、表示することができます ザ ユーザーが支援する 識別する 問題を解決し、エラーのトラブルシューティングと診断のプロセスを容易にします。 See RFC7231, セクション 6.5.1 詳細については、を参照してください。

401: 無許可

401 不正エラー 状態コードは、要求に適切な認証資格情報が含まれていないことを示します。 クライアントは、サーバーからの認証を必要とします。承認および認証される用語は、しばしば同じ意味で使用されますが、 彼らは別々のことを意味します。 A 401 の状態コードは ストリctly懸念 認証を使用します。 あなたがしたい場合に 彼らが許可されないことをクライアントに通知する 全然です、その後、ステータスコード403 実装する必要があります. A仕様に対するコード化、 ザ 401 ステータス コードには、 WWW 認証 サーバーからのヘッダー 応答, 示す クライアントに対して、サーバーの認証方式またはメソッド 必要es. See RFC7235、セクション3.1 詳細については、を参照してください。

402: 支払いが必要

もともと可能性を可能にする方法の一部としてdを作成します 将来のデジタル支払い方法、 402 支払いが必要なエラー ステータスコードは将来の使用のために正式に予約されていますが、いくつかの制限付きのを使用しましたが、まれに、 シチュエーション.402 支払が必要なエラーコードの詳細については、RFC7231、 セクション 6.5.2

を参照してください。

403: 禁止

403 禁止エラー状態コードは、クライアントからの要求が理解されたことを示しますが、サーバーはそれを承認しません。 アクセスします。 サーバーは、既知の 不正なパスワードやユーザー名などのさまざまな理由が原因である可能性がある、応答内の要求を承認しない理由. とは異なり、 401 ステータス 認証を必要とするコード 403 ステータス コード 示す クライアントが本当に承認を持っていない これらのリソースにアクセスするため、認証 この例では です じゃない 可能. See RFC7231, セクション 6.5.3 詳細については、を参照してください。

404: 見つかりません

最も一般的で悪名高いステータスコードの1つが検出されました ユーザー別 と開発者、404 見つかりません エラー ステータス コード 示す リソース 必須 サーバーから じゃない 存在するか、 noクライアントに提供する意思はありません。 A 404 ステータス コード will not 示す かどうか the の欠如 リソースが一時的または永続的に提供されますが、クライアントはリソースにアクセスするための要求を行うことができます。リソースが完全になくなったことがわかっている場合、410 ステータスコードは 使用されます。404 ステータス コードは、デフォルトでは、他のキャッシュ コントロール are inplaceを除き、キャッシュ可能です。See RFC7231、 セクション 6.5.4

の詳細については、 を参照してください。

405: メソッドが許可されていません

405 メソッドが許可されていません エラー 状態コード クライアントが要求した特定のリソースが、クライアントによってサポートされないことを示します サーバー。 405 メソッドが許可されない という感じで 403用ただし、入札したステータスコードは、 403 ステータス コード 示す リソースが利用可能である可能性があるそれ 私s クライアントが行うだけ じゃない 要求を実行するために必要な権限を持っています。 405 メソッドの許可しない状態と共に、サーバーは 示す ザ アプロバリアテ そして サポート メソッド ターゲット リソースの場合. 405 メソッドを許可しないエラー コードの詳細については、 RFC7231, セクション 6.5.5

406: 受け入れられない

405 メソッドの許可しないエラー状態コードと同様に、406 受け入れ不可エラー コードは、特定の要求をサポートしていないことを示しています。 この場合、彼406受け入れられない ステータスコード サーバーが要求を理解したことを示しますが、応答は クライアントがサポートまたは認識する。 クライアントは、 A-IM などの、ヘッダー内のリソースの特定のバージョンを要求します。 または言語を受け入れる, とりわけ、 サーバーが は じゃない それをサポートし、406受け入れられないステータスコードで応答します。 サーバーは、次のリストで応答できます。 適切なリソース クライアントが選択できる識別子 差出人。 See RFC7231, セクション 6.5.6 モルのためにe 情報。

407: プロキシ認証が必要です

必要な 407 プロキシ認証 エラー sタタスコードは という感じで 401 不正な状態コードただし、場合は 407 ステータス コード in order to プロキシを使用する場合、クライアントはまず認証される必要があります。 プロキシは認証のメソッドを返す必要があります。 VPN、プロキシの台頭のために今日ほど一般的ではありません ユーザー/クライアントとインターネットの間の仲介役 コンテンツがコンテンツのように、より迅速にリソースにアクセスできる 通常 キャッシュ、および、 また ユーザーにセキュリティと匿名性のレイヤーを提供します。 407 プロキシ認証が必要なエラー コードの詳細については、RFC7235、 セクション 3.2 を参照

してください。

408: 要求のタイムアウト

408 要求タイムアウト エラー 状況コードは、サーバーが 指定された時間内にクライアントから要求を受信しなかったことを意味します。 クライアントからの遅延要求は、接続の速度や切断など、さまざまな理由により発生する可能性があります。 時間が経過すると、408 要求タイムアウトステータスがサーバから送信されます。 ユーザー/クライアントは、要求を再送信できます。 408 リクエストタイムアウトエラーコードの詳細については
、RFC7231、セクション6.5.7を参照してください。

409: 競合

409紛争 エラー ステータス コード 示す クライアントからの要求が not サーバーとの競合が原因で処理されます。 クライアントからの要求は問題なく、そこに were 要求の実行を妨げるサーバー側の問題が発生します。 この例としては、特定のファイルを編集する要求があった場合があります。 dを削除する ユーザーによって作成されますが、これらの機能は許可されません。 409 応答に加えて、サーバーは、ユーザーがこの問題を解決する方法についての指示を返す必要があります。 なぜ問題が起こったのかをg. See RFC7231、 セクション 6.5.8

の詳細については、 を参照してください。

410: ゴーン

先ほど説明した 404 Not Found エラー状態コードと同様に、クライアントが要求しているリソースが削除され、サーバーからは利用できなくなったことを示す 410 Gone ステータス コード. N詳細については、URL リダイレクトの観点から、またはリソースにアクセスする場所を参照してください。無期限に削除されました。410 Gone エラーコードの詳細については、RFC7231、 セクション 6.5.9 を参照してください。

411: 必要な長さ

411 長さが必要なエラー状況コードは、事前定義された要求本文content length が原因で、サーバーがクライアントからの要求を許可していないことを示します。 後続のリソース要求で有効な Content-Length ヘッダーが指定されている場合、クライアントは要求を繰り返すことができます。411 長さが必要なエラー コードの詳細については、RFC7231、セクション 6.5.10 を参照してください。

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

サーバーへの条件付き要求 は、HTTP プロトコルの一部として許可されます。 右の場合 要求内で条件が満たされ、要求がサーバーによって実行および処理 されます。 412 前提条件 失敗エラー状態コードは、要求ヘッダー内の 1 つまたは複数の条件が失敗したことを意味します。たとえば、これは GET 要求で使用できます。 and a 条件付き要求は 利用 宛先 そのリソースがha sの場合にのみリソースを再び回します 変更されました。412 前提条件失敗エラー コードの詳細については、RFC7232、セクション 4.2 を参照

してください。

413: 要求エンティティが大きすぎます

ザ 413 要求エンティティが大きすぎます エラー ステータス コード 示す サーバーが w病気ではない 要求を受け入れ、処理する要求に対する e 体 サーバーより大きい場合 許可または許可 過程。 このような例には、ファイルをアップロードする ファイルが 最大 アップロードサイズ サーバーによって設定 アップロードの最大数を超えた場合。 ある場合は、e 413 要求エンティティが大きすぎるエラー が発生すると、サーバーは接続を完全に閉じ、クライアントが接続を切断するのを防ぐことができます 要求の送信を続行します。 場合によっては, it 私s 可能性が高いです サーバー クライアントが要求を再試行することを許可しますの場合は、次の私s 一時的な条件、 そして クライアントにメッセージを含める必要があります。 ハウエフer、それは 私要求によってサーバー自体が物理を使い果たしてしまう可能性があります ディスク領域。 この場合、507 ストレージ不足エラーは、次の応答 クライアントは、戻って受信する必要があります。 詳細については
、RFC7231、セクション6.5.11
を参照してください。

414: URI が長すぎます

サーバーの応答があまり一般的ではない、414 URI が長すぎるエラー状態コードは、サーバーがクライアント要求を拒否したことを意味し、 サーバーが処理できる URL よりも長い。 仲間wsers と検索エンジンは、Url の長さに制限を設けますが、一部はDDoS 攻撃やコード エラーを回避しますが、URL または HTTP のパスは制限を設けません。 には明示的な制限があります。 だから、もしliならmit がサーバーによって設定された値を超えると、414 URI が長すぎるエラーが発生します。414 URI が長すぎるエラー コードの詳細については、RFC7231、セクション 6.5.12 を

参照してください。

415: サポートされていないメディアの種類

415 サポートされていないメディアタイプ のエラー ステータスコード は、サポートされていないメディア形式のため、サーバーが要求本文 または要求本文の一部を処理できないことを示します。クライアントからの要求がサポートされている場合でも、415 エラーは 要求の本文にサポートされていないコンテンツがある場合に返されます。 415 サポートされていないメディアの種類のエラー コードは、406 受け入れ不能状態コードのようなものです。 違いは、 406 受け入れられないエラーコードは、ヘッダーまたはエンコーディングの内容によるものではなく、むしろ HTTP ヘッダー内で設定された値のため。サーバーが定義された形式を処理し、正しい形式で要求を送信できるようにすることで、415 のメディアタイプのエラーステータスコードが発生するのを防ぐことができます。詳細については、RFC7231、セクション6.5.13

を参照してください。

416: 範囲は、不一分の

206 部分要求ステータス コードで説明したように、クライアント/ブラウザは、サーブrからの部分的な応答を要求することが可能です。たとえば、ファイルまたはビデオの特定の部分を示します。 クライアントとサーバーは、範囲要求と呼ばれるものを使用して、 これらの要求を実行します。 ただし、サーバーが これらのタイプの要求をサポートしていない、それは単に全体のresouを返します200 OK応答と一緒にrce。 サーバーが範囲要求をサポートしている場合は、t は ここで、 416 部分要求 エラー ステータス コード は画像を入力し、クライアントが求めているものを返します。 サーバーが範囲要求をサポートしているが、その場合は サーバーの does に同意する 依頼 受信した理由は、受け取る じゃない 範囲内に収まる 又は おそらくその先 指定された範囲、416範囲は、それがない エラー 状態コードが返されます. See RFC7233, セクション 4.4 詳細については、を参照してください。

417: 期待に失敗しました

クライアントは、Expect ヘッダーを使用

して、サーバーから特定の動作を想定していることを示すことができます。 100 Continue ステータス コードで説明されているように、クライアントは要求を受け入れるかどうかをサーバーに確認できます。 その場合、サーバーは 100 続行状態コードで応答します。. ない場合は、t彼 417 期待が失敗しました エラー ステータス コード 示す それ サーバー did じゃない 理解する 予想する ヘッダ またはそれをサポートする、したがって、それはすることができますじゃない クライエンを処理するt 依頼. 417 期待失敗エラー コードの詳細については、 RFC7231, セクション 6.5.14

418-420: 未割り当て

エラーのタタス コード 418-421 は現在割り当てられていませんが、状態コード 418 私は 小さなティーポットは、いくつかの例で使用されます。 エイプリルフールのジョークとして作成され、それはいくつかの牽引力を得ており、です 時には冗談やイースターエッグとして使用され、実際の日常の目的のために使用されません。それは私は公式のステータスコードではないので、ほとんどのブラウザはそれを無視します。このカテゴリのもう一つは、420 あなたのCalmエラーステータスコードを強化する ツイッターによって紹介されています。 それ is n エラーコードは、クライアントにレート制限があることを伝えますが、which は指定された期間内に行うことができる要求の数に対する制限です。 1989 年以来、RFC エディタはよりユーモラスな RFCを公開します。ウィキペディアは、よりユーモラスなエイプリルフールのRFCの完全なランダウンを持

っています.

421: 誤った要求

HTTP/2 プロトコルで導入され、 ザ 421 誤った要求 エラー ステータス コードは、サーバが要求を受け取った じゃない その特定のサーバーを対象としています。 そして正しく応答できない. これは、DNS (ドメイン ネーム システム) が間違った IP アドレスに設定されている場合に発生する可能性があります。 クライアント にする必要があります。 を含める ホスト 要求のヘッダー。 また、単一のサイトを持つサイトで発生する可能性があります。 SSL 複数のドメインからの証明書。 これは、n 使用されているホスティング プロバイダーや特定のブラウザーに問題があるため、問題の場所を実際に把握するには多大な作業が必要になる場合があります. サーバーが、ドメインが req に構成されていない場合最も多い、421誤った指示要求で応答します エラー応答. See RFC7540, セクション 9.1.2 詳細については、を参照してください。

422:処理不可能なエンティティ

A 422 処理不可 実体 エラー ステータス コード 示す に関する問題 の内容 要求の構文. ザ 要求の配置 サーバーによって理解されましただがしかし ザ 要求内のフィールドが無効です または じゃない サーバーが期待する内容と一致する. という感じで 102処理と207マルチ-ステータスステータスコード、422 処理不可 実体 エラー コードは WebDAV プロトコルの一部 Web サービス/API でよく使用される. 一般的に、 400 不正な要求は推奨応答ですが、WebDAV がサポートされている場合は、t彼 422 処理不可 実体 使用する必要があります. See RFC4918, セクション 11.2 詳細については、を参照してください。

423: ロック

422処理不能エンティティエラーステータスコードと同様に、423 ロックエラー ステータスコードは、WebDAVプロトコルの一部でもあります。 423 ロック状態コードは、フィルe、リソース、または直接、たとえば編集できません. その目的は、複数のユーザーが同時にファイル、リソースなどを更新することを避けることです。 これらのリソースは、編集のためにロックを解除することができます。必要なヘン。 423 ロックエラーコードの詳細については
、RFC4918、セクション 11.3 を参照してください。

424: 依存関係の失敗

WebDav でサポートされている別のステータス コード プロトコル; 424 失敗した依存関係 エラー状態コードが 示す クライアントからの要求は、同じく失敗した別の要求への依存関係により失敗しました。 ウェブDAV は利用しています メソッド プロップパッチとして知られています

特定の resource プロパティを更新する. 宛先 リソースが正常に更新されたかどうかを示す場合、WebDAV は標準の HTTP ステータス コード応答を使用します。さらに、424 失敗した依存関係の状態コードは、HTTP 本文の応答が 207 マルチセントを持つインスタンスでのみ使用されます。アトゥス応答。 SpropPATCH が使用され、リソースが更新に失敗した場合

、4xx ステータス コードが送信されます。 リソースの更新中にエラーが発生し、424 失敗した依存関係エラー コードも、その更新が成功したが失敗したに依存する他の要求と共に送信されます。See 詳細については、RFC4918、 セクション 11.4

を参照してください。

425: 早すぎる

今日使用されている一般的な HTTP ステータス コードではなく、HTTP クライアントが HTTPS クライアントに接続している状況では、425 の早すぎるエラー応答コードが使用されます。プロセス中に、接続を確立するのに時間がかかる場合があります。 サーバーとクライアントを使用します。 このプロセスはセキュリティ上の問題を引き起こす可能性があるため、サーバーはクライアントに要求を再試行するように指示します セキュリティで保護された TLS (トランスポート層セキュリティ) 接続が 製. その場合、425 の早すぎる状態コードが返されます。 425 のエラー コードの詳細については、RFC8470、 セクション 5.2を参照してください。

426: アップグレードが必要です

426 アップグレードが必要なエラー ステータス コードは、クライアントに新しいプロトコルを使用する必要があることを示します in order to サーバーに要求を送信します。 たとえば、クライアントが使用している、および古いバージョンの HTTP を使用している可能性があります。 HTTP/1.0が、サーバーは 必要 HTTP2.0. サーバーは、受信しません。 要求が、 クライエンに戻って応答しますt 示す 許容できるプロトコル クライアントが 必要なプロトコルを使用すると、サーバーはクライアントからの要求を受け入れます。 426 アップグレードが必要なエラー コードの詳細については、 RFC7231, セクション 6.5.15

427: 未割り当て

エラー sタタス コード 427 は現在割り当てられていません。

428: 前提条件が必要です

428 前提条件が必要なエラー状況コードは、サーバーへの要求が条件付き要求でなければならないことをクライアントに示します。 に述べたように、 304 変更されていないステータス コード、 クライアントは条件付き要求を送信できます サーバーにとか If-Match, If-None-一致, 変更された場合 – それ以降, 変更されていない場合- それ以降又は 範囲の場合. ただし、これらの条件付き要求は、 必須. サーバーが必要とする場合は、サーバー 示す これは、428 前提条件が必要なエラー コードで応答します。 これは少しです 類似 412 前提条件 エラー コードに失敗しましたが、412 前提条件が失敗しました クライアントがヘッダーに条件付き要求を含む場合にのみ、エラー コードが返されます。 は じゃない mサーバー上のリソースの状態を確認する‘s 横. 要求が本質的に条件付きである必要があることをユーザーに通知することで、ユーザーが適切なファイルまたはリソースを使用して作業を行い、ユーザーが 防ぐのに役立ちます 変更を上書きする可能性があるユーザー. See RFC6585、セクション3 詳細については、を参照してください。

429: 要求が多すぎます

エラーの名前と同じように コードは、429 要求が多すぎるエラー状態コードは、レート制限が実装されていることを意味し、 client どのように限界を超えた 多くの要求 それは作ることができます 指定された時間の経過. 429 の要求が多すぎるエラー応答と共に、次のようになります。 示さ れた 待つ時間 開始 サーバーへの新しい要求ですが、そうではありません 旧来 必須 そうするために. [要求が多すぎる] エラー コードの詳細については、 RFC6585、セクション4

430: 未割り当て

430 エラー状態コードは現在割り当てられていませんが、HTTP /1.1 プロトコル内で 430ブロックエラーコードとして提案されました。. その意図は、何に対する反応として機能することであった として知られている パイプライン。 これにより、クライアントは複数の要求を送信できます。TCP 接続を介して、サーバーがrespond を待っている間. 私正式にそれを作ったことはありません HTTP protocol が HTTP /2.0に更新され、パイプライン処理のサポートが広く採用されたことがないため標準です。

431 要求ヘッダーが大きすぎます

431 要求ヘッダーが大きすぎるエラーステータスコードは、クライアントが許容制限を超えるヘッダー r equest を送信したことを示します。異なる Web サーバーでは、ヘッダーに関しては、許容サイズの制限が異なります。これは、個々のヘッダー要求が大きすぎるために発生する可能性があります または全体が 組み合わされているため すべてのサイズ ヘッダー要求。 ほとんどの場合、これは私が通常あまりにも多くのクッキーを送信することによって引き起こされるので、これは簡単に改善することができます ファイル サイズが大きすぎるCookie 。431 要求ヘッダーが大きすぎるエラー コードの詳細については、RFC6585、セクション 5 を参照してください。

432-450:未割り当て

エラー状態コード 432 から 450 は現在割り当てられていません。

451: 法的な理由により利用不可

エラー sタタスコード 451 法的な理由により利用不可 示す サーバーは要求されたコンテンツの提供を拒否しています によって 合法 理由 また、ユーザーへの応答にエラーの理由も含める必要があります。 451 を使用する理由は、法的な理由により、エラー状態コードが含まれます DMCA(デジタルミレニアム著作権法)のような著作権法に違反するコンテンツ、特定のコンテンツを検閲する政府、または、法律または裁判所の命令に違反するコンテンツ。 禁じられた403 404 Not Found error ステータスコードは、451エラーステータスコードの代わりに使用されることもありますが、451エラーステータスコードは、whに詳細な情報や説明を提供しますy エラーが発生しています。 ユーザーは通常、周りを回っていますe 451 エラーは、コンテンツにアクセスするための VPN を実装します。See RFC7725、 セクション 3

の詳細については 、を参照してください。

452-499: 未割り当て

エラー コード 452-499 は現在割り当てられていません。

5xx: サーバー エラー

4xx ステータスコードと同様に、5xx ステータスコードはエラーがあることを示しますが、問題のエラーは接続不良やブラウザ自体が原因ではない可能性があります。5xx 状況コードは示します そこに 私は サーバーレベルで問題があり、処理することはできません クライアントからの要求。 エラーと共に、サーバーはエラーの説明を返す必要があります。それは私が一時的または永続的な条件であるかどうか、そしてそれがどのように改善されるか。

500: 内部サーバー エラー

500 内部サーバー エラー状態コードは、単にサーバーが発生したことを意味します 問題が発生し、要求を処理できません。 通常、正確な問題が他の 5xx Serverエラーステータスコードのいずれかに該当しない場合は、500 内部サーバーエラーコードが汎用サーバーエラーコードとして使用されます。 仕様。 T彼 500 内部サーバー エラー コードは、おそらく 5xx サーバー エラー分類コードの最も使用されます。詳細については、RFC7231、セクション6.6

を参照してください。

501: 実装されていません

実装されていない 501 サーバーがエラー状態コードを発生する じゃない 要求のメソッドを認識するため、SU要求を pport または処理します。 それ 私s という感じで 405 メソッドが許可されていません クライアント エラー ステータス コードだがしかし 501 実装されていないエラー状態コード 示す クライアントからの要求メソッドが有効であり、サーバーではサポートされていません。 405 メソッドが許可されていませんエラー ステータス 示す クライアントによって呼び出されるメソッドが じゃない サポート そして、する必要があります じゃない ずっと 利用. 見る RFC7231, セクション 6.6.2 詳細については、を参照してください。

502:ゲートウェイが無効

502 Bad Gateway エラー状態コードは、サーバーがプロキシを実行しており、無効として戻された配信元サーバーから応答を受信したことを示します。 それ 私可能な 私サーバーが過負荷のため、クライアントは要求を再送信できますが、 ほとんどの場合, it 私s 正当 宛先 Web サーバーに関する問題 又は CDN(コンテンツ配信ネットワーク) クライアントとサーバーの間に座って、そして 要する 余分な エラーがスローされる理由を理解するために、ホスティング プロバイダーとのトラブルシューティング. 見る 詳細については、RFC7231、セクション6.6.3。

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

503 サービスUnilable エラー状態コードは、サーバーが現在要求で過負荷になっているか、リソースが不足している、現在は in メンテナンスを示します。 アクセスしようとしているアプリケーションがダウンしている可能性があり、サーバーは現在の状態のために要求を完了できません。クライアントは、要求を再試行するように指示する 503 サービス利用不可エラー状態コードと共にメッセージを表示することがあります。 あとで。 しかし、それは 503 サービス利用不可エラー状態コードがいつ、どのくらい長く続くかについての明確な説明は提供されない場合があります。詳細については、RFC7231、セクション6.6.4

を参照してください。

504: ゲートウェイのタイムアウト

502 Bad Gateway エラーステータスコードと同様に、サーバーがプロキシとして動作している場合は 504 ゲートウェイ タイムアウトエラーステータスコードが使用されますが、504ゲートウェイTimeoutで応答します エラー状態コード if the response from an 配信元サーバーの応答に時間がかかりすぎます。 502 Bad Gateway エラー状態コードは、応答が無効な場合に使用する必要があります。 プロキシ サーバーが受信していない 全然です. 504ガットと一緒にメッセージeタイムアウトが示す方法 そして推薦する クライアントが要求を再送信しようとする. 見る RFC7231, セクション 6.6.5 詳細については、を参照してください。

505: HTTP バージョンがサポートされていません

505 HTTP バージョン サポートされていないエラー状態コードは、サーバーが要求のメッセージで使用される HTTP プロトコルのバージョンをサポートしていないため、処理ができないという意味です。 要求を確認します。 505 HTTP バージョンと共に サポートされていないエラー状態コードを使用する場合、サーバーからの応答には、特定の HTTPプロトコルがサポートされていない理由と、サポートされているプロトコルを示すメッセージが含まれている必要があります。詳細については、RFC7231、セクション6.6.6

を参照してください。

506: バリアントもネゴシエート

506バリアントもネゴシエートは実験的なHTTP ステータス コードであり、今日の標準の一部ではありません。 506 バリアントもネゴシエートは、サーバーとの内部構成の問題があることを示します コンテンツ ネゴシエーションの問題が原因で発生します。 コンテンツ ネゴシエーションにより、クライアントは送信できます。 複数の受け入れヘッダーを使用し、次の指示に基いて、リソースの特定の表現をサーバーに指示します。 ブラウザを表示します。 これは次の場合があります。 適切な言語を提供し、ドキュメントはtを形成するなど. 506 バリアントもネゴシエートエラー状態コードが ひとつの HTTP 標準の一部ではなく、実験的な状態はまれに使用されます。 一部のGoogle Play ユーザーは、アプリケーションの複数のバージョンをダウンロードしようとしたときに、この問題が発生し、ir デバイスが閉じたループプロセスでアプリを継続的にダウンロードしようとします。詳細については、RFC2295、 8.1を

参照してください。

507: ストレージが不足しています

507 ストレージ サーバーのエラー 状態コードが不足している は WebDAV プロトコルの一部でもあります。 507 ストレージ不足エラー状況コード プット

やPOST

などの要求を行うことを示します。 要求は、ファイル サイズが大きすぎます。 また、サーバが 一時的にストレージが不足します。詳細については、RFC4981、セクション11.5

を参照してください。

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

検出された 508 ループ サーバー エラー状態コード507 ストレージ サーバーのエラー コードが不十分な場合と同様に、WebDAV プロトコルの一部です。 WebDAV プロトコル内で、 it 私s クライアントがサーバーに要求を行うことができる可能性 ディレクトリ全体の場合 ターゲットを作成して、どこ 同じディレクトリが、無限の要求/応答ループを発生します。 508 ループ検出サーバー エラーステータスコード 示す サーバーが 終わった クライアント要求具体的には 深さ: でヘ不道徳, というのは サービン人 識別 要求 結果は infiniteループ、繰り返し自分自身に呼び戻す. 見る RFC5842、セクション 7.2 より多くのために 情報。

509: 未割り当て

509 サーバーエラー状態コードは現在割り当てられていません。

510: 拡張されていない

510 拡張されていないサーバーエラー状態コードは現在提案/実験ステータスにあり、標準の HTTP ステータスコード仕様の一部ではありません。510 Not Extended は、要求に拡張 HTTP 要求が必要であることをクライアントに示します。 サーバーが 510 Not Extended サーバー エラー状態コードで応答する場合は、CLientはレムする必要がありますedy 彼らの要求が、仕様 は じゃない 明示的 状態 それ。 そこ‘sデバテかどうか t彼のshouldは、4xxクライアントエラーと見なすことができるので、5xxサーバーエラー分類に該当しますが、それ以来 そうです 正式には標準の一部ではない、 私s はレレフではない蟻 日常の使用にはめったに使用されません。 見る RFC2774、セクション7 詳細については、を参照してください。

511: ネットワーク認証が必要です

ネットワークにアクセスするためにクライアントが自身を認証することを要求する、511 ネットワーク認証が必要なサーバー エラー ステータス コード。たとえば、企業でパブリック Wi-Fi ネットワークに接続しようとすると、ユーザーにこのメッセージが表示される場合があります。 ユーザーは、アクセスを許可される前に、契約条件に同意する必要があります。 必要な 511 ネットワーク認証と共に サーバー エラー応答を実行する場合は、ユーザーがログインできる場所に誘導する必要もあります。詳細については、RFC6585、セクション6

を参照してください。

512-599: 未割り当て

サーバー エラーステータスコード 512-599 は現在割り当てられていませんが、一部の企業では、クライアントに対するカスタム サーバー エラー メッセージとしてこれらのエラー を使用する場合があります。

HTTP ステータス コード応答の監視

特定の URL のステータス コードの一覧を直接表示するには、ブラウズ内の [開発ツール] タブを確認します。r. ページ読み込み速度のメトリックに加えて、関連するすべての HTTP ステータス コードと共に、サーバーの応答を表示して、ページ上のすべてが読み込み、読み込み状態を確認できます。 レンダリング ちゃんと.

より積極的で自動化された監視アプローチを行う場合、Dotcom-Monito rのプロフェッショナルモニタリングソリューションは、特定のHTTPエラーコードがユーザーに遭遇するたびに、チームに通知を受け取ることを保証できます。 すぐに彼らはできる 問題を迅速に解決します。 また、 削除するフィルタ機能 タスク、アラート、およびレポートからの個々の HTTP ステータス コードを個別に使用するため、特定のニーズに関係しないHTTPステータス コードは無視されます。