5. ヘッダーフィールドの定義 (Header Field Definitions)

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

5.1. Age

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

Age = delta-seconds

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

Age ヘッダーフィールドの存在は、レスポンスがこのリクエストに対してオリジンサーバーによって生成または検証されなかったことを意味します。ただし、Age ヘッダーフィールドがないことは、オリジンに接続されたことを意味するものではありません。レスポンスは Age を実装していない HTTP/1.0 キャッシュから受信された可能性があるためです。

5.2. Cache-Control

「Cache-Control」ヘッダーフィールドは、リクエスト/レスポンスチェーン上のキャッシュに対するディレクティブを指定するために使用されます。このようなキャッシュディレクティブは一方向であり、リクエスト内のディレクティブの存在は、レスポンス内に同じディレクティブを与える必要があることを意味しません。

キャッシュは、本セクションで定義された Cache-Control ディレクティブの要件に従わなければなりません (MUST)。他で定義された Cache-Control ディレクティブの処理方法については、セクション 5.2.3 を参照してください。

注意: 一部の HTTP/1.0 キャッシュは Cache-Control を実装していない可能性があります。

プロキシは、キャッシュを実装しているかどうかにかかわらず、転送されたメッセージ内のキャッシュディレクティブを通過させなければなりません (MUST)。これは、そのアプリケーションに対するそれらの重要性にかかわらず、ディレクティブがリクエスト/レスポンスチェーン上のすべての受信者に適用される可能性があるためです。特定のキャッシュにディレクティブをターゲットにすることはできません。

キャッシュディレクティブはトークンで識別され、大文字と小文字を区別せずに比較され、トークンと引用文字列の両方の構文を使用できるオプションの引数があります。引数を定義する以下で定義されたディレクティブについては、受信者は両方の形式を受け入れるべきです (SHOULD)。たとえ一方が優先されると文書化されていても。この仕様で定義されていないディレクティブについては、受信者は両方の形式を受け入れなければなりません (MUST)。

Cache-Control   = 1#cache-directive

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

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

5.2.1. リクエスト Cache-Control ディレクティブ (Request Cache-Control Directives)

5.2.1.1. max-age

引数構文:

delta-seconds (セクション 1.2.1 を参照)

「max-age」リクエストディレクティブは、クライアントが指定された秒数よりも古いレスポンスを受け入れる意思がないことを示します。max-stale リクエストディレクティブも存在しない限り、クライアントは古いレスポンスを受け入れる意思がありません。

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

5.2.1.2. max-stale

引数構文:

delta-seconds (セクション 1.2.1 を参照)

「max-stale」リクエストディレクティブは、クライアントが鮮度有効期限を超えたレスポンスを受け入れる意思があることを示します。max-stale に値が割り当てられている場合、クライアントは鮮度有効期限を指定された秒数以内に超えたレスポンスを受け入れる意思があります。max-stale に値が割り当てられていない場合、クライアントは任意の年齢の古いレスポンスを受け入れる意思があります。

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

5.2.1.3. min-fresh

引数構文:

delta-seconds (セクション 1.2.1 を参照)

「min-fresh」リクエストディレクティブは、クライアントが鮮度有効期限が現在の年齢に指定された秒数を加えた値以上のレスポンスを受け入れる意思があることを示します。つまり、クライアントは少なくとも指定された秒数の間新鮮であるレスポンスを望んでいます。

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

5.2.1.4. no-cache

「no-cache」リクエストディレクティブは、キャッシュがオリジンサーバーでの正常な検証なしに格納されたレスポンスを使用してリクエストを満たしてはならない (MUST NOT) ことを示します。

5.2.1.5. no-store

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

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

このディレクティブを含むリクエストがキャッシュから満たされた場合、no-store リクエストディレクティブはすでに格納されているレスポンスには適用されないことに注意してください。

5.2.1.6. no-transform

「no-transform」リクエストディレクティブは、中間者（キャッシュを実装しているかどうかにかかわらず）が [RFC7230] のセクション 5.7.2 で定義されているペイロードを変換してはならない (MUST NOT) ことを示します。

5.2.1.7. only-if-cached

「only-if-cached」リクエストディレクティブは、クライアントが格納されたレスポンスのみを取得したいことを示します。このディレクティブを受信した場合、キャッシュはリクエストの他の制約と一致する格納されたレスポンスを使用して応答するか、504 (Gateway Timeout) ステータスコードで応答すべきです (SHOULD)。キャッシュのグループが良好な内部接続を持つ統一システムとして動作している場合、メンバーキャッシュはそのキャッシュグループ内でこのようなリクエストを転送することができます (MAY)。

5.2.2. レスポンス Cache-Control ディレクティブ (Response Cache-Control Directives)

