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

3. キャッシュへの応答の格納

キャッシュは、次のすべてに該当しない限り、いかなるリクエストへの応答も格納してはならない (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 参照)、または

    • そのキャッシュを許可するキャッシュ制御拡張を含む (セクション 5.2.3 参照)、または

    • 既定でキャッシュ可能と定義されているステータスコードを持つ (セクション 4.2.2 参照)、または

    • public 応答ディレクティブを含む (セクション 5.2.2.5 参照)。

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

この文脈において、キャッシュがリクエストメソッドや応答ステータスコードを「理解した」とは、それを認識し、規定されたキャッシュ関連の動作をすべて実装していることを意味します。

通常の運用では、キャッシュバリデータも明示的な有効期限も持たない応答は、格納しても通常は有用でないため、一部のキャッシュはそのような応答を格納しないことに注意してください。ただし、キャッシュがそのような応答を格納することは禁止されていません。

3.1. 不完全な応答の格納​

応答メッセージは、メッセージフレーミング ([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. 認証されたリクエストへの応答の格納​

共有キャッシュは、そのような応答の格納を許可するキャッシュディレクティブが応答に存在しない限り、Authorization ヘッダーフィールド ([RFC7235] のセクション 4.2) を含むリクエストへのキャッシュされた応答を、後続のいかなるリクエストの充足にも使用してはならない (MUST NOT)。

本仕様では、次の Cache-Control 応答ディレクティブ (セクション 5.2.2) がその効果を持ちます: must-revalidate、public、s-maxage。

"must-revalidate" および/または "s-maxage" 応答ディレクティブを含むキャッシュされた応答は、共有キャッシュが古い状態で提供すること (セクション 4.2.4) を許されないことに注意してください。特に、"max-age=0, must-revalidate" または "s-maxage=0" のいずれかを持つ応答は、オリジンサーバーで再検証することなく後続のリクエストを満たすために使用できません。

3.3. 部分コンテンツの結合​

接続が途中で閉じられた場合、またはリクエストが 1 つ以上の Range 指定子 ([RFC7233]) を使用した場合、応答は表現の一部のみを転送することがあります。そのような転送が数回行われると、キャッシュは同じ表現の複数の範囲を受け取っている可能性があります。それらがすべて同じ強バリデータを共有しており、キャッシュが [RFC7233] のセクション 4.3 のクライアント要件に従っている場合、キャッシュはこれらの範囲を単一の格納された応答に結合し、その応答を再利用して後続のリクエストを満たしてもよい (MAY)。

新しい応答を 1 つ以上の格納された応答と結合する場合、キャッシュは次を行わなければならない (MUST):

  • 格納された応答内の warn-code 1xx の Warning ヘッダーフィールドをすべて削除する (セクション 5.5 参照)。

  • 格納された応答内の warn-code 2xx の Warning ヘッダーフィールドをすべて保持する。そして、

  • 新しい応答で提供されたその他のヘッダーフィールド (Content-Range を除く) を使用して、格納された応答内の対応するヘッダーフィールドのすべてのインスタンスを置き換える。