HTTP レスポンスステータスコード

これは暫定レスポンスで、その時点までのすべてに問題がなく、クライアントはリクエストを継続してよい、またもしリクエストが完了している場合はレスポンスを無視してよいことを示します。

このコードはクライアントからの Upgrade リクエストヘッダーのレスポンスとして送信され、サーバーはプロトコルを切り替えていることを示します。

このコードは、サーバーはリクエストを受け取って処理しているが、まだレスポンスを提供できないことを示します。

このステータスコードは主に Link ヘッダーとともに使用され、サーバーがリソースを準備している間、ユーザーエージェントがリソースの先読みを開始できるようにするためのものです。

リクエストが成功したことを示します。成功が意味することは、 HTTP メソッドにより異なります。

• GET: リソースが読み込まれ、メッセージ本文で転送された。
• HEAD: メッセージ本文がなく、表現ヘッダーがレスポンスに含まれている。
• PUT または POST: 操作の結果を表すリソースがメッセージ本文で送信される。
• TRACE: メッセージ本文に、サーバーが受け取ったリクエストメッセージが含まれている。

リクエストは成功し、その結果新たなリソースが作成されたことを示します。これは一般的に、 POST リクエストや、一部の PUT リクエストを送信した後のレスポンスになります。

リクエストは受理されたが、まだ実行されていないことを示します。 これはあいまいです。 HTTP ではリクエストを処理した結果を示す非同期なレスポンスを後から送信する方法がないためです。 リクエストは別のプロセスかサーバーが処理する、またはバッチ処理する予定です。

このレスポンスコードは、返されるメタ情報のセットが生成元のサーバーから得られるセットと同一ではなく、ローカルまたは第三者の持つ複製から収集したことを表します。 これは主に、他のリソースのミラーやバックアップを使用したときに使用されます。 このような場合以外は、このステータスより 200 OK のほうが好ましいレスポンスです。

リクエストに対して送信するコンテンツはありませんが、ヘッダーは有用であることを示します。ユーザーエージェントはこのリソースに関するキャッシュ済みのヘッダーを、新たな内容に更新します。

ユーザーエージェントに対し、リクエストを送信した文書をリセットするよう伝達します。

このレスポンスコードは、クライアントが Range ヘッダーを送信し、リソースの一部だけをリクエストした時に使用されます。

複数のステータスコードがあてはまる状況で、複数のリソースに関する情報を伝えます。

同じコレクションに繰り返し複数のバインディングする内部メンバーを列挙することを避けるため、 <dav:propstat> レスポンス要素の内部で使用します。

サーバーはリソースへの GET リクエストの処理を完了しており、レスポンスは現在のインスタンスに適用された 1 つ以上の instance manipulation の結果を表します。

リクエストに対して複数のレスポンスがあることを示します。ユーザーエージェントやユーザーは、それらからひとつを選択します。 (複数のレスポンスからひとつを選ぶ方法は標準化されていませんが、選択肢へリンクする HTML が推奨されており、それによってユーザーが選択することができます。)

リクエストされたリソースの URL が永遠に変更されたことを示します。レスポンスで新しい URL が与えられます。

このレスポンスコードは、リクエストされたリソースの URI が 一時的に 変更されたことを示します。 URI は将来、さらに変更される可能性があります。従って、クライアントは将来のリクエストでも同じ URI を使用するべきです。

サーバーはこのレスポンスを、リクエストされたリソースを別の URI で GET リクエストを使用して取得するようクライアントを誘導するために送信します。

これはキャッシュ用に使用します。 このレスポンスコードはクライアントに対して、レスポンスは変更されていないことを示します。よって、クライアントはキャッシュ済みのレスポンスを使い続けます。

これは旧バージョンの HTTP 仕様書で、リクエストされたレスポンスはプロキシーからアクセスしなければならないことを示していました。 プロキシーのインバンド設定に関するセキュリティの懸念により、このレスポンスコードは非推奨になりました。

