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

3. Storing Responses in Caches (キャッシュへの応答の保存)

以下のすべての条件が満たされない限り、キャッシュはリクエストに対する応答を保存してはなりません (MUST NOT):

  • リクエストメソッドがキャッシュによって理解されている;

  • 応答ステータスコードが最終的 (Final) である ([HTTP]のセクション15を参照);

  • 応答ステータスコードが206または304の場合、またはmust-understandキャッシュディレクティブが存在する場合 (セクション5.2.2.3を参照): キャッシュがその応答ステータスコードを理解している;

  • no-storeキャッシュディレクティブが応答に存在しない (セクション5.2.2.5を参照);

  • キャッシュが共有されている場合: private応答ディレクティブが存在しないか、共有キャッシュが変更された応答を保存することを許可している (セクション5.2.2.7を参照);

  • キャッシュが共有されている場合: リクエストにAuthorizationヘッダーフィールド ([HTTP]のセクション11.6.2を参照) が存在しないか、応答ディレクティブが共有キャッシュを明示的に許可している (セクション3.5を参照); および

  • 応答が以下の少なくとも1つを含んでいる:

    • public応答ディレクティブ (セクション5.2.2.9を参照);

    • キャッシュが共有されていない場合のprivate応答ディレクティブ (セクション5.2.2.7を参照);

    • Expiresヘッダーフィールド (セクション5.3を参照);

    • max-age応答ディレクティブ (セクション5.2.2.1を参照);

    • キャッシュが共有されている場合: s-maxage応答ディレクティブ (セクション5.2.2.10を参照);

    • キャッシングを許可するキャッシュ拡張 (セクション5.2.3を参照); または

    • ヒューリスティックにキャッシュ可能 (Heuristically Cacheable) として定義されたステータスコード (セクション4.2.2を参照)。

キャッシュ拡張は上記の要件のいずれかをオーバーライドできることに注意してください。セクション5.2.3を参照してください。

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

通常の動作では、キャッシュバリデータ (Cache Validator) も明示的な有効期限も持たない応答は、多くの場合保存する価値がないため、一部のキャッシュはそのような応答を保存しないことに注意してください。ただし、キャッシュはそのような応答を保存することを禁止されていません。

3.1 Storing Header and Trailer Fields (ヘッダーフィールドとトレーラーフィールドの保存)​

キャッシュは、応答を保存する際に、認識されないフィールドを含め、受信したすべての応答ヘッダーフィールドを含めなければなりません (MUST)。これにより、新しいHTTPヘッダーフィールドを正常に展開できます。ただし、以下の例外があります:

  • Connectionヘッダーフィールドとその中に名前が列挙されているフィールドは、[HTTP]のセクション7.6.1に従って、メッセージを転送する前に削除しなければなりません (MUST)。これは、保存する前に削除することで実現できます (MAY)。

  • 同様に、一部のフィールドのセマンティクスは、メッセージを転送する前にそれらを削除することを要求しており、これは保存する前に削除することで実現できます (MAY)。いくつかの例については、[HTTP]のセクション7.6.1を参照してください。

  • no-cache (セクション5.2.2.4) およびprivate (セクション5.2.2.7) キャッシュディレクティブは、それぞれすべてのキャッシュおよび共有キャッシュがヘッダーフィールドを保存することを防ぐパラメータを持つことができます。

  • キャッシュがリクエストを転送する際に使用するプロキシ固有のヘッダーフィールドは、キャッシュがプロキシのアイデンティティをキャッシュキーに組み込まない限り、保存してはなりません (MUST NOT)。実際には、これはProxy-Authenticate ([HTTP]のセクション11.7.1)、Proxy-Authentication-Info ([HTTP]のセクション11.7.3)、およびProxy-Authorization ([HTTP]のセクション11.7.2) に限定されます。

キャッシュは、トレーラーフィールド (Trailer Fields) をヘッダーフィールドとは別に保存するか、破棄してもかまいません (MAY)。キャッシュは、トレーラーフィールドをヘッダーフィールドと結合してはなりません (MUST NOT)。

