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 や迅雷といった HTTP ダウンロードツールは、いずれもこの種のレスポンスを用いてレジューム（断続ダウンロード）を実現したり、大きなドキュメントを複数のダウンロードセグメントに分割して同時にダウンロードしたりしている。 このリクエストには、クライアントが希望するコンテンツの範囲を示す Range ヘッダー情報を含めなければならず、またリクエスト条件として If-Range を含めてもよい。 レスポンスには以下のヘッダーフィールドを含めなければならない： Content-Range は今回のレスポンスで返されるコンテンツの範囲を示すために用いる。Content-Type が multipart/byteranges であるマルチパートダウンロードの場合は、各 multipart セグメントに本セグメントのコンテンツ範囲を示す Content-Range フィールドを含めるべきである。レスポンスに Content-Length が含まれる場合、その数値は返されるコンテンツ範囲の実際のバイト数と一致しなければならない。同じリクエストが本来 200 レスポンスを返すべきであった場合には、Date、ETag、および/または Content-Location を含める。その値が、同じ変数に対応する他のレスポンスの値と異なる可能性がある場合には、Expires、Cache-Control、および/または Vary を含める。本レスポンスのリクエストが If-Range の強キャッシュ検証を用いた場合、今回のレスポンスには他のエンティティヘッダーを含めるべきではない。本レスポンスのリクエストが If-Range の弱キャッシュ検証を用いた場合、今回のレスポンスには他のエンティティヘッダーを含めてはならない。これにより、キャッシュされたエンティティ内容と更新されたエンティティヘッダー情報との間の不一致を避ける。そうでなければ、本レスポンスには本来 200 レスポンスで返すべきすべてのエンティティヘッダーフィールドを含めるべきである。ETag または Last-Modified ヘッダーが正確に一致しない場合、クライアントキャッシュは 206 レスポンスで返された内容を、以前にキャッシュされたいかなる内容とも組み合わせてはならない。Range および Content-Range ヘッダーをサポートしないキャッシュは、206 レスポンスで返された内容をキャッシュしてはならない。
207	WebDAV(RFC 2518)で拡張されたステータスコードで、これに続くメッセージボディが XML メッセージとなり、先行するサブリクエストの数に応じて、一連の独立したレスポンスコードを含む可能性があることを表します。
300	要求されたリソースには、それぞれ固有のアドレスとブラウザ主導のネゴシエーション情報を持つ、複数の選択可能な応答情報が存在します。ユーザーまたはブラウザは、優先するアドレスを自ら選択してリダイレクトできます。これが HEAD リクエストでない限り、応答にはリソースの特性とアドレスのリストからなるエンティティを含め、ユーザーまたはブラウザが最適なリダイレクト先を選択できるようにすべきです。このエンティティの形式は Content-Type で定義された形式によって決まります。ブラウザは応答の形式と自身の能力に応じて、最も適切な選択を自動的に行う場合があります。もちろん、RFC 2616 仕様ではそのような自動選択をどのように行うかは規定していません。サーバー自体に優先する応答選択がすでにある場合、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 レスポンスを生成できるのはオリジンサーバーのみです。 注意：RFC 2068 では、305 レスポンスが単独のリクエストをリダイレクトするためのものであり、オリジンサーバーのみが生成できることが明確にされていません。これらの制限を無視すると、重大なセキュリティ上の結果を招く可能性があります。
306	最新版の仕様では、306 ステータスコードはすでに使用されていません。
307	要求されたリソースは現在、異なる URI から一時的にリクエストに応答している。このようなリダイレクトは一時的なものであるため、クライアントは以後のリクエストも元のアドレスに送り続けるべきである。このレスポンスがキャッシュ可能となるのは、Cache-Control または 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	リクエスト行で指定されたリクエストメソッドを、そのリクエスト対象のリソースに使用することはできません。このレスポンスには、現在のリソースが受け付け可能なリクエストメソッドの一覧を示す Allow ヘッダー情報を必ず返さなければなりません。PUT や DELETE メソッドはサーバー上のリソースに対する書き込み操作を行うため、ほとんどの Web サーバーはこれらのリクエストメソッドをサポートしていないか、デフォルト設定では許可していません。そのため、この種のリクエストに対しては 405 エラーが返されます。
406	要求されたリソースのコンテンツ特性がリクエストヘッダー内の条件を満たせないため、レスポンスエンティティを生成できません。HEAD リクエストでない限り、このレスポンスは、ユーザーまたはブラウザがそこから最も適切なエンティティ特性とアドレスのリストを選択できるエンティティを返すべきです。エンティティの形式は Content-Type ヘッダーで定義されたメディアタイプによって決まります。ブラウザは形式と自身の能力に応じて、最適な選択を独自に行うことができます。ただし、仕様ではこのような自動選択を行うための基準は何も定義されていません。
407	401 応答と同様ですが、クライアントはプロキシサーバー上で認証を受ける必要があります。プロキシサーバーは認証要求を行うために Proxy-Authenticate を返さなければなりません。クライアントは認証を受けるために Proxy-Authorization ヘッダーを返すことができます。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 が極端に長くなる場合。クライアントが一部のサーバーに存在するセキュリティ脆弱性を悪用してサーバーを攻撃しようとしている場合。この種のサーバーは固定長のバッファでリクエスト 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）
424	以前のリクエストで発生したエラーが原因で、現在のリクエストが失敗した場合。例えば PROPPATCH。（RFC 4918 WebDAV）
425	WebDAV Advanced Collections のドラフトで定義されていますが、《WebDAV 順序集合プロトコル》（RFC 3658）には登場しません。
426	クライアントはTLS/1.0に切り替える必要があります。（RFC 2817）
449	Microsoft による拡張で、適切な操作を実行した後にリクエストを再試行すべきことを示します。
500	サーバーが予期しない状況に遭遇し、リクエストの処理を完了できなくなった状態。一般的に、この問題はサーバー側のプログラムコードにエラーが発生したときに現れる。
501	サーバーが現在のリクエストに必要な機能をサポートしていません。サーバーがリクエストメソッドを認識できず、かつ任意のリソースに対するそのメソッドをサポートできない場合に返されます。
502	ゲートウェイまたはプロキシとして動作するサーバーがリクエストを実行しようとした際に、上流サーバーから無効な応答を受信した。
503	一時的なサーバーメンテナンスまたは過負荷により、サーバーは現在リクエストを処理できません。この状況は一時的なものであり、しばらくしてから復旧します。遅延時間が見込める場合、レスポンスに Retry-After ヘッダーを含めてその遅延時間を示すことができます。Retry-After 情報が提供されていない場合、クライアントは 500 レスポンスを処理するのと同じ方法で処理すべきです。注意：503 ステータスコードが存在するからといって、サーバーが過負荷時に必ずそれを使わなければならないわけではありません。単にクライアントの接続を拒否したいだけのサーバーもあります。
504	ゲートウェイまたはプロキシとして動作するサーバーがリクエストを実行しようとした際に、上流サーバー（URI で識別されるサーバー。たとえば HTTP、FTP、LDAP）または補助サーバー（たとえば DNS）から適時に応答を受け取れなかった。 注意：一部のプロキシサーバーでは、DNS クエリのタイムアウト時に 400 または 500 エラーを返すことがある
505	サーバーが、リクエストで使用された HTTP バージョンをサポートしていない、またはサポートを拒否している。これは、サーバーがクライアントと同じバージョンを使用できない、あるいは使用する意思がないことを示唆している。レスポンスには、なぜそのバージョンがサポートされていないのか、そしてサーバーがどのプロトコルをサポートしているのかを説明するエンティティを含めるべきである。
506	《透過コンテンツネゴシエーション協定》（RFC 2295）によって拡張され、サーバーに内部設定エラーが存在することを表す。要求されたネゴシエーション変数リソースが、透過コンテンツネゴシエーションにおいて自分自身を使用するように設定されているため、一つのネゴシエーション処理において適切な焦点ではない。
507	サーバーがリクエストを完了するために必要な情報を保存できません。この状態は一時的なものと見なされます。WebDAV (RFC 4918)
509	サーバーが帯域幅の制限に達しました。これは公式のステータスコードではありませんが、広く使われています。
510	リソースの取得に必要なポリシーが満たされていません。（RFC 2774）

HTTP 状态码 - 维基百科

（これは同じ記事の52/52番目のパートです。）