このレスポンスコードはもう使用されず、予約済みです。 HTTP/1.1 仕様書の旧バージョンでは使用されていました。

サーバーはこのレスポンスを、リクエストされたリソースを別の URI で、元のリクエストと同じメソッドを使用して取得するようクライアントを誘導するために送信します。 これは 302 Found HTTP レスポンスコードと同じ意味を持ちますが、ユーザーエージェントは使用する HTTP メソッドを変更してはならない点が異なります。始めのリクエストで POST を用いた場合は、次のリクエストでも POST を使用しなければなりません。

これは、リソースが HTTP の Location: レスポンスヘッダーで指定した別の URI へ永続的に置かれていることを示します。 これは 301 Moved Permanently HTTP レスポンスコードと同じ意味を持ちますが、ユーザーエージェントは使用する HTTP メソッドを変更してはならない点が異なります。始めのリクエストで POST を用いた場合は、次のリクエストでも POST を使用しなければなりません。

構文が無効であるためサーバーがリクエストを理解できないことを示します。

HTTP 標準では "unauthorized" (不許可) と定義されていますが、意味的にはこのレスポンスは "unauthenticated" (未認証) です。 つまり、クライアントはリクエストされたレスポンスを得るためには認証を受けなければなりません。

このレスポンスコードは、将来のために予約されています。このコードは当初、デジタル決済システムで使用するために作成されましたが、ごく稀にしか使用されておらず、標準的な慣例はありません。

認証されていないなどの理由でクライアントにコンテンツのアクセス権がなく、サーバーが適切なレスポンスの返信を拒否していることを示します。 401 Unauthorized とは異なり、クライアントの ID がサーバーに知られています。

サーバーがリクエストされたリソースを発見できないことを示します。 ブラウザーでは、これは URL が解釈できなかったことを意味します。 API では、これは通信先が有効であるものの、リソース自体が存在しないことを意味することがあります。 サーバーは認証されていないクライアントからリソースの存在を隠すために、 403 の代わりにこのレスポンスを返すことがあります。 このレスポンスコードはウェブで頻繁に見られるため、おそらくもっとも有名なコードでしょう。

サーバーがリクエストメソッドを理解しているものの、無効にされており使用することができません。例えば、 API がリソースを DELETE することを禁止できます。 GET および HEAD の 2 つは必須で、無効にすることができず、このエラーコードを返してはいけません。

このレスポンスは、ウェブサーバーが サーバー駆動型コンテンツネゴシエーション (en-US) を行った結果、ユーザーエージェントから与えられた条件に合うコンテンツが見つからない場合に送信されます。

これは 401 Unauthorized と似ていますが、プロキシーサーバーが認証を要求している点が異なります。

このレスポンスはクライアントが以前にリクエストを行っていない、アイドル状態の接続において一部のサーバーが送信します。 サーバーが使用していない接続の終了を望んでいることを示します。 このレスポンスは Chrome、 Firefox 27 以降、IE9 など、閲覧を高速化するための HTTP 事前接続機能を使用する一部のブラウザーでよく使用します。 また、一部のサーバーはこのメッセージを送らずに接続を閉じることに注意してください。

このレスポンスは、リクエストがサーバーの現在の状態と矛盾する場合に送られるでしょう。

このレスポンスは、リクエストされたコンテンツがサーバーから永久に削除され、転送先アドレスがない場合に送られます。 クライアントはこのリソースへのキャッシュやリンクを削除することが期待されます。 HTTP 仕様書ではこのコードを「期間限定のプロモーションサービス」に使用することを意図しています。 API はこのステータスコードの場合、削除されたリソースを無理に示そうとするべきではありません。

サーバーが Content-Length ヘッダーフィールドを要求しているが、リクエストで定義されていないために、サーバーがリクエストを拒否したことを示します。

サーバー側で適合しない前提条件が、クライアント側のヘッダーに含まれていることを示します。

