Internet Engineering Task Force (IETF) R. Fielding, Editor
Request for Comments: 9111 Adobe
Obsoletes: 7234 M. Nottingham, Editor
STD: 98 Fastly
Category: Standards Track J. Reschke, Editor
ISSN: 2070-1721 greenbytes
June 2022

HTTP キャッシュ

概要

Hypertext Transfer Protocol (HTTP) は、分散型で協調的なハイパーテキスト情報システムのためのステートレスなアプリケーション層プロトコルです。本書では HTTP キャッシュと、キャッシュの動作を制御するかキャッシュ可能なレスポンスメッセージを示す関連ヘッダフィールドを定義します。

本書は RFC 7234 を廃止します。

本メモの状態

これはインターネット標準トラックの文書です。

本書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティのコンセンサスを表しています。本書は公開審査を受け、Internet Engineering Steering Group (IESG) により公開が承認されています。インターネット標準に関する詳細は RFC 7841 のセクション 2 を参照してください。

本書の現在の状況、訂正情報（errata）、およびフィードバックの提供方法に関する情報は https://www.rfc-editor.org/info/rfc9111 で入手できます。

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

1. 導入

Hypertext Transfer Protocol (HTTP) は、拡張可能なセマンティクスと自己記述的なメッセージを用いて、ネットワークベースのハイパーテキスト情報システムと柔軟にやり取りするためのステートレスなアプリケーション層のリクエスト/レスポンスプロトコルです。通常は分散型情報システムで使用され、レスポンスキャッシュを利用することで性能が向上します。本書はレスポンスメッセージのキャッシュおよび再利用に関連する HTTP の側面を定義します。

HTTP の キャッシュ は、レスポンスメッセージのローカルな保存領域と、その中のメッセージの格納、取得、削除を制御するサブシステムを指します。キャッシュは、同等の将来のリクエストに対してレスポンス時間およびネットワーク帯域幅の消費を削減するために、キャッシュ可能なレスポンスを格納します。任意のクライアントまたはサーバーはキャッシュを使用してもよい（MAY）が、トンネルとして動作している場合は使用してはなりません（Section 3.7 of [HTTP]）。

共有キャッシュは、複数のユーザーによる再利用のためにレスポンスを格納するキャッシュであり、通常（必ずしも常にではありませんが）インターメディアリの一部として配置されます。これに対して、プライベートキャッシュは単一のユーザーに専有されるキャッシュであり、多くの場合ユーザーエージェントのコンポーネントとして配置されます。

HTTP キャッシュの目的は、以前のレスポンスメッセージを再利用して現在のリクエストに応答することで性能を著しく向上させることです。キャッシュは、保存されたレスポンスが「検証」なしに再利用できる場合（定義は Section 4.2）にそのレスポンスを「新鮮」と見なします。新鮮なレスポンスはキャッシュがそれを再利用するたびに待ち時間とネットワーク負荷を低減します。保存されたレスポンスが新鮮でない場合でも、検証によって新鮮化できる場合（Section 4.3）や、オリジンが利用できない場合（Section 4.2.4）には再利用可能なことがあります。

本書は RFC 7234 を廃止し、その変更点は Appendix B に要約されています。

1.1. 要件の表記

本書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、すべて大文字で現れる場合に限り BCP 14 に記載された解釈に従うものとします（参照：[RFC2119] および [RFC8174]）。

Section 2 of [HTTP] では適合性基準が定義され、エラー処理に関する考慮事項が含まれています。

1.2. 構文表記

本仕様は Augmented Backus-Naur Form (ABNF) の表記法（[RFC5234]）を使用し、文字列の大文字小文字の区別に関する表記は [RFC7405] で定義された拡張を用います。

また、Section 5.6.1 of [HTTP] で定義されたリスト拡張を使用し、これは "#" 演算子を使ったコンマ区切りリストの簡潔な定義を可能にします（"*" 演算子が反復を示すのと類似）。Appendix A には、すべてのリスト演算子を標準 ABNF 表記に展開した収集済みの文法が示されています。

1.2.1. インポートされた規則

次のコアルールは参照により含まれており、[RFC5234] の Appendix B.1 に定義されています: DIGIT（10進の 0-9）。

[HTTP] は次の規則を定義します:

  HTTP-date     = <HTTP-date, see [HTTP], Section 5.6.7>
  OWS           = <OWS, see [HTTP], Section 5.6.3>
  field-name    = <field-name, see [HTTP], Section 5.1>
  quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
  token         = <token, see [HTTP], Section 5.6.2>

1.2.2. デルタ秒（delta-seconds）

delta-seconds ルールは、秒単位の非負整数を指定します。

delta-seconds 値を解析して二進形式に変換する受信者は、少なくとも 31 ビットの非負整数範囲を持つ算術型を使用することが望まれます。キャッシュが表現可能な最大整数より大きい delta-seconds 値を受け取るか、後続の計算のいずれかがオーバーフローする場合、キャッシュはその値を 2147483648（231）または便利に表現できる最大の正の整数と見なさなければなりません（MUST）。

2. キャッシュ動作の概要

適切なキャッシュ運用は HTTP 転送のセマンティクスを保持しつつ、既にキャッシュに保持されている情報の送信を減らします。一般的な用語やコア概念については、Section 3 of [HTTP] を参照してください。

キャッシュは HTTP の完全に OPTIONAL な機能ですが、キャッシュされたレスポンスを再利用することが望ましく、そのような再利用が妨げられる要件やローカル設定がない場合のデフォルト挙動であると見なすことができます。したがって、HTTP キャッシュ要件はキャッシュが非再利用可能なレスポンスを格納したり、保存されたレスポンスを不適切に再利用したりすることを防ぐことに重点を置いており、特定のレスポンスを必ず格納・再利用することを義務付けるものではありません。

キャッシュキーは、キャッシュがレスポンスを選択するために使用する情報であり、少なくとも保存されたレスポンスを取得するために使用されたリクエストのメソッドとターゲット URI から構成されます。メソッドは、そのレスポンスが後続のリクエストを満たすためにどのような状況で使用できるかを決定します。ただし、今日一般に使用されている多くの HTTP キャッシュは GET レスポンスのみをキャッシュするため、URI のみをキャッシュキーとして使用することが多いです。

コンテンツネゴシエーションの対象となるリクエストターゲットについて、キャッシュが複数のレスポンスを格納することがあります。キャッシュは、Vary レスポンスヘッダフィールドの情報を使って、元のリクエストの一部ヘッダフィールドをキャッシュキーに組み込むことで、これらのレスポンスを区別します（詳細は Section 4.1 を参照）。

キャッシュは追加の情報をキャッシュキーに組み込むことがあります。例えば、ユーザーエージェントのキャッシュは参照元サイトの識別子を含めて「二重キー化」し、いくつかのプライバシーリスクを回避することがあります（詳細は Section 7.2 を参照）。

もっとも一般的には、キャッシュは取得リクエストの成功結果（例えば GET リクエストに対する 200 (OK) レスポンスで、ターゲットリソースの表現を含む）を格納します（Section 9.3.1 of [HTTP]）。しかし、リダイレクト、負の結果（例: 404 (Not Found)）、不完全な結果（例: 206 (Partial Content)）、およびメソッドの定義がそのようなキャッシュを許可しキャッシュキーとして使用可能な何かを定義している場合には GET 以外のメソッドへのレスポンスを格納することも可能です。

キャッシュがオリジンサーバーに接続できない、またはリクエストのためのフォワード経路を見つけられない場合、そのキャッシュは 切断状態（disconnected）であると表現されます。切断されたキャッシュは特定の状況で期限切れのレスポンスを返すことができます（Section 4.2.4）。

3. キャッシュへのレスポンスの格納

キャッシュは次のいずれかの条件を満たさない限り、リクエストに対するレスポンスを格納してはなりません（MUST NOT）。

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

  • レスポンスのステータスコードが確定的であること（詳細は Section 15 of [HTTP] を参照）;

  • レスポンスのステータスコードが 206 または 304 である場合、または must-understand キャッシュディレクティブ（Section 5.2.2.3）が存在する場合：キャッシュがそのステータスコードを理解していること;

  • レスポンスに no-store キャッシュディレクティブが存在しないこと（Section 5.2.2.5 を参照）;

  • キャッシュが共有キャッシュである場合：private レスポンスディレクティブが存在しないか、共有キャッシュが修正したレスポンスを格納することを許すこと（詳細は Section 5.2.2.7 を参照）;

  • キャッシュが共有キャッシュである場合：リクエストに Authorization ヘッダーフィールドが存在しないこと（詳細は Section 11.6.2 of [HTTP] を参照）か、またはレスポンスに共有キャッシュでの格納を明示的に許可するレスポンスディレクティブが存在すること（詳細は Section 3.5 を参照）;

  • レスポンスが次のいずれかを少なくとも含んでいること:

    • public レスポンスディレクティブ（Section 5.2.2.9）;
    • キャッシュが共有でない場合の private レスポンスディレクティブ（Section 5.2.2.7）;
    • Expires ヘッダーフィールド（Section 5.3）;
    • max-age レスポンスディレクティブ（Section 5.2.2.1）;
    • キャッシュが共有である場合：s-maxage レスポンスディレクティブ（Section 5.2.2.10）;
    • キャッシュ可能であることを許すキャッシュ拡張（Section 5.2.3）;
    • ヒューリスティックにキャッシュ可能と定義されているステータスコード（Section 4.2.2）。

