HTTPステータスコード一覧・検索

空白区切りで複数の語を指定すると、すべてを含むコードだけが表示されます。「4xx」で分類を指定することもできます。

該当するステータスコードが見つかりません。

• 1xx 情報

  100 Continue

  継続

  要求ヘッダーは受け付けたので、クライアントはリクエストボディの送信を続けてよい、という中間応答です。

  主な用途・原因

  Expect: 100-continue を付けた大きなリクエストの送信前に、サーバーが受け入れ可否を返す場合に使われます。

  対処・実装メモ

  通常はHTTPクライアントが自動で処理します。アプリ側で意識する必要はほとんどありません。

  仕様: RFC 9110 §15.2.1

• 1xx 情報

  101 Switching Protocols

  プロトコル切替

  クライアントの Upgrade 要求に応じて、通信プロトコルを切り替えることを示します。

  主な用途・原因

  WebSocket の接続確立（ハンドシェイク）で返されます。

  対処・実装メモ

  WebSocket が繋がらないときは、リバースプロキシが Upgrade / Connection ヘッダーを転送しているか確認します。

  仕様: RFC 9110 §15.2.2

• 1xx 情報

  102 Processing

  処理中

  処理は受け付けたが完了までに時間がかかっていることを示す中間応答です（WebDAV）。

  主な用途・原因

  時間のかかる WebDAV 操作でタイムアウトを避けるために使われます。

  対処・実装メモ

  一般的なWeb APIではほぼ使われません。非同期処理には 202 を使います。

  仕様: RFC 2518

• 1xx 情報

  103 Early Hints

  早期ヒント

  最終応答の前に、Link ヘッダーなどでブラウザへ先読みすべきリソースを知らせる中間応答です。

  主な用途・原因

  サーバーが本体を生成している間に、CSS や JavaScript の事前読み込み（preload）を始めさせるために使われます。

  対処・実装メモ

  CDN やサーバーが対応している場合に表示速度の改善に使えます。非対応のクライアントは無視します。

  仕様: RFC 8297

• 2xx 成功

  200 OK

  成功

  リクエストが成功し、応答に結果が含まれています。

  主な用途・原因

  GET では取得した内容、POST では処理結果を返すときなど、最も一般的な成功応答です。

  対処・実装メモ

  本文がない場合は 204、新規作成は 201 を返すと意図が明確になります。エラーなのに 200 を返す設計は避けます。

  仕様: RFC 9110 §15.3.1

• 2xx 成功

  201 Created

  作成済み

  リクエストが成功し、新しいリソースが作成されました。

  主な用途・原因

  POST や PUT でリソースを新規作成したときに返します。

  対処・実装メモ

  作成したリソースのURLを Location ヘッダーで返すのが一般的です。

  仕様: RFC 9110 §15.3.2

• 2xx 成功

  202 Accepted

  受理

  リクエストは受け付けたが、処理はまだ完了していません（非同期処理）。

  主な用途・原因

  メール送信や重いバッチなど、バックグラウンドで処理する場合に返します。

  対処・実装メモ

  処理状況を確認できる URL やジョブ ID を本文で返すと親切です。

  仕様: RFC 9110 §15.3.3

• 2xx 成功

  203 Non-Authoritative Information

  非権威情報

  成功しましたが、内容は元のサーバーではなく中継のプロキシ等が変換・加工したものです。

  主な用途・原因

  プロキシが応答内容を書き換えた場合に返されます。

  対処・実装メモ

  ほとんど見かけません。通常は 200 として扱って問題ありません。

  仕様: RFC 9110 §15.3.4

• 2xx 成功

  204 No Content

  内容なし

  成功しましたが、返すべき本文はありません。

  主な用途・原因

  DELETE や、更新結果を返さない PUT / PATCH、CORS のプリフライト応答などで使われます。

  対処・実装メモ

  本文は付けません。「画面を遷移せず、今のページに留まる」という意味でも使われます。

  仕様: RFC 9110 §15.3.5

• 2xx 成功

  205 Reset Content

  リセット

  成功しました。クライアントは入力フォームなどの表示を初期状態に戻すべきです。

  主な用途・原因

  フォーム送信後に入力欄をクリアさせたい場合に理論上使います。

  対処・実装メモ

  実際にはほとんど使われず、ブラウザの対応も限定的です。

  仕様: RFC 9110 §15.3.6

