httpステータスコード関数

HTTP ステータス コードの機能は次のとおりです。Web サーバーはそれを使用してクライアントに何が起こったかを伝えます。

ステータス コードは HTTP レスポンスの最初の行にあり、「3 桁のステータス コード」と「ステータス メッセージ」を返します。 「3桁のステータスコード」はプログラムが処理しやすく、「ステータスメッセージ」は人が理解しやすいです。

ステータス コードの分類

HTTP ステータス コードは 5 つの主要なカテゴリに分類されます。現在使用している HTTP プロトコルのバージョンは 1.1 で、次のステータス コードがサポートされています。プロトコルが発展するにつれて、より多くのステータス コードが HTTP 仕様で定義されることになります。

ヒント: ステータス コード 518 が表示された場合、518 が具体的に何を意味するのかはわかりません。 現時点では、518 が属していることだけを知っていれば十分です (5XX、サーバーエラーで十分です)

定義範囲 カテゴリ

1XX 100-101 情報プロンプト

2XX 200-206 成功

3XX 300-305 反復方向

4XX 400 -415 クライアント エラー

5XX 500-505 サーバー エラー

一般的なステータス コード

ほとんどの人は、次の一般的なステータス コードを理解するだけで済みます。さらに詳しく知りたい場合は、読み続けてください。

200 OK サーバーはリクエストを正常に処理しました (これが最も多く表示されます)

301/302 Moved Permanently (リダイレクト) リクエストされた URL は移動されました。応答には、リソースの現在の場所を示す場所 URL が含まれている必要があります。

304 Not Modified (未変更) クライアントのキャッシュされたリソースは最新であり、クライアントはキャッシュを使用する必要があります。

404 リソースが見つかりませんでした。見つかりません。

501 内部サーバー エラーサーバーでリクエストの処理を妨げるエラーが発生しました。

1xx メッセージ

このタイプのステータス コードは、リクエストが受け入れられ、処理を続行する必要があることを意味します。このタイプの応答は一時的な応答であり、ステータス行といくつかのオプションの応答ヘッダー情報のみが含まれ、空白行で終わります。 HTTP/1.0 プロトコルでは 1xx ステータス コードが定義されていないため、特定の実験条件下を除き、サーバーがそのようなクライアントに 1xx 応答を送信することは禁止されています。 これらのステータス コードで表される応答は情報を提供するものであり、クライアントが実行する必要がある追加のアクションを示します。

100 続行 クライアントはリクエストの送信を続行する必要があります。この暫定応答は、要求の一部がサーバーによって受信され、まだ拒否されていないことをクライアントに通知するために使用されます。クライアントはリクエストの残りを送信し続けるか、リクエストがすでに完了している場合はこのレスポンスを無視する必要があります(SHOULD)。サーバーは、リクエストが完了した後、クライアントに最終応答を送信する必要があります。 101 スイッチング プロトコル (スイッチング プロトコル) サーバーはクライアントの要求を理解し、アップグレード メッセージ ヘッダーを通じて、要求を完了するために別のプロトコルを使用するようにクライアントに通知します。この応答の最後の空白行を送信した後、サーバーは Upgrade ヘッダーで定義されたプロトコルに切り替えます。このような措置は、新しいプロトコルに切り替えることがより有益な場合にのみ実行する必要があります。たとえば、新しい HTTP バージョンに切り替えることには、古いバージョンよりも利点があり、また、そのような機能を利用してリソースを配信するためにリアルタイム同期プロトコルに切り替えることもできます。 102 Processing は、WebDAV (RFC 2518) によって拡張されたステータス コードであり、処理が続行されることを示します。

2xx Success

このタイプのステータス コードは、リクエストがサーバーによって正常に受信、理解され、受け入れられたことを意味します。