5.2.2.1. must-revalidate

「must-revalidate」レスポンスディレクティブは、古くなった後、キャッシュがオリジンサーバーでの正常な検証なしにレスポンスを使用して後続のリクエストを満たしてはならない (MUST NOT) ことを示します。

must-revalidate ディレクティブは、特定のプロトコル機能の信頼性のある動作をサポートするために必要です。すべての状況において、キャッシュは must-revalidate ディレクティブに従わなければなりません (MUST)。特に、キャッシュが何らかの理由でオリジンサーバーに到達できない場合、504 (Gateway Timeout) レスポンスを生成しなければなりません (MUST)。

must-revalidate ディレクティブは、表現に対するリクエストの検証に失敗すると、サイレントに実行されない金融取引のような不正な動作が発生する可能性がある場合にのみ、サーバーによって使用されるべきです (SHOULD)。

5.2.2.2. no-cache

引数構文:

#field-name

「no-cache」レスポンスディレクティブは、レスポンスがオリジンサーバーでの正常な検証なしに後続のリクエストを満たすために使用されてはならない (MUST NOT) ことを示します。これにより、オリジンサーバーは、キャッシュがそれに接触せずにリクエストを満たすために使用することを防ぐことができます。これは、古いレスポンスを送信するように設定されたキャッシュからも含まれます。

no-cache レスポンスディレクティブが 1 つ以上のフィールド名を指定する場合、キャッシュはキャッシングに関する他の制限に従って、後続のリクエストを満たすためにレスポンスを使用することができます (MAY)。ただし、リストされたフィールド名を持つレスポンス内のヘッダーフィールドは、オリジンサーバーとの正常な再検証なしに後続のリクエストへのレスポンスで送信されてはなりません (MUST NOT)。これにより、オリジンサーバーはレスポンス内の特定のヘッダーフィールドの再利用を防ぐことができますが、レスポンスの残りの部分のキャッシングは引き続き許可されます。

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

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

注意: 多くの実装にバックポートされていますが、一部の HTTP/1.0 キャッシュはこのディレクティブを認識しないか従わない場合があります。さらに、フィールド名を持つ no-cache レスポンスディレクティブは、通常、非修飾の no-cache ディレクティブを受信したかのようにキャッシュによって処理されます。つまり、修飾形式の特別な処理は広く実装されていません。

5.2.2.3. no-store

「no-store」レスポンスディレクティブは、キャッシュが即座のリクエストまたはレスポンスのいずれの部分も格納してはならない (MUST NOT) ことを示します。このディレクティブはプライベートキャッシュと共有キャッシュの両方に適用されます。このコンテキストでの「格納してはならない」とは、キャッシュが意図的に情報を不揮発性ストレージに格納してはならず (MUST NOT)、転送後できるだけ早く揮発性ストレージから情報を削除するために最善の努力をしなければならない (MUST) ことを意味します。

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

5.2.2.4. no-transform

「no-transform」レスポンスディレクティブは、中間者（キャッシュを実装しているかどうかにかかわらず）が [RFC7230] のセクション 5.7.2 で定義されているペイロードを変換してはならない (MUST NOT) ことを示します。

5.2.2.5. public

「public」レスポンスディレクティブは、レスポンスが通常キャッシュ不可能であるか、プライベートキャッシュ内でのみキャッシュ可能である場合でも、任意のキャッシュがレスポンスを格納できる (MAY) ことを示します。（Authorization を含むリクエストへの応答での public の使用に関する追加の詳細についてはセクション 3.2 を、デフォルトでキャッシュ可能として定義されていないステータスコードのために通常格納されないレスポンスに public がどのように影響するかの詳細についてはセクション 3 を参照してください。セクション 4.2.2 を参照。）

5.2.2.6. private

引数構文:

#field-name

「private」レスポンスディレクティブは、レスポンスメッセージが単一のユーザーを対象としており、共有キャッシュによって格納されてはならない (MUST NOT) ことを示します。プライベートキャッシュはレスポンスを格納し、後続のリクエストに対して再利用することができます (MAY)。レスポンスが通常キャッシュ不可能である場合でも。

private レスポンスディレクティブが 1 つ以上のフィールド名を指定する場合、この要件はリストされたレスポンスヘッダーフィールドに関連付けられたフィールド値に限定されます。つまり、共有キャッシュは指定されたフィールド名を格納してはならず (MUST NOT)、レスポンスメッセージの残りの部分を格納することができます (MAY)。

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

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

注意: 「private」のこの使用は、レスポンスが格納できる場所のみを制御します。メッセージ内容のプライバシーを保証することはできません。さらに、フィールド名を持つ private レスポンスディレクティブは、通常、非修飾の private ディレクティブを受信したかのようにキャッシュによって処理されます。つまり、修飾形式の特別な処理は広く実装されていません。