• 2xx 成功

  206 Partial Content

  部分的内容

  Range ヘッダーで要求された範囲の一部だけを返しています。

  主な用途・原因

  動画のシーク再生や、大きなファイルの分割・再開ダウンロードで返されます。

  対処・実装メモ

  Content-Range ヘッダーで返した範囲を示します。Accept-Ranges: bytes で対応を知らせます。

  仕様: RFC 9110 §15.3.7

• 2xx 成功

  207 Multi-Status

  マルチステータス

  複数のリソースへの操作結果が、本文（XML）の中で個別に示されます。

  主な用途・原因

  WebDAV で複数のファイルをまとめて操作したときに返されます。

  対処・実装メモ

  本文内の各リソースのステータスを個別に確認する必要があります。

  仕様: RFC 4918

• 2xx 成功

  208 Already Reported

  報告済み

  同じ応答内で既に列挙済みのリソースなので、重複して詳細を返しません（WebDAV）。

  主な用途・原因

  WebDAV のバインディング機能で、同じ内容の再列挙を避けるために使われます。

  対処・実装メモ

  一般的なWeb開発では目にすることはありません。

  仕様: RFC 5842

• 2xx 成功

  226 IM Used

  IM 使用

  デルタエンコーディングにより、現在の内容との差分として応答しています。

  主な用途・原因

  差分配信（Delta encoding in HTTP）に対応した環境で使われます。

  対処・実装メモ

  実運用ではほとんど使われません。

  仕様: RFC 3229

• 3xx リダイレクト

  300 Multiple Choices

  複数の選択肢

  要求に対して複数の候補があり、どれかを選ぶ必要があります。

  主な用途・原因

  言語や形式の違う複数の表現が存在する場合の応答です。

  対処・実装メモ

  実際にはほとんど使われません。自動で選べるなら Accept 系ヘッダーによるコンテンツネゴシエーションを使います。

  仕様: RFC 9110 §15.4.1

• 3xx リダイレクト

  301 Moved Permanently

  恒久的に移動

  リソースのURLが恒久的に変わりました。以後は新しいURL（Location）を使います。

  主な用途・原因

  サイト移転、http から https への転送、URLの正規化（www の有無・末尾スラッシュ）で使われます。

  対処・実装メモ

  検索エンジンの評価が新URLへ引き継がれます。POST が GET に変わることがあるため、メソッドを保つなら 308 を使います。ブラウザがキャッシュするので、誤設定すると戻しにくくなります。

  仕様: RFC 9110 §15.4.2

• 3xx リダイレクト

  302 Found

  見つかった（一時的な移動）

  リソースは一時的に別のURLにあります。

  主な用途・原因

  ログイン後の遷移、メンテナンス画面への転送、A/Bテストなど一時的なリダイレクトで使われます。

  対処・実装メモ

  元のURLを維持したいときに使います。メソッドを保ちたい場合は 307、POST 後に GET へ遷移させたい場合は 303 が明確です。

  仕様: RFC 9110 §15.4.3

• 3xx リダイレクト

  303 See Other

  他を参照せよ

  結果は別のURLにあるので、GET で取得してください。

  主な用途・原因

  フォーム送信（POST）後に結果画面へリダイレクトする PRG パターンで使われます。

  対処・実装メモ

  リロードによる二重送信を防げます。リダイレクト先には必ず GET でアクセスされます。

  仕様: RFC 9110 §15.4.4

• 3xx リダイレクト

  304 Not Modified

  未更新

  リソースは前回の取得から変更されていないので、キャッシュを再利用できます。

  主な用途・原因

  クライアントが If-None-Match（ETag）や If-Modified-Since を付けて問い合わせた場合に返されます。

  対処・実装メモ

  本文は含めません。ETag や Last-Modified を正しく返すと通信量を減らせます。更新が反映されないときはキャッシュを疑います。

  仕様: RFC 9110 §15.4.5

• 3xx リダイレクト

  305 Use Proxy

  プロキシを使用

  指定のプロキシ経由でアクセスするよう求めていました。

  主な用途・原因

  歴史的な仕様で、現在は非推奨です。

  対処・実装メモ

  セキュリティ上の理由でブラウザは無視します。使用しないでください。

  仕様: RFC 9110 §15.4.6

• 3xx リダイレクト

  307 Temporary Redirect

  一時的リダイレクト

  リソースは一時的に別のURLにあります。リクエストのメソッドと本文はそのまま保ちます。

  主な用途・原因

  HSTS による http から https への内部リダイレクトや、POST を保ったままの一時転送で使われます。

  対処・実装メモ

  302 と違い、POST を POST のまま再送します。ブラウザの開発者ツールで「307 Internal Redirect」と見えるものは、HSTS によるブラウザ内の転送です。

  仕様: RFC 9110 §15.4.8

