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サーバーはリクエストを正常に処理しましたが、エンティティ コンテンツを返す必要はなく、更新されたメタ情報を返すことを期待しています。応答は、新しいメタ情報または更新されたメタ情報をエンティティ ヘッダーの形式で返す場合があります。これらのヘッダーが存在する場合は、要求された変数に対応する必要があります。クライアントがブラウザーである場合、ユーザーのブラウザーは、ドキュメント ビューを変更せずに、要求を送信したページを保持する必要があります。ただし、新しいメタ情報または更新されたメタ情報は、ドキュメント ビューの仕様に従ってユーザーのブラウザー アクティビティに適用する必要があります。204 応答にはメッセージ本文を含めることが禁止されているため、常にヘッダーの後の最初の空行で終了します。
205サーバーはリクエストを正常に処理し、何も返しませんでした。ただし、204 応答とは異なり、このステータス コードを返す応答では、リクエスターがドキュメント ビューをリセットする必要があります。この応答は主に、ユーザー入力を受け入れた直後にフォームをリセットして、ユーザーが別の入力を簡単に開始できるようにするために使用されます。204 応答と同様に、この応答にもメッセージ本文を含めることは禁止されており、メッセージ ヘッダーの後の最初の空白行で終了します。
206サーバーは部分的な GET 要求を正常に処理しました。FlashGet や Xunlei などの HTTP ダウンロード ツールは、このタイプの応答を使用して、ダウンロードを再開したり、大きなファイルを複数のダウンロード セグメントに分割して同時ダウンロードしたりします。要求には、クライアントが期待するコンテンツの範囲を示す Range ヘッダー情報が含まれている必要があり、要求条件として If-Range が含まれる場合があります。応答には、次のヘッダー フィールドが含まれている必要があります: Content-Range は、この応答で返されるコンテンツの範囲を示すために使用されます; マルチパート/バイト範囲として Content-Type を持つマルチパート ダウンロードの場合、各マルチパート パートには Content- が含まれている必要があります。範囲ドメインは、この段落の内容範囲を示すために使用されます。Content-Length が応答に含まれる場合、その値は content-range に対して返される実際のバイト数と一致する必要があります。Date ETag および/または Content-Location (同じ要求が 200 応答を返す必要がある場合)。Expires、Cache-Control、および/または Vary の値が、同じ変数に対する以前の応答と異なる場合があります。この応答要求が If-Range の強力なキャッシュ検証を使用する場合、この応答に他のエンティティ ヘッダーを含めないでください。この応答要求が If-Range の弱いキャッシュ検証を使用する場合、この応答に他のエンティティ ヘッダーを含めることは禁止されています。これにより、キャッシュされたエンティティ コンテンツと更新されたエンティティ ヘッダー情報が解決されます。それ以外の場合、この応答には、200 応答で返される必要があるすべてのエンティティ ヘッダー フィールドが含まれている必要があります。ETag または Last-Modified ヘッダーが正確に一致しない場合、クライアント キャッシュは、206 応答によって返されたコンテンツを以前にキャッシュされたコンテンツと組み合わせることを禁止する必要があります。Range ヘッダーと Content-Range ヘッダーをサポートしないキャッシュは、206 応答によって返されるコンテンツをキャッシュすることが禁止されています。
207WebDAV (RFC 2518) によって拡張されたステータス コードは、後続のメッセージ ボディが XML メッセージになることを意味し、以前のサブ要求の数に応じて、一連の独立した応答コードが含まれる場合があります。
300要求されているリソースには、一連のオプションの戻り情報があり、それぞれに固有のアドレスとブラウザー主導のネゴシエーション情報があります。ユーザーまたはブラウザは、リダイレクト用の優先アドレスを選択できます。これが HEAD リクエストでない限り、レスポンスには、ユーザーまたはブラウザが最も適切なリダイレクト アドレスを選択できるリソース プロパティとアドレスのリストを持つエンティティを含める必要があります。このエンティティの形式は、Content-Type で定義された形式によって決まります。ブラウザーは、応答の形式とブラウザー自体の機能に基づいて、最も適切な選択を自動的に行う場合があります。もちろん、RFC 2616 仕様では、そのような自動選択を実行する方法を指定していません。サーバー自体に優先フィードバック オプションがある場合、フィードバックの 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 にアクセスします。 、最初に要求されたメソッドに関係なく。サーバーがクライアントから期待する応答を指定するために、ステータス コード 303 および 307 が追加されました。
303現在のリクエストに対するレスポンスは別の URI で見つけることができ、クライアントは GET を使用してそのリソースにアクセスする必要があります。このメソッドは主に、スクリプトによってアクティブ化された POST 要求の出力を新しいリソースにリダイレクトできるようにするために存在します。この新しい URI は、元のリソースへの代替参照ではありません。同時に、303 応答をキャッシュしてはなりません。もちろん、2 番目の要求 (リダイレクト) はキャッシュされる可能性があります。新しい URI は、応答の Location フィールドで返される必要があります。これが HEAD 要求でない限り、応答の本文には、新しい URI へのハイパーリンクと短い説明を含める必要があります。注: HTTP/1.1 より前のブラウザの多くは、303 ステータスを正しく理解していません。これらのブラウザーとのやり取りを考慮する必要がある場合、302 ステータス コードは適切である必要があります。ほとんどのブラウザーが 302 応答を処理する方法は、上記の仕様で 303 応答を処理するときにクライアントが行う必要があることとまったく同じだからです。
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 リクエストでない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限り、ブラウザは自動リダイレクトを禁止します。
4001. セマンティクスが間違っていて、現在のリクエストをサーバーが理解できない。変更されない限り、クライアントはこのリクエストを再送信すべきではありません。2. リクエストパラメータが間違っています。
401現在のリクエストにはユーザー認証が必要です。応答には、要求されたリソースに適用可能な WWW-Authenticate ヘッダーを含めて、ユーザー情報を要求する必要があります。クライアントは、適切な Authorization ヘッダーを付けてリクエストを再送信できます (MAY)。現在の要求に認証証明書が既に含まれている場合、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/byteranges を使用することも禁止されています。
417要求ヘッダー Expect で指定された予期されるコンテンツがサーバーによって満たされていません。または、サーバーがプロキシ サーバーであり、現在のルートの次のノードで Expect のコンテンツが満たされないという明白な証拠があります。
421クライアントの現在の IP アドレスからサーバーへの接続数が、サーバーで許可されている最大範囲を超えています。通常、ここでの IP アドレスは、サーバーから見たクライアント アドレス (ユーザーのゲートウェイやプロキシ サーバーのアドレスなど) を指します。この場合、接続数の計算に複数のエンド ユーザーが関与する可能性があります。
422クライアントの現在の IP アドレスからサーバーへの接続数が、サーバーで許可されている最大範囲を超えています。通常、ここでの IP アドレスは、サーバーから見たクライアント アドレス (ユーザーのゲートウェイやプロキシ サーバーのアドレスなど) を指します。この場合、接続数の計算に複数のエンド ユーザーが関与する可能性があります。
422リクエストは整形式ですが、セマンティック エラーのため応答できません。(RFC 4918 WebDAV) 423 Locked 現在のリソースはロックされています。(RFC 4918 WebDAV)
424PROPPATCH などの前のリクエストのエラーが原因で、現在のリクエストが失敗しました。(RFC 4918 WebDAV)
425WebDav Advanced Collections ドラフトで定義されていますが、WebDAV Sequenced Collections 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)

オンライン ツール ナビゲーション