5. Field Definitions (フィールド定義)

このセクションでは、キャッシュに関連するHTTPフィールドの構文と意味論を定義します。

5.1 Age

「Age」応答ヘッダーフィールドは、オリジンサーバーで応答が生成または正常に検証されてから経過した時間の送信者の推定を伝えます。Age値はセクション4.2.3で指定されているように計算されます。

Age = delta-seconds

Ageフィールド値は非負整数で、秒単位の時間を表します（セクション1.2.2を参照）。

これは単一のヘッダーフィールドとして定義されていますが、リストベースのAgeフィールド値を持つメッセージに遭遇したキャッシュは、フィールド値の最初のメンバーを使用し、後続のメンバーを破棄すべきです（SHOULD）。

フィールド値（上記のように他のメンバーを破棄した後）が無効な場合（例えば、非負整数以外のものが含まれている場合）、キャッシュはそのフィールドを無視すべきです（SHOULD）。

Ageヘッダーフィールドの存在は、この要求に対して応答がオリジンサーバーによって生成または検証されなかったことを意味します。ただし、Ageヘッダーフィールドの欠如は、オリジンサーバーに連絡したことを意味するものではありません。

5.2 Cache-Control

「Cache-Control」ヘッダーフィールドは、要求/応答チェーンに沿ってキャッシュのディレクティブをリストするために使用されます。キャッシュディレクティブは一方向であり、要求内にディレクティブが存在しても、応答内に同じディレクティブが存在または複製されることを意味しません。

他の場所で定義されたCache-Controlディレクティブの処理方法については、セクション5.2.3を参照してください。

プロキシは、キャッシュを実装しているかどうかにかかわらず、転送されたメッセージ内のキャッシュディレクティブを渡さなければなりません（MUST）。これらのディレクティブがそのアプリケーションにとって意味を持つかどうかに関係なく、ディレクティブは要求/応答チェーン上のすべての受信者に適用される可能性があるためです。特定のキャッシュにディレクティブをターゲットにすることはできません。

キャッシュディレクティブはトークン（大文字小文字を区別せずに比較される）によって識別され、オプションの引数を持つことができます。引数はトークンと引用文字列の両方の構文を使用できます。引数が定義されている以下で定義されているディレクティブの場合、受信者は、特定の形式が生成に必要な場合でも、両方の形式を受け入れるべきです（SHOULD）。

Cache-Control   = #cache-directive

cache-directive = token [ "=" ( token / quoted-string ) ]

以下で定義されているキャッシュディレクティブについて、特に明記されていない限り、引数は定義されていません（許可もされていません）。

5.2.1 Request Directives (要求ディレクティブ)

このセクションでは、キャッシュ要求ディレクティブを定義します。これらは勧告的なものです。キャッシュはそれらを実装してもかまいません（MAY）が、必須ではありません。

5.2.1.1 max-age

引数構文:

delta-seconds（セクション1.2.2を参照）

max-age要求ディレクティブは、クライアントが年齢が指定された秒数以下の応答を好むことを示します。max-stale要求ディレクティブも存在しない限り、クライアントは古い応答を受け取りたくありません。

このディレクティブは引数構文のトークン形式を使用します: 例えば、'max-age=5'であり'max-age="5"'ではありません。送信者は引用文字列形式を生成してはなりません（MUST NOT）。

5.2.1.2 max-stale

引数構文:

delta-seconds（セクション1.2.2を参照）

max-stale要求ディレクティブは、クライアントが新鮮度ライフタイムを超えた応答を受け入れることを示します。値が存在する場合、クライアントは新鮮度ライフタイムを指定された秒数以内で超えた応答を受け入れる意思があります。max-staleに値が割り当てられていない場合、クライアントは任意の年齢の古い応答を受け入れます。

このディレクティブは引数構文のトークン形式を使用します: 例えば、'max-stale=10'であり'max-stale="10"'ではありません。送信者は引用文字列形式を生成してはなりません（MUST NOT）。

5.2.1.3 min-fresh

引数構文:

delta-seconds（セクション1.2.2を参照）

min-fresh要求ディレクティブは、クライアントが新鮮度ライフタイムが現在の年齢に指定された秒数を加えたもの以上である応答を好むことを示します。つまり、クライアントは少なくとも指定された秒数の間新鮮なままである応答を望んでいます。