• 3xx リダイレクト

  308 Permanent Redirect

  恒久的リダイレクト

  リソースのURLが恒久的に変わりました。メソッドと本文は保ったまま再送します。

  主な用途・原因

  POST などを保ったまま恒久的に移転したい場合に使います。

  対処・実装メモ

  301 のメソッドを保つ版です。API のエンドポイント移転で有用です。

  仕様: RFC 9110 §15.4.9

• 4xx クライアントエラー

  400 Bad Request

  不正なリクエスト

  リクエストの構文や内容が不正で、サーバーが処理できません。

  主な用途・原因

  JSON の構文エラー、必須パラメーターの欠落、不正なヘッダーや大きすぎるCookie、URLの不正な文字などで発生します。

  対処・実装メモ

  リクエストボディとヘッダーを見直します。API では、どのフィールドが不正かをエラーメッセージに含めると親切です。

  仕様: RFC 9110 §15.5.1

• 4xx クライアントエラー

  401 Unauthorized

  認証が必要

  認証されていないか、認証情報が無効です。名称は Unauthorized ですが、実際には「未認証」を意味します。

  主な用途・原因

  トークンや Cookie がない・期限切れ・誤りの場合、またはBASIC認証が必要な場合に返されます。

  対処・実装メモ

  WWW-Authenticate ヘッダーで認証方式を示します。認証済みだが権限がない場合は 403 を使います。

  仕様: RFC 9110 §15.5.2

• 4xx クライアントエラー

  402 Payment Required

  支払いが必要

  支払いが必要であることを示すために予約されたコードです。

  主な用途・原因

  標準では用途が定義されていませんが、一部のAPIが課金・利用枠超過の表現に独自に使います。

  対処・実装メモ

  使うAPIの仕様を確認します。標準的な意味に頼らない設計が安全です。

  仕様: RFC 9110 §15.5.3

• 4xx クライアントエラー

  403 Forbidden

  禁止

  リクエストは理解したが、認可されておらず実行を拒否します。

  主な用途・原因

  権限不足、IP制限、ディレクトリの閲覧禁止、WAF やボット対策による遮断などで発生します。

  対処・実装メモ

  認証し直しても解決しません。権限・ファイルのパーミッション・WAF のログを確認します。存在を隠したい場合は 404 を返す設計もあります。

  仕様: RFC 9110 §15.5.4

• 4xx クライアントエラー

  404 Not Found

  見つからない

  指定されたリソースがサーバー上に見つかりません。

  主な用途・原因

  URLの誤り、ページの削除や移動、ファイル名の大文字小文字の違い、デプロイの漏れなどで発生します。

  対処・実装メモ

  URLを確認し、移転した場合は 301 を設定します。恒久的に削除したなら 410 も選べます。ソフト404（200 で「見つかりません」画面を返す）は避けます。

  仕様: RFC 9110 §15.5.5

• 4xx クライアントエラー

  405 Method Not Allowed

  メソッドは許可されない

  そのURLでは、使用したHTTPメソッドは許可されていません。

  主な用途・原因

  GET 専用のエンドポイントに POST を送った、または静的ファイルへの POST などで発生します。

  対処・実装メモ

  Allow ヘッダーに使えるメソッドを返します。CORS のプリフライト（OPTIONS）が通らない場合もこれになります。

  仕様: RFC 9110 §15.5.6

• 4xx クライアントエラー

  406 Not Acceptable

  受理できない

  Accept 系ヘッダーが示す形式や言語では応答を返せません。

  主な用途・原因

  Accept: application/xml のみを求めたのに JSON しか返せない場合などです。

  対処・実装メモ

  Accept ヘッダーの指定を見直します。mod_security などが誤検知して返すこともあります。

  仕様: RFC 9110 §15.5.7

• 4xx クライアントエラー

  407 Proxy Authentication Required

  プロキシ認証が必要

  プロキシサーバーでの認証が必要です。

  主な用途・原因

  企業のプロキシ等が認証を要求している場合に返されます。

  対処・実装メモ

  Proxy-Authorization ヘッダーで認証情報を送ります。401 のプロキシ版です。

  仕様: RFC 9110 §15.5.8

