2xx Success (リクエスト成功)

概要

2xxコードは正常なレスポンスを示します。これは、クライアントからの要求されたアクションを正しく受信、理解、受理したことを意味します。

誰もが好きなレスポンス：リクエストが成功しました。

レスポンスペイロードは使用されるリクエストメソッドによって異なります。対応するリクエストメソッドに対するレスポンス本文は以下の通りです。

GET - リクエストされたリソースに対応するヘッダーとデータ
HEAD - 実際のデータ抜きでリクエストされたリソースに対応するヘッダーのみ
POST - アクションから取得したステータスまたは結果

200レスポンスは、常にペイロードが_なくてはなりません_が、義務ではありません。このようにオリジンサーバーの長さがゼロである200を生成するかもしれません。EFC規格に準拠するために、204はこうした場合（(例外はCONNECT)で生成されなければなりません。

デフォルトで、プロキシサーバーとブラウザがキャッシュできるようになっています。Cloudflareのキャッシュ制御で特定されていない場合、このレスポンスと静的リソースをエッジにおいてキャッシュのデフォルトを２時間で行います。

201 Created (作成完了）****( RFC7231)

リクエストが正常に完了し、複数のリソースが新しく作成されました。新しいリソースのロケーションは、LocationヘッダーフィールドまたはリクエストのURIのどちらかで提示されることが想定されます。通常、ペイロードは新しく生成されたリソースのリンクに記述し、参照します。

201レスポンスのETagやLast-Modifiedといった検証ヘッダーフィールドの意味と目的について話し合うために RFC 7231セクション7.2を参照してください。

202 Accepted (受理済み) ( RFC7231)

リクエストが受理され、現在オリジンサーバーで処理中です。サーバーの仕様によっては、実際にリクエストが実行中でもクライアントがリクエストを実行するかしないか、まだ決定していません。

203 Non-Authoritative information (非公式情報）****( RFC7231)

リクエストを説明する200ステータスコードの任意の置き換えは成功でしたが、オリジンサーバーから直接発生したものではありませんでした。オリジナルのオリジンサーバーからのレスポンスはプロキシまたは中間サーバーで変更されています。例えば、203を使って、クライアントにリソースがプロキシでキャッシュされたということを通知することができ、今後同様のリクエストが同一のリソースでそのキャッシュサーバーをヒットする可能性も、ヒットしない可能性もあります。他にも、ローカルオリジンサーバーにだけ適用可能なヘッダーが削除される場合の例があります。

デフォルトで、キャッシュ可能なレスポンスですが、Cloudflareはキャッシュしません。
Cloudflareが生成することはありませんが、存在する場合は他のプロキシからプロキシを行うことはあります。Cloudflareはオリジンレスポンスを尊重しますが、例外もあります： CloudflareがHTTPリクエストヘッダーをどのように処理するか

204 No Content (コンテンツなし) ( RFC7231)

要求されたアクションが、オリジンサーバーで正しく実行されました。一般的な使用事例は、ドキュメントエディターで「保存する」アクションがオリジンサーバーに送信されますが、ペイロードはクライアントに送り返されるために必要となります。保存が完了したことをユーザーに警告したい場合もまだあります。

204レスポンスを返す時に、ペイロードが存在してはいけません。
デフォルトで、キャッシュ可能なレスポンスですが、Cloudflareはキャッシュしません。

205 Reset Content (コンテンツをリセット)( RFC7231)

オリジンサーバーは、リクエストの前にクライアントがオリジナルのステートへの表示を再設定することを提案します。フォームや他の入力送信でよく用いられたのがペイロードで、リクエストで送信されます。オリジンサーバーが正常に動作し、今、追加の送信が許可されることをブラウザに通知しています。

205レスポンスは、ペイロードを返してはいけません。直後にクローズまたはゼロバイトのレスポンスが続くContent-Lengthが0、またはチャンクドレスポンスのみが許可されます。

206 Partial Content ( RFC 7233)

リソースの一部に対するリクエストが完了し、今ペイロードにあります。リクエストは次のいずれかの範囲を示す必要があります。

サイズとともにContent Rangeを含む、HTTPヘッダーの単一の一部リクエストです。（レスポンスヘッダーにある場合は、ペイロードのoctetsと全く等しいはずです）例： Content Range: bytes 21010-47021/47022
複数のチャンクとコンテンツタイプ：HTTPヘッダーのmultipart/byteranges とContent Rangeフィールドを含む個々のpartですが、レスポンスHTTPヘッダーには_ありません_。 RFC 7233 Section 4.1区で指定されている通り、区切り文字も必要となります。例

 HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Length: 1741 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 500-999/8000 ...the first range... --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 7000-7999/8000 ...the second range --THIS_STRING_SEPARATES--

206は、大きめのファイル処理をするクライアントにとって便利なものです。こうしたファイルの処理には、複数の同時ストリームでダウンロードを分割したり、中断する必要があるからです。

2xx Success (リクエスト成功)

​​ 2xx Success (リクエスト成功)

2xx Success (リクエスト成功)