キャッシュ拡張はここに挙げた要件のいずれかをオーバーライドすることができる点に注意してください（詳しくは Section 5.2.3 を参照）。

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

通常の運用では、いくつかのキャッシュは検証子も明示的な有効期限も持たないレスポンスを格納しないことがあり、そうしたレスポンスは格納しても通常有用ではありません。ただし、キャッシュがそのようなレスポンスを格納することは禁止されていません。

3.1. ヘッダーおよびトレーラーフィールドの格納

キャッシュは、展開可能な新しい HTTP ヘッダーフィールドの導入が成功することを保証するため、受信したすべてのレスポンスヘッダーフィールド（未認識のものを含む）をレスポンス格納時に含めなければなりません（MUST）。ただし、次の例外があります:

  • The Connection ヘッダーフィールドおよびそれに列挙された名前のフィールドは、Section 7.6.1 of [HTTP] において転送前に削除することが要求されています。これは格納前に削除することで実装しても構いません。
  • 同様に、いくつかのフィールドのセマンティクスは転送前にそれらを削除することを要求し、これも格納前に削除することで実装してよい例があります（詳細は Section 7.6.1 of [HTTP] を参照）。
  • no-cache（Section 5.2.2.4）および private（Section 5.2.2.7）キャッシュディレクティブは、それぞれすべてのキャッシュおよび共有キャッシュによるヘッダーフィールドの格納を妨げる引数を持つことがあります。
  • キャッシュがリクエストを転送する際に使用するプロキシに固有のヘッダーフィールドは、キャッシュキーにプロキシの識別子を組み込まない限り格納してはなりません（MUST NOT）。実質的にこれは Proxy-Authenticate（Section 11.7.1 of [HTTP]）、Proxy-Authentication-Info（Section 11.7.3 of [HTTP]）、および Proxy-Authorization（Section 11.7.2 of [HTTP]）に限定されます。

キャッシュはトレーラーフィールドをヘッダーフィールドとは別に格納するか破棄してもよい（MAY）。キャッシュはトレーラーフィールドをヘッダーフィールドと結合してはならない（MUST NOT）。

3.2. 保存されたヘッダーフィールドの更新

キャッシュは、保存されたレスポンスのヘッダーフィールドを別の（通常はより新しい）レスポンスから更新することが要求される状況がいくつかあります。例えば、Section 3.4、4.3.4、および 4.3.5 を参照してください。

その際、キャッシュは提供されたレスポンス内の各ヘッダーフィールドを保存されたレスポンスに追加し、既に存在するフィールド値を置き換えなければなりません（MUST）。ただし、次の例外があります:

  • Section 3.1（Storing Header and Trailer Fields）で格納が例外とされたヘッダーフィールド、
  • キャッシュの保存レスポンスが依存するヘッダーフィールド（以下に記述）、
  • 受信者によって自動的に処理され削除されるヘッダーフィールド（以下に記述）、および
  • Content-Length ヘッダーフィールド。

場合によっては、キャッシュ（特にユーザーエージェント内のもの）は受信したレスポンスを処理した結果を格納し、レスポンス自体ではなくその処理結果を保持することがあります。そのような場合に、その処理に影響するヘッダーフィールドを更新すると一貫性のない挙動やセキュリティ上の問題を引き起こす可能性があります。このような状況のキャッシュは、例外的にこれらのヘッダーフィールドを保存レスポンスの更新から省略してもよい（MAY）が、その省略は保存レスポンスの整合性を確保するために必要なフィールドに限定すべきである（SHOULD）。

例えば、ブラウザはレスポンスのコンテンツコーディングを受信中にデコードして保存することがあり、その結果保存データとレスポンスの元のメタデータとの間に乖離が生じます。その保存されたメタデータを異なる Content-Encoding ヘッダーフィールドで更新することは問題を生じさせます。同様に、ブラウザが受信したコンテンツをパースした後の HTML ツリーを保存している場合、Content-Type ヘッダーフィールドを更新することは妥当ではありません。なぜならパース時に行われた形式に関する仮定が無効になるためです。

さらに、一部のフィールドは HTTP 実装によって自動的に処理され削除されます。例えば Content-Range ヘッダーフィールドなどです。実装はそのようなヘッダーフィールドを更新から自動的に省略してもよい（MAY）、たとえ実際の処理が行われていない場合でもです。

Content-* プレフィックスはヘッダーフィールドが更新から省略されることを示す信号ではない点に注意してください；これは MIME ヘッダーフィールドの慣習であり、HTTP の仕様ではありません。

3.3. 不完全なレスポンスの格納

リクエストメソッドが GET、レスポンスのステータスコードが 200 (OK) であり、レスポンスヘッダ全体が受信済みである場合、キャッシュは完全でないレスポンス（Section 6.1 of [HTTP]）を保存してもよい（MAY）、ただしその保存レスポンスは不完全であると記録されなければなりません。同様に、206 (Partial Content) レスポンスは不完全な 200 (OK) レスポンスとして格納してもよい（MAY）。しかし、キャッシュが Range および Content-Range ヘッダーフィールドをサポートしていない場合、またはそれらのフィールドで使用されているレンジ単位を理解していない場合、キャッシュは不完全または部分コンテンツのレスポンスを格納してはなりません（MUST NOT）。

キャッシュは、後続のレンジリクエスト（Section 14.2 of [HTTP]）を行い、成功したレスポンスと保存されたレスポンスを結合することで、不完全に保存されたレスポンスを完成させることができます（Section 3.4 に定義）。キャッシュは、レスポンスが完成しているか、またはリクエストが不完全で保存されたレスポンス内に完全に含まれるレンジを指定している場合を除き、不完全なレスポンスを使ってリクエストに応答してはなりません（MUST NOT）。また、キャッシュはクライアントに対して部分レスポンスを送信する際に、明示的に 206 (Partial Content) ステータスコードでマークせずに送信してはなりません（MUST NOT）。

3.4. 部分コンテンツの結合

接続が早期に切断されたり、リクエストが 1 つ以上の Range 指定子を使用したりした場合、レスポンスが表現の一部しか転送しないことがあります。複数回そのような転送が発生した後、キャッシュは同じ表現のいくつかのレンジを受信しているかもしれません。キャッシュは、それらすべてが同じ強い検証子を共有し、キャッシュが Section 15.3.7.3 of [HTTP] に示されたクライアント要件を満たす場合、それらのレンジを単一の保存レスポンスに結合し、後続のリクエストを満たすためにそのレスポンスを再利用してもよい（MAY）。

新しいレスポンスを 1 つ以上の保存済みレスポンスと結合する際、キャッシュは Section 3.2（Updating Stored Header Fields）に従って、新しいレスポンスで提供されたヘッダーフィールドを用いて保存レスポンスのヘッダーフィールドを更新しなければなりません（MUST）。

3.5. 認証済みリクエストへのレスポンスの格納

共有キャッシュは、リクエストに Authorization ヘッダーフィールドが含まれるリクエストへのレスポンスを、後続のいかなるリクエストを満たすためにも使用してはなりません（MUST NOT）、ただしレスポンスに共有キャッシュによる格納を明示的に許可するレスポンスディレクティブ（Section 5.2.2 のレスポンスディレクティブ）が含まれており、かつキャッシュがそのレスポンスに対する当該ディレクティブの要件に準拠している場合は除きます。

本仕様では、must-revalidate（Section 5.2.2.2）、public（Section 5.2.2.9）、および s-maxage（Section 5.2.2.10）がそのような効果を持つレスポンスディレクティブとして扱われます。

4. キャッシュからのレスポンス構築