• 4xx クライアントエラー

  408 Request Timeout

  リクエストタイムアウト

  サーバーがリクエストの受信完了を待ちきれませんでした。

  主な用途・原因

  通信が遅い・途中で止まった、接続だけ開いて送信しない場合などに返されます。

  対処・実装メモ

  回線状況の確認や再試行を行います。サーバーやロードバランサーのタイムアウト設定も確認します。

  仕様: RFC 9110 §15.5.9

• 4xx クライアントエラー

  409 Conflict

  競合

  リソースの現在の状態と競合しており、リクエストを完了できません。

  主な用途・原因

  同じ値の重複登録、同時更新による編集の衝突、バージョン不一致などで発生します。

  対処・実装メモ

  最新の状態を取得し直してから再試行するよう、クライアントに促します。

  仕様: RFC 9110 §15.5.10

• 4xx クライアントエラー

  410 Gone

  消滅

  リソースは恒久的に削除されており、今後も戻りません。

  主な用途・原因

  意図的に削除したページやAPIの廃止を明示したい場合に返します。

  対処・実装メモ

  404 より「意図した削除」を強く伝えられ、検索エンジンの登録解除が早まることがあります。

  仕様: RFC 9110 §15.5.11

• 4xx クライアントエラー

  411 Length Required

  長さが必要

  Content-Length ヘッダーが必要です。

  主な用途・原因

  本文つきのリクエストに Content-Length がなく、サーバーが必須としている場合です。

  対処・実装メモ

  本文のバイト数を Content-Length に指定して再送します。

  仕様: RFC 9110 §15.5.12

• 4xx クライアントエラー

  412 Precondition Failed

  前提条件の失敗

  If-Match など、リクエストヘッダーの前提条件を満たしていません。

  主な用途・原因

  ETag を使った楽観的ロックで、他の更新によりリソースが変わっていた場合に返されます。

  対処・実装メモ

  最新のリソースを取得し、ETag を更新して再試行します。

  仕様: RFC 9110 §15.5.13

• 4xx クライアントエラー

  413 Content Too Large

  コンテンツが大きすぎる

  リクエストの本文がサーバーの許容サイズを超えています。

  主な用途・原因

  ファイルアップロードが大きい場合に発生します。nginx の client_max_body_size やアプリ側の上限が原因のことが多いです。

  対処・実装メモ

  設定の上限値を確認・引き上げるか、ファイルを小さくして再送します。

  仕様: RFC 9110 §15.5.14

• 4xx クライアントエラー

  414 URI Too Long

  URIが長すぎる

  リクエストURIがサーバーの処理できる長さを超えています。

  主な用途・原因

  GET のクエリ文字列に大量のデータを載せた場合や、リダイレクトのループで発生します。

  対処・実装メモ

  大きなデータは POST で本文に載せます。リダイレクトのループも確認します。

  仕様: RFC 9110 §15.5.15

• 4xx クライアントエラー

  415 Unsupported Media Type

  サポートされないメディアタイプ

  本文の形式（Content-Type）をサーバーが受け付けません。

  主な用途・原因

  JSON を期待するAPIに form 形式で送る、Content-Type の指定漏れなどで発生します。

  対処・実装メモ

  Content-Type: application/json など、APIが受け付ける形式を指定します。

  仕様: RFC 9110 §15.5.16

• 4xx クライアントエラー

  416 Range Not Satisfiable

  範囲が不正

  Range ヘッダーで指定された範囲が、リソースの大きさを外れています。

  主な用途・原因

  再開ダウンロードで、実際のファイルサイズより後ろを要求した場合などです。

  対処・実装メモ

  Content-Range: bytes */全体サイズ で実際のサイズを確認し、範囲を修正します。

  仕様: RFC 9110 §15.5.17

• 4xx クライアントエラー

  417 Expectation Failed

  期待に添えない

  Expect ヘッダーの要求をサーバーが満たせません。

  主な用途・原因

  Expect: 100-continue に対応していないサーバーやプロキシで発生します。

  対処・実装メモ

  Expect ヘッダーを外して送信します。

  仕様: RFC 9110 §15.5.18

• 4xx クライアントエラー

  418 I'm a teapot

  私はティーポットです

  ティーポットにコーヒーを淹れさせようとした、というジョークのコードです（RFC 2324）。

  主な用途・原因

  エイプリルフールのRFCに由来します。一部のサービスが独自に、ボットの拒否などで使います。

  対処・実装メモ

  本番の標準的な用途はありません。見かけたらそのサービスの独自仕様を確認します。

  仕様: RFC 2324