リクエストの本体がサーバーで定めている上限を超えていることを示します。 サーバーは接続を閉じるか、Retry-After ヘッダーフィールドを返します。

クライアントがリクエストした URI が、サーバーで扱える長さを超えていることを示します。

リクエストされたデータのメディア形式をサーバーが対応しておらず、サーバーはリクエストを拒否したことを示します。

リクエスト内の Range ヘッダーフィールドで指定された範囲を満たすことができないことを示します。 指定した範囲が、目的の URI のデータサイズを超えている可能性があります。

このレスポンスコードは、Expect リクエストヘッダーで指定された内容がサーバー側と適合しないことを示します。

サーバーは、ティーポットでコーヒーを淹れようとする試みを拒否します。

リクエストは、レスポンスを生成できないサーバーに送られました。 リクエストの URI に含まれているスキームや権限の組み合わせに対してレスポンスを生成するよう設定されていないサーバーが、このコードを送ることがあります。

リクエストは適正ですが、意味が誤っているために従うことができません。

アクセス中のリソースはロックされています。

前のリクエストが失敗したため、このリクエストも失敗しました。

サーバーが、繰り返される可能性のあるリクエストを処理するリスクを望まないことを示します。

サーバーは現在のプロトコルを使用したリクエストの実行を拒否しましたが、クライアントが別のプロトコルにアップグレードした後は受け入れることができます。 サーバーは必要なプロトコルを示すために、426 のレスポンスで Upgrade ヘッダーフィールドを送信しなければなりません。

オリジンサーバーはリクエストが条件付きになることを必要としています。 このレスポンスは「ロストアップデート問題」 (クライアントがリソースの状態を取得して変更およびサーバーに送信している間に、第三者がサーバーの状態を変更して競合が発生すること) を防ごうとするものです。

ユーザーは一定の時間内に大量のリクエストを送信しました ("レート制限")。

ヘッダーフィールドが大きすぎるため、サーバーはリクエストの処理を望みません。 ヘッダーフィールドのサイズを削減した後に、リクエストを再送信できます。

ユーザーエージェントが政府によって検閲されたウェブページなど、違法なリソースをリクエストしています。

サーバー側で処理方法がわからない事態が発生したことを示します。

リクエストメソッドをサーバーが対応しておらず、扱えないことを示します。サーバーが対応しなければならない (従って、このコードを返してはならない) メソッドは GET と HEAD だけです。

このエラーレスポンスは、リクエストの処理に必要なレスポンスを受け取るゲートウェイとして動作するサーバーが無効なレスポンスを受け取ったことを示します。

サーバーはリクエストを処理する準備ができていないことを示します。 一般的な原因は、サーバーがメンテナンスや過負荷でダウンしていることです。 このレスポンスとともに問題について説明する、ユーザーにわかりやすいページを送信するべきであることに注意してください。 このレスポンスは一時的な状況について使用するものであり、また可能であれば、サービスが復旧する前に HTTP の Retry-After ヘッダーに予定時刻を含めてください。 また、これら一時的な状況のレスポンスは通常キャッシュされるべきではないことから、ウェブ管理者はこのレスポンスとともに送られるキャッシュ関連のヘッダーに注意しなければなりません。

このエラーレスポンスは、ゲートウェイとして動作するサーバーが時間内にレスポンスを得られない場合に送られます。

リクエストで使用した HTTP のバージョンにサーバーが対応していないことを示します。

サーバーに内部構成エラーがあることを示します。選択したバリアントリソースが透過的コンテンツネゴシエーション自体に携わるよう設定されており、ネゴシエーションプロセスが正しく終了しなかったことを示します。

サーバーがリクエストを完了させるのに必要な表現を保存することができなかったため、メソッドがリソースに対して実行できなかったことを示します。

サーバーは、リクエストの処理中に無限ループを検出しました。

サーバーがリクエストを処理するために、リクエストをさらに拡張することが必要です。

クライアントがネットワークでアクセスするために認証が必要であることを示します。