5.2.2.7. proxy-revalidate

「proxy-revalidate」レスポンスディレクティブは must-revalidate レスポンスディレクティブと同じ意味を持ちますが、プライベートキャッシュには適用されません。

5.2.2.8. max-age

引数構文:

delta-seconds (セクション 1.2.1 を参照)

「max-age」レスポンスディレクティブは、その年齢が指定された秒数を超えた後、レスポンスが古いと見なされることを示します。

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

5.2.2.9. s-maxage

引数構文:

delta-seconds (セクション 1.2.1 を参照)

「s-maxage」レスポンスディレクティブは、共有キャッシュにおいて、このディレクティブで指定された最大年齢が max-age ディレクティブまたは Expires ヘッダーフィールドで指定された最大年齢を上書きすることを示します。s-maxage ディレクティブは proxy-revalidate レスポンスディレクティブのセマンティクスも意味します。

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

5.2.3. Cache-Control 拡張 (Cache Control Extensions)

Cache-Control ヘッダーフィールドは、オプションの値を持つ 1 つ以上のキャッシュ拡張トークンを使用して拡張できます。キャッシュは認識されないキャッシュディレクティブを無視しなければなりません (MUST)。

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

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

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

Cache-Control: private, community="UCI"

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

5.3. Expires

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

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

Expires 値は [RFC7231] のセクション 7.1.1.1 で定義されている HTTP-date タイムスタンプです。

Expires = HTTP-date

例えば：

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

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

レスポンスに max-age ディレクティブ（セクション 5.2.2.8）を持つ Cache-Control フィールドが含まれている場合、受信者は Expires フィールドを無視しなければなりません (MUST)。同様に、レスポンスに s-maxage ディレクティブ（セクション 5.2.2.9）が含まれている場合、共有キャッシュ受信者は Expires フィールドを無視しなければなりません (MUST)。これら両方の場合、Expires 内の値は Cache-Control フィールドをまだ実装していない受信者のみを対象としています。

時計を持たないオリジンサーバーは、その値が過去の固定時刻（常に期限切れ）を表すか、その値が信頼できる時計を持つシステムまたはユーザーによってリソースに関連付けられている場合を除き、Expires フィールドを生成してはなりません (MUST NOT)。

歴史的に、HTTP は Expires フィールド値が将来 1 年以内であることを要求していました。より長い鮮度有効期間はもはや禁止されていませんが、非常に大きな値は問題を引き起こすことが実証されており（例えば、時間値に 32 ビット整数を使用することによる時計オーバーフロー）、多くのキャッシュはそれよりはるかに早くレスポンスを追い出します。

5.4. Pragma

「Pragma」ヘッダーフィールドは HTTP/1.0 キャッシュとの後方互換性を可能にし、クライアントが理解する「no-cache」リクエストを指定できるようにします（Cache-Control は HTTP/1.1 まで定義されていなかったため）。リクエストで Cache-Control ヘッダーフィールドも存在し理解されている場合、Pragma は無視されます。

HTTP/1.0 では、Pragma は受信者の実装固有のディレクティブの拡張可能なフィールドとして定義されていました。この仕様は、相互運用性を向上させるためにそのような拡張を非推奨にします。

Pragma           = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]

リクエストに Cache-Control ヘッダーフィールドが存在しない場合、キャッシュは no-cache リクエストプラグマディレクティブを「Cache-Control: no-cache」が存在するのと同じ効果を持つものと見なさなければなりません (MUST)（セクション 5.2.1 を参照）。

no-cache リクエストを送信する場合、クライアントは pragma ディレクティブと cache-control ディレクティブの両方を含めるべきです (OUGHT)。ただし、HTTP/1.1 キャッシュの他の Cache-Control レスポンスディレクティブをターゲットにするために Cache-Control: no-cache が意図的に省略されている場合を除きます。例えば：

GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

これにより、HTTP/1.1 キャッシュは 30 秒より古くないレスポンスを提供するように制約され、Cache-Control を理解しない実装がキャッシュされたレスポンスを提供することを防ぎます。

注意: レスポンスでの「Pragma: no-cache」の意味は指定されていないため、それらに対して信頼性のある「Cache-Control: no-cache」の代替を提供することはできません。

5.5. Warning

「Warning」ヘッダーフィールドは、ステータスコードに反映されない可能性のあるメッセージのステータスまたは変換に関する追加情報を伝達するために使用されます。この情報は通常、キャッシング操作またはメッセージのペイロードに適用された変換によって導入される可能性のある不正確さについて警告するために使用されます。