このディレクティブは引数構文のトークン形式を使用します: 例えば、'min-fresh=20'であり'min-fresh="20"'ではありません。送信者は引用文字列形式を生成してはなりません（MUST NOT）。

5.2.1.4 no-cache

no-cache要求ディレクティブは、クライアントがオリジンサーバーでの正常な検証なしに保存された応答を使用して要求を満たさないことを好むことを示します。

5.2.1.5 no-store

no-store要求ディレクティブは、キャッシュがこの要求またはそれに対する任意の応答のいずれの部分も保存してはならない（MUST NOT）ことを示します。このディレクティブは、プライベートキャッシュと共有キャッシュの両方に適用されます。このコンテキストでの「MUST NOT store」とは、キャッシュが意図的に不揮発性ストレージに情報を保存してはならない（MUST NOT）こと、およびそれを転送した後できるだけ早く揮発性ストレージから情報を削除するために最善の努力をしなければならない（MUST）ことを意味します。

このディレクティブは、プライバシーを確保するための信頼性のある十分なメカニズムではありません。特に、悪意のあるまたは侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に脆弱である可能性があります。

このディレクティブを含む要求がキャッシュから満たされた場合、no-store要求ディレクティブは既に保存されている応答には適用されないことに注意してください。

5.2.1.6 no-transform

no-transform要求ディレクティブは、クライアントが中間装置に[HTTP]のセクション7.7で定義されているようにコンテンツの変換を避けるよう求めていることを示します。

5.2.1.7 only-if-cached

only-if-cached要求ディレクティブは、クライアントが保存された応答のみを取得したいことを示します。この要求ディレクティブを尊重するキャッシュは、それを受信したときに、要求の他の制約と一致する保存された応答、または504（Gateway Timeout）ステータスコードで応答すべきです（SHOULD）。

5.2.2 Response Directives (応答ディレクティブ)

このセクションでは、キャッシュ応答ディレクティブを定義します。キャッシュは、このセクションで定義されているCache-Controlディレクティブに従わなければなりません（MUST）。

5.2.2.1 max-age

引数構文:

delta-seconds（セクション1.2.2を参照）

max-age応答ディレクティブは、その年齢が指定された秒数より大きくなった後に応答を古いと見なすべきであることを示します。

このディレクティブは引数構文のトークン形式を使用します: 例えば、'max-age=5'であり'max-age="5"'ではありません。送信者は引用文字列形式を生成してはなりません（MUST NOT）。

5.2.2.2 must-revalidate

must-revalidate応答ディレクティブは、応答が古くなった後、キャッシュがセクション4.3で定義されているようにオリジンサーバーによって正常に検証されるまで、その応答を使用して別の要求を満たしてはならない（MUST NOT）ことを示します。

must-revalidateディレクティブは、特定のプロトコル機能の信頼性のある操作をサポートするために必要です。すべての状況において、キャッシュはmust-revalidateディレクティブを無視してはなりません（MUST NOT）。特に、キャッシュが切断されている場合、キャッシュは古い応答を再利用するのではなく、エラー応答を生成しなければなりません（MUST）。生成されるステータスコードは、他のエラーステータスコードがより適切でない限り、504（Gateway Timeout）であるべきです（SHOULD）。

サーバーは、要求の再検証に失敗すると不正確な操作（黙って実行されない金融取引など）を引き起こす可能性がある場合にのみ、must-revalidateディレクティブを使用すべきです（SHOULD）。

must-revalidateディレクティブはまた、共有キャッシュがAuthorizationヘッダーフィールド（[HTTP]のセクション11.6.2を参照）を含む要求に対する応答を再利用することを可能にしますが、上記の再検証要件に従う必要があります（セクション3.5）。

5.2.2.3 must-understand

must-understand応答ディレクティブは、応答のキャッシュを、その応答のステータスコードの要件を理解し、それに準拠するキャッシュに制限します。

must-understandディレクティブを含む応答は、no-storeディレクティブも含むべきです（SHOULD）。must-understandディレクティブを実装するキャッシュがそれを含む応答を受信した場合、キャッシュがステータスコードのキャッシュ要件を理解して実装している場合、キャッシュはno-storeディレクティブを無視すべきです（SHOULD）。

