最も完全で詳細な http ステータス コード分類表はここにあります。

                                                                                                               

#HTTP ステータス コード分類

##カテゴリ1**2**#3**リダイレクト、リクエストを完了するにはさらなるアクションが必要ですクライアント エラー。リクエストに構文エラーが含まれているか、リクエストを完了できません。サーバーエラー、サーバーはリクエストの処理中にエラーが発生しました

カテゴリの説明

情報、サーバーはリクエストを受信しました。リクエスターは操作の実行を続行する必要があります。

成功、操作は正常に受信され、処理されました

#4**

5**

#

HTTP ステータス コード テーブル (バージョン 1) このテーブルには、ステータス コードの英語名が含まれています。

# で始まるステータス コード#100続行続行します。クライアントは、リクエスト 101プロトコルの切り替え プロトコルの切り替えを続行する必要があります。サーバーはクライアントの要求に基づいてプロトコルを切り替えます。より高度なプロトコルにのみ切り替えることができます。たとえば、 で始まる新しいバージョンの HTTP プロトコル 200OKリクエストは成功しました。通常、GET および POST リクエストに使用されます。 201Created が作成されました。新しいリソースのリクエストと作成が正常に完了しました#202#203非権限情報非権限情報。リクエストは成功しました。ただし、返されたメタ情報は元のサーバー上にあるのではなく、コピー204コンテンツなしコンテンツがありません。サーバーは正常に処理されましたが、コンテンツが返されませんでした。 Web ページを更新せずに、ブラウザーが現在のドキュメントを表示し続けるようにします。205コンテンツをリセットコンテンツをリセットします。サーバーの処理は成功し、ユーザー端末 (ブラウザなど) はドキュメント ビューをリセットする必要があります。このリターン コードは、ブラウザのフォーム フィールド206部分コンテンツ部分コンテンツをクリアするために使用できます。サーバーは、#3 の一部を正常に処理しました。 複数の選択肢Moved PermanentlyFound##303See Other を引き続き使用する必要があります。 301と同じですね。 GET リクエストと POST リクエストを使用して、304未変更未変更を表示します。要求されたリソースは変更されていません。サーバーがこのステータス コードを返した場合、リソースは返されません。通常、クライアントは、指定された日付以降に変更されたリソースのみを返したいことを示すヘッダーを提供することによって、アクセスされたリソースをキャッシュします。305プロキシを使用するプロキシを使用します。要求されたリソースにはプロキシ経由でアクセスする必要があります306未使用非推奨の HTTP ステータス コード307一時的なリダイレクト一時的なリダイレクト。 302と同じですね。 GET リクエストを使用して、4 で始まるステータス コードをリダイレクトします。#403Forbiddenサーバーはクライアントからのリクエストを理解しましたが、リクエストの実行を拒否しました 404405406407408409#サーバーは、クライアントの PUT リクエストを完了するときにこのコードを返す可能性があります。サーバーがリクエストを処理したときに競合が発生しましたGone#411# を使用してリソースの新しい場所を指定できます。 #サーバーは、Content-Length がないとクライアントから送信されたリクエスト情報を処理できません#414Request-URI Too Large415416#クライアントによってリクエストされた範囲は無効です417Expectation Failedサーバーは Expect リクエスト ヘッダー情報で始まるステータス コードを満たすことができません 5500内部サーバー エラー実装されていません#サーバーは要求された機能をサポートしていないため、リクエストを完了できませんゲートウェイまたはプロキシとして機能するサーバーがリモート サーバーから無効なリクエストを受信しました#503サービスを利用できません過負荷またはシステム過負荷のため、メンテナンスのため、サーバーは一時的にクライアントのリクエストを処理できません。遅延の長さはサーバーの Retry-After ヘッダー情報に含めることができます504ゲートウェイ タイムアウトゲートウェイとして機能するサーバーまたはプロキシ、リクエストは時間内にリモート サーバーから取得されませんでした505HTTP バージョンがサポートされていませんサーバーはリクエストされたリクエストをサポートしていませんHTTP プロトコルのバージョンがあり、対処を完了できません#

HTTP ステータス コード リスト (バージョン 2) このテーブルの説明はさらに詳細です

ステータス コード	英語名でのステータス コード	中国語の説明
# 1
	2 ステータス コードに切り替えることができます。
