| HTTPステータスコード | ステータスコードの意味 |
|---|
| 100 | クライアントはリクエストの送信を続行する必要があります。この暫定応答は、要求の一部がサーバーによって受信され、まだ拒否されていないことをクライアントに通知するために使用されます。クライアントはリクエストの残りを送信し続けるか、リクエストがすでに完了している場合はこのレスポンスを無視する必要があります(SHOULD)。サーバーは、リクエストが完了した後、クライアントに最終応答を送信する必要があります。 |
| 101 | サーバーはクライアントのリクエストを理解し、リクエストを完了するために別のプロトコルを使用するように、アップグレード メッセージ ヘッダーを通じてクライアントに通知します。この応答の最後の空白行を送信した後、サーバーは Upgrade ヘッダーで定義されたプロトコルに切り替えます。このような措置は、新しいプロトコルに切り替えることがより有益な場合にのみ実行する必要があります。たとえば、新しい HTTP バージョンに切り替えることには、古いバージョンよりも利点があり、また、そのような機能を利用してリソースを配信するためにリアルタイム同期プロトコルに切り替えることもできます。 |
| 102 | WebDAV (RFC 2518) によって拡張されたステータス コードで、処理が続行されることを示します。 |
| 200 | リクエストは成功し、リクエストで予期された応答ヘッダーまたはデータ本体がこの応答とともに返されます。 |
| 201 | リクエストは実行され、リクエストのニーズに基づいて新しいリソースが作成され、その URI が Location ヘッダーとともに返されました。必要なリソースを時間内に作成できない場合は、「202 Accepted」が返される必要があります。 |
| 202 | サーバーはリクエストを受け入れましたが、まだ処理していません。リクエストが拒否される場合があるのと同様に、リクエストは最終的に実行される場合もあれば、実行されない場合もあります。非同期操作の場合、このステータス コードを送信するより便利な方法はありません。 202 ステータス コード応答を返す目的は、バッチ操作が実行されるまでクライアントをサーバーに接続したままにすることなく、サーバーが他のプロセス (1 日に 1 回だけ実行されるバッチベースの操作など) からのリクエストを受け入れることができるようにすることです。完成されました。リクエスト処理を受け入れて 202 ステータス コードを返す応答には、返されたエンティティに処理の現在のステータスを示す情報と、処理ステータス モニタまたはステータス予測へのポインタが含まれている必要があります。これにより、ユーザーは操作が適切かどうかを推測できます。完成しました。 |
| 203 | サーバーはリクエストを正常に処理しましたが、返されたエンティティ ヘッダーのメタ情報は、元のサーバーで有効な明確なセットではなく、ローカルまたはサード パーティからのコピーです。現在の情報は、元のバージョンのサブセットまたはスーパーセットである可能性があります。たとえば、リソースのメタデータを含めると、オリジン サーバーがメタデータに関する詳細な情報を知ることになる場合があります。このステータス コードの使用は必須ではなく、このステータス コードがなければ応答が 200 OK を返した場合にのみ適切です。 |
| 204 | サーバーはリクエストを正常に処理しましたが、エンティティ コンテンツを返す必要はなく、更新されたメタ情報を返したいと考えています。応答は、エンティティ ヘッダーの形式で新しいメタ情報または更新されたメタ情報を返す場合があります。これらのヘッダーが存在する場合、要求された変数に対応する必要があります。クライアントがブラウザの場合、ドキュメントビューの仕様に従って新規または更新されたメタ情報がユーザーのブラウザアクティビティに適用される必要がある場合でも、ユーザーのブラウザはドキュメントビューを変更することなく、リクエストが行われたページを保持すべきです(SHOULD)。 204 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージ ヘッダーの後の最初の空行で終わります。 |
| 205 | サーバーはリクエストを正常に処理しましたが、何も返しませんでした。ただし、204 応答とは異なり、このステータス コードを返す応答では、要求者がドキュメント ビューをリセットする必要があります。この応答は主に、ユーザー入力を受け入れた直後にフォームをリセットして、ユーザーが別の入力を簡単に開始できるようにするために使用されます。 204 応答と同様に、この応答にはメッセージ本文を含めることが禁止されており、メッセージ ヘッダーの後の最初の空白行で終わります。 |
| 206 | サーバーは GET リクエストの一部を正常に処理しました。 FlashGet や Thunder などの HTTP ダウンロード ツールは、このタイプの応答を使用して、中断されたダウンロードを再開したり、大きなドキュメントを複数のダウンロード セグメントに分割して同時ダウンロードしたりします。リクエストには、クライアントが予期するコンテンツの範囲を示す Range ヘッダーを含める必要があり、リクエスト条件として If-Range を含めることもできます。応答には次のヘッダー フィールドが含まれている必要があります: Content-Range は、この応答で返されるコンテンツの範囲を示すために使用されます。Content-Type multipart/byteranges のマルチパート ダウンロードの場合、各マルチパート パートには Content-Range が含まれている必要があります。ドメインは、この段落の内容範囲を示すために使用されます。 Content-Length が応答に含まれる場合、その値は返されるコンテンツ範囲の実際のバイト数と一致する必要があります。同じリクエストが 200 レスポンスを返す必要がある場合は、日付 ETag および/または Content-Location。 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 仕様では、そのような自動選択がどのように実行されるべきかについては規定されていません。サーバー自体に優先フィードバックの選択肢がすでにある場合は、このフィードバックの URI を Location に指定する必要があります。ブラウザは、この Location 値を自動リダイレクトのアドレスとして使用できます。さらに、特に指定がない限り、この応答はキャッシュ可能です。 |
| 301 | 要求されたリソースは新しい場所に永久に移動されました。今後このリソースを参照する場合は、この応答で返されたいくつかの URI の 1 つを使用する必要があります。可能であれば、リンク編集機能を持つクライアントは、要求されたアドレスをサーバーから返されたアドレスに自動的に変更する必要があります。特に指定がない限り、この応答もキャッシュ可能です。新しい永続的な 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 にアクセスします。元のリクエストのメソッド。ステータス コード 303 および 307 は、サーバーがクライアントからどのような応答を期待しているかを明確にするために追加されました。 |
| 303 | 現在のリクエストに対する応答は別の URI で見つかるため、クライアントは GET を使用してそのリソースにアクセスする必要があります。このメソッドは主に、スクリプトによってアクティブ化された POST リクエストの出力を新しいリソースにリダイレクトできるようにするために存在します。この新しい URI は、元のリソースへの代替参照ではありません。同時に、303 応答のキャッシュは禁止されます。もちろん、2 番目のリクエスト (リダイレクト) はキャッシュされる可能性があります。新しい URI は応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。注: HTTP/1.1 より前のブラウザの多くは 303 ステータスを正しく理解できません。これらのブラウザとの対話を考慮する必要がある場合は、302 ステータス コードで十分です。これは、ほとんどのブラウザが、上記の仕様でクライアントに 303 応答の処理を要求しているのとまったく同じ方法で 302 応答を処理するためです。 |
| 304 | クライアントが条件付き GET リクエストを送信し、そのリクエストが許可されたものの、ドキュメントの内容が (最後のアクセス以来、またはリクエストの条件に従って) 変更されていない場合、サーバーはこのステータス コードを返す必要があります。 304 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージ ヘッダーの後の最初の空白行で終わります。応答には、次のヘッダー情報が含まれていなければなりません: サーバーに時計がない場合は、日付。クロックのないサーバーもこれらのルールに準拠している場合、プロキシ サーバーとクライアントは、(RFC 2068 で規定されているように) 受信した応答ヘッダー自体に Date フィールドを追加でき、キャッシュ メカニズムは正常に動作します。 ETag および/または Content-Location (同じリクエストが 200 応答を返す必要がある場合)。 Expires、Cache-Control、および/または Vary (その値が、同じ変数に対する以前の他の応答に対応する値と異なる可能性がある場合)。この応答リクエストが強力なキャッシュ検証を使用する場合、この応答には他のエンティティ ヘッダーを含めるべきではありません。それ以外の場合 (たとえば、条件付き GET リクエストが弱いキャッシュ検証を使用する場合)、この応答には他のエンティティ ヘッダーを含めることが禁止されます。これにより、キャッシュされた間の不一致の解決が回避されます。エンティティのコンテンツと更新されたエンティティ ヘッダー情報。エンティティが現在キャッシュされていないことを 304 応答が示している場合、キャッシング システムはその応答を無視し、制限なしで要求を繰り返す必要があります。キャッシュ エントリの更新を必要とする 304 応答を受信した場合、キャッシュ システムはエントリ全体を更新して、応答で更新されたすべてのフィールドの値を反映する必要があります。 |
| 305 | 要求されたリソースには、指定されたプロキシを通じてアクセスする必要があります。指定されたプロキシの 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 ヘッダーが含まれなければなりません (MUST)。クライアントは、適切な 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 Gone」のマークを付ける必要があるかどうか、またこのマークをどのくらいの期間維持する必要があるかは、完全にサーバー所有者次第です。 |
| 411 | サーバーは、Content-Length ヘッダーが定義されていない要求の受け入れを拒否します。リクエスト メッセージ本文の長さを示す有効な Content-Length ヘッダーを追加した後、クライアントはリクエストを再度送信できます。 |
| 412 | サーバーは、リクエストのヘッダー フィールドを検証するときに、リクエストのヘッダー フィールドに指定された 1 つ以上の前提条件を満たしていません。このステータス コードを使用すると、クライアントはリソースを取得するときにリクエストのメタ情報 (リクエスト ヘッダー フィールドのデータ) に前提条件を設定できるため、リクエスト メソッドが予期したもの以外のリソースに適用されるのを防ぐことができます。 |
| 413 | リクエストで送信されたエンティティ データが、サーバーが処理できる、または処理できるサイズよりも大きいため、サーバーは現在のリクエストの処理を拒否しています。この場合、サーバーは接続を閉じて、クライアントがこのリクエストを送信し続けるのを防ぐことができます。状況が一時的な場合、サーバーは Retry-After 応答ヘッダーを返し、クライアントに再試行できる時間を通知する必要があります。 |
| 414 | 要求された URI はサーバーが解釈できる長さを超えているため、サーバーは要求の処理を拒否します。これは比較的まれですが、一般的な状況としては、POST メソッドを使用する必要があるフォームの送信が GET メソッドになり、クエリ文字列 (Query String) が長すぎます。リダイレクト URI の「ブラック ホール」。たとえば、各リダイレクトで古い URI が新しい URI の一部として使用されるため、数回リダイレクトすると URI が長すぎます。クライアントは、一部のサーバーに存在するセキュリティの脆弱性を悪用してサーバーを攻撃しようとしています。このタイプのサーバは、リクエストされた URI の読み取りや操作に固定長のバッファを使用するため、GET 以降のパラメータが一定の値を超えるとバッファ オーバーフローが発生し、任意のコードが実行されることがあります [1]。このような脆弱性がないサーバーは 414 ステータス コードを返すはずです。 |
| 415 | 現在要求されているメソッドと要求されたリソースについては、要求で送信されたエンティティがサーバーでサポートされている形式ではないため、要求は拒否されます。 |
| 416 | リクエストに Range リクエスト ヘッダーが含まれており、Range で指定されたデータ範囲が現在のリソースの利用可能な範囲と一致せず、リクエストで If-Range リクエスト ヘッダーが定義されていない場合、サーバーは 416 ステータスを返す必要があります。コード。 Range でバイト範囲を使用する場合、この状況は、リクエストで指定されたすべてのデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを意味します。サーバーには、416 ステータス コードを返すときに現在のリソースの長さを示す Content-Range エンティティ ヘッダーも含める必要があります。この応答では、Content-Type として multipart/byterange を使用することも禁止されています。 |
| 417 | リクエスト ヘッダーに指定された期待されるコンテンツがサーバーによって満たされない、またはサーバーがプロキシ サーバーであり、期待されるコンテンツが現在のルートの次のノードで満たされないという明らかな証拠があります。 |
| 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 Collection Protocol」(RFC 3658) には記載されていません。 |
| 426 | クライアントは TLS/1.0 に切り替える必要があります。 (RFC 2817) |
| 449 | Microsoft によって拡張され、適切なアクションを実行した後にリクエストを再試行する必要があることを示します。 |
| 500 | サーバーで予期しない状況が発生したため、リクエストの処理を完了できませんでした。一般に、この問題はサーバーのプログラム コードにエラーがある場合に発生します。 |
| 501 | サーバーは、現在のリクエストで必要な機能をサポートしていません。サーバーが要求されたメソッドを認識せず、リソースに対するその要求をサポートできない場合。 |
| 502 | ゲートウェイまたはプロキシとして機能するサーバーが、リクエストを実行しようとしたときに、上流のサーバーから無効な応答を受け取りました。 |
| 503 | 一時的なサーバーのメンテナンスまたは過負荷のため、サーバーは現在リクエストを処理できません。この状態は一時的なもので、一定時間が経過すると元に戻ります。遅延時間が予想される場合、応答には遅延時間を示す Retry-After ヘッダーを含めることができます。この Retry-After メッセージが与えられない場合、クライアントは 500 応答を処理するのと同じ方法でそれを処理すべきです (SHOULD)。注: 503 ステータス コードの存在は、サーバーが過負荷になったときにそれを使用する必要があることを意味するものではありません。一部のサーバーは、単にクライアントからの接続を拒否したいだけです。 |
| 504 | ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとすると、上流サーバー (HTTP、FTP、LDAP などの URI によって識別されるサーバー) または補助サーバー (DNS など) からタイムリーな応答を受信できません。 ）。注: 一部のプロキシ サーバーは、DNS クエリがタイムアウトすると 400 または 500 エラーを返します。 |
| 505 | サーバーは、リクエストで使用されている HTTP バージョンをサポートしていないか、サポートを拒否しています。これは、サーバーがクライアントと同じバージョンを使用できない、または使用したくないことを意味します。応答には、そのバージョンがサポートされない理由とサーバーがサポートするプロトコルを説明するエンティティが含まれている必要があります。 |
| 506 | 透過的コンテンツ ネゴシエーション プロトコル (RFC 2295) によって拡張されたもので、サーバーに内部構成エラーがあることを示します。要求されたネゴシエーション引数リソースは、透過的コンテンツ ネゴシエーションでそれ自体を使用するように構成されているため、ネゴシエーション プロセスで適切な焦点ではありません。 |
| 507 | サーバーはリクエストを完了するために必要なコンテンツを保存できません。この状態は一時的なものと考えられます。 WebDAV (RFC 4918) |
| 509 | サーバーが帯域幅の制限に達しました。これは正式なステータス コードではありませんが、依然として広く使用されています。 |
| 510 | 資源を獲得するために必要な戦略はまだ満たされていません。 (RFC 2774) |