200 OK (成功) リクエストは成功し、リクエストで予期される応答ヘッダーまたはデータ本体がこの応答とともに返されます。 201 作成された (作成された) リクエストが実装され、リクエストのニーズに従って新しいリソースが作成され、その URI が Location ヘッダー情報とともに返されました。必要なリソースを時間内に作成できない場合は、「202 Accepted」が返される必要があります。 202 Accepted サーバーはリクエストを受け入れましたが、まだ処理していません。リクエストが拒否される場合があるのと同様に、リクエストは最終的に実行される場合もあれば、実行されない場合もあります。非同期操作の場合、このステータス コードを送信するより便利な方法はありません。 202 ステータス コード応答を返す目的は、バッチ操作が実行されるまでクライアントをサーバーに接続したままにすることなく、サーバーが他のプロセス (1 日に 1 回だけ実行されるバッチベースの操作など) からのリクエストを受け入れることができるようにすることです。完成されました。リクエスト処理を受け入れて 202 ステータス コードを返す応答には、返されたエンティティに処理の現在のステータスを示す情報と、処理ステータス モニタまたはステータス予測へのポインタが含まれている必要があります。これにより、ユーザーは操作が適切かどうかを推測できます。完成しました。 203 Non-Authoritative Information (非権限情報) サーバーはリクエストを正常に処理しましたが、返されたエンティティ ヘッダーのメタ情報は、元のサーバーで有効であると決定されたセットではなく、ローカルまたはサード パーティからのコピーです。現在の情報は、元のバージョンのサブセットまたはスーパーセットである可能性があります。たとえば、リソースのメタデータを含めると、オリジン サーバーがメタ情報のスーパーセットを認識することになります。このステータス コードの使用は必須ではなく、このステータス コードがなければ応答が 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 が応答に含まれる場合、その値は返されるコンテンツ範囲の実際のバイト数と一致する必要があります。

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 メッセージになり、前のサブリクエストの数に応じて一連の独立した応答コードが含まれる可能性があることを意味します。

3xx リダイレクト

このタイプのステータス コードは、クライアントがリクエストを完了するためにさらなるアクションを実行する必要があることを意味します。通常、これらのステータスコードはリダイレクトに使用され、この応答の Location フィールドには後続のリクエストのアドレス (リダイレクト先) が指定されます。

後続のリクエストで使用されるメソッドが GET または HEAD である場合に限り、ユーザーのブラウザは、ユーザーの介入なしに、必要な後続のリクエストを自動的に送信できます。クライアントは、無限ループ リダイレクト (例: A→B→C→...→A または A→A) を自動的に検出する必要があります。これは、サーバーとクライアントで大量の不必要なリソース消費を引き起こすためです。 HTTP/1.0 仕様で推奨されているように、ブラウザは 5 つを超えるリダイレクトに自動的にアクセスすべきではありません。

