| HTTPステータスコード | ステータスコードの意味 |
|---|
| 100 | クライアント側は引き続きリクエストを送信する必要があります。この一時的な応答は、クライアント側の一部のリクエストがサーバーに受け取られ、却下されていないことを通知するために使用されます。クライアント側は残りのリクエストを送信し続けるか、リクエストが完了した場合には応答を無視する必要があります。サーバーはリクエストが完了した後、クライアント側に最終的な応答を送信する必要があります。 |
| 101 | The server has understood the client's request and will inform the client side through the Upgrade header to use a different protocol to complete the request. After sending the last blank line in the response, the server will switch to those protocols defined in the Upgrade header. Similar measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a new HTTP version has advantages over an old version, or switching to a real-The server has understood the client's request and will inform the client side through the Upgrade header to use a different protocol to complete the request. After sending the last blank line in the response, the server will switch to those protocols defined in the Upgrade header. Similar measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a new HTTP version has advantages over an old version, or switching to a real |
| 102 | time and synchronous protocol to deliver resources that take advantage of such features. 2518The status code extended by WebDAV (RFC |
| 2) は処理が続くことを示します。 | 00. |
| 201 | リクエストが成功し、期待されるレスポンスヘッダーやデータボディがレスポンスとともに返信されます。202 リクエストが受理され、リクエストの要件に基づいて新しいリソースが作成され、そのURIがLocationヘッダーとともに返信されます。必要なリソースが時間内に作成できない場合、' |
| 202 | サーバーはリクエストを受け入れたが、まだ処理していない。拒否される可能性があるように、リクエストは最終的に実行されるかどうかも分からない。非同期操作の場合、このステータスコードを送信すること以外に便利な方法はない。'Accepted'が返信されるべき目的。 202 ステータスコードのリスポンスは、サーバーが他のプロセス（バッチ処理など）からのリクエストを受け入れることを許可する-一日に一度のみ実行されるバックグラウンドオペレーションが完了するまでクライアント側がサーバーに接続を維持する必要がないように、リクエストの処理を受け入れ、返信する 202 ステータスコード、返されたエンティティには、プロセスの現在の状態を示す情報およびプロセスステータス監視や予測へのポインタを含むべきです。これにより、ユーザーは操作が完了したかどうかを推測できるようになります。 |
| 203 | サーバーはリクエストを成功処理しましたが、返されたエンティティヘッダーメタ情報はオリジナルサーバー上で有効な決定論的なセットではありません。代わりに、ローカルまたは第三の-パーティーコピー。現在の情報は、オリジナルバージョンのサブセットまたはスーパーセットであったかもしれません。例えば、リソースを含むメタデータが、オリジナルサーバーがメタスーパーセットを知ることができる原因となります。このステータスコードを使用する必要はなく、応答が返される場合にのみ適しています。 200 OK というステータスコードがありません。 |
| 204 | サーバーはリクエストを成功処理しましたが、物理的なコンテンツを返す必要はありません。また、更新されたメタ情報を返したいと考えています。応答はエンティティヘッダーの形式で、新しいまたは更新されたメタ情報を返します。このヘッダー情報が存在する場合、リクエストに対応する変数に一致する必要があります。クライアント側がブラウザの場合、ユーザーのブラウザはリクエストを送信したページをドキュメントビューに変更なく保持する必要があります。新しいまたは更新されたメタ情報がユーザーのブラウザのアクティブビューに適用されるべきであるにもかかわらず、指定に従います。なぜなら、 204 メッセージボディを含むことは禁止されており、ヘッダーの後の最初の空白行で終わります。 |
| 205 | サーバーはリクエストを成功処理し、何も返しません。しかし、 204 このステータスコードを返すリクエストは、リクエスト者がドキュメントビューをリセットする必要があります。この応答は、ユーザー入力を受け入れた直後にフォームをリセットするために主に使用されます。ユーザーが簡単に別の入力を開始できるようにするためには、例えば 204 リクエストが含まれる場合、このレスポンスもメッセージボディを含めることはできず、ヘッダーの後の最初の空白行で終了します。 |
| 206 | サーバーはGETリクエストの一部を成功処理しました。FlashGetやXunleiなどのHTTPダウンロードツールは、このタイプのレスポンスを使用して、ブレイクポイントの継続を実現したり、大規模なドキュメントを複数のダウンロードセグメントに分割して同時にダウンロードするために使用します。-レンジを使用してリクエスト条件として。レスポンスには以下のヘッダーフィールドを含める必要があります：Content-Rangeを使用して、このレスポンスで返されるコンテンツの範囲を示します；-セグメントのダウンロードをContent-Typemultipart/Contentbyterangesが含まれている場合、各マルチパートセグメントにはContent-DateETagとレンジフィールドを使用して、このセグメントのコンテンツ範囲を示します。-Lengthを使用する場合、その値は返されるコンテンツ範囲の実際のバイト数に一致する必要があります。/またはContent-Location、もし同じリクエストが返されるべきであれば 200レスポンス。Expires、Cache-コントロール、および/Varyを使用して、その値が他の同じ変数に対するレスポンスの値と異なる可能性がある場合、-レンジの弱いキャッシュ検証があれば、このレスポンスには他のエンティティヘッダーを含めず、-ETagまたはLast 200レスポンスで返されるコンテンツを組み合わせることを禁止すべきです。-Modifiedヘッダーが完全に一致しない場合、クライアント側のキャッシュは、 206 レスポンスでのキャッシュを禁止されます。レンジとコンテンツ-レンジヘッダーは、前回キャッシュされたコンテンツとの 206 レスポンス。 |
| 207 | WebDAV（RFC）で拡張されたステータスコード 2518)は、次のメッセージのボディがXMLメッセージであることを示し、前のサブリクエストの数に応じて一連の独立したレスポンスコードを含む可能性があります。-リクエストがあります。 |
| 300 | リクエストされたリソースには、それぞれ独自の特定のアドレスとブラウザ-駆動交渉情報。ユーザーやブラウザは、リダイレクトのために推奨されるアドレスを選択できます。HEADリクエストでない場合、レスポンスは、ユーザーやブラウザが最適なリダイレクトアドレスを選択できるリソース属性とアドレスのリストを持つエンティティを含むべきです。このエンティティの形式は、Content-タイプ。ブラウザは、レスポンスの形式とブラウザの独自機能に基づいて最適な選択を自動的に行うことができます。もちろん、RFC 2616 仕様では、このような自動選択がどのように実行されるべきかは指定されていません。サーバー自体が既に推奨されるフィードバック選択を持っている場合、フィードバックのURIはLocationに指定されるべきです。ブラウザはこのLocation値を使用して自動リダイレクトのアドレスとして使用することができます。さらに、特に指定されていない限り、レスポンスもキャッシュ可能です。 |
| 301 | リクエストされたリソースは永遠に新しい場所に移行されました。このリソースに対する今後の参照は、このレスポンスから返されるいくつかのURIのうちの1つを使用する必要があります。可能な場合は、リンク編集機能を持つクライアント側は、サーバーから返されるアドレスに自動的にリクエストされたアドレスを変更するべきです。特に指定されていない限り、このレスポンスもキャッシュ可能です。新しい永続的なURIは、レスポンスのLocationフィールドに返されるべきです。HEADリクエストでない場合、レスポンスエンティティは新しいURIへのハイパーリンクと簡単な説明を含むべきです。GETまたはHEADリクエストでない場合、ユーザーが確認しない限り、ブラウザは自動的にリダイレクトすることを禁止されます。なぜなら、リクエストの条件は変更される可能性があるからです。注意: HTTPを使用する一部のブラウザでは、/1.0プロトコル、POSTリクエストを送信し、応答を得た場合 301 応答後、次のリダイレクトリクエストはGETになります。 |
| 302 | リクエストされたリソースは現在、異なるURIからのリクエストに一時的に応答しています。このようなリダイレクトは一時的なため、クライアント側は将来のリクエストを元のアドレスに続けて送信する必要があります。この応答は、Cacheに指定されている場合にのみキャッシュ可能です。-コントロールまたはExpires。新しい一時的なURIは、応答のLocationフィールドに返されなければなりません。HEADリクエストでない場合、応答エンティティには新しいURIへのハイパーリンクと簡単な説明を含むべきです。GETまたはHEADリクエストでない場合、ユーザーが確認しない限り、ブラウザは自動リダイレクトを禁止します。なぜなら、リクエストの条件は変更される可能性があるためです。注：RFC 1945 および 2068 仕様では、クライアント側がリダイレクト時にリクエストのメソッドを変更することを許可していないため、多くの既存のブラウザではRFC 302 応答として 303 応答を使用して、Locationに指定されたURIにアクセスし、元のリクエストメソッドを無視します。ステータスコード 303 そして 307 を追加して、サーバーがクライアント側から期待していることを明確にするために存在しています。 |
| 303 | 現在のリクエストへの応答は別のURIに見つかります。クライアント側はそのリソースにGETアクセスを取得する必要があります。このメソッドは主にスクリプト-新しいリソースにリダイレクトされるPOSTリクエストの出力がアクティブ化されました。この新しいURIは元のリソースへの参照の代わりではありません。また、 303 responses are prohibited from being cached. Of course, a second request (redirect) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlinke to the new URI and a brief description. Note: Many browsers prior to HTTP/1.1 レスポンスはキャッシュされることが禁止されています。もちろん、二つ目のリクエスト（リダイレクト）はキャッシュされることがあります。新しいURIはレスポンスのLocationフィールドに返されるべきです。HEADリクエストでない場合、レスポンスエンティティには新しいURIへのハイパーリンクと簡単な説明を含める必要があります。注：HTTP以前の多くのブラウザは 303 理解できない 302 ステータスコードが十分であるべきです、なぜならほとんどのブラウザがステータスを正しく処理するからです。これらのブラウザとの相互作用を考慮する必要がある場合、 302 上記の仕様がクライアント側に要求するように、正確に処理する必要があります。 303 レスポンス。 |
| 304 | クライアント側が条件付きGETリクエストを送信し、そのリクエストが許可され、ドキュメントの内容が変更されていない場合（最後の訪問以来またはリクエストの条件に従って）、サーバーはこのステータスコードを返さなければなりません。 304 メッセージボディを含めることが禁止されているため、ヘッダーの後ろの最初の空白行で常に終わる必要があります。レスポンスには以下のヘッダー情報を含める必要があります：Date、このサーバーがクロックを持っていない場合を除きます。
サーバーがクロックを持っていない場合でもこれらのルールに従うと、プロキシサーバーやクライアント側はRFCに指定されているように、受け取ったレスポンスヘッダーにDateフィールドを自分で追加することができます。 2068）、そしてキャッシュメカニズムが正常に動作します。ETagおよび/またはContent-Location、もし同じリクエストが返されるべきであれば 200レスポンス。Expires、Cache-コントロール、および/またはVaryを使用する場合、その値が前回の同じ変数に対する他のレスポンスの値と異なる可能性があります。
このレスポンスリクエストが強いキャッシュバリデーションを使用する場合、このレスポンスには他のエンティティヘッダーを含めないべきです；それ以外の場合（例えば、条件付きGETリクエストが弱いキャッシュバリデーションを使用する場合）、このレスポンスには他のエンティティヘッダーを含めることが禁止されます；これにより、キャッシュされたエンティティコンテンツと更新されたエンティティヘッダー情報の間の不一致を避けます。もし 304 レスポンスがエンティティが現在キャッシュされていないことを示す場合、キャッシュシステムはこのレスポンスを無視し、制限なく繰り返しリクエストを送信する必要があります。
もし、 304 レスポンスを受信してキャッシュエントリを更新する場合、キャッシュシステムは、レスポンスで更新されたすべてのフィールドの値を反映するために、エントリ全体を更新する必要があります。 |
| 305 | リクエストされたリソースは、指定されたプロキシを通じてアクセスする必要があります。指定されたプロキシのURI情報はLocationフィールドに示されます。受信者は、このプロキシを通じて対応するリソースにアクセスするために別々のリクエストを繰り返し送信する必要があります。このリダイレクトは、オリジンサーバーによってのみ設定できます。 305 レスポンス。注意：明示的な 305 RFCのレスポンス 2068 単一のリクエストをリダイレクトするためのものです。これはオリジンサーバーによってのみ設定できます。これらの制限を無視すると、深刻なセキュリティ上の影響を受ける可能性があります。 |
| 306 | 最新の規格のバージョンでは、 306 ステータスコードはもはや使用されません。 |
| 307 | リクエストされたリソースは、現在一時的に異なるURIからのリクエストに応じています。このようなリダイレクトは一時的なものであるため、クライアント側は将来のリクエストを元のアドレスに継続して送信する必要があります。このレスポンスは、Cacheで指定されている場合にのみキャッシュ可能です。-制御またはExpires。新しい一時的なURIは、レスポンスのLocationフィールドに返されなければなりません。HEADリクエストでない場合、応答エンティティは新しいURIを指すハイパーリンクと簡単な説明を含むべきです。一部のブラウザでは、 307 レスポンス、上記の情報を追加する必要があります。これにより、ユーザーが新しいURIに理解し、アクセスを要求することができます。
このリクエストがGETまたはHEADでない場合、ブラウザはユーザーが確認しない限り自動的なリダイレクトを禁止します。なぜなら、リクエストの条件が変更される可能性があるからです。 |
| 400 | 1セマンティクスが間違っており、現在のリクエストはサーバーによって理解できません。変更しない場合は、クライアント側はリクエストを繰り返し提出すべきではありません。 2リクエストパラメータが間違っています。 |
| 401 | 現在のリクエストはユーザー認証が必要です。応答にはWWW-Authenticateヘッダーを含む必要があります。-認証ヘッダーをリクエストリソースに設定してユーザーに情報を求める必要があります。クライアント側は適切なAuthorizationヘッダー情報を含むリクエストを再送信することができます。もし現在のリクエストがAuthorization証明書を含んでいる場合、 401 応答がサーバーがその証明書を拒否したことを示しています。もし 401 応答が前の応答と同じ認証クエリを含んでおり、ブラウザが少なくとも一度認証を試みた場合、ブラウザはユーザーに応答に含まれるエンティティ情報を表示するべきです。なぜなら、このエンティティ情報には関連する診断情報が含まれている可能性があるためです。RFCを参照してください。 2617. |
| 402 | このステータスコードは将来の要望のために予約されています。 |
| 403 | サーバーはリクエストを理解しましたが、実行を拒否しました。これは 401 応答が、認証が役に立たない場合、リクエストは繰り返しすべきではありません。これはHEADリクエストでない場合、サーバーがリクエストが実行できない理由を説明したい場合、拒否の理由はエンティティ内に記述されるべきです。もちろん、サーバーは他に応答を返すこともできます。 404 応答が、クライアント側に情報を得させたくない場合の応答です。 |
| 404 | リクエストは失敗し、必要なリソースがサーバー上に見つかりませんでした。この状態が一時的であるか永続的であるかをユーザーに伝える情報はありません。サーバーが状況を把握している場合、 410 ステータスコードは、内部の設定メカニズムにより永遠に利用不可能となった旧リソースに通知するために使用されるべきです。その 404 ステータスコードは、サーバーがリクエストが拒否された理由を明かしたくない場合や他に適切な応答がない場合に広く使用されています。 |
| 405 | The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header indicating a list of request methods that can be accepted by the current resource. Since PUT and DELETE methods write to resources on the server, most web servers do not support or do not allow the above request method by default, and will return a 405 リクエストラインに指定されたリクエストメソッドは、対応するリソースをリクエストするために使用できません。応答は、現在のリソースが受け入れることができるリクエストメソッドのリストを示すAllowヘッダーを返さなければなりません。PUTおよびDELETEメソッドはサーバーのリソースに書き込むため、ほとんどのウェブサーバーはデフォルトで上記のリクエストメソッドをサポートしたり認可したりせず、返します。 |
| 406 | このようなリクエストに対するエラーエンティティ。-リクエストされたリソースの内容の特徴が、リクエストヘッダーの条件に一致しないため、応答エンティティを生成することができません。これはHEADリクエストでない場合、ユーザーやブラウザが最も適切なエンティティの特徴とアドレスリストを選択できるエンティティを返す応答が必要です。エンティティの形式は、Contentヘッダーで定義されたメディアタイプに基づいて決定されます。 |
| 407 | Typeヘッダー。ブラウザは、フォーマットとその独自の機能に基づいて最善の選択を行うことができます。ただし、このような自動選択のための基準は、仕様では定義されていません。 401 似たような-認証のために認証を行います。クライアント側は、プロキシサーバーで認証を行う必要があります。プロキシサーバーは、Proxy応答を返さなければなりません。-認証のためにAuthorizationヘッダー。RFCを参照してください。 2617. |
| 408 | リクエストがタイムアウトしました。クライアント側は、サーバーが待つ準備ができた時間内にリクエストの送信を完了していません。クライアント側は、変更なしでいつでもリクエストを再提出できます。 |
| 409 | リクエストは、リクエストされたリソースの現在の状態との衝突により完了できません。このコードは、ユーザーが衝突を解決できると仮定して新しいリクエストを再提出する場合にのみ使用できます。ユーザーが衝突の原因を特定できる十分な情報を含む応答が必要です。衝突は通常、PUTリクエストの処理中に発生します。例えば、バージョン-チェックされた環境、PUTに付随するバージョン情報が含まれている場合-特定のリソースに対する修正リクエストが前の（第3党）のリクエストと競合している場合、-（第X党）のリクエストに対して、サーバーは 409 ユーザーにリクエストが完了しなかったことを伝えるエラーメッセージ。
この時点で、レスポンスエンティティはおそらく、二つの競合するバージョン間の差分比較を含んでおり、ユーザーが統合されたバージョンを再提出できるようにするためです。 |
| 410 | リクエストされたリソースがサーバー上で利用できなくなっており、どのフォワードアドレスも知られていない状態です。この状態は永続的なものと考えるべきです。可能な場合は、リンク編集機能を持つクライアント側はユーザーの許可を得て、このアドレスへのすべての参照を削除するべきです。サーバーがこの状態が永続的なかどうかを知らないか、または判断できない場合は、 404 ステータスコードを使用する必要があります。特に指定しない限り、このレスポンスはキャッシュ可能です。その目的は、 410 レスポンスは、ウェブマスターがウェブサイトを維持するのに役立ち、ユーザーにリソースが利用できなくなったことを通知し、サーバー所有者がこのリソースに対するすべてのリモート接続を削除したいことを示します。
この種のイベントは時間-限定された、値-追加されたサービスも同様に、 410 リソースがもともと個別に属していたが、現在のサーバーサイトで利用できなくなったことをクライアント側に通知するために使用されるレスポンスです。もちろん、すべての永続的に利用できないリソースを「'削除済み'とマークするかどうかは、サーバー所有者に完全に任されています。 410 「削除済み」とそのマークをどれくらい保持するか。 |
| 411 | サーバーはコンテンツを定義しないでリクエストを受け入れ拒否します。-長さヘッダー。有効なコンテンツを追加した後-リクエストボディの長さを示す長さヘッダー、クライアント側がリクエストを再度送信することができます。 |
| 412 | サーバーはリクエストのヘッダーフィールドの値を確認する際に、その前提条件を満たしていない一つまたは複数の前提条件を確認失敗しました。このステータスコードは、クライアント側がリソースを取得する際にリクエストメタデータ（リクエストヘッダーフィールドデータ）に前提条件を設定することを許可し、リクエストメソッドが望まないリソースに適用されることを防ぎます。 |
| 413 | サーバーは現在のリクエストを処理を拒否します。なぜなら、リクエストがサーバーが受け入れたり処理したりできるよりも多くのエンティティデータを提出しているからです。この場合、サーバーは接続を閉じることでクライアント側がリクエストを続けて送信することを防ぐことができます。この状況が一時的な場合、サーバーはRetryステータスコードを返すべきです。-レスポンスヘッダーにクライアント側が再試行できる時間を通知するために。 |
| 414 | リクエストされたURIがサーバーが解釈できる長さを超えるため、サーバーはリクエストを拒否します。これは稀なケースであり、一般的な例には：POSTメソッドを使用するべきフォームの提出がGETメソッドになり、クエリ文字列（クエリ文字列）が長すぎること、リダイレクトURI「ブラックホール」、例えば各リダイレクトで古いURIを新しいURIの一部として使用し、リダイレクトが複数回行われることでURIが長くなること、クライアントがサーバーにセキュリティバグを攻撃しようと試みていることが含まれます。
この種のサーバーは固定の-リクエストされたURIを読んだり操作したりするための長さバッファーを設定します。GETパラメータが一定の値を超えると、バッファーオーバーフローの発生があり、任意のコード実行に繋がる可能性があります[1]. そのような脆弱性を持たないサーバーは、以下のように返すべきです。 414 ステータスコード。 |
| 415 | 現在のリクエストのメソッドとリクエストされたリソースに対して、リクエストに提出されたエンティティがサーバーがサポートする形式ではありませんので、リクエストは拒否されます。 |
| 416 | リクエストにRangeヘッダーが含まれており、Rangeで指定されたデータ範囲が現在のリソースの利用可能な範囲と一致しない場合、およびIf-リクエストにはRangeヘッダーが定義されていません、サーバーはその場合に応じて返すべきです。 416 status code. If the Range uses a byte range, then this situation means that the first byte position of all data ranges specified by the request exceeds the length of the current resource. The server should also include a Content-Rangeエンティティヘッダーとともに 416 ステータスコードを現在のリソースの長さを示す。このレスポンスはmultipartの使用も禁止されています。/byterangesをContentとして持つ-Type. |
| 417 | リクエストヘッダーのExpectで指定された期待される内容がサーバーで満たされない場合、またはサーバーが次のルートのノードで期待される内容が満たされないという明確な証拠を持つプロキシサーバーの場合。 |
| 421 | 現在のクライアント側が位置するインターネットプロトコルアドレスからサーバーへの接続数が、サーバーが許可する最大値を超えています。ここでのインターネットプロトコルアドレスは、サーバーから見たクライアント側のアドレス（ユーザーのゲートウェイやプロキシサーバーのアドレスなど）を指します。この場合、接続数には1以上のエンドユーザーが関与する可能性があります。 |
| 422 | 現在のクライアント側が位置するインターネットプロトコルアドレスからサーバーへの接続数が、サーバーが許可する最大値を超えています。ここでのインターネットプロトコルアドレスは、サーバーから見たクライアント側のアドレス（ユーザーのゲートウェイやプロキシサーバーのアドレスなど）を指します。この場合、接続数には1以上のエンドユーザーが関与する可能性があります。 |
| 422 | リクエストは正しくフォーマットされていますが、意味的なエラーにより応答することができません。（RFC 4918 WebDAV) 423 ロックされた現在のリソースはロックされています。（RFC 4918 WebDAV) |
| 424 | 現在のリクエストは、前のリクエスト（例えばPROPPATCH）でのエラーにより失敗しました。（RFC 4918 WebDAV) |
| 425 | WebDav Advanced Collections草案で定義されていますが、WebDAV Sequential Set Protocol (RFC 3658). |
| 426 | クライアント側はTLSに切り替えるべきです/1.0. (RFC 2817) |
| 449 | マイクロソフトによって拡張され、適切なアクションを実行した後、リクエストを再試行すべきです。 |
| 500 | サーバーは予期せぬ状況に直面し、リクエストの完了を妨げました。一般的に、この問題はサーバーのコードが失敗した場合に発生します。 |
| 501 | サーバーは現在のリクエストに必要な機能をサポートしていません。サーバーがリクエストされたメソッドを認識できず、リソースに対するリクエストをサポートできない場合。 |
| 502 | ゲートウェイやプロキシとして動作するサーバーがリクエストを実行しようとすると、上位サーバーから無効なレスポンスを受信します。 |
| 503 | サーバーは一時的なサーバーメンテナンスやオーバーロードのために現在リクエストを処理することができません。この状態は一時的であり、少し経つと復旧します。遅延時間が予測可能であれば、レスポンスにはRetryを含めることができます。-ヘッダーに遅延時間を示すために使用されます。このRetry-情報が提供されない場合、クライアント側はそれをそのまま処理する必要があります。 500レスポンス。注意： 503 ステータスコードがオーバーロードの際にサーバーがそれを使用する必要があることを意味するものではありません。一部のサーバーは、クライアントの接続を拒否したいだけです。 |
| 504 | ゲートウェイやプロキシとして動作するサーバーがリクエストを実行しようと試みたとき、タイムリーに上位サーバー（HTTP、FTP、LDAPなどのURIで識別される）またはサブサーバー（DNSなどの）からの応答を受け取ることができません。注意：一部のプロキシサーバーは、 400または 500エラーがDNSクエリタイムアウト時発生 |
| 505 | サーバーはリクエストで使用されるHTTPのバージョンをサポートしていないか、サポートを拒否しています。これは、サーバーがクライアント側と同じバージョンを使用できないか、使用しないことを意味します。レスポンスには、バージョンがサポートされていない理由とサーバーがサポートするプロトコルを説明するエンティティを含める必要があります。 |
| 506 | Transparent Content Negotiation Protocol（RFC）によって拡張されています 2295）、これはサーバー内の内部設定エラーを表します：リクエストされたネゴシエーション変数リソースは、透明なコンテンツネゴシエーションで自分自身を使用するように設定されており、したがって、ネゴシエーションプロセスの適切な焦点ではありません。 |
| 507 | サーバーはリクエストを完了するために必要なコンテンツを保存できません。この状態は一時的なものとされています。WebDAV（RFC） 4918) |
| 509 | サーバーがバンドウィットルリミットに達しました。これは公式のステータスコードではありませんが、広く使用されています。 |
| 510 | リソースを取得するために必要なポリシーが満たされていません。（RFC） 2774) |