リクエストを受け取ったとき、キャッシュは次の条件を満たさない限り、保存されたレスポンスを再利用してはなりません（MUST NOT）。

  • 提示されたターゲット URI（Section 7.1 of [HTTP]）と保存されたレスポンスのものが一致していること、および

  • 保存されたレスポンスに関連付けられたリクエストメソッドが、提示されたリクエストに対してそのレスポンスを使用することを許可していること、および

  • 保存されたレスポンスで指名された（ある場合の）リクエストヘッダーフィールドが提示されたリクエストのそれと一致していること（詳細は Section 4.1 を参照）、および

  • 保存されたレスポンスに no-cache ディレクティブ（Section 5.2.2.4）が含まれていないこと（ただし正常に検証されている場合は除く）（詳細は Section 4.3 を参照）、および

  • 保存されたレスポンスが次のいずれかであること:

    • 新鮮であること（Section 4.2 を参照）、または
    • 期限切れのまま提供することが許可されていること（Section 4.2.4 を参照）、または
    • 正常に検証されていること（Section 4.3 を参照）。

キャッシュ拡張がここに挙げた要件のいずれかをオーバーライドできる点に注意してください。詳細は Section 5.2.3 を参照してください。

検証なしで保存されたレスポンスを使用してリクエストに応答する場合、キャッシュは Age ヘッダーフィールド（Section 5.1）を生成し、レスポンス内に存在するものがあればそれを置き換えて、保存レスポンスの current_age と等しい値にしなければなりません。詳細は Section 4.2.3 を参照してください。

キャッシュは、安全でないメソッド（Section 9.2.1 of [HTTP]）を持つリクエストをオリジンサーバーへ書き抜く（write through）必要があります。つまり、キャッシュはそのようなリクエストに対して、リクエストを転送して対応するレスポンスを受け取る前に応答を生成してはなりません。

また、安全でないリクエストは既に保存されているレスポンスを無効化する可能性があることに注意してください。詳細は Section 4.4 を参照してください。

キャッシュは、保存済みまたは保存可能なレスポンスを複数のリクエストに対して流用できる場合があります。ただし、それが当該リクエストに対して再利用することが許可されている場合に限ります。これによりキャッシュは「リクエストの折り畳み（collapse requests）」— キャッシュミス時に複数の着信リクエストを単一の転送リクエストにまとめる — を行い、オリジンサーバーおよびネットワークの負荷を低減できます。しかし、キャッシュが返されたレスポンスを折り畳まれたリクエストの一部または全部に使用できない場合、キャッシュはそれらを満たすためにリクエストを転送する必要があり、その結果追加の待ち時間が生じる可能性があります。

複数の適切なレスポンスが保存されている場合、キャッシュは最も最近のもの（Date ヘッダーフィールドで決定）を使用しなければなりません（MUST）。使用するレスポンスを明確にするために、"Cache-Control: max-age=0" や "Cache-Control: no-cache" を付けてリクエストを転送することもできます。

時計を持たないキャッシュ（Section 5.6.7 of [HTTP]）は、保存されたレスポンスを使用するたびにそれらを再検証しなければなりません（MUST）。

4.1. Vary ヘッダーフィールドによるキャッシュキーの計算

キャッシュが保存されたレスポンスで満たせるリクエストを受け取り、かつその保存されたレスポンスが Vary ヘッダーフィールドを含む場合（Section 12.5.5 of [HTTP]）、キャッシュはその保存されたレスポンスを再検証なしに使用してはなりません（MUST NOT）、ただしその Vary フィールドで指名されたすべての提示されたリクエストヘッダーフィールドが、元のリクエスト（キャッシュされたレスポンスを生成したリクエスト）のそれと一致する場合はその限りではありません。

2 つのリクエストのヘッダーフィールドが一致すると定義されるのは、次のいずれかの操作を適用することで最初のリクエストのヘッダーフィールドが 2 番目のリクエストのものに変換できる場合に限ります：

  • ヘッダーフィールド構文で許される範囲で空白を追加または削除すること
  • 同じフィールド名を持つ複数のヘッダーフィールド行を結合すること（詳細は Section 5.2 of [HTTP] を参照）
  • ヘッダーフィールドの仕様に従って意味が同一であることが知られている方法で両方のヘッダーフィールド値を正規化すること（例：順序が重要でない場合の値の並べ替え、値が大文字小文字を区別しない場合のケース正規化）

（行われるかもしれない正規化の後に）ヘッダーフィールドがリクエストから欠落している場合、それは相手側のリクエストでも欠落している場合にのみもう一方と一致することができます。

メンバー "*" を含む Vary ヘッダーフィールド値を持つ保存されたレスポンスは常に一致に失敗します。

複数の保存レスポンスが一致する場合、キャッシュはそのうちの 1 つを選択する必要があります。指名されたリクエストヘッダーフィールドに優先順位をランク付けする既知のメカニズム（例：Accept 等の q 値）がある場合、そのメカニズムは優先レスポンスを選択するために使用してもよい（MAY）。そのようなメカニズムが利用できないか、同等に好ましいレスポンスに至る場合は、最も最近のレスポンス（Date ヘッダーフィールドで決定）を選択します（Section 4 を参照）。

一部のリソースは、デフォルトレスポンス（すなわちリクエストがいかなる優先も表明しないときに送られるもの）から Vary ヘッダーフィールドを誤って省略することがあり、その結果、より好ましいレスポンスが利用可能であっても後続のリクエストに対してそれが選択されてしまいます。キャッシュがターゲット URI に対して複数の保存レスポンスを持ち、そのうちの 1 つ以上が Vary ヘッダーフィールドを省略している場合、キャッシュは有効な Vary フィールド値を持つ保存レスポンスのうち最も最近のものを選択することが望ましい（SHOULD）（詳細は Section 4.2.3 を参照）。

一致する保存レスポンスがない場合、キャッシュは提示されたリクエストを満たすことができません。通常、そのリクエストはオリジンサーバーに転送され、キャッシュが既に保存しているレスポンスを説明するための前提条件が追加されることがあります（Section 4.3 を参照）。

4.2. 新鮮度（Freshness）

新鮮な（fresh）レスポンスは、その年齢がまだ新鮮度寿命を超えていないレスポンスです。逆に、期限切れ（stale）レスポンスはその寿命を超えているものを指します。

レスポンスの 新鮮度寿命（freshness lifetime） は、オリジンサーバーによる生成時からその有効期限時刻までの長さです。明示的な有効期限時刻（explicit expiration time） は、オリジンサーバーが保存されたレスポンスを検証なしでキャッシュが使用できなくなる時刻を示します。一方、ヒューリスティックな有効期限時刻（heuristic expiration time） は、明示的な有効期限が利用できない場合にキャッシュが割り当てるものです。

レスポンスの 年齢（age） は、それがオリジンサーバーによって生成されてから、またはオリジンサーバーと正常に検証されてから経過した時間です。

レスポンスが新鮮である場合、オリジンサーバーに連絡することなく後続のリクエストを満たすために使用でき、効率が向上します。

新鮮度を決定する主要なメカニズムは、オリジンサーバーが将来の明示的な有効期限時刻を提供することです。それは Expires ヘッダーフィールド（Section 5.3）または max-age レスポンスディレクティブ（Section 5.2.2.1）を使用して行われます。一般に、オリジンサーバーは表現がその有効期限に達するまで意味的に重要な変化を伴わないと考えて将来の明示的な有効期限を割り当てます。

オリジンサーバーがキャッシュに対してすべてのリクエストを検証させたい場合、過去の明示的な有効期限時刻を割り当てることで、レスポンスが既に期限切れであることを示すことができます。準拠したキャッシュは通常、期限切れのキャッシュレスポンスを再利用する前に検証します（Section 4.2.4 を参照）。

オリジンサーバーが常に明示的な有効期限を提供するわけではないため、キャッシュは特定の状況下で有効期限を決定するためにヒューリスティックを使用することが許されています（Section 4.2.2 を参照）。

レスポンスが新鮮かどうかを判断する計算は次のとおりです：

   response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime は Section 4.2.1 に定義され、current_age は Section 4.2.3 に定義されています。

クライアントは max-age や min-fresh のリクエストディレクティブ（Section 5.2.1）を送信して対応するレスポンスの新鮮度計算に制限を示唆できますが、キャッシュはそれらを尊重する義務はありません。

新鮮度を計算する際、日付解析における一般的な問題を避けるために：

  • すべての日付フォーマットは大文字小文字を区別すると指定されていますが、キャッシュ受信者はフィールド値を大文字小文字を区別せずに一致させることが望ましい（SHOULD）。
  • キャッシュ受信者の内部実装の時間分解能が HTTP-date の値よりも小さい場合、受信者は解析された Expires 日付を受け取った値と等しいかそれ以前の最も近い時刻として内部的に表現しなければならない（MUST）。
  • キャッシュ受信者はローカルタイムゾーンが年齢や有効期限時刻の計算または比較に影響を与えることを許してはならない（MUST NOT）。
  • キャッシュ受信者は、"GMT" 以外のゾーン略語を持つ日付を有効期限計算に使用する際には無効と見なすべきである（SHOULD）。