• 4xx クライアントエラー

  421 Misdirected Request

  誤った宛先

  リクエストが、応答を返せないサーバーに向けて送られています。

  主な用途・原因

  HTTP/2 で複数のホスト名が同じ接続を共有し、証明書やSNIの構成が合わない場合に起きます。

  対処・実装メモ

  新しい接続でリクエストを再送します。証明書のSAN構成も確認します。

  仕様: RFC 9110 §15.5.20

• 4xx クライアントエラー

  422 Unprocessable Content

  処理できないコンテンツ

  構文は正しいものの、意味的に処理できない内容です。

  主な用途・原因

  JSON は正しいがバリデーションに失敗した場合（メール形式の誤りなど）に、多くの API が使います。

  対処・実装メモ

  400 が構文エラー、422 が入力値の検証エラー、と使い分けるのが一般的です。

  仕様: RFC 9110 §15.5.21

• 4xx クライアントエラー

  423 Locked

  ロック中

  アクセス先のリソースがロックされています（WebDAV）。

  主な用途・原因

  他のユーザーが編集中などでロックされている場合です。

  対処・実装メモ

  ロックが解除されるまで待つか、ロックトークンを付けて送ります。

  仕様: RFC 4918

• 4xx クライアントエラー

  424 Failed Dependency

  依存関係の失敗

  前提となる別の操作が失敗したため、このリクエストも実行できません（WebDAV）。

  主な用途・原因

  複数操作の一括処理で、依存先の処理が失敗した場合です。

  対処・実装メモ

  失敗した元の操作（本文内のステータス）を先に解決します。

  仕様: RFC 4918

• 4xx クライアントエラー

  425 Too Early

  早すぎる

  再送される可能性のあるリクエストを、サーバーが処理したくないことを示します。

  主な用途・原因

  TLS 1.3 の 0-RTT（アーリーデータ）で届いたリクエストの再送攻撃を避けるために返されます。

  対処・実装メモ

  クライアントはハンドシェイク完了後に再送します。通常は自動で処理されます。

  仕様: RFC 8470

• 4xx クライアントエラー

  426 Upgrade Required

  アップグレードが必要

  現在のプロトコルでは処理できず、別のプロトコルへの切り替えが必要です。

  主な用途・原因

  TLS や新しいHTTPバージョンなど、特定のプロトコルを要求するサーバーが返します。

  対処・実装メモ

  Upgrade ヘッダーに示されたプロトコルで接続し直します。

  仕様: RFC 9110 §15.5.22

• 4xx クライアントエラー

  428 Precondition Required

  事前条件が必要

  リクエストに条件付きヘッダー（If-Match など）が必須です。

  主な用途・原因

  更新の競合（ロストアップデート）を防ぐため、If-Match を必須とするAPIが返します。

  対処・実装メモ

  取得時の ETag を If-Match に付けて送ります。

  仕様: RFC 6585

• 4xx クライアントエラー

  429 Too Many Requests

  リクエストが多すぎる

  一定時間内のリクエスト数が、レート制限を超えました。

  主な用途・原因

  APIの呼び出し回数制限、スクレイピング、ログイン試行の連打などで発生します。

  対処・実装メモ

  Retry-After ヘッダーの秒数だけ待って再試行します。指数バックオフを用いるのが定石です。

  仕様: RFC 6585

• 4xx クライアントエラー

  431 Request Header Fields Too Large

  ヘッダーが大きすぎる

  リクエストヘッダー全体、または個々のヘッダーが大きすぎます。

  主な用途・原因

  Cookie が肥大化した場合や、巨大な Authorization / Referer などで発生します。

  対処・実装メモ

  不要な Cookie を削除する、またはサーバーのヘッダーサイズ上限を見直します。

  仕様: RFC 6585

• 4xx クライアントエラー

  451 Unavailable For Legal Reasons

  法的理由により利用不可

  法的な要求（検閲・裁判所命令など）により、リソースを提供できません。

  主な用途・原因

  政府や裁判所の命令、著作権関連、地域規制によって遮断された場合です。名称は小説『華氏451度』に由来します。

  対処・実装メモ

  Link ヘッダーで遮断を行った主体を示す方法が仕様化されています。

  仕様: RFC 7725