5.2.2.4 no-cache

引数構文:

#field-name

限定されていない形式（引数なし）のno-cache応答ディレクティブは、検証のために転送し、成功した応答を受信しない限り、応答を他の要求を満たすために使用してはならない（MUST NOT）ことを示します。セクション4.3を参照してください。

これにより、オリジンサーバーは、古い応答を送信するように構成されているキャッシュであっても、キャッシュが応答を使用して要求を満たすことを防ぐことができます。

引数を持つno-cache応答ディレクティブの限定形式（1つ以上のフィールド名をリストする）は、リストされたヘッダーフィールドが後続の応答から除外されるか、後続の応答がオリジンサーバーで正常に再検証された場合（これらのフィールドを更新または削除する）、キャッシュがキャッシングに関する他の制限に従う限り、後続の要求を満たすために応答を使用してもよい（MAY）ことを示します。これにより、オリジンサーバーは、応答の残りの部分のキャッシングを許可しながら、応答内の特定のヘッダーフィールドの再利用を防ぐことができます。

指定されたフィールド名は、この仕様で定義されているヘッダーフィールドのセットに限定されません。フィールド名は大文字小文字を区別しません。

このディレクティブは引数構文の引用文字列形式を使用します。送信者は、単一エントリリストに対して引用が必要でないように見える場合でも、トークン形式を生成すべきではありません（SHOULD NOT）。

注意: ディレクティブの限定形式は、多くの場合、限定されていないno-cacheディレクティブを受信したかのようにキャッシュによって処理されます。つまり、限定形式の特別な処理は広く実装されていません。

5.2.2.5 no-store

no-store応答ディレクティブは、キャッシュが即座の要求または応答のいずれの部分も保存してはならない（MUST NOT）こと、および他の要求を満たすために応答を使用してはならない（MUST NOT）ことを示します。

このディレクティブは、プライベートキャッシュと共有キャッシュの両方に適用されます。このコンテキストでの「MUST NOT store」とは、キャッシュが意図的に不揮発性ストレージに情報を保存してはならない（MUST NOT）こと、およびそれを転送した後できるだけ早く揮発性ストレージから情報を削除するために最善の努力をしなければならない（MUST）ことを意味します。

このディレクティブは、プライバシーを確保するための信頼性のある十分なメカニズムではありません。特に、悪意のあるまたは侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に脆弱である可能性があります。

must-understandキャッシュディレクティブは特定の状況でno-storeをオーバーライドすることに注意してください。セクション5.2.2.3を参照してください。

5.2.2.6 no-transform

no-transform応答ディレクティブは、中間装置（キャッシュを実装しているかどうかにかかわらず）が[HTTP]のセクション7.7で定義されているようにコンテンツを変換してはならない（MUST NOT）ことを示します。

5.2.2.7 private

引数構文:

#field-name

限定されていないprivate応答ディレクティブは、共有キャッシュが応答を保存してはならない（MUST NOT）こと（つまり、応答は単一のユーザーを対象としている）を示します。また、プライベートキャッシュがセクション3で定義されている制約に従う限り、応答がプライベートキャッシュによってヒューリスティックにキャッシュ可能でない場合でも、プライベートキャッシュが応答を保存してもよい（MAY）ことを示します。

限定されたprivate応答ディレクティブ（1つ以上のフィールド名をリストする引数を持つ）が存在する場合、リストされたヘッダーフィールドのみが単一のユーザーに制限されます: 元の応答にリストされたヘッダーフィールドが存在する場合、共有キャッシュはそれらを保存してはなりません（MUST NOT）が、セクション3で定義されている制約に従う限り、それらのヘッダーフィールドなしで応答メッセージの残りを保存してもかまいません（MAY）。

指定されたフィールド名は、この仕様で定義されているヘッダーフィールドのセットに限定されません。フィールド名は大文字小文字を区別しません。

このディレクティブは引数構文の引用文字列形式を使用します。送信者は、単一エントリリストに対して引用が必要でないように見える場合でも、トークン形式を生成すべきではありません（SHOULD NOT）。