新鮮度はキャッシュ運用にのみ適用されることに注意してください；これはユーザーエージェントに表示を更新させたりリソースを再読み込みさせたりするために使用することはできません。キャッシュと履歴メカニズムの違いについては Section 6 を参照してください。

4.2.1. 新鮮度寿命の計算

キャッシュは以下の規則を評価して、最初に一致したものを使用することでレスポンスの新鮮度寿命（freshness_lifetime）を計算できます：

  • キャッシュが共有キャッシュであり、s-maxage レスポンスディレクティブ（Section 5.2.2.10）が存在する場合はその値を使用する、または
  • max-age レスポンスディレクティブ（Section 5.2.2.1）が存在する場合はその値を使用する、または
  • Expires レスポンスヘッダーフィールド（Section 5.3）が存在する場合はその値から Date レスポンスヘッダーフィールドの値を差し引いた値を使用する（Date が存在しない場合はメッセージ受信時刻を使用する、詳細は Section 6.6.1 を参照）、または
  • それ以外の場合は、レスポンスに明示的な有効期限時刻が存在しません。ヒューリスティックな新鮮度寿命が適用される可能性があります；Section 4.2.2 を参照してください。

この計算は、可能な限りオリジンサーバーが提供する時計情報を使用することでクロックスキューを減らすことを意図している点に注意してください。

同じディレクティブに対して複数の値が存在する場合（例：2 行の Expires ヘッダーフィールド行や複数の Cache-Control: max-age 指定）、最初の出現を使用するか、レスポンスを期限切れと見なすべきです。ディレクティブが矛盾する場合（例：max-age と no-cache の両方が存在する場合）、最も制限的なディレクティブを尊重すべきです。キャッシュは無効な新鮮度情報（例：非整数の max-age ディレクティブ）を持つレスポンスを期限切れと見なすことが推奨されます。

4.2.2. ヒューリスティックな新鮮度の計算

オリジンサーバーが常に明示的な有効期限を提供するわけではないため、キャッシュは明示的な時刻が指定されていない場合にヒューリスティックな有効期限時刻を割り当てることができます（MAY）。その際、Last-Modified 時刻などの他のフィールド値を使って妥当な有効期限を推定するアルゴリズムを用いることがあります。本仕様は具体的なアルゴリズムを提供しませんが、その結果に対して最悪ケースの制約を課します。

キャッシュは、保存されたレスポンスに明示的な有効期限時刻が存在する場合にヒューリスティックを使って新鮮度を決定してはなりません（MUST NOT）。Section 3（Storing Responses in Caches）の要件のため、ヒューリスティックは明示的な新鮮度情報を持たない、かつステータスコードが ヒューリスティックにキャッシュ可能（heuristically cacheable） と定義されているレスポンス（例：Section 15.1 を参照）および明示的にキャッシュ可能とマークされたレスポンス（例：public レスポンスディレクティブ）にのみ使うことができます。

以前の仕様では、ヒューリスティックにキャッシュ可能とされたレスポンスのステータスコードは「デフォルトでキャッシュ可能（cacheable by default）」と呼ばれていました。

レスポンスに Last-Modified ヘッダーフィールドがある場合、キャッシュはその時刻からの経過時間の一部を上限としてヒューリスティックな有効期限値を使用することが推奨されます。典型的な割合設定は 10% 程度です。

4.2.3. 経過時間（Age）の計算

Age ヘッダーフィールドは、キャッシュから取得された際のレスポンスメッセージの推定年齢を伝えるために使用されます。Age フィールド値は、オリジンサーバーがレスポンスを生成または検証してからの秒数に対するキャッシュの推定です。したがって Age 値は、オリジンサーバーからの経路に沿って各キャッシュ内にレスポンスが滞在していた時間の合計に、ネットワーク上での転送時間を加えたものになります。

年齢計算は次のデータを用いて行います：

age_value
「age_value」とは、算術演算に適した形式の Age ヘッダーフィールドの値（Section 5.1）を指します；存在しない場合は 0 を意味します。
date_value
「date_value」とは、算術演算に適した形式の Date ヘッダーフィールドの値を指します。Date ヘッダーフィールドの定義と、これが存在しないレスポンスに関する要件については Section 6.6.1 of [HTTP] を参照してください。
now
「now」とは、この実装のクロックの現在値を意味します（Section 5.6.7 of [HTTP]）。
request_time
保存されたレスポンスをもたらしたリクエストが行われた時のクロックの値。
response_time
レスポンスが受信された時のクロックの値。

レスポンスの年齢は、完全に独立した 2 つの方法で計算できます：

  1. 「apparent_age」：実装のクロックがオリジンサーバーのクロックと概ね同期している場合の、response_time minus date_value。結果が負ならば 0 に置き換える。
  2. 「corrected_age_value」：応答経路上のすべてのキャッシュが HTTP/1.1 以上を実装している場合に利用可能。キャッシュはこの値を要求が開始された時刻に対して解釈しなければならない（レスポンス受信時刻ではない）。
  apparent_age = max(0, response_time - date_value);

  response_delay = response_time - request_time;
  corrected_age_value = age_value + response_delay;

corrected_age_value は corrected_initial_age として利用してもよい（MAY）。古いキャッシュ実装が正しく Age を挿入していない可能性がある場合、corrected_initial_age はより保守的に次のように計算できます：

  corrected_initial_age = max(apparent_age, corrected_age_value);

保存されたレスポンスの current_age は、最後にオリジンサーバーによって検証された時刻から経過した時間（秒）を corrected_initial_age に加えることで計算できます。

  resident_time = now - response_time;
  current_age = corrected_initial_age + resident_time;

4.2.4. 期限切れレスポンスの提供（Serving Stale Responses）

「期限切れ（stale）」レスポンスとは、明示的な有効期限情報があるかヒューリスティックな有効期限が計算可能であるものの、Section 4.2 の計算により新鮮ではないと判定されるものを指します。

キャッシュは、プロトコル内の明示的な指示（例：no-cache レスポンスディレクティブ、must-revalidate レスポンスディレクティブ、適用可能な s-maxage や proxy-revalidate レスポンスディレクティブ等）によって禁止されている場合、期限切れレスポンスを生成してはなりません（MUST NOT）。詳細は Section 5.2.2 を参照してください。

キャッシュは、切断状態であるか、クライアントまたはオリジンサーバーによって明示的に許可されている場合（例：Section 5.2.1 の max-stale リクエストディレクティブ、あるいは [RFC5861] のような拡張ディレクティブ、またはアウトオブバンドの契約に基づく設定）でない限り、期限切れレスポンスを生成してはなりません（MUST NOT）。

4.3. 検証（Validation）

キャッシュが要求された URI に対して 1 件以上の保存レスポンスを持っているが、それらのいずれも提供できない場合（例：新鮮でない、または選択できない等；Section 4.1 を参照）、キャッシュは転送するリクエストに条件付きリクエスト機構（Section 13 of [HTTP]）を使って、次に受信するサーバーに対して有効な保存レスポンスを選択する機会を与え、保存されたメタデータを更新するか、保存レスポンスを新しいレスポンスで置換させることができます。このプロセスは保存レスポンスの 検証（validating） または 再検証（revalidating） と呼ばれます。

4.3.1. 検証リクエストの送信

検証のための条件付きリクエストを生成する際、キャッシュは満たそうとしているリクエストから開始するか、あるいは独立してリクエストを開始する場合は保存レスポンスを使ってメソッド、ターゲット URI、および Vary ヘッダーフィールドで特定されたリクエストヘッダーフィールドをコピーしてリクエストを合成します（Section 4.1 を参照）。

次に、キャッシュはそのリクエストを 1 個以上の前提条件ヘッダーフィールドで更新します。これらは、同じ URI を持つ保存レスポンスから取得された検証子メタデータを含みます。通常は同じキャッシュキーを持つ保存レスポンスのみを含みますが、キャッシュは送信しているリクエストヘッダーフィールドで選択できないレスポンスを検証することも許可されています（Section 4.1 を参照）。

前提条件ヘッダーフィールドは、受信者によって比較され、保存されたレスポンスのいずれかが現在のリソース表現と等価であるかどうかを判定します。

そのような検証子の一例は Last-Modified ヘッダーフィールドに示されたタイムスタンプで、検証には If-Modified-Since を使用できます。また、表現選択には If-Unmodified-Since や If-Range を使用することがあります（詳細は該当セクションを参照）。

