オンラインツール
HTTPステータスコードステータスコード 意味
100クライアントはリクエストを送信し続ける必要があります。この一時的な応答は、リクエストの一部がサーバーによって受信され、拒否されていないことをクライアントに通知するために使用されます。クライアントはリクエストの残りの部分を送信し続けるか、リクエストが完了した場合はこの応答を無視する必要があります。リクエストが完了したら、サーバーはクライアントに最終応答を送らな ければならない。
101サーバーはクライアントのリクエスト を理解したので、リクエストを完了するために別のプロトコルを使うように Upgradeメッセージヘッダでクライアントに通知する。この応答の最後の空行を送信した後、サーバーはUpgradeメッセージヘッダー で定義されているプロトコルに切り替える。これは、新しいプロトコルに切り替えた方が有益な場合にのみ実行され るべきである。例えば、古いバージョンよりも新しいバージョンの HTTP に切り替えた方が有利な場合や、リアルタイムかつ同期的なプロトコルに切り替えて、そのような機能を利用したリソースを配信する場合などです。
102WebDAV (RFC 2518) によって拡張されたステータスコードは、処理が継続することを表します。
200リクエストは成功し、リクエストによって要求されたレスポンスヘッダまたはデータボディがこのレスポンスで返されます。
201リクエストが満たされ、リクエストで要求された新しいリソースが生成され、 そのURIがLocationヘッダーとともに返された。要求されたリソースの作成が間に合わない場合、「202 Accepted」が返されるべ きである。
202サーバーはリクエストを受け入れたが、まだ処理していない。拒否されるかもしれないのと同じように、最終的にリクエストは実行される かもしれないし、実行されないかもしれない。非同期操作の文脈では、このステータスコードを送るほど便利なものはない。202ステータスコードで応答を返す目的は、バッチ操作が完全に完了するまでクライアントをサーバーに接続し続けなくても、サーバーが他のプロセスからのリクエスト(例えば、1日に1回だけ実行されるバッチベースの操作など)を受け入れられるようにすることである。処理のリクエストを受け入れ、202ステータスコードを返す応答は、返される エンティティに、処理の現在の状態を示す情報と、処理が完了したかどうかをユー ザーが推測できるように、処理ステータスモニターまたはステータス予測へのポインタを 含むべきである[SHOULD]。
203サーバーはリクエストの処理に成功したが、返されたエンティティヘッダー のメタ情報は、オリジナルサーバー上で有効な確定セットではなく、ローカルま たはサードパーティからのコピーである。現在の情報はオリジナルバージョンのサブセットまたはスーパーセット であるかもしれない。例えば、リソースを含むメタデータは、元のサーバーにメタ情報のスーパーを知らせるかもしれない。このステータスコードの使用は必須ではなく、このステータスコードがなければ応答が200 OKを返していた場合にのみ適切である。
204サーバーはリクエストを正常に処理したが、物理的なコンテンツを返す必 要はなく、更新されたメタ情報を返したい。応答は新規または更新されたメタ情報を、エンティティヘッダーの形で返すかもしれない。そのようなヘッダーが存在する場合、それらはリクエストされた変数に 対応すべきである。クライアントがブラウザの場合、仕様によると新しいまたは更新されたメタ情 報は、ユーザーのブラウザのアクティブビューのドキュメントに適用されるべきで ある[SHOULD]が、ユーザーのブラウザは、ドキュメントビューを変更すること なく、リクエストが送られたページを保持するべきである[SHOULD]。204応答はいかなるメッセージボディも含むことが禁止されているので、常にメッ セージヘッダの後の最初の空行で終わる。
205サーバーはリクエストを正常に処理し、何も返さない。しかしながら、204応答とは異なり、このステータスコードを返す応答は、 リクエスト元にドキュメントビューのリセットを要求する。このレスポンスは主に、ユーザー入力を受け付けた直後にフォームをリセットし、ユーザーが簡単に別の入力を開始できるようにするために使用される。204応答のように、この応答はメッセージボディを含むことを禁じられ、メッセージヘッダの後の最初の空行で終わる。
206サーバーはGETリクエストの一部を正常に処理した。FlashGetやThunderboltのようなHTTPダウンロードツールは、断続的なダウンロードを実行したり、大きなドキュメントを同時に複数のダウンロードセグメントに分割したりするために、このタイプのレスポンスを使用する。リクエストは、クライアントが受け取りたいコンテンツの範囲を示すRangeヘッダーを含まなければならず、リクエスト条件としてIf-Rangeを含むことができる。Content-Typeがmultipart/byterangesのマルチセグメントダウンロードの場 合、各マルチパートセグメントは、そのセグメントのコンテンツの範囲を示 すContent-Rangeフィールドを含むべきである。応答がContent-Lengthを含む場合、その値は、それが返すコンテンツ範囲の本当のバイト数と一致しなければならない。 日付 ETagおよび/またはContent-Location、同じリクエストが200応答を返すべきだった場合。 Expires、Cache-Control、および/またはVary、それらの値が同じ変数を持つ他の応答と異なる可能性がある場合。Expires、Cache-Control、および(または)Varyの値が、同じ変数に対す る以前の他の応答の値と異なる可能性がある場合。リクエストがIf-Rangeの強いキャッシュ検証を使用している場合、この 応答は他のエンティティヘッダを含むべきではない[SHOULD NOT]。また、 リクエストがIf-Rangeの弱いキャッシュ検証を使用している場合、この 応答は他のエンティティヘッダを含むべきではない[SHOULD NOT]。そうでなければ、この応答は、返されるべきであったすべての200 応答で返されるべきであったすべてのエンティティヘッダーフィールドを含むべ きである[SHOULD]。ETagヘッダーまたはLast-Modifiedヘッダーが正確に一致しない場合、クライアント サイドのキャッシュは、応答206で返されるコンテンツを以前にキャッシュされ ていたコンテンツと組み合わせることを禁止するべきである[SHOULD]。RangeヘッダーとContent-Rangeヘッダーをサポートしないキャッシュは、206応答で返されたコンテンツをキャッシュすることを禁止される。
207WebDAV (RFC 2518)によって拡張されたこのステータスコードは、後続のメッセージボディがXMLメッセージになることを意味し、以前のサブリクエストの数に応じて一連の個別の応答コードを含むかもしれない。
300要求されたリソースは、それぞれ固有のアドレスとブラウザ主導のネゴシエーション情報を持つ、一連の代替リターンメッセージを持ちます。ユーザーまたはブラウザは、自分でリダイレクトのための優先アドレスを 選択することができる。これがHEADリクエストでない限り、応答はリソースの特性とアドレスの 一覧であるエンティティを含むべきである。このエンティティの書式はContent-Type定義の書式によって決定される。ブラウザは応答のフォーマットとブラウザ自身の能力に基づいて、自動的に最も適切な選択を行うかもしれない。もちろん、RFC2616の仕様では、そのような自動的な選択がどのように行われるべきかは規定されていない。サーバー自身がすでに優先する返り値の選択を持っている場合、この返り値の 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リクエストでない場合、リクエストの条件が結果として変 わるかもしれないので、ユーザーが確認しない限り、ブラウザが自動的にリダイレ クトすることは禁止されている。注意: RFC1945とRFC2068の仕様では、クライアントがリダイレクト時に リクエストのメソッドを変更することを許可していないが、多くの既存 のブラウザは302応答を303応答として扱い、元のリクエストのメソッドを 無視して、Locationで指定されたURIにアクセスするためにGETを使用する。ステータスコード303と307は、サーバーがクライアントに期待する 応答を明確にするために追加された。
303現在のリクエストに対する応答は別のURIで見つけることができるので、クライアントはGETを使ってそのリソースにアクセスするべきである。このメソッドは主に、スクリプトによって活性化されたPOSTリクエストの出力を新しいリソースにリダイレクトできるようにするために存在します。この新しいURIは元のリソースの代替参照ではない。また、303応答はキャッシュされることが禁止されています。もちろん、2番目のリクエスト(リダイレクト)はキャッシュされるかもしれません。新しいURIは応答のLocationフィールドで返されるべきである。これがHEADリクエストでない限り、応答エンティティは新しいURIへのハイパーリンクと短い説明を含むべきである。注意: HTTP/1.1バージョンより前の多くのブラウザは、303ステートを正しく理解しない。これらのブラウザとのやりとりを考慮する必要がある場合、302 ステータスコードでうまくいくはずです。なぜなら、ほとんどのブラウザは、上記の仕様がクライアントに 303 応答を処理するように要求しているのとまったく同じ方法で 302 応答を処理するからです。
304クライアントが許可された条件付きGETリクエストを送り、ドキュメントのコンテン ツが(最後に訪れたときから、またはリクエストの条件に従って)変更されていな い場合、サーバーはこのステータスコードを返すべきである[SHOULD]。304応答はメッセー ジボディを含むことを禁止されているので、常にメッセージヘッダの後の 最初の空行で終わる。応答は以下のヘッダーを含まなければならない[MUST]: 日付(サーバーが時計を持っていない場合を除く)。Date(サーバーに時計がない場合を除く)。時計を持たないサーバーがこのルールに 従う場合、プロキシサーバーとクライアントは(RFC2068で規定されている ように)独自に受信応答ヘッダーにDateフィールドを追加することができ、 キャッシュの仕組みは正しく動作する。Expires、Cache-Control、および/またはVary、値が同じ変数に対する他の以前の応答に対応する値と異なる可能性がある場合。この応答リクエストが強いキャッシュ検証を使用する場合、この応答は 他のエンティティヘッダを含むべきではない。そうでない場合(例えば、条件付きGET リクエストが弱いキャッシュ検証を使用する場合)、この応答は他のエンティティ ヘッダを含むことを禁止される。これは、キャッシュされたエンティティコンテン ツと更新されたエンティティヘッダ情報との間の矛盾を避けるためである。304応答が、あるエンティティが現在キャッシュされていないことを示す場合、キャッシングシステムはその応答を無視し、制限なしでリクエストを繰り返さなければならない。キャッシュエントリを更新することを要求する304応答を受け取った場合、キャッシングシステムは、応答で更新されたすべてのフィールドの値を反映するためにエントリ全体を更新しなければならない[MUST]。
305リクエストされたリソースは指定されたプロキシを通してアクセス されなければならない。Locationフィールドは、指定されたプロキシがある URIについての情報を与える。元のサーバーだけが305応答を作成できる。注意: 305応答が一つのリクエストをリダイレクトするためのものであり、オ リジナルサーバーだけが構築できるということは、RFC2068では明 確ではない。これらの制限を無視することは、重大なセキュリティー上の結 果につながる可能性がある。
306仕様の最新バージョンでは、306ステータスコードはもはや使用されない。
307リクエストされたリソースは一時的に別のURIからリクエストに 応答するようになった。このようなリダイレクトは一時的なものなので、クライアン トは今後のリクエストを元のアドレスに送り続けるべきである。この応答は、Cache-ControlまたはExpiresで指定されている場合にのみ キャッシュ可能である。新しい一時的なURIは応答のLocationフィールドで返されるべきである。これがHEADリクエストでない限り、応答エンティ ティは新しいURIへのハイパーリンクと短い説明を含むべきである。一部のブラウザは307応答を認識しないので、ユーザーが新しいURIへの アクセスを理解し要求できるように、上記の情報を追加する必要がある。これがGETまたはHEADリクエストでない場合、リクエストの条件が変わるかもしれないので、ブラウザはユーザーが確認しない限り、自動的なリダイレクトを禁止する。
4001.セマンティックエラーがあり、サーバーが現在のリクエストを理解できな い。修正されない限り、クライアントはこのリクエストを繰り返し送信してはならない。 2、リクエストパラメータが間違っている。
401現在のリクエストにはユーザー認証が必要です。応答は、ユーザー情報を要求するために、要求されたリソースのWWW-Authenticateヘッダーを含んでいなければならない。クライアントは、適切なAuthorisationヘッダー情報を含むリクエストを繰り返し 提出できる。現在のリクエストがすでにAuthorisationの信用証明書を含んでいる場合、 401応答は、サーバーがそれらの信用証明書が拒否されたことを検証する ことを意味する。401応答が前の応答と同じ認証クエリを含み、ブラウザがすでに少なくとも一度は 認証を試みている場合、ブラウザは応答に含まれるエンティティ情報をユーザーに 提示するべきである[SHOULD]。RFC2617を参照のこと。
402このステータスコードは将来の要求のために予約されている。
403サーバーはリクエストを理解したが、その実行を拒否した。401応答とは異なり、認証は何の助けにもならないので、このリクエス トは再送されるべきではない。これがHEADリクエストでなく、サーバーがリクエストを実行できない理由を明 確に語れるようにしたい場合、拒否の理由はエンティティ中に記述されるべ きである。もちろん、クライアントに情報を与えたくない場合、サーバーは404 応答を返すこともできる。
404リクエストは失敗しました。リクエストされたリソースはサーバーに見つかりませんでした。その状況が一時的なものなのか永続的なものなのかをユーザーに伝える情報はありません。サーバーがこの状況を認識している場合は、410ステータスコードを使って、古いリソースが内部設定の仕組みによって永久に利用できないこと、および利用可能なリダイレクトがないことをユーザーに通知する必要があります。404は、サーバーがリクエストが拒否された理由を明らかにしたくない場合や、他に適切な応答がない場合に広く使われます。
405リクエスト行で指定されたリクエストメソッドは、対応するリソースを リクエストするために使用できない。応答は、現在のリソースで受け入れ可能なリクエストメソッドのリストを示す Allowヘッダーを返さなければならない。PUTメソッドとDELETEメソッドがサーバー上のリソースに書き込むことを考えると、ほとんどのWebサーバーはこれらのリクエストメソッドをサポートしていないか、デフォルトで許可していないので、そのようなリクエストに対しては405エラーを返します。
406リクエストされたリソースのコンテンツ特性はリクエストヘッダの条件を 満たさず、応答エンティティは生成できない。これがHEADリクエストでない限り、応答はエンティティの特性と アドレスのリストを含むエンティティを返すべきである。エンティティの形式は、Content-Typeヘッダーで定義されるメディア タイプによって決定される。ブラウザは、フォーマットと自身の能力に基づいて、独自の最適な選択を行うことができる。しかし、この仕様では、そのような自動的な選択を行うための基準は定義されていない。
407クライアントがプロキシサーバーで認証しなければならない[MUST]ことを除けば、 401応答と似ている。プロキシサーバーはアイデンティティの問い合わせのためにProxy-Authenticate を返さなければならない[MUST]。クライアントは認証のためにProxy-Authorizationヘッダーを返 してもよい[MAY]。RFC 2617を参照のこと。
408リクエストタイムアウト。クライアントが、サーバーが待機するために用意した時間内にリク エストの送信を完了しなかった。クライアントは変更を加えずにいつでもリクエストを再送してもよい。
409リクエストされたリソースの現在の状態と衝突したため、リクエストを完了できませんでした。このコードは、ユーザーが競合を解決して新しいリクエストを再送信でき ると判断された場合にのみ使用が許可される。応答は、ユーザーが競合の原因を発見するのに十分な情報を含むべきである。コンフリクトは通常PUTリクエストの処理で起こる。例えば、バージョンチェック環境では、特定のリソースを修正するために 提出されたPUTに添付されたバージョン情報が、以前の(サードパーティの) リクエストと衝突する場合、サーバーはリクエストを完了できなかったことをユーザーに 通知する409エラーを返すべきである。この場合、応答エンティティは、ユーザーがマージ後に新しいバージョンを再送信できるように、競合する2つのバージョン間の差分の比較を含む可能性が高い。
410要求されたリソースはサーバー上で利用できなくなり、既知の転送先アドレスもない。このような状態は永久的なものと考えるべきである。可能であれば、リンク編集機能を持つクライアントは、ユーザーの許可を得て、このアドレスへの参照をすべて削除すべきである。サーバーがこの状態が永続的であるかどうかを知らないか、判断できない場合は、404ステータスコードを使用すべきである。410 このレスポンスの目的は主に、リソースが利用できなくなったこと、およびサーバー所有者がこのリソースへのすべてのリモート接続も削除することを望んでいることをユーザーに通知することで、ウェブマスターがサイトを維持するのを支援することです。この種のイベントは、時間制限のある付加価値サービスによく見られます。同様に、410 レスポンスは、現在のサーバーサイトのある個人に属していたリソースが利用できなくなったことをクライアントに通知するために使用されます。もちろん、永久に利用できないリソースをすべて「410 Gone」とマークする必要があるかどうか、またこのマークをどのくらいの期間維持する必要があるかは、すべてサーバーの所有者次第です。
411サーバーは、Content-Lengthヘッダーが定義されていないリクエストを 受け付けない。リクエストメッセージボディの長さを示す有効なContent-Lengthヘッダーを追加した後、クライアントはリクエストを再送することができる。
412サーバーは、リクエストのヘッダーフィールドで与えられた前提条件を 検証するときに、1つ以上の前提条件を満たすことができなかった。このステータスコードによって、クライアントはリソースを取得するときにリクエストのメタメッセージ(リクエストヘッダーフィールドデータ)に前提条件を設定することができ、その結果、リクエストメソッドが希望するコンテンツ以外のリソースに適用されることを防ぐことができる。
413サーバーが現在のリクエストの処理を拒否した。その理由は、サーバーが処理する意思または能力を超えるサイズのエンティティデータが送信されたからである。この場合、サーバはクライアントがこのリクエストを送信し続けないように、コネクションを閉じるかもしれない。この状態が一時的なものである場合、サーバーはクライアントに再試行可能な 時間を知らせるためにRetry-After応答ヘッダーを返すべきである。
414リクエストのURIの長さがサーバーが解釈できる長さを超えたので、 サーバーはリクエストの処理を拒否した。これはまれなケースで、POSTメソッドを使うべきフォーム送信がGETメソッドになり、結果的に長いQuery Stringになった場合によく起こります。リダイレクトのたびに古い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 Sequential Collections Protocol (RFC 3658) にはありません。
426クライアントは TLS/1.0 に切り替えるべきである(RFC 2817)。
449マイクロソフトによって拡張され、適切なアクションが実行された後にリクエストを再試行することを表す。
500サーバーがリクエストの処理を完了できない予期せぬ状況に遭遇した。通常、この問題はサーバーのプログラムコードにエラーがある場合に発生します。
501サーバーが、現在のリクエストに必要な特定の機能をサポートしていない。サーバーがリクエストされたメソッドを認識できず、いかなるリソースに対するリクエストもサポートできない場合。
502ゲートウェイまたはプロキシとして動作するサーバーが、リクエストを実行しようとしたときに、上流のサーバーから無効な応答を受信した場合。
503一時的なサーバーのメンテナンスまたは過負荷のため、サーバーは現在リクエストを処理できません。この状態は一時的なもので、しばらくすると回復します。遅延が予想される場合、応答は遅延を示すためにRetry-Afterヘッダーを 含むかもしれない。このRetry-After情報が与えられない場合、クライアントは500 応答と同じようにそれを扱うべきである。注意: 503ステータスコードが存在するということは、サーバーが過負荷の場合に それを使わなければならないということではない。単にクライアントの接続を拒否したいだけのサーバもあります。
504リクエストを実行しようとするゲートウェイまたはプロキシとして動作しているサーバーが、アップストリームサーバー(HTTP、FTP、LDAPなどのURIで識別されるサーバー)またはセカンダリサーバー(DNSなど)からのタイムリーな応答を受け取れなかった場合。注：DNSルックアップがタイムアウトすると、400または500エラーを返すプロキシサーバーもあります。
505サーバはリクエストで使われたHTTPのバージョンをサポートしていないか、サポートを拒否しています。これは、サーバーがクライアントと同じバージョンを使えないか、使いたがらないことを意味する。レスポンスには、そのバージョンがサポートされていない理由と、サーバがどのプロトコルをサポートしているかを記述したエンティティが含まれるべきです。
506透過的コンテンツネゴシエーションプロトコル(Transparent Content Negotiation Protocol: RFC 2295)によって拡張された、サーバー側の内部的な設定ミスを表すもの: リクエストされた Negotiation Variant リソースは透過的コンテンツネゴシエーションでそれ自身を使用するように設定されているため、ネゴシエーションプロセスでは適切なフォーカスではない。
507サーバーはリクエストを完了するために必要なコンテンツを保存できない。この状態は一時的なものとみなされる。WebDAV (RFC 4918)
509サーバーが帯域幅の上限に達した。これは公式のステータスコードではないが、まだ広く使われている。
510リソースを取得するために必要なポリシーが満たされていない。(RFC 2774)
アクセスログ

オンラインツールコレクション