注意: 「private」という言葉のこの使用法は、応答を保存できる場所のみを制御します。メッセージコンテンツのプライバシーを確保することはできません。また、ディレクティブの限定形式は、多くの場合、限定されていないprivateディレクティブを受信したかのようにキャッシュによって処理されます。つまり、限定形式の特別な処理は広く実装されていません。

5.2.2.8 proxy-revalidate

proxy-revalidate応答ディレクティブは、応答が古くなった後、共有キャッシュがセクション4.3で定義されているようにオリジンサーバーによって正常に検証されるまで、その応答を使用して別の要求を満たしてはならない（MUST NOT）ことを示します。これはmust-revalidate（セクション5.2.2.2）に類似していますが、proxy-revalidateはプライベートキャッシュには適用されません。

proxy-revalidate自体は応答がキャッシュ可能であることを意味しないことに注意してください。例えば、publicディレクティブ（セクション5.2.2.9）と組み合わせて応答のキャッシングを許可し、古くなったときに共有キャッシュのみに再検証を要求することができます。

5.2.2.9 public

public応答ディレクティブは、セクション3で定義されている制約に従う限り、応答が他の方法で禁止されている場合でも、キャッシュが応答を保存してもよい（MAY）ことを示します。言い換えれば、publicは応答を明示的にキャッシュ可能としてマークします。例えば、publicは共有キャッシュがAuthorizationヘッダーフィールド（セクション3.5）を含む要求に対する応答を再利用することを許可します。

セクション3によってすでにキャッシュ可能な応答にpublicディレクティブを追加する必要はないことに注意してください。

publicディレクティブを持つ応答に明示的な新鮮度情報がない場合、それはヒューリスティックにキャッシュ可能です（セクション4.2.2）。

5.2.2.10 s-maxage

引数構文:

delta-seconds（セクション1.2.2を参照）

s-maxage応答ディレクティブは、共有キャッシュの場合、このディレクティブで指定された最大年齢がmax-ageディレクティブまたはExpiresヘッダーフィールドで指定された最大年齢をオーバーライドすることを示します。

s-maxageディレクティブは、共有キャッシュに対してproxy-revalidate応答ディレクティブ（セクション5.2.2.8）のセマンティクスを含みます。共有キャッシュは、セクション4.3で定義されているようにオリジンサーバーによって正常に検証されるまで、s-maxageを持つ古い応答を使用して別の要求を満たしてはなりません（MUST NOT）。このディレクティブはまた、共有キャッシュがAuthorizationヘッダーフィールドを含む要求に対する応答を再利用することを許可しますが、最大年齢と再検証に関する上記の要件に従う必要があります（セクション3.5）。

このディレクティブは引数構文のトークン形式を使用します: 例えば、's-maxage=10'であり's-maxage="10"'ではありません。送信者は引用文字列形式を生成してはなりません（MUST NOT）。

5.2.3 Extension Directives (拡張ディレクティブ)

Cache-Controlヘッダーフィールドは、1つ以上の拡張キャッシュディレクティブの使用によって拡張できます。キャッシュは認識できないキャッシュディレクティブを無視しなければなりません（MUST）。

情報提供拡張（キャッシュ動作の変更を必要としない拡張）は、他のディレクティブのセマンティクスを変更せずに追加できます。

動作拡張は、既存のキャッシュディレクティブの基盤に対する修飾子として機能するように設計されています。新しいディレクティブと古いディレクティブの両方が提供されるため、新しいディレクティブを理解しないアプリケーションは古いディレクティブで指定された動作にデフォルトになり、新しいディレクティブを理解するアプリケーションは、古いディレクティブに関連する要件を変更するものとしてそれを認識します。このようにして、デプロイされたキャッシュを壊すことなく既存のキャッシュディレクティブへの拡張を行うことができます。

例えば、privateディレクティブの修飾子として機能する「community」という仮想の新しい応答ディレクティブを考えてみましょう: プライベートキャッシュに加えて、名前付きコミュニティのメンバーのみによって共有されるキャッシュが応答をキャッシュすることが許可されます。UCIコミュニティがその共有キャッシュでそうでなければプライベートな応答を使用できるようにしたいオリジンサーバーは、次のように含めることでそれを行うことができます:

Cache-Control: private, community="UCI"

そのようなcommunityキャッシュディレクティブを認識するキャッシュは、その拡張に従って動作を広げることができます。communityキャッシュディレクティブを認識しないキャッシュはそれを無視し、privateディレクティブに従います。

新しい拡張ディレクティブは、以下を定義することを考慮すべきです:

• ディレクティブが複数回指定されることが何を意味するか、

• ディレクティブ引数が存在する場合、引数が存在しないことが何を意味するか、

• ディレクティブ引数が必要な場合、引数が欠落していることが何を意味するか、および

• ディレクティブが要求固有、応答固有、または両方で使用可能かどうか。

5.2.4 Cache Directive Registry (キャッシュディレクティブレジストリ)

「ハイパーテキスト転送プロトコル（HTTP）キャッシュディレクティブレジストリ（Hypertext Transfer Protocol (HTTP) Cache Directive Registry）」は、キャッシュディレクティブの名前空間を定義します。これは作成され、現在https://www.iana.org/assignments/http-cache-directivesで維持されています。

登録には次のフィールドを含める必要があります（MUST）:

• キャッシュディレクティブ名

• 仕様テキストへのポインター

この名前空間に追加する値には、IETFレビュー（[RFC8126]のセクション4.8を参照）が必要です。

5.3 Expires

「Expires」応答ヘッダーフィールドは、応答が古いと見なされる日付/時刻を示します。新鮮度モデルの詳細については、セクション4.2を参照してください。

Expiresヘッダーフィールドの存在は、元のリソースがその時刻に、その前に、またはその後に変更されるか、存在しなくなることを意味するものではありません。

Expiresフィールド値は、[HTTP]のセクション5.6.7で定義されているHTTP-dateタイムスタンプです。キャッシュ固有の解析要件については、セクション4.2も参照してください。

Expires = HTTP-date

例:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

キャッシュ受信者は、無効な日付形式、特に値「0」を、過去の時刻（つまり、「すでに期限切れ」）を表すものとして解釈しなければなりません（MUST）。

応答がmax-ageディレクティブ（セクション5.2.2.1）を持つCache-Controlヘッダーフィールドを含む場合、受信者はExpiresヘッダーフィールドを無視しなければなりません（MUST）。同様に、応答がs-maxageディレクティブ（セクション5.2.2.10）を含む場合、共有キャッシュ受信者はExpiresヘッダーフィールドを無視しなければなりません（MUST）。これらのいずれかの場合、Expiresの値は、まだCache-Controlヘッダーフィールドを実装していない受信者のみを対象としています。

時計のないオリジンサーバー（[HTTP]のセクション5.6.7を参照）は、その値が過去の固定時刻（常に期限切れ）を表すか、その値が時計を持つシステムによってリソースに関連付けられている場合を除き、Expiresヘッダーフィールドを生成してはなりません（MUST NOT）。

歴史的に、HTTPはExpiresフィールド値が将来1年以内であることを要求していました。より長い新鮮度ライフタイムはもはや禁止されていませんが、極端に大きな値は問題を引き起こすことが実証されており（例えば、時刻値に32ビット整数を使用することによる時計オーバーフロー）、多くのキャッシュははるかに早く応答を削除します。

5.4 Pragma

「Pragma」要求ヘッダーフィールドは、HTTP/1.0キャッシュ用に定義されたため、クライアントが「no-cache」要求を指定できるようになりました（Cache-ControlはHTTP/1.1まで定義されていませんでした）。

ただし、Cache-Controlのサポートは現在広く普及しています。その結果、この仕様はPragmaを非推奨にします。

注意: 応答内の「Pragma: no-cache」の意味が指定されたことがないため、応答内の「Cache-Control: no-cache」の信頼できる代替を提供しません。

5.5 Warning

「Warning」ヘッダーフィールドは、ステータスコードに反映されない可能性のあるメッセージのステータスまたは変換に関する追加情報を伝えるために使用されていました。この仕様はそれを廃止します。これは広く生成されたり、ユーザーに表示されたりしないためです。それが伝えていた情報は、Ageなどの他のヘッダーフィールドを調べることで収集できます。