別の検証子は ETag フィールドに示されたエンティティタグです。1 個以上のエンティティタグは、検証のために If-None-Match ヘッダーフィールドで使用でき、また If-Match や If-Range で表現選択に使われることがあります。

検証のために条件付きリクエストを生成する際、キャッシュは以下を行います：

  • MUST：検証対象の保存レスポンスにエンティティタグが含まれている場合、対応するエンティティタグを（If-Match、If-None-Match、または If-Range を使って）送信しなければなりません。
  • SHOULD：要求がサブレンジでなく、単一の保存レスポンスを検証しており、そのレスポンスが Last-Modified 値を含む場合、Last-Modified 値を（If-Modified-Since を使って）送信することが推奨されます。
  • MAY：要求がサブレンジであり、単一の保存レスポンスを検証していて、そのレスポンスがエンティティタグではなく Last-Modified のみを含む場合、Last-Modified 値を（If-Unmodified-Since または If-Range を使って）送信してもよいです。

ほとんどの場合、両方の検証子がキャッシュ検証リクエストで生成されます。これは、エンティティタグに対応していない古い仲介者（インターメディアリ）が適切に応答できるようにするためです。

4.3.2. 受信した検証リクエストの処理

リクエストチェーン内の各クライアントはそれぞれ独自のキャッシュを持ちうるため、仲介者にあるキャッシュが他の（送信方向の）キャッシュから条件付きリクエストを受け取ることは一般的です。同様に、一部のユーザーエージェントは条件付きリクエストを利用して最近変更された表現へのデータ転送を制限したり、部分的に取得した表現の転送を完了したりします。

キャッシュが保存された 200 (OK) または 206 (Partial Content) レスポンスで応答できるリクエストを受け取った場合は、キャッシュはそのリクエストで受け取った適用可能な条件付きヘッダーフィールド前提条件を、保存レスポンス内の対応する検証子に照らして評価することが望ましい（SHOULD）。

キャッシュは、オリジンサーバーにのみ適用される条件や、キャッシュで満たすことができない意味を持つリクエスト内にある条件、あるいは保存レスポンスを持たないターゲットリソースに対するリクエスト内の条件を評価してはなりません（MUST NOT）。そのような前提条件は別の（受信方向の）サーバーを意図している可能性が高いからです。

キャッシュによる条件付きリクエストの適切な評価は、受信した前提条件ヘッダーフィールドとその優先順位に依存します。要約すると、If-Match と If-Unmodified-Since はキャッシュには適用されず、If-None-Match が If-Modified-Since に優先します。前提条件の優先順位の完全な仕様は Section 13.2.2 of [HTTP] を参照してください。

If-None-Match ヘッダーフィールドを含むリクエスト（Section 13.1.2 of [HTTP]）は、クライアントが自身の保存レスポンスのいくつかを、キャッシュが選択した保存レスポンスと比較して検証したいことを示します（Section 4 を参照）。

If-None-Match が存在しない場合、If-Modified-Since を含むリクエスト（If-Modified-Since）はクライアントが自身の保存レスポンスを修正日時で検証したいことを示します。

リクエストに If-Modified-Since が含まれており、保存レスポンスに Last-Modified フィールドが存在しない場合、キャッシュは条件評価に保存レスポンスの Date フィールド値（存在しない場合は保存レスポンスを受信した時刻）を使用することが望ましい（SHOULD）。

レンジ要求に対する部分レスポンスを実装するキャッシュは、受信した If-Range ヘッダーフィールド（Section 13.1.5）を、キャッシュが選択したレスポンスに対して評価する必要があります。

キャッシュが、If-None-Match のエンティティタグリストを含むリクエストに対して自身の保存レスポンスを再検証するためにリクエストを転送することを決定した場合、キャッシュは受信したリストと自身の保存レスポンス群（新鮮または期限切れ）からのエンティティタグのリストを結合して、その和集合を転送リクエストの If-None-Match ヘッダーフィールド値として送信してもよい（MAY）。保存レスポンスが部分コンテンツのみを含む場合、その部分保存レスポンスが要求されている範囲を完全に満たす場合を除き、その保存レスポンスのエンティティタグを和集合に含めてはならない（MUST NOT）。転送リクエストへの応答が 304 (Not Modified) で、ETag フィールド値を持ち、そのエンティティタグがクライアントのリストに含まれていない場合、キャッシュは 304 レスポンスのメタデータで更新した対応する保存レスポンスを再利用してクライアントに 200 (OK) レスポンスを生成しなければならない（Section 4.3.4 を参照）。

4.3.3. 検証レスポンスの処理

条件付きリクエストへのレスポンスに対するキャッシュの処理は、そのステータスコードに依存します：

  • 304 (Not Modified) ステータスコードは、保存されたレスポンスが更新され再利用できることを示します。詳細は Section 4.3.4 を参照。
  • 完全なレスポンス（コンテンツを含むもの）は、条件付きリクエストで指名された保存レスポンスのいずれも適切でないことを示します。その場合、キャッシュはその完全なレスポンスをリクエストを満たすために使用しなければなりません（MUST）。キャッシュはそのような完全なレスポンスを格納してもよいが（MAY）、格納に関する制約は守らなければなりません（Section 3 を参照）。
  • ただし、キャッシュが検証中に 5xx (Server Error) レスポンスを受け取った場合、キャッシュはそのレスポンスを要求クライアントに転送するか、サーバーが応答しなかったかのように振る舞うことができます。後者の場合、キャッシュは以前に保存されたレスポンスを送信するか（条件は Section 4.2.4 を参照）、検証リクエストを再試行することができます。

4.3.4. 検証時の保存レスポンスの新鮮化

キャッシュが 304 (Not Modified) レスポンスを受け取った場合、キャッシュは新しい情報で更新するのに適した保存レスポンスを特定し、それらを更新する必要があります。

更新の初期セットは、そのリクエストに対して選択可能であったもの、すなわち Section 4 の要件を満たすすべての保存レスポンス（ただし最後の「新鮮である、期限切れのまま提供可能、またはちょうど検証された」という要件を除く）です。

次に、その初期セットは次のいずれか最初に一致する条件でさらに絞り込まれます：

  • 新しいレスポンスが 1 個以上の 強い検証子（strong validators） を含む場合、各強い検証子は更新のための選択された表現を特定します。初期セット内で同じ強い検証子を持つすべての保存レスポンスが更新対象として識別されます。初期セットのいずれも同じ強い検証子を少なくとも 1 つ含まない場合、キャッシュは新しいレスポンスを使って保存レスポンスを更新してはなりません（MUST NOT）。
  • 新しいレスポンスが強い検証子を含まないが 1 個以上の 弱い検証子（weak validators） を含み、それらの検証子が初期セットの保存レスポンスのいずれかに対応する場合、その一致する保存レスポンスのうち最も新しいものが更新対象として識別されます。
  • 新しいレスポンスがいかなる形式の検証子も含まない場合（例えばクライアントが Last-Modified を使わない別のソースから If-Modified-Since を生成した場合）、初期セットに保存レスポンスが 1 件だけあり、その保存レスポンスも検証子を欠く場合、その保存レスポンスが更新対象として識別されます。

識別された各保存レスポンスに対して、キャッシュは 304 (Not Modified) レスポンスで提供されたヘッダーフィールドを用いてヘッダーフィールドを更新しなければなりません（Section 3.2 に従う）（MUST）。

4.3.5. HEAD によるレスポンスの新鮮化

HEAD メソッドへのレスポンスは、同等の GET リクエストに対するものと同一であり、コンテンツを送信しない点が異なります。HEAD レスポンスのこの特性は、保存された GET レスポンスを無効化または更新するために利用できます。これは、保存レスポンスに検証子が存在しないためにより効率的な条件付き GET が利用できない場合や、コンテンツの送信が望まれない場合に有用です。

キャッシュがターゲット URI に対して入方向の HEAD リクエストを行い、200 (OK) レスポンスを受け取った場合、キャッシュはそのリクエストに対して選択可能であった各保存 GET レスポンスを更新または無効化するべきです（SHOULD）（詳細は Section 4.1 を参照）。

選択可能であった各保存レスポンスについて、保存レスポンスと HEAD レスポンスが受信した検証子フィールド（ETag および Last-Modified）の値で一致し、かつ HEAD レスポンスが Content-Length ヘッダーフィールドを持ち、その値が保存レスポンスのものと一致する場合、キャッシュは保存レスポンスを以下に述べるとおり更新するべきです（SHOULD）。そうでない場合、キャッシュは保存レスポンスを期限切れと見なすべきです（SHOULD）。