300 の複数の選択肢 要求されたリソースには一連の代替応答があり、それぞれに独自の特定のアドレスとブラウザ主導のネゴシエーション情報が含まれます。ユーザーまたはブラウザは、リダイレクト用の優先アドレスを選択できます。これが HEAD リクエストでない限り、応答には、ユーザーまたはブラウザが最適なリダイレクト アドレスを選択できるリソース属性とアドレスのリストを含むエンティティが含まれている必要があります。このエンティティの形式は、Content-Type で定義された形式によって決まります。ブラウザは、応答の形式とブラウザ自体の機能に基づいて、最も適切な選択を自動的に行う場合があります。もちろん、RFC 2616 仕様では、そのような自動選択がどのように実行されるべきかについては規定されていません。サーバー自体に優先フィードバックの選択肢がすでにある場合は、このフィードバックの URI を Location に指定する必要があります。ブラウザはこの Location 値を自動リダイレクトのアドレスとして使用できます。さらに、特に指定がない限り、この応答はキャッシュ可能です。 301 Moved Permanently 要求されたリソースは新しい場所に永続的に移動されました。今後このリソースを参照する場合は、この応答で返されたいくつかの URI の 1 つを使用する必要があります。可能であれば、リンク編集機能を持つクライアントは、要求されたアドレスをサーバーから返されたアドレスに自動的に変更する必要があります。特に指定がない限り、この応答もキャッシュ可能です。新しい永続的な URI は、応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。これが GET または HEAD リクエストではない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限りブラウザは自動リダイレクトを禁止します。注: HTTP/1.0 プロトコルを使用する一部のブラウザでは、送信した POST リクエストが 301 レスポンスを受け取ると、後続のリダイレクト リクエストは GET メソッドになります。 302 Found (Temporarily Moved) 要求されたリソースは現在、別の URI から一時的に提供されています。このようなリダイレクトは一時的なものであるため、クライアントは今後も元のアドレスにリクエストを送信し続ける必要があります。この応答は、Cache-Control または Expires で指定されている場合にのみキャッシュ可能です。新しい一時 URI は、応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。これが GET または HEAD リクエストではない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限りブラウザは自動リダイレクトを禁止します。注: RFC 1945 および RFC 2068 の仕様では、クライアントがリダイレクト時にリクエスト メソッドを変更することを許可していませんが、多くの既存のブラウザは 302 レスポンスを 303 レスポンスと見なし、場所に関係なく、GET メソッドを使用して Location で指定された URI にアクセスします。元のリクエストのメソッド。ステータス コード 303 および 307 は、サーバーがクライアントからどのような応答を期待しているかを明確にするために追加されました。 303 See Other 現在のリクエストに対する応答は別の URI にあるため、クライアントは GET を使用してそのリソースにアクセスする必要があります。このメソッドは主に、スクリプトによってアクティブ化された POST リクエストの出力を新しいリソースにリダイレクトできるようにするために存在します。この新しい URI は、元のリソースへの代替参照ではありません。同時に、303 応答のキャッシュは禁止されます。もちろん、2 番目のリクエスト (リダイレクト) はキャッシュされる可能性があります。新しい URI は応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。注: HTTP/1.1 より前のブラウザの多くは、303 ステータスを正しく理解できません。これらのブラウザとの対話を考慮する必要がある場合は、302 ステータス コードで十分です。これは、ほとんどのブラウザが、上記の仕様でクライアントに 303 応答の処理を要求しているのとまったく同じ方法で 302 応答を処理するためです。 304 Not Modified (未変更) クライアントが条件付き GET リクエストを送信し、そのリクエストが許可されたが、ドキュメントの内容が (最後のアクセス以来、またはリクエストの条件に従って) 変更されていない場合、サーバーはこれを返す必要があります。ステータスコード。 304 応答にはメッセージ本文を含めることが禁止されているため、常にメッセージ ヘッダーの後の最初の空白行で終わります。サーバーに時計がない場合を除き、応答にはヘッダー情報

