メインコンテンツまでスキップ

3. キャッシュへのレスポンスの保存 (Storing Responses in Caches)

キャッシュは、次の条件を満たさない限り、いかなるリクエストへのレスポンスも保存してはならない (MUST NOT):

  • リクエストメソッドがキャッシュによって理解され、キャッシュ可能として定義されており、かつ
  • レスポンスステータスコードがキャッシュによって理解されており、かつ
  • "no-store"キャッシュディレクティブ（セクション5.2参照）がリクエストまたはレスポンスヘッダーフィールドに現れておらず、かつ
  • "private"レスポンスディレクティブ（セクション5.2.2.6参照）がレスポンスに現れていない（キャッシュが共有されている場合）、かつ
  • Authorizationヘッダーフィールド（[RFC7235] のセクション4.2参照）がリクエストに現れていない（キャッシュが共有されている場合）、ただしレスポンスが明示的に許可している場合を除く（セクション3.2参照）、かつ
  • レスポンスが次のいずれかを満たす:
    • Expiresヘッダーフィールドを含む（セクション5.3参照）、または
    • max-ageレスポンスディレクティブを含む（セクション5.2.2.8参照）、または
    • s-maxageレスポンスディレクティブを含み、キャッシュが共有されている（セクション5.2.2.9参照）、または
    • キャッシュを許可するCache Control拡張を含む（セクション5.2.3参照）、または
    • デフォルトでキャッシュ可能として定義されているステータスコードを持つ（セクション4.2.2参照）、または
    • publicレスポンスディレクティブを含む（セクション5.2.2.5参照）。

上記の要件のいずれも、キャッシュ制御拡張によって上書きできることに注意すること; セクション5.2.3を参照。

この文脈では、キャッシュがリクエストメソッドまたはレスポンスステータスコードを「理解した」とは、それを認識し、指定されたすべてのキャッシュ関連の動作を実装している場合を指す。

通常の操作では、一部のキャッシュは、キャッシュバリデータも明示的な有効期限も持たないレスポンスを保存しないことに注意すること。このようなレスポンスは通常、保存する価値がないためである。ただし、キャッシュがそのようなレスポンスを保存することは禁止されていない。

3.1. 不完全なレスポンスの保存 (Storing Incomplete Responses)​

レスポンスメッセージは、接続が閉じられる前にメッセージフレーミング（[RFC7230]）によって示されるすべてのオクテットが受信された場合に、完全であると見なされる。リクエストメソッドがGETであり、レスポンスステータスコードが200（OK）であり、レスポンスヘッダーセクション全体が受信された場合、キャッシュは、キャッシュエントリが不完全として記録されているときは、不完全なレスポンスメッセージ本文を保存してもよい (MAY)。同様に、206（Partial Content）レスポンスは、不完全な200（OK）キャッシュエントリであるかのように保存されてもよい (MAY)。ただし、キャッシュは、RangeおよびContent-Rangeヘッダーフィールドをサポートしていない場合、またはこれらのフィールドで使用される範囲単位を理解していない場合は、不完全または部分コンテンツのレスポンスを保存してはならない (MUST NOT)。

キャッシュは、後続の範囲リクエスト（[RFC7233]）を行い、成功したレスポンスをセクション3.3で定義されているように保存されたエントリと組み合わせることによって、保存された不完全なレスポンスを完成させてもよい (MAY)。キャッシュは、レスポンスが完成するか、リクエストが部分的であり、不完全なレスポンス内に完全に含まれる範囲を指定している場合を除き、不完全なレスポンスを使用してリクエストに応答してはならない (MUST NOT)。キャッシュは、206（Partial Content）ステータスコードで明示的にマークせずに、部分レスポンスをクライアントに送信してはならない (MUST NOT)。

3.2. 認証されたリクエストに対するレスポンスの保存 (Storing Responses to Authenticated Requests)​

共有キャッシュは、Authorizationヘッダーフィールド（セクション4.2 of [RFC7235]）を含むリクエストに対するキャッシュされたレスポンスを、そのようなレスポンスの保存を許可するキャッシュディレクティブがレスポンスに存在しない場合を除き、後続のリクエストを満たすために使用してはならない (MUST NOT)。

この仕様では、次のCache-Controlレスポンスディレクティブ（セクション5.2.2）がそのような効果を持つ: must-revalidate、public、およびs-maxage。

なお、must-revalidateおよび/またはs-maxageレスポンスディレクティブを含むキャッシュされたレスポンスは、共有キャッシュによって古いものとして提供されてはならない（セクション6? いいえ、セクション4.2.4）。具体的には、max-age=0, must-revalidateまたはs-maxage=0のいずれかを含むレスポンスは、オリジンサーバーで再検証せずに後続のリクエストを満たすために使用することはできない。

3.3. 部分コンテンツの結合 (Combining Partial Content)​

接続が早期に閉じられた場合、またはリクエストが1つ以上のRange指定子（[RFC7233]）を使用した場合、レスポンスは部分的な表現のみを転送することができる。そのような複数の転送の後、キャッシュは同じ表現の複数の範囲を受信している可能性がある。キャッシュは、それらがすべて同じ強力なバリデータを共有し、キャッシュが[RFC7233]のセクション4.3のクライアント要件を満たす場合、これらの範囲を単一の保存されたレスポンスに結合し、後続のリクエストを満たすためにそのレスポンスを再利用してもよい (MAY)。

新しいレスポンスを1つ以上の保存されたレスポンスと結合する際、キャッシュは以下を行わなければならない (MUST):

  • 警告コード1xxを持つ保存されたレスポンス内のすべてのWarningヘッダーフィールドを削除する（セクション5.5参照）;
  • 警告コード2xxを持つ保存されたレスポンス内のすべてのWarningヘッダーフィールドを保持する; および
  • Content-Rangeを除き、新しいレスポンスで提供される他のヘッダーフィールドを使用して、保存されたレスポンスの対応するヘッダーフィールドのすべてのインスタンスを置き換える。