キャッシュが HEAD レスポンスで提供されたメタデータで保存レスポンスを更新する場合、キャッシュは HEAD レスポンスで提供されたヘッダーフィールドを用いて保存レスポンスを更新しなければなりません（Section 3.2）（MUST）。

4.4. 保存レスポンスの無効化（Invalidating Stored Responses）

PUT、POST、DELETE のような安全でないリクエストメソッド（Section 9.2.1 of [HTTP]）はオリジンサーバー上の状態を変更する可能性があるため、介在するキャッシュは保存レスポンスを無効化して内容を最新に保つことが要求されます。

キャッシュは、安全でないリクエストメソッドに対して非エラーのステータスコードを受け取った場合、そのターゲット URI（Section 7.1 of [HTTP]）を無効化しなければなりません（MUST）。この要件は、安全性が不明なメソッドにも適用されます。

キャッシュは、安全でないリクエストメソッドに対して非エラーのステータスコードを受け取った場合、他の URI を無効化してもよい（MAY）。特に、レスポンスヘッダーフィールドの Location および Content-Location にある URI（存在する場合）は無効化の候補です；その他の URI は本書で指定されていないメカニズムを通じて発見されるかもしれません。ただし、キャッシュは無効化対象の URI のオリジン（Section 4.3.1 of [HTTP]）がターゲット URI のオリジンと異なる場合には、これらの条件下で無効化を発生させてはなりません（MUST NOT）。これはサービス拒否攻撃を防ぐのに役立ちます。

無効化（Invalidate） とは、キャッシュが与えられた URI とターゲット URI が一致するすべての保存レスポンスを削除するか、あるいはそれらを「無効」とマークし、後続のリクエストに応答する前に必ず検証を行う必要がある状態にすることを意味します。

「非エラーレスポンス（non-error response）」とは、2xx (Successful) または 3xx (Redirection) ステータスコードを持つレスポンスを指します。

これはすべての適切なレスポンスがグローバルに無効化されることを保証するものではないことに注意してください；状態変更を伴うリクエストは、そのリクエストが通過したキャッシュ内のレスポンスのみを無効化します。

5. フィールド定義

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

5.1. Age

「Age」レスポンスヘッダーフィールドは、レスポンスがオリジンサーバーで生成されたか、または正常に検証されてからの経過時間に関する送信者の推定値を伝えます。Age 値は Section 4.2.3 の規定に従って計算されます。

Age フィールド値は秒単位の非負整数です（Section 1.2.2 を参照）。

定義上は単一のヘッダーフィールドですが、リスト形式の Age 値を受け取ったキャッシュは、最初のメンバーを使用し、後続のメンバーを破棄することを SHOULD とします。

フィールド値（上記のように追加要素を破棄したあと）が無効（たとえば非負整数以外を含む）である場合、キャッシュはそのフィールドを無視することを SHOULD とします。

Age ヘッダーフィールドが存在することは、そのレスポンスがこのリクエストのためにオリジンサーバーで生成または検証されていないことを示唆します。ただし、Age ヘッダーフィールドが欠けていることがオリジンに接触したことを意味するわけではありません。

5.2. Cache-Control

「Cache-Control」ヘッダーフィールドは、リクエスト/レスポンスチェーン上のキャッシュに対するディレクティブの一覧を記述するために用いられます。Cache-Control ディレクティブは一方向的であり、リクエストにディレクティブが存在するからといって同じディレクティブがレスポンスに存在したりコピーされることを意味しません。

外部で定義された Cache-Control ディレクティブの扱いについては、Section 5.2.3 を参照してください。

プロキシは、キャッシュを実装しているかどうかにかかわらず、転送されるメッセージ中のキャッシュディレクティブをその意義にかかわらず通過させなければなりません（MUST）。これらのディレクティブはリクエスト/レスポンスチェーン上のすべての受信者に適用されうるためです。特定のキャッシュを対象にディレクティブを指定することはできません。

キャッシュディレクティブはトークンで識別され、大文字小文字を区別せずに比較されます。引数は任意で、token または quoted-string の構文を使えます。以下で引数を定義するディレクティブに対しては、受信者は生成時に特定の形式が要求されていても両方の形式を受け入れるべきです。

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

5.2.1. リクエスト向けディレクティブ（Request Directives）

この節ではキャッシュリクエストディレクティブを定義します。これらは助言的であり、キャッシュは実装してもよい（MAY）が必須ではありません。

5.2.1.1. max-age

引数構文:

max-age リクエストディレクティブは、クライアントが指定秒数以下の年齢のレスポンスを好むことを示します。max-stale リクエストディレクティブが同時に存在しない限り、クライアントは期限切れのレスポンスを受け取りたくないことを意味します。

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

5.2.1.2. max-stale

引数構文:

max-stale リクエストディレクティブは、クライアントが有効期限を超えたレスポンスを受け入れることを示します。値がある場合、その指定秒数を超えていない期限切れレスポンスを受け入れることを意味します。値が指定されない場合、クライアントは年齢にかかわらず期限切れレスポンスを受け入れます。

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

5.2.1.3. min-fresh

引数構文:

min-fresh リクエストディレクティブは、クライアントが要求時点から指定秒数以上はまだ新鮮であるレスポンスを好むことを示します。つまり、少なくとも指定秒数は新鮮であり続けるレスポンスを求めています。

このディレクティブは token 形式の引数を使用します（例: '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」は、キャッシュが意図的に情報を永続的な記憶域に格納してはならないこと、および転送後できるだけ早く揮発性記憶から情報を削除するよう最善を尽くすことを意味します。

このディレクティブはプライバシーを確実にする信頼できる十分な手段ではありません。悪意あるまたは妥協されたキャッシュはこのディレクティブを認識または遵守しない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。

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

5.2.1.6. no-transform

no-transform リクエストディレクティブは、クライアントが中継者に対してコンテンツ変換（Section 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

引数構文:

max-age レスポンスディレクティブは、レスポンスが指定秒数を超えて年齢を有する場合に期限切れと見なされることを示します。

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

5.2.2.2. must-revalidate

must-revalidate レスポンスディレクティブは、レスポンスが期限切れになった場合、キャッシュはオリジンによって正常に検証されるまでそのレスポンスを他のリクエストに再利用してはならないことを示します（Section 4.3 参照）。

must-revalidate は特定のプロトコル機能の信頼できる動作を支えるために必要です。あらゆる状況においてキャッシュは must-revalidate を無視してはならず（MUST NOT）、特にキャッシュが切断状態にある場合は期限切れレスポンスを再利用する代わりにエラー応答を生成しなければなりません（MUST）。生成されるステータスコードは、他に適切なエラーコードがない限り 504 (Gateway Timeout) であることが SHOULD とされています。

must-revalidate は、検証に失敗すると誤った動作を招く可能性がある場合（例えば金融取引が黙って実行されない等）にのみサーバーが使用することが推奨されます。

must-revalidate は、共有キャッシュが Authorization ヘッダーフィールドを含むリクエストに対するレスポンスを再利用することを許可する（ただし再検証が必要）などの効果を持ちます（詳細は Section 3.5 を参照）。

5.2.2.3. must-understand

must-understand レスポンスディレクティブは、そのレスポンスのステータスコードに関する要件を理解し順守するキャッシュに限定してレスポンスをキャッシュさせることを意図します。

must-understand を含むレスポンスは SHOULD もまた no-store ディレクティブを含むべきです。must-understand を実装するキャッシュが must-understand を含むレスポンスを受け取った場合、そのキャッシュはステータスコードのキャッシュ要件を理解および実装しているならば no-store を無視してもよい（SHOULD）とされています。

5.2.2.4. no-cache

引数構文:

無引数の no-cache レスポンスディレクティブは、そのレスポンスがオリジンサーバーでの検証と成功応答を受けるまでは他のリクエストを満たすために使用してはならないことを示します（MUST NOT）。詳細は Section 4.3 を参照してください。

これにより、オリジンサーバーはキャッシュがオフラインでも期限切れレスポンスを返すように設定されていても、キャッシュに対して問い合わせることを強制できます。

引数を伴う（特定のフィールド名を列挙する）no-cache の修飾形は、列挙されたヘッダーフィールドが後続のレスポンスで除外されているか、あるいはオリジンでの再検証が成功してそれらのフィールドが更新または削除された場合に限り、キャッシュがそのレスポンスを使用して後続のリクエストを満たしてもよい（MAY）ことを示します。これにより、オリジンサーバーはレスポンス中の特定のヘッダーフィールドの再利用のみを防ぎ、残りの部分はキャッシュ可能にすることができます。

