iToolify ツールボックス
Httpステータスコードステータスコードの意味
100クライアントは引き続き要求を送信しなければならない。この一時的な応答は、要求の一部がサーバに受信され、拒否されていないことをクライアントに通知するために使用されます。クライアントは要求の残りの部分を送信し続けるか、要求が完了した場合は、この応答を無視しなければならない。サーバは、要求が完了した後、クライアントに最終的な応答を送信する必要があります。
101サーバは、クライアントの要求を理解しており、クライアントに異なるプロトコルを使用して要求を完了するようにアップグレードメッセージを介して通知します。この応答の最後の空白行を送信すると、サーバはUpgradeメッセージ・ヘッダで定義されているプロトコルに切り替えます。新しいプロトコルを切り替えることがよりメリットがある場合にのみ、同様の措置を講じるべきである。たとえば、新しいHTTPバージョンへの切り替えは、古いバージョンよりもメリットがあるか、リアルタイムで同期されたプロトコルに切り替えて、このような機能を利用するリソースを転送します。
102WebDAV(RFC 2518) によって拡張されたステータスコードは、処理が継続されることを表しています。
200リクエストが成功しました。リクエストの所望のレスポンスヘッダまたはデータ体は、このレスポンスと共に返されます。
201要求はすでに実現されており、要求の必要に応じて新しいリソースが確立され、そのURIはすでにLocationヘッダ情報とともに返されている。必要な資源がすぐに確立できない場合は、「202 accepted」に戻る必要があります。
202サーバは要求を受け入れたが、まだ処理されていない。拒否される可能性があるように、最終的には要求が実行されない可能性があります。非同期操作の場合、このステータスコードを送信するよりも便利な方法はありません。202ステータスコードを返す応答の目的は、サーバが他のプロセスの要求 (例えば、1日に1回しか実行しないバッチベースの操作) を受け入れることを許可することであるバッチ操作がすべて完了するまで、クライアントがサーバに接続し続ける必要はありません。要求処理を受けて202ステータスコードを返す応答には、返されたエンティティに現在のステータスを処理することを示す情報と、ステータスモニタまたはステータス予測を処理するポインタが含まれていなければならない操作が完了したかどうかをユーザーが見積もることができます。
203サーバは要求を正常に処理したが、返された物理ヘッダのメタ情報は、元のサーバで有効な確定セットではなく、ローカルまたはサードパーティからのコピーである。現在の情報は、元のバージョンのサブセットまたはスーパーセットのいずれかです。たとえば、リソースを含むメタデータは、元のサーバがメタ情報のスーパーを知っている可能性があります。このステータスコードを使用することは必須ではなく、応答がこのステータスコードを使用しないと200 OKを返す場合にのみ適しています。
204サーバは要求を正常に処理したが、エンティティ・コンテンツを返す必要はなく、更新されたメタ情報を返すことを望んでいる。応答は、エンティティのヘッダの形で、新しいまたは更新されたメタ情報を返すことができます。これらのヘッダ情報が存在する場合、要求された変数に呼応しなければならない。クライアントがブラウザの場合、ユーザーのブラウザは、ドキュメントのビューを変更することなく、要求を送信したページを保持する必要があります仕様に基づいて新規または更新されたメタ情報は、ユーザーのブラウザのアクティビティビューのドキュメントに適用する必要があります。204応答はメッセージ本体を含めることが禁止されているため、常にメッセージヘッダの後の最初の空白行で終わる。
205サーバは要求を正常に処理し、何も返さなかった。しかし204応答とは异なり、このステータスコードを返す応答は、要求者にドキュメントのビューをリセットするように要求する。この応答は、主にユーザー入力を受け入れた直後にフォームをリセットして、ユーザーが別の入力を簡単に開始できるようにするために使用されます。204応答と同様に、この応答は、いかなるメッセージ本体を含むことも禁止され、メッセージヘッダの后の最初の空白行で终了する。
206サーバはGET要求の一部を正常に処理した。FlashGetや迅雷のようなHTTPダウンロードツールは、このような応答を使用してブレークポイントの継続を実現したり、大きな文書を複数のダウンロードセグメントに分解して同時にダウンロードしたりします。このリクエストには、クライアントが望むコンテンツの範囲を示すレンジヘッダー情報が含まれている必要があり、リクエスト条件としてIf-レンジヘッダーが含まれている可能性があります。応答には、今回の応答で返されたコンテンツの範囲を示すためのヘッダドメインが含まれている必要がありますContent-Typeがmultipart/byterangesの複数のダウンロードの場合各multipartセグメントには、このセグメントのコンテンツ範囲を示すContent-Rangeドメインが含まれている必要があります。応答にContent-Lengthが含まれている場合、その値は、返されたコンテンツ範囲の実際のバイト数と一致している必要があります。Date ETagやContent-Locationは、同じ要求が200応答を返すべきである。Expires、Cache-Control、および/またはVaryは、その値が以前と同じ変数の他の応答に対応する値と異なる可能性がある場合。本応答要求がIf-レンジエクステンションキャッシュ検証を使用している場合、今回の応答には他の実体ヘッダを含めるべきではない本応答の要求がIf-レンジエクステンションキャッシュ検証を使用している場合今回の応答では、他のエンティティヘッダを含めることは禁止されていますこれにより、キャッシュされたエンティティの内容と更新されたエンティティのヘッダ情報との不一致が回避されます。そうでない場合、本応答は、200応答のうち、返すべきすべての実体ヘッダドメインを含むべきである。ETagまたはLast-Modifiedヘッダが正確に一致しない場合、クライアントキャッシュは206応答から返されたコンテンツと以前にキャッシュされたコンテンツを組み合わせることを禁止する必要があります。RangeおよびContent-Rangeヘッダをサポートしていないキャッシュは、206応答から返されたコンテンツをキャッシュすることを禁止します。
207WebDAV(RFC 2518) によって拡張されたステータスコードは、その後のメッセージ・ボディがXMLメッセージであることを表し、以前のサブ要求数によっては、一連の独立した応答コードが含まれている可能性があります。
300要求された資源には一連のフィードバック情報があり、それぞれに自分の特定の住所とブラウザ主導の協議情報がある。ユーザーまたはブラウザは、優先アドレスを選択してリダイレクトすることができます。これがHEAD要求でない限り、応答には、ユーザーまたはブラウザが最適なリダイレクトアドレスを選択できるように、リソースの特性とアドレスのリストのエンティティが含まれている必要があります。このエンティティのフォーマットは、Content-Typeで定義されたフォーマットによって決まります。ブラウザは、応答のフォーマットとブラウザ自体の能力に応じて、自動的に最適な選択をすることができます。もちろん、このような自動選択をどのように行えば良いかというのは、rf2616仕様では規定されていません。サーバ自体に優先的なフィードバック選択がある場合は、LocationにこのフィードバックのURIを指定する必要がありますブラウザは、この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ステータスコードの応答と同様に扱い、元のリクエストメソッドに関係なく、Locationフィールドに指定されたURIに対してGETメソッドでアクセスします。ステータスコード303と307が追加され、サーバーがクライアントにどのような応答を求めているのかを明確にするようになりました。
303現在のリクエストに対するレスポンスは別のURIで見つけることができ、クライアントはそのリソースにGETメソッドを使ってアクセスする必要があります。このメソッドが存在する主な目的は、スクリプトによってトリガーされたPOSTリクエストの出力を新しいリソースへとリダイレクトできるようにすることです。この新しいURIは、元のリソースの代替となる参照ではありません。同時に、303応答はキャッシュされてはならない。もちろん、2つ目のリクエスト（リダイレクト）はキャッシュされる可能性があります。新しいURIは、レスポンスのLocationフィールドに返されるべきです。これがHEADリクエストでない限り、レスポンスの本文には、新しいURIへのハイパーリンクおよび簡潔な説明が含まれている必要があります。注意: HTTP/1.1以前の多くのブラウザーは、303ステータスコードを正しく解釈できません。これらのブラウザーとの相互作用を考慮する必要がある場合、302ステータスコードで十分に対応できます。なぜなら、ほとんどのブラウザーは302レスポンスを処理する際、前述の仕様でクライアントが303レスポンスを処理すべきとされている動作と同じ動作をするからです。
304クライアントが条件付きのGETリクエストを送信し、そのリクエストが許可されているにもかかわらず、ドキュメントの内容が（前回のアクセス以降またはリクエストの条件に基づいて）変更されていない場合、サーバーはこのステータスコードを返すべきです。304応答はメッセージ本文を含むことを禁じられているため、常にヘッダーの後に続く最初の空行で終了します。この応答には、以下のヘッダー情報が含まれている必要があります：Date。ただし、このサーバーに時計がない場合は除きます。時計を持たないサーバーもこれらのルールに従う場合、プロキシサーバーやクライアントは受信したレスポンスヘッダーにDateフィールドを自ら追加することが可能です（RFC 2068で規定されているとおりであり）、こうすることでキャッシュメカニズムは正常に動作します。ETagおよび/またはContent-Locationは、同じリクエストが本来は200ステータスコードのレスポンスを返すべきである場合に設定されます。Expires、Cache-Control、および/またはVaryは、その値が以前の同一ヘッダーを持つ別の応答の値と異なる可能性がある場合に設定する必要があります。この応答リクエストで強制キャッシュ検証が使用された場合、当該応答には他の実体ヘッダーを含めてはならない。それ以外の場合（例えば、条件付きのGETリクエストで弱いキャッシュ検証が使用された場合）にも、当該応答に他の実体ヘッダーを含めることは禁止されている。これは、キャッシュされた実体コンテンツと更新された実体ヘッダー情報との不整合を回避するためである。ある304応答が、現在のエンティティがキャッシュされていないことを示している場合、キャッシュシステムは当該応答を無視し、制約条件を含まないリクエストを再送しなければなりません。あるキャッシュエントリーの更新を求める304応答を受信した場合、キャッシュシステムは、応答内で更新されたすべてのフィールドの値を反映するよう、当該エントリー全体を更新しなければなりません。
305要求されたリソースは、指定されたエージェントを介してアクセスする必要があります。Locationドメインには、指定されたエージェントが存在するURI情報が表示されます。受信者は、適切なリソースにアクセスするために、個別の要求を繰り返し送信する必要があります。305応答を確立できるのは元のサーバだけです。注意: rf2068には、個別の要求をリダイレクトするための305応答がなく、元のサーバでのみ確立できます。これらの制限を無視すると、重大なセキュリティ結果を招く可能性があります。
306最新版の仕様では、306ステータスコードは使用されなくなりました。
307リクエストされたリソースは現在、一時的に別のURIから応答しています。このようなリダイレクトは一時的なものであるため、クライアントはその後のリクエストを引き続き元のアドレスに送信する必要があります。この応答がキャッシュ可能となるのは、Cache-ControlまたはExpiresで明示的に指定されている場合に限られます。新しい一時的なURIは、レスポンスのLocationフィールドに返されるべきです。これがHEADリクエストでない限り、レスポンスの本文には、新しいURIへのハイパーリンクおよび簡潔な説明が含まれている必要があります。一部のブラウザーは307応答を認識できないため、ユーザーがそれを理解し、新しいURIへアクセスリクエストを送信できるよう、上記の必須情報を追加する必要があります。これがGETまたはHEADリクエストでない場合、ブラウザはユーザーの確認を得ないかぎり自動的にリダイレクトを実行することを禁止しています。これは、リクエストの条件が変更される可能性があるためです。
4001.意味が間違っていて、現在の要求はサーバに理解されていない。変更しない限り、クライアントはこの要求を繰り返し提出してはならない。2.要求パラメータが間違っている。
401現在の要求にはユーザー認証が必要です。この応答には、要求されたリソースに適したWWW-Authenticate情報ヘッダが含まれていなければならない。クライアントは、適切な認証ヘッダ情報を含む要求を繰り返し送信できます。現在の要求に認証証明書が含まれている場合、401応答は、サーバ認証が拒否した証明書を表します。401応答に前の応答と同じ認証クエリが含まれていて、ブラウザが少なくとも1回認証を試みた場合、ブラウザは応答に含まれるエンティティ情報をユーザーに表示する必要がありますこの実体情報には診断情報が含まれている可能性があるからです。Rf2617を参照してください。
402このステータスコードは、将来の可能なニーズのために予約されています。
403サーバは要求を理解していますが、実行を拒否します。401応答とは異なり、認証は何の役にも立たず、この要求も重複して提出されるべきではない。これがHEAD要求ではなく、サーバが要求を実行できない理由を明確にしたい場合は、エンティティ内に拒否の理由を記述する必要があります。もちろん、サーバは、クライアントに情報を取得させたくない場合には、404応答を返すこともできます。
404要求に失敗しました。要求したいリソースはサーバー上で発見されていません。この状況が一時的なのか永久的なのかをユーザーに伝える情報はない。サーバが状況を知っている場合は、410ステータスコードを使用して、古いリソースが内部の構成メカニズムの問題で永久的に利用できなくなったことを知らせ、ジャンプできるアドレスがないことを知らせなければならない。404このステータスコードは、サーバが要求が拒否された理由を明らかにしたくない場合や、他の適切な応答がない場合に広く適用されている。
405要求行で指定された要求メソッドは、対応するリソースを要求するために使用できません。この応答は、現在のリソースが受け入れることができる要求メソッドのリストを示すために、hashヘッダ情報を返す必要があります。PUTを考慮すると、DELETEメソッドはサーバ上のリソースを書き込み操作するため、ほとんどのwebサーバはサポートしていないか、デフォルト設定では上記の要求メソッドを許可していませんこのような要求に対して405エラーが返されます。
406要求されたリソースのコンテンツ特性が要求ヘッダの条件を満たすことができないため、応答エンティティを生成できない。これがHEAD要求でない限り、応答は、ユーザーまたはブラウザが最適なエンティティ特性とアドレスリストを選択できるエンティティを返す必要があります。エンティティのフォーマットは、Content-Typeヘッダで定義されているメディアタイプによって決まります。ブラウザはフォーマットと自分の能力によって自分で最適な選択ができます。しかし、規範にはこのような自動選択をする基準は定義されていない。
407401応答と同様ですが、クライアントはプロキシサーバー上で認証を行う必要があります。プロキシサーバーは、認証要求を行うための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レンジリクエストヘッダーがリクエストに含まれていて、レンジリクエストヘッダーで指定されたデータ範囲が現在のリソースで使用可能な範囲と一致しない場合、リクエストにIf-レンジリクエストヘッダーが定義されていない場合サーバは416ステータスコードを返す必要があります。Rangeがバイト範囲を使用しているとすると、要求で指定されたすべてのデータ範囲の最初のバイト位置が現在のリソースの長さを超えていることを意味します。サーバは416ステータスコードを返すと同時に、現在のリソースの長さを示すContent-レンジエントリヘッダーを含める必要があります。この応答は、multipart/byterangesをContent-Typeとして使用することも禁止されています。
417要求ヘッダExpectで指定された予想内容がサーバで満足できないか、このサーバはプロキシサーバであり、現在のルーティングの次のノードで明らかな証拠があるexpectの内容を満たすことができません。
421現在のクライアントが存在するipアドレスからサーバへの接続数が、サーバの許可の最大範囲を超えています。通常、ここでのipアドレスとは、サーバから見たクライアントアドレス (ユーザのゲートウェイやプロキシサーバのアドレスなど) を指します。この場合、接続数の計算には複数のエンドユーザーが含まれる可能性があります。
422現在のクライアントが存在するipアドレスからサーバへの接続数が、サーバの許可の最大範囲を超えています。通常、ここでのipアドレスとは、サーバから見たクライアントアドレス (ユーザのゲートウェイやプロキシサーバのアドレスなど) を指します。この場合、接続数の計算には複数のエンドユーザーが含まれる可能性があります。
422リクエストのフォーマットは正しいですが、セマンティックエラーが含まれているため、応答できません。 (Rf4918webdav) 423 Locked現在のリソースはロックされています。 (Rf4918webdav)
424以前の要求で発生したエラーのため、PROPPATCHなどの現在の要求は失敗しました。 (Rf4918webdav)
425WebDav advancedcollectの草案で定義されているが、「WebDAVシーケンシャルセットプロトコル」 (RFC 3658) には存在しない。
426クライアントはTLS/1.0に切り替える必要があります。 (Rf2817)
449マイクロソフトが拡張し、代表的な要求は適切な操作を実行した後に再試行しなければならない。
500サーバは予期しない状況に遭遇し、要求の処理を完了できなくなった。一般的に、この問題はサーバのプログラムコードが間違っているときに発生します。
501サーバは、現在の要求に必要な機能をサポートしていません。サーバが要求されたメソッドを識別できず、リソースへの要求をサポートできない場合。
502ゲートウェイまたはプロキシとして動作しているサーバがリクエストの実行を試みたときに、上流サーバから無効なレスポンスを受信しました。
503一時的なサーバのメンテナンスや過負荷のため、サーバは現在要求を処理できません。この状況は一時的で、しばらくしてから回復する。遅延時間が予想される場合、応答にはこの遅延時間を示すRetry-Afterヘッダを含めることができます。このRetry-After情報が与えられていない場合、クライアントは500応答を処理するように処理しなければならない。注意:503ステータスコードの存在は、サーバが過負荷になったときに使用する必要があることを意味するものではありません。一部のサーバは、クライアントの接続を拒否したいにすぎない。
504ゲートウェイまたはプロキシとして動作するサーバが要求を実行しようとしたとき、上流サーバ (URIで識別されたサーバ) からHTTP、FTP、LDAP、DNSなどのセカンダリサーバが応答を受信します。注意: 一部のプロキシサーバは、DNSクエリがタイムアウトしたときに400または500エラーを返します
505サーバーがサポートしていないか、リクエストで使用されているHTTPバージョンのサポートを拒否します。これは、サーバがクライアントと同じバージョンを使用できないか、使用したくないことを示唆しています。応答には、バージョンがサポートされていない理由と、サーバがサポートするプロトコルを記述したエンティティが含まれている必要があります。
506「透過的コンテンツ交渉プロトコル」 (rf2295) によって拡張され、代表サーバに内部構成エラーが存在する: 要求された交渉変数リソースは、透過的コンテンツ交渉で自分を使用するように構成されているそのため、協議処理では適切なポイントではない。
507サーバは、要求を完了するために必要なコンテンツを保存できません。この状況は一時的なものとみなされます。WebDAV (rf4918)
509サーバは帯域幅制限に達した。これは公式のステータスコードではありませんが、まだ広く使われています。
510リソースを取得するために必要なポリシーが満たされていません。 (Rf2774)
あなたの足跡:

iToolify ツールボックスナビゲーション

相互リンク:iCMS