Accepted	Accepted。リクエストは受け入れられましたが、処理されていません
# で始まるステータス コードを持つ GET リクエスト		#300
複数の選択肢。要求されたリソースには複数の場所が含まれる場合があるため、ユーザー端末 (ブラウザーなど) の選択のためにリソースの特性とアドレスのリストが返される場合があります。		301
永久に移動します。要求されたリソースは新しい URI に永続的に移動され、返される情報には新しい URI が含まれ、ブラウザーは自動的に新しい URI にリダイレクトされます。今後の新しいリクエストでは、		302
Temporarily Moved の代わりに新しい URI を使用する必要があります。 301と同じですね。ただし、リソースは一時的にのみ移動されます。クライアントは、他のアドレスを表示するには、元の URI
400	不正なリクエスト	クライアントリクエストの構文が正しくないため、サーバーはそれを理解できません
401	Unauthorized	リクエストにはユーザーの ID 認証が必要です
402	支払いが必要です	将来の使用のために予約
#Not Found	サーバーは、クライアントの要求に従ってリソース (Web ページ) を見つけることができません。このコードを通じて、Web サイト デザイナーは、「要求したリソースが見つかりません」というパーソナライズされたページをセットアップできます。
メソッドは許可されていません	顧客クライアント リクエストのメソッドは禁止されています
Not Acceptable	サーバーは、クライアント リクエストのコンテンツ特性に基づいてリクエストを完了できません
プロキシ認証が必要です	リクエストには 401 と同様にプロキシ認証が必要ですが、リクエスタは承認にプロキシを使用する必要があります
リクエストのタイムアウト	サーバーはクライアントから送信されたリクエストを待機しすぎたため、タイムアウトになりました
競合		#410
クライアントが要求したリソースはもう存在しません。 410 は 404 とは異なります。リソースが完全に削除されている場合は、410 コードを使用できます。Web サイトのデザイナーは、301 コード		## 長さが必要です
##412	前提条件が失敗しました	クライアント要求情報の前提条件エラー
413	要求エンティティが大きすぎます	要求されたエンティティが大きすぎるため拒否されましたサーバーに問い合わせて処理されます。クライアントからの継続的なリクエストを防ぐために、サーバーは接続を閉じることがあります。サーバーが一時的に処理できないだけの場合は、Retry-After 応答メッセージ
	## が含まれます。 #要求された URI が長すぎるため (URI は通常 URL)、サーバーは処理できません
サポートされていないメディア タイプ	サーバーは処理できませんリクエストに添付されたメディア形式
リクエストされた範囲は満足できません
	内部サーバー エラー、完了できませんリクエスト	# 501
	#502	不正なゲートウェイ

#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 応答によって返されたコンテンツをキャッシュすることを禁止されています。

ステータス コード	意味
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 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージ ヘッダーの後の最初の空白行で終了します。
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	要求されたリソースには、指定されたプロキシを通じてアクセスする必要があります。 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 ヘッダーが含まれなければなりません (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 メソッドになり、クエリ文字列が長すぎます。リダイレクト URI の「ブラック ホール」。たとえば、各リダイレクトで古い URI が新しい URI の一部として使用されるため、数回リダイレクトすると長すぎる URI が生成されます。クライアントは、一部のサーバーのセキュリティ ホールを悪用してサーバーを攻撃しようとしています。このタイプのサーバは、リクエストされた URI の読み取りや操作に固定長のバッファを使用するため、GET 以降のパラメータが一定の値を超えるとバッファ オーバーフローが発生し、任意のコードが実行されることがあります [1]。このような脆弱性がないサーバーは 414 ステータス コードを返すはずです。
415	現在のリクエスト メソッドとリクエストされたリソースでは、リクエストで送信されたエンティティはサーバーでサポートされている形式ではないため、リクエストは拒否されます。
416	リクエストに Range リクエスト ヘッダーが含まれており、Range で指定されたデータ範囲が現在のリソースの使用可能な範囲と一致しない場合、リクエストに含まれる If-Range リクエスト ヘッダーが定義されていない場合、サーバーは 416 ステータス コードを返す必要があります。Range でバイト範囲を使用する場合、この状況は、リクエストで指定されたすべてのデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを意味します。サーバーには、416 ステータス コードを返すときに現在のリソースの長さを示す Content-Range エンティティ ヘッダーも含める必要があります。この応答では、Content-Type として multipart/byterange を使用することも禁止されています。
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	ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとすると、上流のサーバー (識別されたサーバー) からリクエストを時間内に取得できません。 HTTP、FTP、LDAP などの URI によって応答を受け取るか、セカンダリ サーバー (DNS など) が応答を受け取ります。注: 一部のプロキシ サーバーは、DNS クエリがタイムアウトすると 400 または 500 エラーを返します。
505	サーバーは HTTP をサポートしていないか、サポートを拒否しています。リクエストで使用されるバージョン。これは、サーバーがクライアントと同じバージョンを使用できない、または使用したくないことを意味します。応答には、そのバージョンがサポートされない理由とサーバーがサポートするプロトコルを説明するエンティティが含まれている必要があります。
506	「透過コンテンツ ネゴシエーション プロトコル」(RFC 2295) によって拡張され、サーバーに内部構成エラーがあることを示します。要求されたネゴシエーション引数リソースが構成されています。 to be in 透過的なコンテンツ ネゴシエーションでそれ自体を使用するため、ネゴシエーション プロセスでは適切な焦点ではありません。
507	サーバーはリクエストを完了するために必要なコンテンツを保存できません。この状態は一時的なものと考えられます。 WebDAV (RFC 4918)
509	サーバーは帯域幅の制限に達しました。これは正式なステータス コードではありませんが、依然として広く使用されています。
510	リソースを取得するために必要な戦略が満たされていません。 (RFC 2774)

##推奨学習: 「PHP ビデオ チュートリアル 」 #

以上が最も完全で詳細な http ステータス コード分類表はここにあります。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。