列挙されるフィールド名は本仕様で定義されるヘッダーフィールドに限定されません。フィールド名は大文字小文字を区別しません。

このディレクティブは引数に quoted-string 形式を使用します。送信者は token 形式を生成すべきではありません（SHOULD NOT）、たとえ単一エントリで引用が不要に見える場合でもです。

5.2.2.5. no-store

no-store レスポンスディレクティブは、キャッシュが当該リクエストまたはレスポンスのいかなる部分も格納してはならないこと、またそのレスポンスを他のリクエストを満たすために使用してはならないことを示します（MUST NOT）。

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

このディレクティブはプライバシーを確実にする信頼できる手段ではありません。悪意あるまたは妥協されたキャッシュがこのディレクティブを認識または遵守しない可能性があり、通信ネットワークは盗聴に対して脆弱です。

must-understand ディレクティブは特定の状況で no-store を上書きすることに注意してください（Section 5.2.2.3 を参照）。

5.2.2.6. no-transform

no-transform レスポンスディレクティブは、中継者（キャッシュを実装しているか否かにかかわらず）がコンテンツを変換してはならないことを示します（Section 7.7 参照）。

5.2.2.7. private

引数構文:

無引数の private レスポンスディレクティブは、共有キャッシュがそのレスポンスを格納してはならない（単一ユーザー向けである）ことを示します。また、プライベートキャッシュは MAY そのレスポンスを Section 3 の制約に従って格納してよいことを示します。これにより、プライベートキャッシュが通常はヒューリスティックにキャッシュされないレスポンスを格納できるようになります。

引数付きの private ディレクティブがある場合（1 個以上のフィールド名を列挙）、列挙されたヘッダーフィールドのみが単一ユーザー向けに制限されます：共有キャッシュは原レスポンスにそれらのフィールドが存在する場合に列挙されたフィールドを格納してはならず（MUST NOT）、残りのレスポンスはそれらのフィールドを除いて格納してもよい（MAY）とされています（Section 3 の制約に従う）。

列挙されるフィールド名は本仕様で定義されるヘッダーフィールドに限定されません。フィールド名は大文字小文字を区別しません。

このディレクティブは quoted-string 形式の引数を使用します。送信者は token 形式を生成すべきではありません（SHOULD NOT）。

5.2.2.8. proxy-revalidate

proxy-revalidate レスポンスディレクティブは、レスポンスが期限切れになった場合、共有キャッシュはオリジンで正常に検証されるまでそのレスポンスを再利用してはならないことを示します（Section 4.3 参照）。これは must-revalidate と類似していますが、proxy-revalidate はプライベートキャッシュには適用されません。

proxy-revalidate 単独ではレスポンスがキャッシュ可能であることを意味しない点に注意してください。例えば public と組み合わせて共有キャッシュに対してのみキャッシュを許可し、期限切れ時には再検証を要求する、といった使い方が可能です。

5.2.2.9. public

public レスポンスディレクティブは、レスポンスが他の場合は格納が禁止されるようなものであっても、キャッシュがそのレスポンスを格納できることを示します（MAY）。言い換えれば、public は明示的にレスポンスをキャッシュ可能であるとマークします。例えば public は共有キャッシュに対して Authorization を含むリクエストのレスポンスを再利用することを許可します（Section 3.5 参照）。

レスポンスが既に Section 3 に従ってキャッシュ可能である場合に public を付加する必要はありません。

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

5.2.2.10. s-maxage

引数構文:

s-maxage レスポンスディレクティブは、共有キャッシュに対して、このディレクティブで指定された最大年齢が max-age または Expires ヘッダーフィールドで指定された最大年齢より優先して適用されることを示します。

s-maxage は共有キャッシュに対して proxy-revalidate の意味を取り込みます（Section 5.2.2.8 参照）。共有キャッシュは、s-maxage による期限切れレスポンスをオリジンで正常に検証されるまで再利用してはなりません（MUST NOT）。このディレクティブはまた、共有キャッシュが Authorization を含むリクエストのレスポンスを再利用することを許容しますが、最大年齢や再検証の要件に従う必要があります（Section 3.5 参照）。

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

5.2.3. 拡張ディレクティブ（Extension Directives）

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

情報的拡張（キャッシュ動作の変更を要求しないもの）は、他のディレクティブの意味を変えずに追加できます。

振る舞いを変更する拡張は、既存のディレクティブの修飾子として働くよう設計されるべきです。新しいディレクティブと古いディレクティブの両方が提供され、古いディレクティブのみを解釈するアプリケーションは従来の挙動を行い、拡張を理解するアプリケーションは新しいディレクティブによって既存の要件が修正されることを認識します。こうして、既存のキャッシュを壊すことなく拡張を導入できます。

例えば、"community" という仮想的な新しいレスポンスディレクティブを private に対する修飾子として定義すると、列挙されたコミュニティのメンバーによって共有されているキャッシュだけが当該レスポンスを格納できるようになります。オリジンサーバーが UCI コミュニティに対して本来は private なレスポンスを共有キャッシュで使用可能にしたい場合、次のように送ることができます：

Cache-Control: private, community="UCI"

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

新しい拡張ディレクティブは次を検討すべきです：

  • ディレクティブが複数回指定された場合の意味、
  • 引数を取らない場合に引数が存在するときの意味、
  • 引数を要求する場合に引数が欠落しているときの意味、
  • そのディレクティブがリクエスト専用かレスポンス専用か、あるいは両方で使用可能か、

5.2.4. キャッシュディレクティブ登録（Cache Directive Registry）

「Hypertext Transfer Protocol (HTTP) Cache Directive Registry」はキャッシュディレクティブの名前空間を定義します。これは現在 https://www.iana.org/assignments/http-cache-directives で作成および管理されています。

登録には次の項目が MUST 含まれなければなりません：

  • Cache Directive Name
  • 仕様文への参照（ポインタ）

この名前空間に追加する値は IETF レビューを要します（詳細は [RFC8126] の関連節を参照）。

5.3. Expires

「Expires」レスポンスヘッダーフィールドは、そのレスポンスが期限切れと見なされる日時を示します。新鮮度モデルの詳細は Section 4.2 を参照してください。

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

Expires のフィールド値は HTTP-date タイムスタンプです（Section 5.6.7 参照）。キャッシュ固有の解析要件については Section 4.2 も参照してください。

例:

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

キャッシュ受信者は、特に値 "0" を含む無効な日付形式を過去の時刻（すなわち既に期限切れ）として解釈しなければなりません（MUST）。

レスポンスが max-age ディレクティブを含む Cache-Control ヘッダーフィールドを持つ場合、受信者は Expires ヘッダーフィールドを無視しなければなりません（MUST）。同様に、共有キャッシュに対して s-maxage ディレクティブが存在する場合、共有キャッシュの受信者は Expires を無視しなければなりません（MUST）。これらの場合、Expires の値は Cache-Control をまだ実装していない受信者のためのみに意図されたものです。

時計を持たないオリジンサーバー（Section 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 を非推奨とします。

5.5. Warning

「Warning」ヘッダーフィールドは、ステータスコードに反映されないメッセージの状態や変換に関する追加情報を伝えるために使用されていました。本仕様では Warning を廃止します。これは広く生成・表示されていないためであり、かつ Warning が伝えていた情報は Age のような他のヘッダーフィールドを調べることで得られるためです。

6. アプリケーションおよび他のキャッシュとの関係

HTTP を使用するアプリケーションは、しばしば追加のキャッシュ形態を定義します。たとえば、ウェブブラウザにはセッション中に以前に取得した表現を再表示するための「戻る」ボタンのような履歴機構が備わっていることが多いです。

同様に、一部のウェブブラウザはページ表示内で画像やその他のアセットのキャッシュを実装しており、必ずしも HTTP のキャッシュセマンティクスに従うとは限りません。

本仕様の要件は、HTTP キャッシュから取得したデータをアプリケーションがその後どのように使用するかに必ずしも適用されるものではありません。たとえば、履歴機構は期限切れになった表現を表示することができ、アプリケーションは有効期限を超えたキャッシュデータを別の方法で利用することがあります。

本仕様はアプリケーションが HTTP キャッシュを考慮することを禁じるものではありません。たとえば、履歴機構がビューが古いことをユーザーに示したり、キャッシュディレクティブ（例: Cache-Control: no-store）に従ったりすることは可能です。

ただし、アプリケーションがデータをキャッシュし、それをユーザーに明示したり容易に制御できる形にしていない場合は、キャッシュセマンティクスが尊重されることを期待する作成者を驚かせないよう、HTTP キャッシュディレクティブに対する動作を定義することが強く推奨されます。たとえば、Cache-Control: no-store を含むレスポンスを同一ページ読み込み中に直接関連するリクエスト（同一ページ読み込みで生成されたリクエストなど）に再利用することを許す「HTTP の上位に位置する」アプリケーションキャッシュを定義することは合理的かもしれませんが、取得元と無関係なリクエストに対して再利用を許すとユーザーや作成者にとって驚きや混乱を招く可能性があります。