• 5xx サーバーエラー

  500 Internal Server Error

  サーバー内部エラー

  サーバー側で予期しないエラーが発生し、リクエストを処理できませんでした。

  主な用途・原因

  アプリケーションの例外、設定ミス（.htaccess など）、DB 接続エラー、未捕捉のバグなどで発生します。

  対処・実装メモ

  サーバーのエラーログを確認します。詳細なエラーはクライアントに返さず、ログに残します。

  仕様: RFC 9110 §15.6.1

• 5xx サーバーエラー

  501 Not Implemented

  未実装

  サーバーが、リクエストのメソッドや機能をサポートしていません。

  主な用途・原因

  未知のHTTPメソッドや、未実装の機能を要求した場合です。

  対処・実装メモ

  そのメソッドが使えるか確認します。メソッドは許可されるが拒否したいときは 405 です。

  仕様: RFC 9110 §15.6.2

• 5xx サーバーエラー

  502 Bad Gateway

  不正なゲートウェイ

  ゲートウェイやプロキシが、上流のサーバーから不正な応答を受け取りました。

  主な用途・原因

  リバースプロキシ（nginx・CDN・ロードバランサー）の背後のアプリが落ちている、または不正な応答を返している場合です。

  対処・実装メモ

  アプリサーバーの稼働・ポート・クラッシュログを確認します。デプロイ直後や再起動中にも発生します。

  仕様: RFC 9110 §15.6.3

• 5xx サーバーエラー

  503 Service Unavailable

  サービス利用不可

  サーバーが一時的に過負荷、またはメンテナンス中でリクエストを処理できません。

  主な用途・原因

  メンテナンス、アクセス集中、リソース不足、デプロイ中などで発生します。

  対処・実装メモ

  Retry-After ヘッダーで復旧の目安を返します。メンテナンス中の表示にも適しています（SEOへの影響を抑えられます）。

  仕様: RFC 9110 §15.6.4

• 5xx サーバーエラー

  504 Gateway Timeout

  ゲートウェイタイムアウト

  ゲートウェイやプロキシが、上流のサーバーからの応答を時間内に受け取れませんでした。

  主な用途・原因

  上流の処理が遅い（重いクエリなど）、ネットワーク障害、プロキシのタイムアウト設定が短い場合に発生します。

  対処・実装メモ

  処理の高速化や非同期化（202 の利用）、プロキシのタイムアウト値を見直します。

  仕様: RFC 9110 §15.6.5

• 5xx サーバーエラー

  505 HTTP Version Not Supported

  HTTPバージョン非対応

  リクエストで使われたHTTPのバージョンを、サーバーがサポートしていません。

  主な用途・原因

  古い・新しすぎるプロトコルバージョンで接続した場合です。

  対処・実装メモ

  サーバーが対応するバージョンで接続します。

  仕様: RFC 9110 §15.6.6

• 5xx サーバーエラー

  506 Variant Also Negotiates

  変種もネゴシエーションする

  コンテンツネゴシエーションの設定が循環参照になっています。

  主な用途・原因

  透過的コンテンツネゴシエーションの設定ミスで起こります。

  対処・実装メモ

  サーバー設定を見直します。現代ではまず見かけません。

  仕様: RFC 2295

• 5xx サーバーエラー

  507 Insufficient Storage

  容量不足

  リクエストを完了するための保存容量がサーバーにありません（WebDAV）。

  主な用途・原因

  ディスク容量やストレージのクォータが不足している場合です。

  対処・実装メモ

  空き容量やクォータを確認します。

  仕様: RFC 4918

• 5xx サーバーエラー

  508 Loop Detected

  ループを検出

  処理中に無限ループを検出したため、リクエストを中止しました（WebDAV）。

  主な用途・原因

  WebDAV で、リソースの参照が循環している場合です。

  対処・実装メモ

  参照構造のループを解消します。

  仕様: RFC 5842

• 5xx サーバーエラー

  510 Not Extended

  拡張が必要

  リクエストの処理に、HTTP 拡張（Extension Framework）が必要です。

  主な用途・原因

  実験的な仕様で、実際にはほとんど使われません。

  対処・実装メモ

  一般的なWeb開発では気にする必要はありません。

  仕様: RFC 2774

• 5xx サーバーエラー

  511 Network Authentication Required

  ネットワーク認証が必要

  ネットワークへのアクセスに認証が必要です。

  主な用途・原因

  カフェやホテルの Wi-Fi など、キャプティブポータルが認証を要求している場合に返されます。

  対処・実装メモ

  ブラウザでログインページを開いて認証を完了します。

  仕様: RFC 6585