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 リクエストを送信し、そのリクエストが許可され、ドキュメントのコンテンツ (最後にアクセスされて以降、またはリクエストの条件に基づく) および If変化がない場合、サーバーはこのステータス コードを返すはずです。 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 で指定されたデータ範囲が現在のリソースの利用可能な範囲と一致せず、リクエストで定義されていない場合Range リクエスト ヘッダーの場合、サーバーは 416 ステータス コードを返す必要があります。 Range でバイト範囲を使用する場合、この状況は、リクエストで指定されたすべてのデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを意味します。サーバーには、416 ステータス コードを返すときに現在のリソースの長さを示す Content-Range エンティティ ヘッダーも含める必要があります。この応答ではマルチパート/バイト範囲の使用も禁止されています コンテンツタイプとして。
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 Collection Protocol」(RFC 3658) には登場しません。
426	クライアントはTLS/1.0に切り替える必要があります。 (RFC 2817)
449	Microsoft による拡張 適切なアクションを実行した後にリクエストを再試行する必要があることを表します。
500	サーバーで予期しない状況が発生したため、リクエストの処理を完了できませんでした。一般に、この問題はサーバーのプログラム コードにエラーがある場合に発生します。
501	サーバーは、現在のリクエストで必要な機能をサポートしていません。サーバーが要求されたメソッドを認識せず、リソースに対するその要求をサポートできない場合。
502	ゲートウェイまたはプロキシとして動作しているサーバーが、リクエストを実行しようとしたときに、上流のサーバーから無効な応答を受け取りました。
503	一時的なサーバーメンテナンスまたは過負荷のため、サーバーは現在リクエストを処理できません。この状態は一時的なもので、一定時間が経過すると元に戻ります。遅延が予想される場合は、応答に遅延を示す Retry-After ヘッダーを含めることができます。この Retry-After メッセージが与えられない場合、クライアントは 500 応答を処理するのと同じ方法でそれを処理すべきです (SHOULD)。 注: 503 ステータス コードの存在は、サーバーが過負荷になったときにそれを使用する必要があることを意味するものではありません。一部のサーバーは、単にクライアントからの接続を拒否したいと考えています。
504	ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとすると、上流のサーバー (URI で識別されるサーバー、たとえば、 HTTP、FTP、LDAP) または補助サーバー (DNS など) の応答を時間内に受信します。 注: 一部のプロキシ サーバーは、DNS クエリがタイムアウトすると 400 または 500 エラーを返します
505	サーバーは、で使用される HTTP バージョンをサポートしていないか、サポートを拒否しています。リクエスト。これは、サーバーがクライアントと同じバージョンを使用できない、または使用したくないことを意味します。応答には、そのバージョンがサポートされない理由とサーバーがサポートするプロトコルを説明するエンティティが含まれている必要があります。
506	透過的コンテンツネゴシエーションプロトコル (RFC 2295) によって拡張され、内部サーバー構成エラーを表します: 要求されたネゴシエーション引数リソースは、透過的コンテンツネゴシエーションで使用されるように構成されています。したがって、交渉プロセスでは適切な焦点ではありません。
507	サーバーは、リクエストを完了するために必要なコンテンツを保存できませんでした。この状態は一時的なものと考えられます。 WebDAV (RFC 4918)
509	サーバーが帯域幅制限に達しました。これは正式なステータス コードではありませんが、依然として広く使用されています。
510	資源を獲得するために必要な戦略は不満ではありません。 (RFC 2774)

以上がHTTPステータスコードの概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。