警告は、キャッシュに関連する目的とその他の目的の両方に使用できます。エラーステータスコードではなく警告を使用することで、これらのレスポンスを真の失敗と区別します。

Warning ヘッダーフィールドは一般的に任意のメッセージに適用できますが、一部の警告コードはキャッシュに固有であり、レスポンスメッセージにのみ適用できます。

Warning       = 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text
                                      [ SP warn-date ]

warn-code  = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-text  = quoted-string
warn-date  = DQUOTE HTTP-date DQUOTE

レスポンス内で複数の警告を生成できます（オリジンサーバーまたはキャッシュによって）。これには、同じ警告コード番号を持ち、警告テキストのみが異なる複数の警告も含まれます。

1 つ以上の Warning ヘッダーフィールドを受信するユーザーエージェントは、レスポンスに表示される順序で、可能な限り多くの警告をユーザーに通知すべきです (SHOULD)。複数の Warning ヘッダーフィールドを生成する送信者は、このユーザーエージェントの動作を念頭に置いてそれらを順序付けることが推奨されます。新しい Warning ヘッダーフィールドを生成する送信者は、既存の Warning ヘッダーフィールドの後にそれらを追加しなければなりません (MUST)。

警告には 3 桁の警告コードが割り当てられます。最初の桁は、検証後に格納されたレスポンスから警告を削除する必要があるかどうかを示します：

• 1xx 警告コードはレスポンスの鮮度または検証ステータスを説明し、したがって検証後にキャッシュによって削除されなければなりません (MUST)。これらはキャッシュがキャッシュエントリを検証する際にのみ生成でき、他のどの状況でも生成してはなりません (MUST NOT)。

• 2xx 警告コードは検証によって修正されない表現の側面（例えば、表現の損失圧縮）を説明し、完全なレスポンスが送信されない限り、検証後にキャッシュによって削除してはなりません (MUST NOT)。その場合、削除しなければなりません (MUST)。

送信者が HTTP/1.0 のみを実装していることが知られている受信者に送信されるメッセージ内で 1 つ以上の 1xx 警告コードを生成する場合、送信者は各対応する警告値にメッセージ内の Date ヘッダーフィールドに一致する警告日を含めなければなりません (MUST)。例えば：

HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"

警告には、エラーを説明する付随する警告テキストがあります（例えば、ログ記録用）。これは助言的なものであり、その内容は警告コードの解釈に影響しません。

Warning ヘッダーフィールドを使用、評価、または表示する受信者が、同じメッセージ内の Date 値とは異なる警告日を受信した場合、受信者はメッセージを格納、転送、または使用する前に、その警告日を含む警告値を除外しなければなりません (MUST)。これにより、受信者はキャッシュ検証後に不適切に保持された警告値を除外できます。すべての警告値が除外された場合、受信者は Warning ヘッダーフィールドも除外しなければなりません (MUST)。

以下の警告コードがこの仕様で定義されており、それぞれに英語での推奨警告テキストとその意味の説明があります。追加の警告コードを定義する手順はセクション 7.2.1 で説明されています。

5.5.1. Warning: 110 - "Response is Stale"

送信されたレスポンスが古い場合は常に、キャッシュはこれを生成すべきです (SHOULD)。

5.5.2. Warning: 111 - "Revalidation Failed"

サーバーに到達できないためレスポンスの検証の試行が失敗した場合に古いレスポンスを送信する際、キャッシュはこれを生成すべきです (SHOULD)。

5.5.3. Warning: 112 - "Disconnected Operation"

キャッシュが意図的に一定期間ネットワークの残りの部分から切断されている場合、これを生成すべきです (SHOULD)。

5.5.4. Warning: 113 - "Heuristic Expiration"

キャッシュがヒューリスティックに 24 時間を超える鮮度有効期間を選択し、レスポンスの年齢が 24 時間を超える場合、これを生成すべきです (SHOULD)。

5.5.5. Warning: 199 - "Miscellaneous Warning"

警告テキストには、人間のユーザーに提示またはログに記録される任意の情報を含めることができます。この警告を受信するシステムは、ユーザーに警告を提示する以外の自動化されたアクションを取ってはなりません (MUST NOT)。

5.5.6. Warning: 214 - "Transformation Applied"

この警告コードは、プロキシが表現に変換を適用する場合（content-coding の変更、media-type の変更、または表現データの変更など）、この警告コードがレスポンスにすでに表示されていない限り、追加しなければなりません (MUST)。

5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"

警告テキストには、人間のユーザーに提示またはログに記録される任意の情報を含めることができます。この警告を受信するシステムは、自動化されたアクションを取ってはなりません (MUST NOT)。