7. セキュリティに関する考慮事項

このセクションは、開発者、情報提供者、ユーザーに対して HTTP キャッシュに特有の既知のセキュリティ上の懸念を知らせることを目的としています。より一般的なセキュリティ考慮事項については "HTTP/1.1" (Section 11 of [HTTP/1.1]) および "HTTP Semantics" (Section 17 of [HTTP]) を参照してください。

キャッシュの内容は魅力的な攻撃対象となるため、キャッシュは追加の攻撃面を露出します。キャッシュ内容は HTTP リクエストが完了した後も保持されるため、キャッシュに対する攻撃はユーザーが情報がネットワーク上から削除されたと考えた後でも情報を露呈させることがあります。したがって、キャッシュ内容は機密情報として保護する必要があります。

特に、プライベートキャッシュは単一ユーザーに制限されているため、ユーザーの活動を再構成するために利用され得ます。その結果、ユーザーエージェントはエンドユーザーがそれらを制御できるようにすること、例えば特定のオリジンまたはすべてのオリジンについて保存されたレスポンスを削除できるようにすることが重要です。

7.1. キャッシュ汚染

キャッシュに悪意あるコンテンツを格納すると、攻撃者がより多くのユーザーに影響を及ぼす範囲を拡大できます。このような「キャッシュ汚染」攻撃は、攻撃者が実装の欠陥、昇格した権限、またはその他の手段を用いてレスポンスをキャッシュに挿入する場合に発生します。共有キャッシュが多くのクライアントに悪意あるコンテンツを配布する際には特に効果的です。

キャッシュ汚染の一般的な攻撃ベクターの一つは、プロキシとユーザーエージェント間のメッセージ解析の違いを悪用することです。関連する HTTP/1.1 の要件については Section 6.3 of [HTTP/1.1] を参照してください。

7.2. タイミング攻撃

キャッシュの主要な用途の一つがパフォーマンスの最適化であるため、その使用により既に要求されたリソースに関する情報が「漏れる」可能性があります。

たとえば、ユーザーがあるサイトを訪問してそのブラウザがそのサイトのいくつかのレスポンスをキャッシュし、続いて別のサイトに移動した場合、そのサイトは最初のサイトに存在することを知っているレスポンスを読み込もうと試みることができます。それらが高速に読み込まれれば、ユーザーがそのサイト、あるいは特定のページを訪れたと推定できます。

この種の「タイミング攻撃」は、参照元サイトの識別子のような追加情報をキャッシュキーに加えることで緩和できます（上記の攻撃を防ぐため）。これを「ダブルキー化」と呼ぶことがあります。

7.3. 機密情報のキャッシュ

実装および配備の欠陥（多くはキャッシュ動作の誤解に起因）により、本来プライベートであると考えられていた機密情報（例: 認証資格情報）がキャッシュされ、許可されていない当事者に露出してしまうことがあります。

Set-Cookie レスポンスヘッダーフィールド（[COOKIE]）はキャッシュを抑止するものではない点に注意してください。Set-Cookie を含むキャッシュ可能なレスポンスは、しばしばキャッシュで保存され、後続のリクエストを満たすために使用されます。これらのレスポンスのキャッシュを制御したいサーバーは、適切な Cache-Control レスポンスヘッダーフィールドを出力することが推奨されます。

8. IANA に関する考慮事項

以下の登録の変更管理者は次の通りです: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

8.1. フィールド名の登録

IANA は "Hypertext Transfer Protocol (HTTP) Field Name Registry" を https://www.iana.org/assignments/http-fields で更新しました（詳細は Section 18.4 of [HTTP] を参照）。以下の表に示すフィールド名が含まれています:

Table 1
Field Name Status Section Comments
Age permanent 5.1
Cache-Control permanent 5.2
Expires permanent 5.3
Pragma deprecated 5.4
Warning obsoleted 5.5

8.2. キャッシュディレクティブの登録

IANA は "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" を https://www.iana.org/assignments/http-cache-directives で更新し、Section 5.2.4 に従う登録手順および以下の表に要約されたキャッシュディレクティブ名を追加しました。

Table 2
Cache Directive Section
max-age 5.2.1.1, 5.2.2.1
max-stale 5.2.1.2
min-fresh 5.2.1.3
must-revalidate 5.2.2.2
must-understand 5.2.2.3
no-cache 5.2.1.4, 5.2.2.4
no-store 5.2.1.5, 5.2.2.5
no-transform 5.2.1.6, 5.2.2.6
only-if-cached 5.2.1.7
private 5.2.2.7
proxy-revalidate 5.2.2.8
public 5.2.2.9
s-maxage 5.2.2.10

8.3. Warn コード登録

IANA は "Hypertext Transfer Protocol (HTTP) Warn Codes" レジストリ（https://www.iana.org/assignments/http-warn-codes）に次の注記を追加しました。これは "Warning" が廃止（obsoleted）されたことを示すものです:

The Warning header field (and the warn codes that it uses) has been obsoleted for HTTP per [RFC9111].

9. 参考文献

9.1. 規範的参考文献

[HTTP]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022.
[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234]
Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC7405]
Kyzivat, P., “Case-Sensitive String Support in ABNF”, RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174]
Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. 参考資料（Informative References）

Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[HTTP/1.1]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1”, STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022.
[RFC2616]
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/info/rfc2616>.
[RFC5861]
Nottingham, M., “HTTP Cache-Control Extensions for Stale Content”, RFC 5861, DOI 10.17487/RFC5861, May 2010, <https://www.rfc-editor.org/info/rfc5861>.
[RFC7234]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

付録 A. 収集された ABNF

以下の収集された ABNF では、リスト規則は Section 5.6.1 of [HTTP] に従って展開されています。

Age = delta-seconds

Cache-Control = [ cache-directive *( OWS "," OWS cache-directive ) ]

Expires = HTTP-date

HTTP-date = <HTTP-date, see [HTTP], Section 5.6.7>

OWS = <OWS, see [HTTP], Section 5.6.3>

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

delta-seconds = 1*DIGIT

field-name = <field-name, see [HTTP], Section 5.1>

quoted-string = <quoted-string, see [HTTP], Section 5.6.4>

token = <token, see [HTTP], Section 5.6.2>

付録 B. RFC 7234 からの変更点

重複および矛盾するキャッシュディレクティブの扱いが明確化されました。 (Section 4.2.1)

Location および Content-Location ヘッダーフィールド中の URI のキャッシュ無効化はもはや必須ではありませんが、依然として許容されます。 (Section 4.4)

Location および Content-Location ヘッダーフィールド中の URI のキャッシュ無効化は、オリジンが異なる場合には禁止されるようになりました；以前は host が基準でした。 (Section 4.4)

無効なおよび複数の Age ヘッダーフィールド値の扱いが明確化されました。 (Section 5.1)

本仕様で定義された一部のキャッシュディレクティブは、その値の引用形式（quoted form）を生成することに対してより強い禁止を持つようになりました。これは相互運用性の問題を引き起こすことが判明したためです。拡張キャッシュディレクティブの利用者はもはや token と quoted-string の両方を受け入れることを要求されませんが、不明な拡張に対しては適切に解析する必要があります。 (Section 5.2)

public および private キャッシュディレクティブが明確化され、いかなる条件でもレスポンスを再利用可能にするわけではないことが示されました。 (Section 5.2.2)

must-understand キャッシュディレクティブが導入されました；これが存在しない場合、キャッシュは新しいレスポンスステータスコードの意味を理解することを要求されなくなりました。 (Section 5.2.2.3)

Warning レスポンスヘッダーフィールドは廃止されました。Warning が提供していた情報の多くはレスポンスを調べることで得られ、残る情報も完全に助言的であるため、実務ではキャッシュや仲介者によって追加されることはありませんでした。 (Section 5.5)

謝辞

この文書にも適用される内容については、Appendix "Acknowledgements" of [HTTP] を参照してください。

索引

A C E F G H M N O P R S V W

著者の連絡先

Roy T. Fielding (編集者)
Adobe
345 Park Ave
San Jose, CA 95110
United States of America
Email: fielding@gbiv.com
URI: https://roy.gbiv.com/
Mark Nottingham (編集者)
Fastly
Prahran
Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/
Julian Reschke (編集者)
greenbytes GmbH
Hafenweg 16
48155 Münster
Germany
Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/