Date が含まれている必要があります。クロックのないサーバーもこれらのルールに準拠している場合、プロキシ サーバーとクライアントは、(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 リクエストではない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限りブラウザは自動リダイレクトを禁止します。

4xx クライアント エラー

このタイプのステータス コードは、クライアントでエラーが発生し、サーバーの処理を妨げている可能性があることを意味します。応答が HEAD リクエストでない限り、サーバーは現在のエラー状態とそれが一時的か永続的かを説明するエンティティを返す必要があります (SHOULD)。これらのステータス コードは、あらゆるリクエスト メソッドに適用されます。ブラウザは、そのようなエラー応答に含まれるエンティティ コンテンツをユーザーに表示する必要があります。

エラーが発生したときにクライアントがデータを送信している場合、TCP を使用するサーバー実装は、クライアントとサーバー間の接続を閉じる前に、クライアントがエラー情報を含むパケットを受信したことを慎重に確認する必要があります。エラー メッセージを受信した後もクライアントがサーバーにデータを送信し続ける場合、サーバーの TCP スタックはクライアントにリセット パケットを送信し、クライアントの未認識の入力バッファをすべてクリアして、これらのデータがサーバーによって使用されないようにします。そして後者に干渉します。

400 Bad Request (不正なリクエスト) 現在のリクエストは構文エラーが含まれているため、サーバーによって理解できません。クライアントは、変更しない限り、このリクエストを再送信しないでください。 401 Unauthorized (Unauthorized) 現在のリクエストにはユーザー認証が必要です。応答には、ユーザー情報を要求する、要求されたリソースに適切な WWW-Authenticate ヘッダーが含まれなければなりません (MUST)。クライアントは、適切な Authorization ヘッダー情報を含むリクエストを繰り返し送信できます。現在のリクエストにすでに認証証明書が含まれている場合、401 応答はサーバー検証でそれらの証明書が拒否されたことを示します。 401 応答に前の応答と同じ認証クエリが含まれており、ブラウザが少なくとも 1 回認証を試みた場合、ブラウザは応答に含まれるエンティティ情報をユーザーに表示する必要があります。このエンティティ情報には関連する診断情報が含まれている可能性があるためです。 RFC 2617 を参照してください。 402 Payment Required このステータス コードは、将来の要件のために予約されています。 403 Forbidden サーバーはリクエストを理解しましたが、実行を拒否しました。 401 応答とは異なり、認証は何の助けも提供しないため、要求を再送信する必要はありません。これが HEAD リクエストではなく、サーバーがリクエストを実行できない理由を説明できるようにしたい場合は、拒否の理由をエンティティに記述する必要があります。もちろん、クライアントに情報を取得させたくない場合、サーバーは 404 応答を返すこともできます。 404 Not Found (見つかりません) リクエストは失敗し、リクエストされたリソースがサーバー上に見つかりませんでした。この状態が一時的なものなのか永続的なものなのかをユーザーに伝える情報はありません。サーバーが状況を認識している場合は、410 ステータス コードを使用して、内部構成メカニズムの問題により古いリソースが永続的に利用できず、ジャンプ アドレスがないことを通知する必要があります。 404 ステータス コードは、サーバーがリクエストが拒否された理由を明らかにしたくない場合、または他の適切な応答が利用できない場合に広く使用されます。 405 メソッドが許可されていません (メソッドが無効です) リクエスト ラインで指定されたリクエスト メソッドを使用して、対応するリソースをリクエストすることはできません。応答は、現在のリソースが受け入れることができるリクエスト メソッドのリストを示す、Allow ヘッダー情報を返す必要があります。 PUT メソッドと DELETE メソッドはサーバーにリソースを書き込むため、ほとんどの Web サーバーはデフォルト設定では上記のリクエスト メソッドをサポートしていないか許可しておらず、そのようなリクエストに対して 405 エラーが返されます。 406 Not Acceptable (Not Acceptable) 要求されたリソースのコンテンツ特性がリクエスト ヘッダーの条件を満たすことができないため、応答エンティティを生成できません。これが HEAD リクエストでない限り、応答は、ユーザーまたはブラウザが最も適切なものを選択できるエンティティ属性とアドレスのリストを含むエンティティを返す必要があります。エンティティの形式は、Content-Type ヘッダーで定義されたメディア タイプによって決まります。ブラウザは、形式とその機能に基づいて独自の最適な選択を行うことができます。ただし、仕様では、そのような自動選択を行うための基準は定義されていません。 407 プロキシ認証が必要ですは、クライアントがプロキシ サーバーで認証する必要があることを除いて、401 応答と似ています。プロキシ サーバーは、ID クエリに対して Proxy-Authenticate を返す必要があります。クライアントは検証のために Proxy-Authorization ヘッダーを返すことができます。 RFC 2617 を参照してください。 408 リクエスト タイムアウト リクエストのタイムアウト。クライアントは、サーバーが待機する準備ができている時間内にリクエストの送信を完了しませんでした。クライアントは、変更を加えることなく、いつでもこのリクエストを再送信できます。 409 競合 要求されたリソースの現在の状態と競合するため、要求を完了できません。このコードは、ユーザーが競合を解決して新しいリクエストを再送信できると思われる場合にのみ使用してください。応答には、ユーザーが競合の原因を発見するのに十分な情報が含まれている必要があります。競合は通常、PUT リクエストの処理中に発生します。たとえば、バージョン チェックを使用する環境では、PUT によって送信された特定のリソースの変更リクエストに添付されたバージョン情報が以前の (サードパーティの) リクエストと競合する場合、サーバーはこの時点で 409 エラーを返す必要があります。リクエストを完了できないことをユーザーに通知します。現時点では、ユーザーがマージ後に新しいバージョンを再送信できるように、応答エンティティには競合する 2 つのバージョン間の相違点の比較が含まれる可能性があります。 410 Gone (削除) 要求されたリソースはサーバー上で利用できなくなり、既知の転送アドレスがありません。このような状況は永続的であると考えるべきです。可能であれば、リンク編集機能を持つクライアントは、ユーザーの許可を得て、このアドレスへのすべての参照を削除する必要があります。サーバーが状態が永続的であるかどうかを知らない、または判断できない場合は、404 ステータス コードを使用する必要があります。特に明記されていない限り、この応答はキャッシュ可能です。 410 応答の目的は主に、Web サイト管理者が Web サイトを維持し、リソースが利用できなくなったことをユーザーに通知し、サーバー所有者はこのリソースを指すすべてのリモート接続も削除されることを望んでいることを支援することです。この種のインシデントは、期間限定の付加価値サービスでよく見られます。同様に、410 応答は、もともと個人に属していたリソースが現在のサーバー サイトで利用できなくなったことをクライアントに通知するためにも使用されます。もちろん、永久に利用できないすべてのリソースに「410 Gone」のマークを付ける必要があるかどうか、またこのマークをどのくらいの期間維持する必要があるかは、完全にサーバー所有者次第です。 411 Length Required (有効な長さが必要) サーバーは、Content-Length ヘッダーを定義せずに要求の受け入れを拒否しました。リクエスト メッセージ本文の長さを示す有効な Content-Length ヘッダーを追加した後、クライアントはリクエストを再度送信できます。 412 Precondition Failed サーバーは、リクエストのヘッダー フィールドで指定された 1 つ以上の前提条件を検証する際に満たすことができませんでした。このステータス コードを使用すると、クライアントはリソースを取得するときにリクエストのメタ情報 (リクエスト ヘッダー フィールドのデータ) に前提条件を設定できるため、リクエスト メソッドが予期したもの以外のリソースに適用されるのを防ぐことができます。 413 リクエスト エンティティが大きすぎます (リクエスト エンティティが大きすぎます) リクエストによって送信されたエンティティ データのサイズが、サーバーが処理できる範囲を超えているため、サーバーは現在のリクエストの処理を拒否しました。この場合、サーバーは接続を閉じて、クライアントがこのリクエストを送信し続けるのを防ぐことができます。状況が一時的な場合、サーバーは Retry-After 応答ヘッダーを返し、クライアントに再試行できる時間を通知する必要があります。 414 Request-URI Too Long (要求された URI が長すぎます) 要求された URI の長さがサーバーが解釈できる長さを超えているため、サーバーは要求の処理を拒否します。これは比較的まれな状況です。

POST メソッドを使用するはずだったフォーム送信が GET メソッドになり、クエリ文字列 (Query String) が長すぎます。

リダイレクト URI の「ブラック ホール」。たとえば、各リダイレクトで古い URI が新しい URI の一部として使用されるため、数回のリダイレクト後に過度に長い URI が生成されます。

クライアントは、一部のサーバーに存在するセキュリティの脆弱性を悪用してサーバーを攻撃しようとしています。このタイプのサーバーは、リクエストされた URI の読み取りまたは操作に固定長のバッファを使用します。GET 後のパラメータが特定の値を超えると、バッファ オーバーフローが発生し、任意のコードが実行される可能性があります。このような脆弱性がないサーバーは 414 ステータス コードを返すはずです。

415 サポートされていないメディア タイプ (サポートされていないメディア タイプ) 現在リクエストされたメソッドおよびリクエストされたリソースでは、リクエストで送信されたエンティティはサーバーでサポートされている形式ではないため、リクエストは拒否されます。 416 Requested Range Not Satisfiable (要求された範囲が要件を満たしていません) リクエストに Range リクエスト ヘッダーが含まれており、Range で指定されたデータ範囲が現在のリソースの使用可能な範囲と一致しない場合、および If-Range リクエストヘッダーがリクエストで定義されていない場合、サーバーは 416 ステータス コードを返す必要があります。 Range でバイト範囲を使用する場合、この状況は、リクエストで指定されたすべてのデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを意味します。サーバーには、416 ステータス コードを返すときに現在のリソースの長さを示す Content-Range エンティティ ヘッダーも含める必要があります。この応答では、Content-Type として multipart/byterange を使用することも禁止されています。 417 Expectation Failed (期待が満たされません) リクエスト ヘッダーで指定された期待された内容がサーバーによって満たされない、またはサーバーがプロキシ サーバーであるため、Expect の内容が次のノードで満たされないという明らかな証拠があります。現在のルートは満足です。 418 I'm a teapot このオペコードは、1998 年に IETF によって伝統的なエイプリル フールのジョークとして RFC 2324 ハイパーテキスト コーヒー ポット コントロール プロトコルで定義されたもので、実際の HTTP サーバーで定義する必要はありません。 421 インターネット アドレスからの接続が多すぎます 現在のクライアントの IP アドレスからサーバーへの接続数が、サーバーの最大許容範囲を超えています。通常、ここでの IP アドレスは、サーバーから見たクライアント アドレス (ユーザーのゲートウェイやプロキシ サーバーのアドレスなど) を指します。この場合、接続数には複数のエンド ユーザーが関与する可能性があります。 422 Unprocessable Entity リクエストの形式は正しいですが、セマンティック エラーのため応答できません。 (RFC 4918 WebDAV) 423 Locked 現在のリソースはロックされています。 (RFC 4918 WebDAV) 424 依存関係の失敗 現在のリクエストは、PROPPATCH など、前のリクエストのエラーにより失敗しました。 (RFC 4918 WebDAV) 425 順序付けされていないコレクションは、WebDav Advanced Collections ドラフトで定義されていますが、「WebDAV Sequential Collection Protocol」(RFC 3658) には記載されていません。 426 アップグレードが必要です クライアントは TLS/1.0 に切り替える必要があります。 (RFC 2817) 449 Retry With は Microsoft によって拡張され、適切な操作を実行した後に要求を再試行する必要があることを示します。

5xx サーバー エラー

このタイプのステータス コードは、リクエストの処理中にサーバーにエラーまたは異常な状態があることを表します。また、サーバーが現在のソフトウェアとハ​​ードウェアではリクエストの処理を完了できないことを認識している可能性もあります。リソース。これが HEAD リクエストでない限り、サーバーは現在のエラーステータスと、その状態が一時的であるか永続的であるかの説明を含めるべきです(SHOULD)。ブラウザは、ユーザーへの現在の応答に含まれるエンティティを表示する必要があります (SHOULD)。

これらのステータス コードは、あらゆる応答メソッドに適用されます。

500 Internal Server Error (サーバー内部エラー) サーバーで予期しない状況が発生し、リクエストの処理を完了できませんでした。一般に、この問題はサーバーのプログラム コードにエラーがある場合に発生します。 501 Not Implemented (未実装) サーバーは、現在のリクエストで必要な機能をサポートしていません。サーバーが要求されたメソッドを認識せず、リソースに対するその要求をサポートできない場合。 502 Bad Gateway ゲートウェイまたはプロキシとして動作しているサーバーが、リクエストを実行しようとしたときに、上流のサーバーから無効な応答を受け取りました。 503 Service Unavailable (サービスを利用できません) 一時的なサーバーのメンテナンスまたは過負荷のため、サーバーは現在リクエストを処理できません。この状態は一時的なもので、一定時間が経過すると元に戻ります。遅延時間が予想される場合、応答には遅延時間を示す Retry-After ヘッダーを含めることができます。この Retry-After メッセージが与えられない場合、クライアントは 500 応答を処理するのと同じ方法でそれを処理すべきです (SHOULD)。 504 ゲートウェイ タイムアウト (ゲートウェイ タイムアウト) ゲートウェイまたはプロキシとして機能するサーバーがリクエストを実行しようとすると、上流サーバー (HTTP、FTP、LDAP などの URI によって識別されるサーバー) からの応答を時間内に受信できません。または補助サーバー (DNS など)。注: 一部のプロキシ サーバーは、DNS クエリがタイムアウトすると 400 または 500 エラーを返します。 505 HTTP バージョンがサポートされていません サーバーは、リクエストで使用されている HTTP バージョンをサポートしていないか、サポートを拒否しています。これは、サーバーがクライアントと同じバージョンを使用できない、または使用したくないことを意味します。応答には、そのバージョンがサポートされない理由とサーバーがサポートするプロトコルを説明するエンティティが含まれている必要があります。 506 バリアント またネゴシエートは、透過的コンテンツ ネゴシエーション プロトコル (RFC 2295) によって拡張され、サーバーの内部構成エラーを表します。要求されたネゴシエーション変数リソースは、透過的コンテンツ ネゴシエーションでそれ自体を使用するように構成されているため、適切なネゴシエーション プロセスではありません。集中。 507 ストレージが不十分です サーバーは、リクエストを完了するために必要なコンテンツを保存できません。この状態は一時的なものと考えられます。 (WebDAV RFC 4918) 509 帯域幅制限を超えました サーバーが帯域幅制限に達しました。これは正式なステータス コードではありませんが、依然として広く使用されています。 510 Not Extended リソースを取得するために必要なポリシーが満たされていません。 (RFC 2774)