| HTTP ステータス コード | ステータスコードの意味 |
|---|---|
| 100 | クライアントは引き続きリクエストを送信する必要があります。 この一時的な応答は、要求の一部がサーバーによって受信され、まだ拒否されていないことをクライアントに通知するために使用されます。 クライアントはリクエストの残りを送信し続けるか、リクエストが完了した場合はレスポンスを無視する必要があります。 要求が完了した後、サーバーはクライアントに最終応答を送信する必要があります。 |
| 101 | サーバーはクライアントの要求を理解し、Upgrade メッセージ ヘッダーを介して、別のプロトコルを使用して要求を完了するようにクライアントに通知します。 この応答の最後の空白行を送信した後、サーバーは Upgrade メッセージ ヘッダーで定義されたプロトコルに切り替えます。 同様の手順は、新しいプロトコルへの切り替えがより有益な場合にのみ実行する必要があります。 たとえば、新しい HTTP バージョンへの切り替えは、古いバージョンよりも利点があります。または、リアルタイムおよび同期プロトコルに切り替えて、そのような機能を利用するリソースを転送します。 |
| 102 | 処理が続行されることを示すために WebDAV (RFC 2518) によって拡張されたステータス コード。 |
| 200 | 要求は成功しました。要求された応答ヘッダーまたはデータ本文がこの応答と共に返されます。 |
| 201 | 要求が満たされ、要求に基づいて新しいリソースが作成され、その URI が Location ヘッダーと共に返されました。 必要なリソースを時間内に確立できない場合は、「202 Accepted」を返す必要があります。 |
| 202 | サーバーはリクエストを受け入れましたが、まだ処理していません。 拒否される可能性があるのと同様に、リクエストは最終的に実行される場合と実行されない場合があります。 非同期操作の場合、このステータス コードを送信する以外に便利な方法はありません。 202 ステータス コードを返す応答の目的は、サーバーが他のプロセス (1 日に 1 回だけ実行されるバッチ ベースの操作など) からの要求を受け入れることができるようにすることです。 バッチ操作が完了しました。 処理のリクエストを受け入れて 202 ステータス コードを返すレスポンスは、返されたエンティティに処理の現在のステータスを示す情報と、処理ステータス モニタまたはステータス予測へのポインタを含める必要があります。 操作が完了しました。 |
| 203 | サーバーはリクエストを正常に処理しましたが、返されたエンティティ ヘッダーのメタ情報は、元のサーバーで有効な確定的なセットではなく、ローカルまたはサード パーティからのコピーです。 現在の情報は、元のバージョンのサブセットまたはスーパーセットである可能性があります。 たとえば、リソースのメタデータを含めると、配信元サーバーがメタ情報スーパーを認識できるようになる場合があります。 このステータス コードを使用する必要はありません。応答でこのステータス コードが使用されていない場合にのみ、200 が返されます。 ケースはOKです。 |
| 204 | サーバーはリクエストを正常に処理しましたが、エンティティ コンテンツを返す必要はなく、更新されたメタ情報を返す必要がありました。 応答は、新しいメタ情報または更新されたメタ情報をエンティティ ヘッダーの形式で返す場合があります。 これらのヘッダーが存在する場合、それらは要求された変数に対応している必要があります。 クライアントがブラウザの場合、新しいメタ情報または更新されたメタ情報をユーザーのブラウザ アクティビティ Document in view に適用する必要がある場合でも、ユーザーのブラウザは、ドキュメント ビューを変更せずにリクエストを送信したページを保持する必要があります。 204 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージ ヘッダーの後の最初の空白行で終了します。 |
| 205 | サーバーはリクエストを正常に処理し、何も返しませんでした。 ただし、204 応答とは異なり、このステータス コードを返す応答では、リクエスターがドキュメント ビューをリセットする必要があります。 この応答は主に、ユーザー入力を受け入れた直後にフォームをリセットして、ユーザーが別の入力を簡単に開始できるようにするために使用されます。 204 応答と同様に、応答にもメッセージ本文を含めることは禁止されており、メッセージ ヘッダーの後の最初の空白行で終了します。 |
| 206 | サーバーはいくつかの GET 要求を正常に処理しました。 FlashGet や Thunder などの HTTP ダウンロード ツールは、このタイプの応答を使用して、ブレークポイント再開を実装したり、大きなドキュメントを複数のダウンロード セグメントに分割して同時ダウンロードしたりします。 要求には、クライアントが必要とするコンテンツの範囲を示す Range ヘッダーを含める必要があり、要求条件として If-Range を含めることができます。 応答には、次のヘッダー フィールドを含める必要があります。 Content-Range は、この応答で返されるコンテンツの範囲を示すために使用されます。 マルチパート/バイト範囲の Content-Type を使用したマルチセグメント ダウンロードの場合、各マルチパート セグメントには、この段落の範囲を示すために使用される Content-Range ドメインが含まれている必要があります。 応答に Content-Length が含まれている場合、その値は、返されるコンテンツ範囲の実際のバイト数と一致する必要があります。 Date ETag および/または Content-Location (同じ要求が 200 応答を返す必要がある場合)。 Expires、Cache-Control、および/または Vary の値が、以前の同じ変数の他の応答の対応する値と異なる場合があります。 この応答要求が If-Range 強力なキャッシュ検証を使用する場合、この応答に他のエンティティ ヘッダーを含めないでください。 この応答要求が If-Range の弱いキャッシュ検証を使用する場合、この応答に他のエンティティ ヘッダーを含めてはなりません。 これにより、キャッシュされたエンティティ コンテンツと更新されたエンティティ ヘッダー情報との間の不一致が回避されます。 それ以外の場合、この応答には、200 応答で返される必要があるすべてのエンティティ ヘッダー フィールドが含まれている必要があります。 ETag または Last-Modified ヘッダーが正確に一致しない場合、クライアント キャッシュは、206 応答によって返されたコンテンツを以前にキャッシュされたコンテンツと結合しないようにする必要があります。 Range ヘッダーと Content-Range ヘッダーをサポートしないキャッシュは、206 応答によって返されるコンテンツをキャッシュすることが禁止されています。 |
| 207 | WebDAV (RFC 2518) によって拡張されたステータス コードは、後続のメッセージ ボディが XML メッセージになることを表し、以前のサブリクエストの数に応じて、一連の独立した応答コードが含まれる場合があります。 |
| 300 | 要求されたリソースには一連のオプションのフィードバック情報があり、それぞれに固有のアドレスとブラウザ駆動のネゴシエーション情報があります。 ユーザーまたはブラウザは、リダイレクト用の優先アドレスを選択できます。 これが HEAD リクエストでない限り、レスポンスにはリソースの特性とアドレスのリストを含むエンティティを含めて、ユーザーまたはブラウザがそこから最も適切なリダイレクト アドレスを選択できるようにする必要があります。 このエンティティの形式は、Content-Type で定義された形式によって決まります。 ブラウザーは、応答の形式とブラウザー自体の機能に基づいて、最も適切な選択を自動的に行う場合があります。 もちろん、RFC 2616 仕様は、そのような自動選択がどのように進められるべきかを指定していません。 サーバー自体に優先フィードバック オプションが既にある場合は、Location URI を Location で指定する必要があります。 ブラウザは、この Location 値を自動リダイレクトのアドレスとして使用できます。 また、特に指定がない限り、このレスポンスもキャッシュ可能です。 |
| 301 | 要求されたリソースは完全に新しい場所に移動されました。このリソースへの今後の参照では、この応答で返される複数の URI のいずれかを使用する必要があります。 可能であれば、リンク編集機能を持つクライアントは、要求されたアドレスをサーバーから返されたアドレスに自動的に変更する必要があります。 特に指定がない限り、この応答もキャッシュ可能です。 新しい永続的な URI は、応答の Location フィールドで返される必要があります。 これが HEAD リクエストでない限り、レスポンス エンティティには新しい URI へのハイパーリンクと短い説明を含める必要があります。 これが GET または HEAD リクエストでない場合、リクエストの条件がそれに応じて変化する可能性があるため、ユーザーが確認しない限り、ブラウザーは自動的にリダイレクトしません。 注: HTTP / 1.0 プロトコルを使用する一部のブラウザーでは、POST 要求に対して 301 応答を送信すると、次のリダイレクト要求が GET になります。 |
| 302 | 要求されたリソースは、別の URI からの要求に一時的に応答するようになりました。 このリダイレクトは一時的なものであるため、クライアントは今後も元のアドレスにリクエストを送信し続ける必要があります。 この応答は、Cache-Control または Expires で指定されている場合にのみキャッシュ可能です。 新しい一時 URI は、応答の Location フィールドで返される必要があります。 これが HEAD リクエストでない限り、レスポンス エンティティには新しい URI へのハイパーリンクと短い説明を含める必要があります。 これが GET または HEAD リクエストでない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限り、ブラウザーは自動リダイレクトを禁止します。 注: RFC 1945 および RFC 2068 の仕様では、リダイレクト中にクライアントがリクエストのメソッドを変更することを許可していませんが、多くの既存のブラウザーは 302 応答を 303 応答として扱い、場所に関係なく、GET を使用して Location で指定された URI にアクセスします。 URI。 最初に要求されたメソッド。 ステータス コード 303 および 307 が追加され、サーバーがクライアントに期待する動作が明確になりました。 |
| 303 | 現在のリクエストに対応するレスポンスは別の URI で見つけることができ、クライアントは GET を使用してそのリソースにアクセスする必要があります。 このメソッドは主に、スクリプトによってアクティブ化された POST 要求の出力を新しいリソースにリダイレクトできるようにするために存在します。 この新しい URI は、元のリソースへの代替参照ではありません。 同時に、303 応答のキャッシュは禁止されます。 もちろん、2 番目の要求 (リダイレクト) をキャッシュすることもできます。 新しい URI は、応答の Location フィールドで返される必要があります。 これが HEAD リクエストでない限り、レスポンス エンティティには新しい URI へのハイパーリンクと短い説明を含める必要があります。 注: HTTP / 1.1 より前の多くのブラウザーは、303 ステータスを正しく認識しませんでした。 これらのブラウザとのやり取りを考慮する必要がある場合は、302 ステータス コードで十分です。ほとんどのブラウザは、上記の仕様で 303 応答を処理するときにクライアントが行う必要があるのとまったく同じように 302 応答を処理するからです。 |
| 304 | クライアントが条件付き GET リクエストを送信し、リクエストが許可され、ドキュメントの内容が (前回の訪問以降またはリクエストの条件に従って) 変更されていない場合、サーバーはこのステータス コードを返す必要があります。 304 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージ ヘッダーの後の最初の空白行で終了します。 応答には次のヘッダーが含まれている必要があります: このサーバーに時計がない場合を除き、日付。 時計のないサーバーもこれらのルールに準拠している場合、プロキシ サーバーとクライアントは、受信した応答ヘッダーに Date フィールドを追加できます (RFC として)。 2068)、キャッシュ メカニズムは正常に動作します。 ETag および/または Content-Location (同じ要求が 200 の応答を返す必要がある場合)。 Expires、Cache-Control、および/または Vary の値が、以前の同じ変数の他の応答の対応する値と異なる場合があります。 この応答要求が強力なキャッシュ認証を使用する場合、この応答には他のエンティティ ヘッダーを含めないでください。 それ以外の場合 (たとえば、条件付き GET 要求が弱いキャッシュ認証を使用する場合)、この応答に他のエンティティ ヘッダーを含めることは禁止されています。 これにより、キャッシュされたエンティティ コンテンツと更新されたエンティティ ヘッダー情報との間の不整合が回避されます。 エンティティが現在キャッシュされていないことを 304 応答が示している場合、キャッシュ システムは応答を無視し、制限を含まない要求を繰り返し送信する必要があります。 キャッシュ エントリを更新する必要がある 304 応答を受信した場合、キャッシュ システムはエントリ全体を更新して、応答で更新されたすべてのフィールドの値を反映する必要があります。 |
| 305 | 要求されたリソースは、指定されたプロキシ経由でアクセスできる必要があります。 Location フィールドは、指定されたプロキシの URI 情報を提供します。 受信者は、このプロキシを介して対応するリソースにアクセスするために、別のリクエストを繰り返し送信する必要があります。 オリジンサーバーのみが 305 応答を確立できます。 注: RFC 2068 には、単一の要求をリダイレクトするための明示的な 305 応答はなく、オリジン サーバーによってのみ確立できます。 これらの制限を無視すると、重大なセキュリティ上の結果につながる可能性があります。 |
| 306 | 仕様の最新バージョンでは、306 ステータス コードは使用されなくなりました。 |
| 307 | 要求されたリソースは、別の URI からの要求に一時的に応答するようになりました。 このリダイレクトは一時的なものであるため、クライアントは今後も元のアドレスにリクエストを送信し続ける必要があります。 この応答は、Cache-Control または Expires で指定されている場合にのみキャッシュ可能です。 新しい一時 URI は、応答の Location フィールドで返される必要があります。 これが HEAD リクエストでない限り、レスポンス エンティティには新しい URI へのハイパーリンクと短い説明を含める必要があります。 一部のブラウザでは 307 レスポンスを認識できないため、ユーザーが理解して新しい URI へのアクセス要求を発行できるように、上記の必要な情報を追加する必要があります。 これが GET または HEAD リクエストでない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限り、ブラウザーは自動リダイレクトを禁止します。 |
| 400 | 1. セマンティクスが正しくなく、サーバーが現在のリクエストを理解できない。 変更しない限り、クライアントはこのリクエストを繰り返し送信しないでください。 2. リクエスト パラメータが正しくありません。 |
| 401 | 現在のリクエストにはユーザー認証が必要です。 応答には、ユーザーに情報を求めるために、要求されたリソースに適した WWW-Authenticate ヘッダーが含まれている必要があります。 クライアントは、適切な Authorization ヘッダーを使用してリクエストを繰り返し送信できます。 現在のリクエストに認証証明書がすでに含まれている場合、401 応答は、それらの証明書が拒否されたことをサーバーが確認したことを意味します。 401 応答に前の応答と同じ認証チャレンジが含まれており、ブラウザーが少なくとも 1 回認証を試行した場合、ブラウザーは応答に含まれるエンティティー情報をユーザーに表示する必要があります。これは、このエンティティー情報に関連する診断情報が含まれている可能性があるためです。 RFC を参照 2617. |
| 402 | このステータス コードは、将来の必要性のために予約されています。 |
| 403 | サーバーはリクエストを理解しましたが、実行を拒否しました。 401 応答とは異なり、認証は何の助けにもならないので、この要求を再送信しないでください。 これが HEAD リクエストではなく、サーバーがリクエストを実行できない理由を説明できるようにしたい場合は、拒否の理由をエンティティで説明する必要があります。 もちろん、サーバーがクライアントに情報を取得させたくない場合は、404 応答を返すこともできます。 |
| 404 | リクエストが失敗し、リクエストされたリソースがサーバー上に見つかりませんでした。 状況が一時的なものか永続的なものかをユーザーに伝える情報はありません。 サーバーが状況を認識している場合は、410 ステータス コードを使用して、内部構成メカニズムの問題により永久に利用できず、ジャンプできるアドレスがないことを古いリソースに通知する必要があります。 404 ステータス コードは、サーバーが要求が拒否された理由を明らかにしたくない場合や、他の適切な応答がない場合に広く使用されます。 |
| 405 | リクエスト ラインで指定されたリクエスト メソッドを使用して、対応するリソースをリクエストすることはできません。 応答は、現在のリソースが受け入れることができる要求メソッドのリストを示すために、Allow ヘッダーを返す必要があります。 PUT を考慮すると、DELETE メソッドはサーバーにリソースを書き込むため、ほとんどの Web サーバーはデフォルト構成で上記のリクエスト メソッドをサポートしていないか許可しておらず、そのようなリクエストに対して 405 エラーを返します。 |
| 406 | 要求されたリソースのコンテンツ特性が要求ヘッダーの条件を満たしていないため、応答エンティティを生成できません。 これが HEAD 要求でない限り、応答は、ユーザーまたはブラウザーが最も適切なものを選択できるエンティティ プロパティとアドレスのリストを含むエンティティを返す必要があります。 エンティティの形式は、Content-Type ヘッダーで定義されたメディア タイプによって決まります。 ブラウザーは、形式と独自の機能に基づいて最適な選択を行うことができます。 ただし、この仕様では、そのような自動選択を行うための基準は定義されていません。 |
| 407 | 401 応答と同様ですが、クライアントはプロキシ サーバーで認証する必要があります。 プロキシ サーバーは、ID 照会のために Proxy-Authenticate を返す必要があります。 クライアントは、検証のために Proxy-Authorization ヘッダーを返すことができます。 RFC を参照 2617. |
| 408 | リクエストはタイムアウトしました。 サーバーが待機する準備ができている時間内に、クライアントが要求の送信を完了しませんでした。 クライアントは、この要求を変更せずにいつでも再送信できます。 |
| 409 | 要求されたリソースの現在の状態と競合するため、要求を完了できませんでした。 このコードは、ユーザーが競合を解決できると見なされ、新しい要求を再送信する場合にのみ許可されます。 応答には、ユーザーが競合の原因を発見するのに十分な情報が含まれている必要があります。 通常、衝突は PUT 要求の処理中に発生します。 たとえば、バージョン チェック環境では、PUT によって送信された特定のリソース変更リクエストに添付されたバージョン情報が以前の (サード パーティの) リクエストと競合する場合、サーバーはこの時点で 409 エラーを返す必要があります。 要求を完了できなかったことをユーザーに通知します。 この時点で、ユーザーがマージ後に新しいバージョンを再送信できるように、競合する 2 つのバージョン間の相違点の比較が応答エンティティに含まれる可能性があります。 |
| 410 | 要求されたリソースはサーバー上で利用できなくなり、既知の転送先アドレスもありません。 このような状況は永続的であると見なされるべきです。 可能であれば、リンク編集機能を持つクライアントは、ユーザーの許可を得た後、このアドレスへのすべての参照を削除する必要があります。 サーバーがこの状態が永続的であるかどうかを認識していない、または不明な場合は、404 ステータス コードを使用する必要があります。 特に指定がない限り、この応答はキャッシュ可能です。 410 応答の主な目的は、Web マスターが Web サイトを維持し、リソースが利用できなくなったことをユーザーに通知し、サーバー所有者がこのリソースへのすべてのリモート接続を削除することを望んでいることです。 このようなインシデントは、時間制限のある付加価値サービスでは一般的です。 同様に、410 応答は、元は個人に属していたリソースが利用できなくなったことを現在のサーバー サイトのクライアントに通知するためにも使用されます。 もちろん、すべての永久に利用できないリソースを「410」としてマークする必要がありますか? このタグを保持する必要がある期間は、完全にサーバーの所有者次第です。 |
| 411 | サーバーは、Content-Length ヘッダーを定義せずに要求を受け入れることを拒否します。 要求メッセージ本文の長さを示す有効な Content-Length ヘッダーを追加した後、クライアントは要求を再度送信できます。 |
| 412 | サーバーは、要求のヘッダー フィールドで前提条件が指定されていることを確認する際に、これらの 1 つ以上を満たすことができませんでした。 このステータス コードにより、クライアントは、リソースを取得するときに要求されたメタ情報 (要求ヘッダー フィールド データ) に前提条件を設定して、要求メソッドが目的のコンテンツ以外のリソースに適用されるのを防ぐことができます。 |
| 413 | リクエストによって送信されたエンティティ データのサイズが、サーバーが処理しようとしていた、または処理できるサイズを超えたため、サーバーは現在のリクエストの処理を拒否しました。 この場合、サーバーは接続を閉じて、クライアントがこの要求を送信し続けないようにすることができます。 この状態が一時的なものである場合、サーバーは Retry-After 応答ヘッダーを返して、後で再試行できる回数をクライアントに通知する必要があります。 |
| 414 | リクエスト URI がサーバーが解釈できる長さを超えているため、サーバーはリクエストの処理を拒否します。 これは比較的まれで、通常は次のような状況があります。 POST メソッドを使用する必要があるフォーム送信が GET メソッドになり、クエリ文字列 (Query 文字列) が長すぎます。 リダイレクト URI の「ブラック ホール」。たとえば、各リダイレクトは古い URI を新しい URI の一部として使用するため、何度かリダイレクトすると URI が長くなります。 クライアントは、一部のサーバーにセキュリティの脆弱性があるサーバーを攻撃しようとしています。 このタイプのサーバーは、固定長のバッファーを使用して、要求の URI を読み取ったり操作したりします。 GET 後のパラメータが一定の値を超えると、バッファオーバーフローが発生し、任意のコードが実行される可能性があります [1]。 このような脆弱性のないサーバーは、414 ステータス コードを返す必要があります。 |
| 415 | 現在リクエストされているメソッドとリクエストされたリソースの場合、リクエストで送信されたエンティティはサーバーでサポートされている形式ではないため、リクエストは拒否されます。 |
| 416 | リクエストに Range リクエスト ヘッダーが含まれており、Range で指定されたデータ範囲が現在のリソースの使用可能な範囲と一致せず、If-Range リクエスト ヘッダーがリクエストで定義されていない場合、サーバーは 416 ステータスを返す必要があります。 コード。 Range がバイト範囲を使用する場合、この状況は、リクエストによって指定されたすべてのデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを意味します。 また、サーバーは 416 ステータス コードを返し、現在のリソースの長さを示す Content-Range エンティティ ヘッダーを含める必要があります。 この応答では、コンテンツ タイプとして multipart / byteranges を使用することも禁止されています。 |
| 417 | リクエスト ヘッダーの Expect で指定された予期される内容がサーバーによって満たされていなかったか、サーバーがプロキシ サーバーであり、現在のルートの次のノードで Expect の内容が満たされていなかったという明確な証拠があります。 |
| 421 | 現在のクライアントの IP アドレスからサーバーへの接続数が、サーバーで許可されている最大範囲を超えました。 通常、ここでの IP アドレスは、サーバーから見たクライアント アドレス (ユーザーのゲートウェイやプロキシ サーバーのアドレスなど) を指します。 この場合、接続数の計算に複数のエンド ユーザーが関与する可能性があります。 |
| 422 | 現在のクライアントの IP アドレスからサーバーへの接続数が、サーバーで許可されている最大範囲を超えました。 通常、ここでの IP アドレスは、サーバーから見たクライアント アドレス (ユーザーのゲートウェイやプロキシ サーバーのアドレスなど) を指します。 この場合、接続数の計算に複数のエンド ユーザーが関与する可能性があります。 |
| 422 | リクエストは正しくフォーマットされていますが、セマンティック エラーが含まれているため応答できません。 (RFC 4918 WebDAV) 423 Locked 現在のリソースはロックされています。 (RFC 4918 WebDAV) |
| 424 | PROPPATCH などの前のリクエストのエラーが原因で、現在のリクエストが失敗しました。 (RFC 4918 WebDAV) |
| 425 | WebDav Advanced Collections ドラフトで定義されていますが、WebDAV Sequence Set Protocol (RFC 3658) には表示されません。 |
| 426 | クライアントは TLS / 1.0 に切り替える必要があります。 (RFC2817) |
| 449 | Microsoft によって拡張された、代表的な要求は、適切なアクションを実行した後に再試行する必要があります。 |
| 500 | サーバーで予期しない状況が発生したため、要求を完了できませんでした。 一般に、この問題はサーバーのプログラム コードが間違っている場合に発生します。 |
| 501 | サーバーは、現在の要求に必要な機能をサポートしていません。 サーバーが要求されたメソッドを認識せず、リソースに対するその要求をサポートできない場合。 |
| 502 | ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとしたときに、アップストリーム サーバーから無効な応答を受け取りました。 |
| 503 | サーバーは、一時的なサーバー メンテナンスまたは過負荷のため、現在要求を処理できません。 この状態は一時的なもので、しばらくすると元に戻ります。 遅延時間が推定できる場合は、遅延時間を示す Retry-After ヘッダーを応答に含めることができます。 この Retry-After 情報が提供されない場合、クライアントは 500 応答と同じ方法で処理する必要があります。 注: 503 ステータス コードの存在は、サーバーが過負荷になったときにそれを使用する必要があるという意味ではありません。 一部のサーバーは、単にクライアント接続を拒否したいだけです。 |
| 504 | ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとすると、アップストリーム サーバー (HTTP、FTP、LDAP などの URI で識別されるサーバー) または補助サーバー (DNS など) からの応答を受信できません。 はやくて。 注: 一部のプロキシ サーバーは、DNS クエリがタイムアウトしたときに 400 または 500 エラーを返します。 |
| 505 | サーバーは、リクエストで使用されている HTTP バージョンをサポートしていないか、サポートを拒否しています。 これは、サーバーがクライアントと同じバージョンを使用できない、または使用したくないことを意味します。 応答には、バージョンがサポートされていない理由と、サーバーがサポートしているプロトコルを説明するエンティティが含まれている必要があります。 |
| 506 | サーバーの内部構成エラーを表す透過的コンテンツ ネゴシエーション プロトコル (RFC 2295) によって拡張されました。 |
| 507 | サーバーは、要求を完了するために必要なコンテンツを保存できません。 この状況は一時的なものと見なされます。 WebDAV (RFC 4918) |
| 509 | サーバーが帯域幅の制限に達しました。 これは正式なステータス コードではありませんが、現在でも広く使用されています。 |
| 510 | リソースを取得するために必要な戦略は不十分ではありません。 (RFC2774) |
