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