3.2 Updating Stored Header Fields (保存されたヘッダーフィールドの更新)​

さまざまな場合において、キャッシュは別の (通常はより新しい) 応答から保存された応答のヘッダーフィールドを更新する必要があります。たとえば、セクション3.4、4.3.4、および4.3.5を参照してください。

その際、キャッシュは、提供する応答の各ヘッダーフィールドを保存された応答に追加し、既存のフィールド値を置き換えなければなりません (MUST)。ただし、以下の例外があります:

  • セクション3.1に従って保存から除外されるヘッダーフィールド、

  • キャッシュの保存された応答が依存しているヘッダーフィールド (以下で説明)、

  • 受信者によって自動的に処理および削除されるヘッダーフィールド (以下で説明)、および

  • Content-Lengthヘッダーフィールド。

場合によっては、キャッシュ (特にユーザーエージェント内) は、応答自体ではなく、受信した応答を処理した結果を保存し、その処理に影響を与えるヘッダーフィールドを更新すると、一貫性のない動作やセキュリティ問題が発生する可能性があります。このような場合、キャッシュは例外として保存された応答の更新からこれらのヘッダーフィールドを省略してもかまいません (MAY) が、保存された応答の整合性を確保するために必要なフィールドにそのような省略を限定すべきです (SHOULD)。

たとえば、ブラウザは受信時に応答のコンテンツエンコーディング (Content Coding) をデコードする可能性があり、保存されたデータと応答の元のメタデータとの間に不整合が生じます。その保存されたメタデータを異なるContent-Encodingヘッダーフィールドで更新することは問題があります。同様に、ブラウザは応答で受信したコンテンツではなく、解析されたHTMLツリーを保存する可能性があります。この状況でContent-Typeヘッダーフィールドを更新することは実行可能ではありません。なぜなら、解析中に形式について行われた仮定がすでに組み込まれているためです。

また、Content-Rangeヘッダーフィールドなど、一部のフィールドはHTTP実装によって自動的に処理および削除されます。実際に処理が行われていない場合でも、実装はこれらのヘッダーフィールドを更新から自動的に省略してもかまいません (MAY)。

Content-*プレフィックスは、ヘッダーフィールドが更新から省略されることを意味するものではないことに注意してください。これはMIMEヘッダーフィールドの規則であり、HTTPの規則ではありません。

3.3 Storing Incomplete Responses (不完全な応答の保存)​

リクエストメソッドがGETで、応答ステータスコードが200 (OK) で、応答ヘッダーセクション全体が受信されている場合、キャッシュは不完全な応答 ([HTTP]のセクション6.1を参照) を保存してもかまいません (MAY)。ただし、保存された応答は不完全として記録されている必要があります。同様に、206 (Partial Content) 応答は、不完全な200 (OK) 応答として保存してもかまいません (MAY)。ただし、キャッシュがRangeおよびContent-Rangeヘッダーフィールドをサポートしていない場合、またはそれらのフィールドで使用されている範囲単位 (Range Units) を理解していない場合、キャッシュは不完全または部分的なコンテンツ応答を保存してはなりません (MUST NOT)。

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

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

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

新しい応答を1つ以上の保存された応答と組み合わせる場合、キャッシュは、セクション3.2に従って、新しい応答で提供されたヘッダーフィールドを使用して、保存された応答のヘッダーフィールドを更新しなければなりません (MUST)。

3.5 Storing Responses to Authenticated Requests (認証されたリクエストへの応答の保存)​

共有キャッシュは、Authorizationヘッダーフィールド ([HTTP]のセクション11.6.2を参照) を含むリクエストに対するキャッシュされた応答を、応答が共有キャッシュによる保存を許可する応答ディレクティブ (セクション5.2.2) を含むCache-Controlフィールドを含み、キャッシュがその応答に対するそのディレクティブの要件に準拠している場合を除き、後続のリクエストを満たすために使用してはなりません (MUST NOT)。

本仕様では、以下の応答ディレクティブがこの効果を持ちます: must-revalidate (セクション5.2.2.2)、public (セクション5.2.2.9)、およびs-maxage (セクション5.2.2.10)。

に最終更新