[要約] RFC 9111は、HTTPキャッシングに関する最新の標準文書で、ウェブのパフォーマンスを向上させるためにリソースの再利用を可能にします。この文書は、キャッシュ可能なレスポンス、キャッシュの検証、新鮮度の制御など、HTTPキャッシングのメカニズムを定義しています。目的は、ウェブトラフィックを減らし、レスポンス時間を短縮することにより、エンドユーザーの体験を改善することです。関連するRFCには、HTTP/1.1を定義するRFC 7230や、条件付きリクエストを扱うRFC 7232などがあります。利用場面は、ウェブサーバー、プロキシサーバー、ブラウザなど、HTTPを使用するあらゆるシステムに適用されます。
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 9111 Adobe
STD: 98 M. Nottingham, Ed.
Obsoletes: 7234 Fastly
Category: Standards Track J. Reschke, Ed.
ISSN: 2070-1721 greenbytes
June 2022
HTTP Caching
HTTPキャッシュ
Abstract
概要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.
HyperText Transfer Protocol（HTTP）は、分散、共同、ハイパーテキスト情報システムのためのステートレスアプリケーションレベルのプロトコルです。このドキュメントでは、キャッシュの動作を制御するか、キャッシュ可能な応答メッセージを示すHTTPキャッシュと関連するヘッダーフィールドを定義します。
This document obsoletes RFC 7234.
このドキュメントは、RFC 7234を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9111.
このドキュメントの現在のステータス、任意の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.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction
1.1. Requirements Notation
1.2. Syntax Notation
1.2.1. Imported Rules
1.2.2. Delta Seconds
2. Overview of Cache Operation
3. Storing Responses in Caches
3.1. Storing Header and Trailer Fields
3.2. Updating Stored Header Fields
3.3. Storing Incomplete Responses
3.4. Combining Partial Content
3.5. Storing Responses to Authenticated Requests
4. Constructing Responses from Caches
4.1. Calculating Cache Keys with the Vary Header Field
4.2. Freshness
4.2.1. Calculating Freshness Lifetime
4.2.2. Calculating Heuristic Freshness
4.2.3. Calculating Age
4.2.4. Serving Stale Responses
4.3. Validation
4.3.1. Sending a Validation Request
4.3.2. Handling a Received Validation Request
4.3.3. Handling a Validation Response
4.3.4. Freshening Stored Responses upon Validation
4.3.5. Freshening Responses with HEAD
4.4. Invalidating Stored Responses
5. Field Definitions
5.1. Age
5.2. Cache-Control
5.2.1. Request Directives
5.2.1.1. max-age
5.2.1.2. max-stale
5.2.1.3. min-fresh
5.2.1.4. no-cache
5.2.1.5. no-store
5.2.1.6. no-transform
5.2.1.7. only-if-cached
5.2.2. Response Directives
5.2.2.1. max-age
5.2.2.2. must-revalidate
5.2.2.3. must-understand
5.2.2.4. no-cache
5.2.2.5. no-store
5.2.2.6. no-transform
5.2.2.7. private
5.2.2.8. proxy-revalidate
5.2.2.9. public
5.2.2.10. s-maxage
5.2.3. Extension Directives
5.2.4. Cache Directive Registry
5.3. Expires
5.4. Pragma
5.5. Warning
6. Relationship to Applications and Other Caches
7. Security Considerations
7.1. Cache Poisoning
7.2. Timing Attacks
7.3. Caching of Sensitive Information
8. IANA Considerations
8.1. Field Name Registration
8.2. Cache Directive Registration
8.3. Warn Code Registry
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Collected ABNF
Appendix B. Changes from RFC 7234
Acknowledgements
Index
Authors' Addresses
The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive messages for flexible interaction with network-based hypertext information systems. It is typically used for distributed information systems, where the use of response caches can improve performance. This document defines aspects of HTTP related to caching and reusing response messages.
HyperText Transfer Protocol（HTTP）は、ネットワークベースのハイパーテキスト情報システムとの柔軟な相互作用のために、拡張可能なセマンティクスと自己記述的なメッセージを使用するステートレスアプリケーションレベルのリクエスト/応答プロトコルです。通常、応答キャッシュの使用がパフォーマンスを改善できる分散情報システムに使用されます。このドキュメントでは、応答メッセージのキャッシュと再利用に関連するHTTPの側面を定義します。
An HTTP "cache" is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses to reduce the response time and network bandwidth consumption on future equivalent requests. Any client or server MAY use a cache, though not when acting as a tunnel (Section 3.7 of [HTTP]).
HTTP「キャッシュ」は、応答メッセージのローカルストアと、その中のメッセージのストレージ、取得、および削除を制御するサブシステムです。キャッシュはキャッシュ可能な応答を保存して、将来の同等の要求で応答時間とネットワーク帯域幅の消費を削減します。クライアントまたはサーバーは、トンネルとして機能する場合はキャッシュを使用できます（[http]のセクション3.7）。
A "shared cache" is a cache that stores responses for reuse by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A "private cache", in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.
「共有キャッシュ」は、複数のユーザーによる再利用の応答を保存するキャッシュです。共有キャッシュは通常、仲介者の一部として展開されます（常にではありませんが）。対照的に、「プライベートキャッシュ」は、単一のユーザー専用です。多くの場合、それらはユーザーエージェントのコンポーネントとして展開されます。
The goal of HTTP caching is significantly improving performance by reusing a prior response message to satisfy a current request. A cache considers a stored response "fresh", as defined in Section 4.2, if it can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time the cache reuses it. When a cached response is not fresh, it might still be reusable if validation can freshen it (Section 4.3) or if the origin is unavailable (Section 4.2.4).
HTTPキャッシュの目標は、現在の要求を満たすために以前の応答メッセージを再利用することにより、パフォーマンスを大幅に改善することです。セクション4.2で定義されているように、「検証」なしで再利用できる場合、セクション4.2で定義されているように、保存された応答を「新鮮」と見なします（Origin Serverでチェックして、キャッシュされた応答がこの要求に対して有効なままであるかどうかを確認します）。したがって、新鮮な応答は、キャッシュが再利用するたびに、レイテンシとネットワークオーバーヘッドの両方を減らすことができます。キャッシュされた応答が新鮮でない場合、検証がそれをリフレッシュできる場合（セクション4.3）、または原点が利用できない場合（セクション4.2.4）、再利用可能である可能性があります。
This document obsoletes RFC 7234, with the changes being summarized in Appendix B.
このドキュメントはRFC 7234を廃止し、変更は付録Bに要約されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Section 2 of [HTTP] defines conformance criteria and contains considerations regarding error handling.
[HTTP]のセクション2は、適合基準を定義し、エラー処理に関する考慮事項を含んでいます。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], extended with the notation for case-sensitivity in strings defined in [RFC7405].
この仕様では、[RFC7405]で定義された文字列の症例感度の表記法とともに拡張された[RFC5234]の拡張されたBackus-NAURフォーム（ABNF）表記を使用します。
It also uses a list extension, defined in Section 5.6.1 of [HTTP], that allows for compact definition of comma-separated lists using a "#" operator (similar to how the "*" operator indicates repetition). Appendix A shows the collected grammar with all list operators expanded to standard ABNF notation.
また、[http]のセクション5.6.1で定義されているリスト拡張子を使用して、「＃」演算子を使用してコンマ分離リストのコンパクトな定義を可能にします（「*」演算子が繰り返しを示す方法と同様）。付録Aは、収集された文法が標準のABNF表記に拡張されたすべてのリストオペレーターを含む文法を示しています。
The following core rule is included by reference, as defined in [RFC5234], Appendix B.1: DIGIT (decimal 0-9).
[RFC5234]で定義されているように、次のコアルールは参照によって含まれています。付録B.1：数字（10進0-9）。
[HTTP] defines the following rules:
[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>
The delta-seconds rule specifies a non-negative integer, representing time in seconds.
Delta-Secondsルールは、秒単位の時間を表す非陰性整数を指定します。
delta-seconds = 1*DIGIT
A recipient parsing a delta-seconds value and converting it to binary form ought to use an arithmetic type of at least 31 bits of non-negative integer range. If a cache receives a delta-seconds value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31) or the greatest positive integer it can conveniently represent.
デルタ秒値を解析し、それをバイナリ形式に変換する受信者は、少なくとも31ビットの非陰性整数範囲の算術タイプを使用する必要があります。キャッシュが表現できる最大の整数よりも大きいデルタ秒の値を受信した場合、またはその後の計算があふれている場合、キャッシュは値を2147483648（2^31）またはそれが便利に表すことができる最大の正の整数であると考える必要があります。
| *Note:* The value 2147483648 is here for historical reasons,
| represents infinity (over 68 years), and does not need to be
| stored in binary form; an implementation could produce it as a
| string if any overflow occurs, even if the calculations are
| performed with an arithmetic type incapable of directly
| representing that number. What matters here is that an
| overflow be detected and not treated as a negative value in
| later calculations.
Proper cache operation preserves the semantics of HTTP transfers while reducing the transmission of information already held in the cache. See Section 3 of [HTTP] for the general terminology and core concepts of HTTP.
適切なキャッシュ操作により、HTTP転送のセマンティクスが保持され、すでにキャッシュに保持されている情報の送信が削減されます。HTTPの一般用語とコア概念については、[HTTP]のセクション3を参照してください。
Although caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.
キャッシュはHTTPの完全にオプションの機能ですが、キャッシュされた応答を再利用することが望ましいと想定できます。また、要件やローカル構成がそれを防止しない場合、そのような再利用はデフォルトの動作です。したがって、HTTPキャッシュの要件は、キャッシュが非繰り返しの応答を保存するか、保存された応答を不適切に再利用することを防ぐことに焦点を当てています。
The "cache key" is the information a cache uses to choose a response and is composed from, at a minimum, the request method and target URI used to retrieve the stored response; the method determines under which circumstances that response can be used to satisfy a subsequent request. However, many HTTP caches in common use today only cache GET responses and therefore only use the URI as the cache key.
「キャッシュキー」は、キャッシュが応答を選択するために使用する情報であり、少なくともリクエスト方法とターゲットURIから構成されており、保存された応答を取得するために使用されます。この方法は、その後のリクエストを満たすために応答を使用できる状況の下で決定します。ただし、今日では一般的に使用されている多くのHTTPキャッシュは、キャッシュのみが応答を取得するため、URIをキャッシュキーとしてのみ使用しています。
A cache might store multiple responses for a request target that is subject to content negotiation. Caches differentiate these responses by incorporating some of the original request's header fields into the cache key as well, using information in the Vary response header field, as per Section 4.1.
キャッシュは、コンテンツネゴシエーションの対象となるリクエストターゲットの複数の応答を保存する場合があります。キャッシュは、セクション4.1に従って、さまざまな応答ヘッダーフィールドの情報を使用して、元のリクエストのヘッダーフィールドの一部をキャッシュキーに組み込むことにより、これらの応答を区別します。
Caches might incorporate additional material into the cache key. For example, user agent caches might include the referring site's identity, thereby "double keying" the cache to avoid some privacy risks (see Section 7.2).
キャッシュは、キャッシュキーに追加の材料を組み込む可能性があります。たとえば、ユーザーエージェントキャッシュには、参照サイトのIDが含まれているため、プライバシーのリスクを回避するためにキャッシュを「二重キーイング」します（セクション7.2を参照）。
Most commonly, caches store the successful result of a retrieval request: i.e., a 200 (OK) response to a GET request, which contains a representation of the target resource (Section 9.3.1 of [HTTP]). However, it is also possible to store redirects, negative results (e.g., 404 (Not Found)), incomplete results (e.g., 206 (Partial Content)), and responses to methods other than GET if the method's definition allows such caching and defines something suitable for use as a cache key.
最も一般的には、Cachesは、取得要求の成功した結果を保存します。つまり、ターゲットリソースの表現を含むGETリクエストに対する200（OK）応答（[HTTP]のセクション9.3.1）です。ただし、リダイレクト、否定的な結果（404（発見されていない）など）、不完全な結果（例：206（部分コンテンツ））、およびメソッドの定義がそのようなキャッシュを許可し、定義する場合の取得以外のメソッドへの応答を保存することも可能です。キャッシュキーとして使用するのに適したもの。
A cache is "disconnected" when it cannot contact the origin server or otherwise find a forward path for a request. A disconnected cache can serve stale responses in some circumstances (Section 4.2.4).
キャッシュは、Origin Serverに連絡したり、リクエストのフォワードパスを見つけられない場合に「切断されます」。切断されたキャッシュは、状況によっては古い応答を提供できます（セクション4.2.4）。
A cache MUST NOT store a response to a request unless:
キャッシュは、次の場合を除き、リクエストへの応答を保存してはなりません。
* the request method is understood by the cache;
* 要求方法はキャッシュによって理解されます。
* the response status code is final (see Section 15 of [HTTP]);
* 応答ステータスコードは最終です（[http]のセクション15を参照）;
* if the response status code is 206 or 304, or the must-understand cache directive (see Section 5.2.2.3) is present: the cache understands the response status code;
* 応答ステータスコードが206または304の場合、または必須のキャッシュ指令（セクション5.2.2.3を参照）が存在する場合：キャッシュは応答ステータスコードを理解します。
* the no-store cache directive is not present in the response (see Section 5.2.2.5);
* ストアなしのキャッシュ指令は、応答には存在しません（セクション5.2.2.5を参照）。
* if the cache is shared: the private response directive is either not present or allows a shared cache to store a modified response; see Section 5.2.2.7);
* キャッシュが共有されている場合：プライベート応答指令が存在しないか、共有キャッシュが変更された応答を保存できるようにします。セクション5.2.2.7を参照）;
* if the cache is shared: the Authorization header field is not present in the request (see Section 11.6.2 of [HTTP]) or a response directive is present that explicitly allows shared caching (see Section 3.5); and
* キャッシュが共有されている場合：承認ヘッダーフィールドはリクエストに存在しません（[http]のセクション11.6.2を参照）または共有キャッシュを明示的に許可する応答指令が存在します（セクション3.5を参照）。と
* the response contains at least one of the following:
* 応答には、以下の少なくとも1つが含まれています。
- a public response directive (see Section 5.2.2.9);
- パブリック応答指令（セクション5.2.2.9を参照）;
- a private response directive, if the cache is not shared (see Section 5.2.2.7);
- キャッシュが共有されていない場合のプライベート応答指令（セクション5.2.2.7を参照）。
- an Expires header field (see Section 5.3);
- ヘッダーフィールドの有効期限（セクション5.3を参照）。
- a max-age response directive (see Section 5.2.2.1);
- 最大年齢の応答指令（セクション5.2.2.1を参照）;
- if the cache is shared: an s-maxage response directive (see Section 5.2.2.10);
- キャッシュが共有されている場合：S-Maxage Responseディレクティブ（セクション5.2.2.10を参照）。
- a cache extension that allows it to be cached (see Section 5.2.3); or
- キャッシュを可能にするキャッシュ拡張機能（セクション5.2.3を参照）。また
- a status code that is defined as heuristically cacheable (see Section 4.2.2).
- ヒューリスティックにキャッシュ可能であると定義されるステータスコード（セクション4.2.2を参照）。
Note that a cache extension can override any of the requirements listed; see Section 5.2.3.
キャッシュ拡張は、リストされている要件のいずれかをオーバーライドできることに注意してください。セクション5.2.3を参照してください。
In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all specified caching-related behavior.
これに関連して、キャッシュは、それを認識し、すべての指定されたキャッシュ関連動作を実装する場合、要求方法または応答ステータスコードを「理解」しました。
Note that, in normal operation, some caches will not store a response that has neither a cache validator nor an explicit expiration time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
通常の操作では、一部のキャッシュは、キャッシュバリデーターも明示的な有効期限もない応答を保存しないことに注意してください。そのような応答は通常保存するのに役立ちません。ただし、キャッシュはそのような応答を保存することを禁止されていません。
Caches MUST include all received response header fields -- including unrecognized ones -- when storing a response; this assures that new HTTP header fields can be successfully deployed. However, the following exceptions are made:
キャッシュは、応答を保存する際に、認識されていないものを含むすべての受信した応答ヘッダーフィールドを含める必要があります。これにより、新しいHTTPヘッダーフィールドを正常に展開できることが保証されます。ただし、次の例外が行われます。
* The Connection header field and fields whose names are listed in it are required by Section 7.6.1 of [HTTP] to be removed before forwarding the message. This MAY be implemented by doing so before storage.
* 名前がリストされている接続ヘッダーフィールドとフィールドは、[http]のセクション7.6.1で、メッセージを転送する前に削除する必要があります。これは、ストレージの前にそうすることで実装できます。
* Likewise, some fields' semantics require them to be removed before forwarding the message, and this MAY be implemented by doing so before storage; see Section 7.6.1 of [HTTP] for some examples.
* 同様に、一部のフィールドのセマンティクスは、メッセージを転送する前にそれらを削除する必要があり、これはストレージの前に実装することができます。いくつかの例については、[http]のセクション7.6.1を参照してください。
* The no-cache (Section 5.2.2.4) and private (Section 5.2.2.7) cache directives can have arguments that prevent storage of header fields by all caches and shared caches, respectively.
* ノーキャッシュ（セクション5.2.2.4）とプライベート（セクション5.2.2.7）キャッシュディレクティブには、それぞれすべてのキャッシュと共有キャッシュによるヘッダーフィールドの保存を防ぐという引数があります。
* Header fields that are specific to the proxy that a cache uses when forwarding a request MUST NOT be stored, unless the cache incorporates the identity of the proxy into the cache key. Effectively, this is limited to Proxy-Authenticate (Section 11.7.1 of [HTTP]), Proxy-Authentication-Info (Section 11.7.3 of [HTTP]), and Proxy-Authorization (Section 11.7.2 of [HTTP]).
* キャッシュがプロキシのIDをキャッシュキーに組み込んでいない限り、要求を転送するときにキャッシュが使用するプロキシに固有のヘッダーフィールドを保存する必要はありません。事実上、これはプロキシと認識（[http]のセクション11.7.1）、プロキシ - 承認Info（[http]のセクション11.7.3）、および委任（[http]のセクション11.7.2）に限定されています。。
Caches MAY either store trailer fields separate from header fields or discard them. Caches MUST NOT combine trailer fields with header fields.
キャッシュは、トレーラーフィールドをヘッダーフィールドとは別に保管するか、それらを破棄する場合があります。キャッシュは、トレーラーフィールドとヘッダーフィールドを組み合わせてはなりません。
Caches are required to update a stored response's header fields from another (typically newer) response in several situations; for example, see Sections 3.4, 4.3.4, and 4.3.5.
キャッシュは、いくつかの状況で別の（通常は新しい）応答から保存された応答のヘッダーフィールドを更新するために必要です。たとえば、セクション3.4、4.3.4、および4.3.5を参照してください。
When doing so, the cache MUST add each header field in the provided response to the stored response, replacing field values that are already present, with the following exceptions:
そうする場合、キャッシュは、以下の例外を除いて、既に存在するフィールド値を置き換えて、保存された応答に対する提供された応答に各ヘッダーフィールドを追加する必要があります。
* Header fields excepted from storage in Section 3.1,
* セクション3.1のストレージから除くヘッダーフィールド、
* Header fields that the cache's stored response depends upon, as described below,
* 以下で説明するように、キャッシュの保存された応答が依存するヘッダーフィールド
* Header fields that are automatically processed and removed by the recipient, as described below, and
* 以下で説明するように、受信者によって自動的に処理および削除されるヘッダーフィールドと
* The Content-Length header field.
* コンテンツレングスヘッダーフィールド。
In some cases, caches (especially in user agents) store the results of processing the received response, rather than the response itself, and updating header fields that affect that processing can result in inconsistent behavior and security issues. Caches in this situation MAY omit these header fields from updating stored responses on an exceptional basis but SHOULD limit such omission to those fields necessary to assure integrity of the stored response.
場合によっては、キャッシュ（特にユーザーエージェントで）は、応答自体ではなく、受信した応答の処理結果を保存し、その処理に影響を与えるヘッダーフィールドを更新すると、一貫性のない動作とセキュリティの問題が発生する可能性があります。この状況でのキャッシュは、これらのヘッダーフィールドを例外的に保存された応答の更新から省略する可能性がありますが、保存された応答の完全性を保証するために必要なフィールドにそのような省略を制限するはずです。
For example, a browser might decode the content coding of a response while it is being received, creating a disconnect between the data it has stored and the response's original metadata. Updating that stored metadata with a different Content-Encoding header field would be problematic. Likewise, a browser might store a post-parse HTML tree rather than the content received in the response; updating the Content-Type header field would not be workable in this case because any assumptions about the format made in parsing would now be invalid.
たとえば、ブラウザは、受信中に応答のコンテンツコーディングをデコードし、保存したデータと応答の元のメタデータ間に切断を作成する場合があります。異なるコンテンツエンコードヘッダーフィールドで保存されたメタデータを更新するのに問題があります。同様に、ブラウザは、応答で受信したコンテンツではなく、パース後のHTMLツリーを保存する場合があります。コンテンツタイプのヘッダーフィールドの更新は、この場合、解析で作成された形式に関する仮定が無効になるため、実行可能ではありません。
Furthermore, some fields are automatically processed and removed by the HTTP implementation, such as the Content-Range header field. Implementations MAY automatically omit such header fields from updates, even when the processing does not actually occur.
さらに、一部のフィールドは、コンテンツレンジヘッダーフィールドなどのHTTP実装により自動的に処理および削除されます。実装は、処理が実際に発生しない場合でも、更新からそのようなヘッダーフィールドを自動的に省略する場合があります。
Note that the Content-* prefix is not a signal that a header field is omitted from update; it is a convention for MIME header fields, not HTTP.
コンテンツ - *プレフィックスは、ヘッダーフィールドが更新から省略されているという信号ではないことに注意してください。これは、HTTPではなく、MIMEヘッダーフィールドのコンベンションです。
If the request method is GET, the response status code is 200 (OK), and the entire response header section has been received, a cache MAY store a response that is not complete (Section 6.1 of [HTTP]) provided that the stored response is recorded as being incomplete. Likewise, a 206 (Partial Content) response MAY be stored as if it were an incomplete 200 (OK) response. However, a cache MUST NOT store incomplete or partial-content responses if it does not support the Range and Content-Range header fields or if it does not understand the range units used in those fields.
リクエストメソッドが取得されている場合、応答ステータスコードは200（OK）であり、応答ヘッダーセクション全体が受信された場合、キャッシュは完全でない応答を保存する場合があります（[http]のセクション6.1）。不完全であると記録されています。同様に、206（部分コンテンツ）応答は、不完全な200（OK）応答であるかのように保存される場合があります。ただし、キャッシュは、範囲とコンテンツレンジのヘッダーフィールドをサポートしていない場合、またはそれらのフィールドで使用されている範囲ユニットを理解していない場合、不完全または部分的な応答を保存してはなりません。
A cache MAY complete a stored incomplete response by making a subsequent range request (Section 14.2 of [HTTP]) and combining the successful response with the stored response, as defined in Section 3.4. A cache MUST NOT use an incomplete response to answer requests unless the response has been made complete, or the request is partial and specifies a range wholly within the incomplete response. A cache MUST NOT send a partial response to a client without explicitly marking it using the 206 (Partial Content) status code.
キャッシュは、後続の範囲要求（[HTTP]のセクション14.2）を作成し、セクション3.4で定義されているように、成功した応答と保存された応答を組み合わせることにより、保存された不完全な応答を完了する場合があります。キャッシュは、応答が完了した場合を除き、リクエストに不完全な応答を使用してはならないか、リクエストが部分的であり、不完全な応答内で完全に範囲を指定してください。キャッシュは、206（部分コンテンツ）ステータスコードを使用して明示的にマークすることなく、クライアントに部分的な応答を送信してはなりません。
A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (Section 14.2 of [HTTP]). After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in Section 15.3.7.3 of [HTTP].
応答は、接続が時期尚早に閉じた場合、または要求が1つ以上の範囲指定子を使用した場合の部分表現のみを転送する場合があります（[HTTP]のセクション14.2）。このような転送の後、キャッシュは同じ表現のいくつかの範囲を受け取った可能性があります。キャッシュは、これらの範囲を単一の保存された応答に組み合わせて、後の要求を満たすための応答を再利用する場合があります。すべてが同じ強力な検証因子を共有し、キャッシュが[HTTP]のセクション15.3.7.3のクライアント要件に準拠している場合。
When combining the new response with one or more stored responses, a cache MUST update the stored response header fields using the header fields provided in the new response, as per Section 3.2.
新しい応答を1つ以上の保存された応答と組み合わせる場合、セクション3.2に従って、新しい応答で提供されているヘッダーフィールドを使用して、キャッシュは保存された応答ヘッダーフィールドを更新する必要があります。
A shared cache MUST NOT use a cached response to a request with an Authorization header field (Section 11.6.2 of [HTTP]) to satisfy any subsequent request unless the response contains a Cache-Control field with a response directive (Section 5.2.2) that allows it to be stored by a shared cache, and the cache conforms to the requirements of that directive for that response.
共有キャッシュは、応答に応答指令を持つキャッシュコントロールフィールドが含まれていない限り、認証ヘッダーフィールド（[http]のセクション11.6.2の[http]のセクション11.6.2）を持つ要求に対するキャッシュされた応答を使用してはなりません（セクション5.2.2）それは共有キャッシュによって保存されることを可能にし、キャッシュはその応答のその指令の要件に適合します。
In this specification, the following response directives have such an effect: must-revalidate (Section 5.2.2.2), public (Section 5.2.2.9), and s-maxage (Section 5.2.2.10).
この仕様では、次の応答指令には、必見（セクション5.2.2.2）、public（セクション5.2.2.9）、およびSマクセージ（セクション5.2.2.10）の効果があります。
When presented with a request, a cache MUST NOT reuse a stored response unless:
リクエストが提示された場合、キャッシュは次のとおりで保存された応答を再利用してはなりません。
* the presented target URI (Section 7.1 of [HTTP]) and that of the stored response match, and
* 提示されたターゲットURI（[http]のセクション7.1）および保存された応答マッチのそれと
* the request method associated with the stored response allows it to be used for the presented request, and
* 保存された応答に関連付けられた要求方法により、提示されたリクエストに使用することができます。
* request header fields nominated by the stored response (if any) match those presented (see Section 4.1), and
* 保存された応答（ある場合）に指名されたヘッダーフィールドをリクエストします（存在する場合）提示されたもの（セクション4.1を参照）、および
* the stored response does not contain the no-cache directive (Section 5.2.2.4), unless it is successfully validated (Section 4.3), and
* 保存された応答には、正常に検証されていない限り（セクション4.3）がない限り（セクション5.2.2.4）、ノーキャッシュ指令が含まれていません（セクション4.3）、
* the stored response is one of the following:
* 保存された応答は次のいずれかです。
- fresh (see Section 4.2), or
- フレッシュ（セクション4.2を参照）、または
- allowed to be served stale (see Section 4.2.4), or
- 古くすることを許可されています（セクション4.2.4を参照）、または
- successfully validated (see Section 4.3).
- 検証されたことに成功しました（セクション4.3を参照）。
Note that a cache extension can override any of the requirements listed; see Section 5.2.3.
キャッシュ拡張は、リストされている要件のいずれかをオーバーライドできることに注意してください。セクション5.2.3を参照してください。
When a stored response is used to satisfy a request without validation, a cache MUST generate an Age header field (Section 5.1), replacing any present in the response with a value equal to the stored response's current_age; see Section 4.2.3.
保存された応答を使用して検証なしでリクエストを満たす場合、キャッシュは年齢ヘッダーフィールド（セクション5.1）を生成する必要があり、応答の存在を保存された応答のcurrent_ageに等しい値に置き換える必要があります。セクション4.2.3を参照してください。
A cache MUST write through requests with methods that are unsafe (Section 9.2.1 of [HTTP]) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request and having received a corresponding response.
キャッシュは、Origin Serverに安全でないメソッド（[HTTP]のセクション9.2.1）を使用したリクエストを介して書き込む必要があります。つまり、要求を転送して対応する応答を受信する前に、キャッシュはそのようなリクエストへの返信を生成することは許可されていません。
Also, note that unsafe requests might invalidate already-stored responses; see Section 4.4.
また、安全でないリクエストは、すでに保存されている応答を無効にする可能性があることに注意してください。セクション4.4を参照してください。
A cache can use a response that is stored or storable to satisfy multiple requests, provided that it is allowed to reuse that response for the requests in question. This enables a cache to "collapse requests" -- or combine multiple incoming requests into a single forward request upon a cache miss -- thereby reducing load on the origin server and network. Note, however, that if the cache cannot use the returned response for some or all of the collapsed requests, it will need to forward the requests in order to satisfy them, potentially introducing additional latency.
キャッシュは、問題のリクエストに対するその応答を再利用できる場合、複数のリクエストを満たすために保存または保存可能な応答を使用できます。これにより、キャッシュが「崩壊要求」を行うことができます。または、複数の着信要求をキャッシュミス時に単一のフォワードリクエストに組み合わせて、Origin Serverとネットワークの負荷を削減できます。ただし、キャッシュが崩壊した要求の一部またはすべてに対して返された応答を使用できない場合、それらを満たすためにリクエストを転送する必要があり、追加のレイテンシを導入する可能性があることに注意してください。
When more than one suitable response is stored, a cache MUST use the most recent one (as determined by the Date header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
複数の適切な応答が保存されている場合、キャッシュは最新の応答を使用する必要があります（日付ヘッダーフィールドで決定されます）。また、「Cache-Control：Max-Age = 0」または「Cache-Control：No-Cache」でリクエストを転送して、使用に対する応答を明確にします。
A cache without a clock (Section 5.6.7 of [HTTP]) MUST revalidate stored responses upon every use.
クロックのないキャッシュ（[HTTP]のセクション5.6.7）は、すべての使用時に保存された応答を再確認する必要があります。
When a cache receives a request that can be satisfied by a stored response and that stored response contains a Vary header field (Section 12.5.5 of [HTTP]), the cache MUST NOT use that stored response without revalidation unless all the presented request header fields nominated by that Vary field value match those fields in the original request (i.e., the request that caused the cached response to be stored).
キャッシュが保存された応答によって満たされ、保存された応答に変化するヘッダーフィールド（[http]のセクション12.5.5）が含まれているリクエストを受信した場合、提示されたすべてのリクエストヘッダーがない限り、キャッシュは再確認なしでその保存された応答を使用してはなりませんそれによって指名されたフィールドは、フィールド値が元のリクエストでこれらのフィールドと一致します（つまり、キャッシュされた応答が保存された要求）。
The header fields from two requests are defined to match if and only if those in the first request can be transformed to those in the second request by applying any of the following:
2つのリクエストからのヘッダーフィールドは、最初のリクエストのものが次のいずれかを適用して、2番目の要求のものに変換できる場合にのみ一致するように定義されます。
* adding or removing whitespace, where allowed in the header field's syntax
* ヘッダーフィールドの構文で許可されているホワイトスペースの追加または削除
* combining multiple header field lines with the same field name (see Section 5.2 of [HTTP])
* 複数のヘッダーフィールドラインと同じフィールド名を組み合わせる（[http]のセクション5.2を参照）
* normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification (e.g., reordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
* ヘッダーフィールドの仕様に応じて、同一のセマンティクスを持つことが知られている方法で両方のヘッダーフィールド値を正規化する（例：順序が重要ではない場合にフィールド値を並べ替える;ケース正規化、ケース非感受性と定義される場合）
If (after any normalization that might take place) a header field is absent from a request, it can only match another request if it is also absent there.
（実行される可能性のある正規化の後）ヘッダーフィールドがリクエストに存在しない場合、そこにも存在しない場合にのみ別の要求と一致させることができます。
A stored response with a Vary header field value containing a member "*" always fails to match.
メンバー「*」を含むさまざまなヘッダーフィールド値を持つ保存された応答は、常に一致しません。
If multiple stored responses match, the cache will need to choose one to use. When a nominated request header field has a known mechanism for ranking preference (e.g., qvalues on Accept and similar request header fields), that mechanism MAY be used to choose a preferred response. If such a mechanism is not available, or leads to equally preferred responses, the most recent response (as determined by the Date header field) is chosen, as per Section 4.
複数の保存された応答が一致する場合、使用するキャッシュを選択する必要があります。ノミネートされた要求ヘッダーフィールドに、ランキング選好のメカニズムが既知の場合（たとえば、受け入れのQValuesや同様のリクエストヘッダーフィールド）、そのメカニズムを使用して優先応答を選択できます。このようなメカニズムが利用できない場合、または等しく好ましい応答につながる場合、セクション4に従って、最新の応答（日付ヘッダーフィールドによって決定される）が選択されます。
Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when the request does not express any preferences), with the effect of choosing it for subsequent requests to that resource even when more preferable responses are available. When a cache has multiple stored responses for a target URI and one or more omits the Vary header field, the cache SHOULD choose the most recent (see Section 4.2.3) stored response with a valid Vary field value.
一部のリソースは、デフォルトの応答からさまざまなヘッダーフィールドを誤って省略します（つまり、リクエストが設定を表明しないときに送信されたものが送信されます）。より好ましい応答が利用可能であっても、そのリソースをその後のリクエストに選択する効果があります。キャッシュにターゲットURIの複数の保存された応答があり、1つ以上が異なるヘッダーフィールドを省略した場合、キャッシュは有効な異なるフィールド値で最新の（セクション4.2.3を参照）保存された応答を選択する必要があります。
If no stored response matches, the cache cannot satisfy the presented request. Typically, the request is forwarded to the origin server, potentially with preconditions added to describe what responses the cache has already stored (Section 4.3).
保存された応答が一致しない場合、キャッシュは提示されたリクエストを満たすことができません。通常、リクエストはOrigin Serverに転送され、潜在的にはキャッシュがすでに保存している応答を説明する前提条件が追加されます（セクション4.3）。
A "fresh" response is one whose age has not yet exceeded its freshness lifetime. Conversely, a "stale" response is one where it has.
「新鮮な」反応とは、年齢がまだ新鮮さの寿命を超えていないものです。逆に、「古い」応答はそれが持っているものです。
A response's "freshness lifetime" is the length of time between its generation by the origin server and its expiration time. An "explicit expiration time" is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation, whereas a "heuristic expiration time" is assigned by a cache when no explicit expiration time is available.
応答の「新鮮な寿命」は、Origin Serverによる生成と有効期限までの間の時間の長さです。「明示的な有効期限」とは、オリジンサーバーが保存された応答をさらに検証せずにキャッシュで使用できなくなることを意図する時間であり、一方、「ヒューリスティックな有効期限」は、明示的な有効期限が利用できない場合にキャッシュによって割り当てられます。
A response's "age" is the time that has passed since it was generated by, or successfully validated with, the origin server.
応答の「年齢」とは、Origin Serverによって生成された、または順調に検証されてから経過した時間です。
When a response is fresh, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.
応答が新鮮な場合、Origin Serverに連絡せずに後続の要求を満たすために使用でき、それにより効率が向上します。
The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, using either the Expires header field (Section 5.3) or the max-age response directive (Section 5.2.2.1). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation is not likely to change in a semantically significant way before the expiration time is reached.
新鮮さを決定するための主なメカニズムは、有効期限がヘッダーフィールド（セクション5.3）または最大時代の応答指令（セクション5.2.2.1）を使用して、将来の明示的な有効期限を提供することです。一般に、Origin Serverは、有効期限が到達する前に表現が意味的に重要な方法で変化する可能性が低いという信念で、将来の明示的な有効期限を応答に割り当てます。
If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing it for subsequent requests (see Section 4.2.4).
Origin Serverがキャッシュを強制的にすべてのリクエストに検証することを希望する場合、過去の明示的な有効期限を割り当てて、応答がすでに古くなっていることを示すことができます。準拠したキャッシュは、通常、古いキャッシュされた応答を検証してから、その後のリクエストのために再利用します（セクション4.2.4を参照）。
Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine an expiration time under certain circumstances (see Section 4.2.2).
原点サーバーは常に明示的な有効期限を提供するとは限らないため、キャッシュはヒューリスティックを使用して、特定の状況下で有効期限を決定することも許可されています（セクション4.2.2を参照）。
The calculation to determine if a response is fresh is:
応答が新鮮かどうかを判断するための計算は次のとおりです。
response_is_fresh = (freshness_lifetime > current_age)
freshness_lifetime is defined in Section 4.2.1; current_age is defined in Section 4.2.3.
Freshness_lifetimeは、セクション4.2.1で定義されています。current_ageは、セクション4.2.3で定義されています。
Clients can send the max-age or min-fresh request directives (Section 5.2.1) to suggest limits on the freshness calculations for the corresponding response. However, caches are not required to honor them.
クライアントは、最大年齢または最小リクエストディレクティブ（セクション5.2.1）を送信して、対応する応答の鮮度計算の制限を提案できます。ただし、キャッシュはそれらを尊重する必要はありません。
When calculating freshness, to avoid common problems in date parsing:
新鮮さを計算するとき、日付の解析の一般的な問題を回避するために：
* Although all date formats are specified to be case-sensitive, a cache recipient SHOULD match the field value case-insensitively.
* すべての日付形式は症例に敏感であるように指定されていますが、キャッシュ受信者はフィールド値のケースインスセンシティングと一致する必要があります。
* If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient MUST internally represent a parsed Expires date as the nearest time equal to or earlier than the received value.
* キャッシュ受信者の時間の内部実装がHTTP日付の値よりも解像度が少ない場合、受信者は、受信値よりも最も近い時間として解析された期限が内部的に表現する必要があります。
* A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
* キャッシュの受信者は、現地時間ゾーンが年齢または有効期限の計算または比較に影響を与えることを許可してはなりません。
* A cache recipient SHOULD consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
* キャッシュ受信者は、「GMT」以外のゾーンの略語がある日付を、有効期限を計算するために無効であることを考慮する必要があります。
Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload a resource. See Section 6 for an explanation of the difference between caches and history mechanisms.
新鮮さはキャッシュ操作にのみ適用されることに注意してください。ユーザーエージェントにディスプレイを更新したり、リソースをリロードするように強制するために使用することはできません。キャッシュと履歴メカニズムの違いの説明については、セクション6を参照してください。
A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by evaluating the following rules and using the first match:
キャッシュは、以下のルールを評価し、最初の一致を使用することにより、応答の新鮮な寿命（新鮮された_lifetimeとして示される）を計算できます。
* If the cache is shared and the s-maxage response directive (Section 5.2.2.10) is present, use its value, or
* キャッシュが共有され、S-Maxage応答指令（セクション5.2.2.10）が存在する場合、その値を使用するか、
* If the max-age response directive (Section 5.2.2.1) is present, use its value, or
* 最大年齢の応答指令（セクション5.2.2.1）が存在する場合、その値を使用するか、
* If the Expires response header field (Section 5.3) is present, use its value minus the value of the Date response header field (using the time the message was received if it is not present, as per Section 6.6.1 of [HTTP]), or
* 対応ヘッダーフィールド（セクション5.3）が存在する場合、[HTTP]のセクション6.6.1に従って、[メッセージが存在しない場合にメッセージが受信された場合も、日付応答ヘッダーフィールドの値を差し引いた値を差し引いた値を使用します）、 また
* Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see Section 4.2.2.
* それ以外の場合、応答に明示的な有効期限が存在しません。ヒューリスティックな新鮮さの寿命が適用される可能性があります。セクション4.2.2を参照してください。
Note that this calculation is intended to reduce clock skew by using the clock information provided by the origin server whenever possible.
この計算は、可能な限りOrigin Serverが提供するクロック情報を使用することにより、クロックスキューを減らすことを目的としていることに注意してください。
When there is more than one value present for a given directive (e.g., two Expires header field lines or multiple Cache-Control: max-age directives), either the first occurrence should be used or the response should be considered stale. If directives conflict (e.g., both max-age and no-cache are present), the most restrictive directive should be honored. Caches are encouraged to consider responses that have invalid freshness information (e.g., a max-age directive with non-integer content) to be stale.
特定のディレクティブに複数の値が存在する場合（たとえば、2つのヘッダーフィールドラインまたは複数のキャッシュコントロール：最大時代のディレクティブ）、最初の発生を使用するか、応答を古くみなす必要があります。指令が競合する場合（例：最大年齢とノーキャッシュの両方が存在する場合）、最も制限的な指令を尊重する必要があります。キャッシュは、無効な鮮度情報（例：非整数コンテンツを含む最大年齢の指令など）が古くすることを考慮することをお勧めします。
Since origin servers do not always provide explicit expiration times, a cache MAY assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other field values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but it does impose worst-case constraints on their results.
Origin Serversは常に明示的な有効期限を提供するとは限らないため、キャッシュは、明示的な時間が指定されていない場合にヒューリスティックな有効期限を割り当てる場合があり、他のフィールド値（ラスト変更時間など）を使用してもっともらしい有効期限を推定するアルゴリズムを使用します。この仕様は特定のアルゴリズムを提供しませんが、結果に最悪の制約を課します。
A cache MUST NOT use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements in Section 3, heuristics can only be used on responses without explicit freshness whose status codes are defined as "heuristically cacheable" (e.g., see Section 15.1 of [HTTP]) and on responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a public response directive).
キャッシュは、保存された応答に明示的な有効期限が存在する場合、新鮮さを決定するためにヒューリスティックを使用してはなりません。セクション3の要件のため、ヒューリスティックは、ステータスコードが「ヒューリスト的にキャッシュ可能」として定義されている明示的な新鮮さのない応答のみで使用できます（例：[HTTP]のセクション15.1を参照）、および明示的な新鮮さのない応答は、明示的にキャッシュ可能（例：パブリック対応指令を使用）。
Note that in previous specifications, heuristically cacheable response status codes were called "cacheable by default".
以前の仕様では、ヒューリスティックなキャッシュ可能な応答ステータスコードは「デフォルトでキャッシュ可能」と呼ばれていたことに注意してください。
If the response has a Last-Modified header field (Section 8.8.2 of [HTTP]), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
応答にラスト変更されたヘッダーフィールド（[HTTP]のセクション8.8.2）がある場合、キャッシュは、それ以降の間隔の一部にすぎないヒューリスティックな有効期限値を使用することをお勧めします。この画分の典型的な設定は10％かもしれません。
| *Note:* A previous version of the HTTP specification
| (Section 13.9 of [RFC2616]) prohibited caches from calculating
| heuristic freshness for URIs with query components (i.e., those
| containing "?"). In practice, this has not been widely
| implemented. Therefore, origin servers are encouraged to send
| explicit directives (e.g., Cache-Control: no-cache) if they
| wish to prevent caching.
The Age header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is the cache's estimate of the number of seconds since the origin server generated or validated the response. The Age value is therefore the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus the time it has been in transit along network paths.
年齢ヘッダーフィールドは、キャッシュから取得した場合、応答メッセージの推定年齢を伝えるために使用されます。AGEフィールド値は、Origin Serverが応答を生成または検証した後の秒数のキャッシュの推定値です。したがって、年齢価値は、オリジンサーバーからのパスに沿った各キャッシュに応答が居住している時間と、ネットワークパスに沿って輸送中の時間の合計です。
Age calculation uses the following data:
年齢計算では、次のデータを使用します。
"age_value" The term "age_value" denotes the value of the Age header field (Section 5.1), in a form appropriate for arithmetic operation; or 0, if not available.
「age_value」という用語 "age_value"は、算術操作に適した形式での年齢ヘッダーフィールドの値（セクション5.1）を示します。または0、利用できない場合。
"date_value" The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See Section 6.6.1 of [HTTP] for the definition of the Date header field and for requirements regarding responses without it.
「date_value」という用語 "date_value"は、算術操作に適した形式の日付ヘッダーフィールドの値を示します。[HTTP]のセクション6.6.1を参照してください。日付ヘッダーフィールドの定義と、それなしの応答に関する要件については。
"now" The term "now" means the current value of this implementation's clock (Section 5.6.7 of [HTTP]).
「Now」という用語「Now」とは、この実装のクロックの現在の値を意味します（[HTTP]のセクション5.6.7）。
"request_time" The value of the clock at the time of the request that resulted in the stored response.
「Request_Time」は、保存された応答をもたらしたリクエストの時点でのクロックの値。
"response_time" The value of the clock at the time the response was received.
「Response_Time」応答が受信された時点でのクロックの値。
A response's age can be calculated in two entirely independent ways:
応答の年齢は、完全に独立した2つの方法で計算できます。
1. the "apparent_age": response_time minus date_value, if the implementation's clock is reasonably well synchronized to the origin server's clock. If the result is negative, the result is replaced by zero.
1. 「cimplent_age」：response_time minus date_value、実装のクロックがOrigin Serverのクロックと合理的によく同期されている場合。結果が負の場合、結果はゼロに置き換えられます。
2. the "corrected_age_value", if all of the caches along the response path implement HTTP/1.1 or greater. A cache MUST interpret this value relative to the time the request was initiated, not the time that the response was received.
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;
The corrected_age_value MAY be used as the corrected_initial_age. In circumstances where very old cache implementations that might not correctly insert Age are present, corrected_initial_age can be calculated more conservatively as
corrected_age_valueは、corrected_initial_ageとして使用できます。年齢を正しく挿入しない可能性のある非常に古いキャッシュの実装が存在する状況では、corrected_initial_ageはより保守的に計算できます
corrected_initial_age = max(apparent_age, corrected_age_value);
The current_age of a stored response can then be calculated by adding the time (in seconds) since the stored response was last validated by the origin server to the corrected_initial_age.
保存された応答がcortered_initial_ageに最後に検証されたため、保存された応答のcurrent_ageは時間（秒単位）を追加することで計算できます。
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but is not fresh according to the calculations in Section 4.2.
「古い」応答とは、明示的な有効期限があるか、ヒューリスティックの有効期限が計算されることが許可されているが、セクション4.2の計算に従って新鮮ではない。
A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a no-cache response directive, a must-revalidate response directive, or an applicable s-maxage or proxy-revalidate response directive; see Section 5.2.2).
CACHEは、明示的な非プロトコル指令によって禁止されている場合、古い応答を生成してはなりません（たとえば、キャッシュ応答の指令、必見の応答指令、または該当するS-MaxageまたはProxy-Revalidate Response Directive;セクション5.2.2を参照）。
A cache MUST NOT generate a stale response unless it is disconnected or doing so is explicitly permitted by the client or origin server (e.g., by the max-stale request directive in Section 5.2.1, extension directives such as those defined in [RFC5861], or configuration in accordance with an out-of-band contract).
キャッシュは、クライアントまたはオリジンサーバーによって切断されているか、そうしている場合を除き、古い応答を生成してはなりません（たとえば、セクション5.2.1の最大段階リクエスト指示、[RFC5861]で定義されているものなどの拡張指令により、または帯域外契約に従って構成）。
When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not fresh, or one cannot be chosen; see Section 4.1), it can use the conditional request mechanism (Section 13 of [HTTP]) in the forwarded request to give the next inbound server an opportunity to choose a valid stored response to use, updating the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as "validating" or "revalidating" the stored response.
キャッシュに要求されたURIの1つ以上の保存された応答があるが、それらのいずれも提供できない場合（たとえば、それらは新鮮ではないか、選択できないため、セクション4.1を参照）、条件付き要求メカニズムを使用できます（セクション13[http]）次のインバウンドサーバーに使用するための有効な保存された応答を選択し、プロセスで保存されたメタデータを更新するか、保存された応答を新しい応答に置き換える機会を与えるという転送要求で。このプロセスは、保存された応答の「検証」または「再検証」として知られています。
When generating a conditional request for validation, a cache either starts with a request it is attempting to satisfy or -- if it is initiating the request independently -- synthesizes a request using a stored response by copying the method, target URI, and request header fields identified by the Vary header field (Section 4.1).
検証の条件付きリクエストを生成するとき、キャッシュは満足しようとするリクエストから始まるか、それが独立してリクエストを開始している場合、メソッドをコピーし、ターゲットURIをコピーして保存された応答を使用してリクエストを合成し、ヘッダーをリクエストするさまざまなヘッダーフィールド（セクション4.1）によって識別されるフィールド。
It then updates that request with one or more precondition header fields. These contain validator metadata sourced from a stored response(s) that has the same URI. Typically, this will include only the stored response(s) that has the same cache key, although a cache is allowed to validate a response that it cannot choose with the request header fields it is sending (see Section 4.1).
次に、その要求を1つ以上の前提条件ヘッダーフィールドで更新します。これらには、同じURIを持つ保存された応答から供給されたバリデーターメタデータが含まれています。通常、これには、同じキャッシュキーを持つ保存された応答のみが含まれますが、キャッシュは送信しているリクエストヘッダーフィールドで選択できない応答を検証することができます（セクション4.1を参照）。
The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource.
次に、前処理ヘッダーフィールドを受信者によって比較され、保存された応答がリソースの現在の表現と同等であるかどうかを判断します。
One such validator is the timestamp given in a Last-Modified header field (Section 8.8.2 of [HTTP]), which can be used in an If-Modified-Since header field for response validation, or in an If-Unmodified-Since or If-Range header field for representation selection (i.e., the client is referring specifically to a previously obtained representation with that timestamp).
そのようなバリデーターの1つは、ラスト修正ヘッダーフィールド（[http]のセクション8.8.2）で与えられたタイムスタンプです。または、表現選択用のif-rangeヘッダーフィールド（つまり、クライアントは、そのタイムスタンプで以前に得られた表現を特に指しています）。
Another validator is the entity tag given in an ETag field (Section 8.8.3 of [HTTP]). One or more entity tags, indicating one or more stored responses, can be used in an If-None-Match header field for response validation, or in an If-Match or If-Range header field for representation selection (i.e., the client is referring specifically to one or more previously obtained representations with the listed entity tags).
別のバリデーターは、ETAGフィールドに与えられたエンティティタグです（[HTTP]のセクション8.8.3）。1つ以上のエンティティタグは、1つまたは複数の保存された応答を示し、応答検証のためにIF-Noneマッチヘッダーフィールドで、または表現選択のためのIFマッチまたはIFレンジヘッダーフィールドで使用できます（つまり、クライアントはです。リストされたエンティティタグを使用して、以前に取得した1つ以上の表現を特に参照してください）。
When generating a conditional request for validation, a cache:
検証の条件付きリクエストを生成する場合、キャッシュ：
* MUST send the relevant entity tags (using If-Match, If-None-Match, or If-Range) if the entity tags were provided in the stored response(s) being validated.
* 関連するエンティティタグ（IF-Match、If-None-Match、またはIf-Rangeを使用して）を送信する必要があります。
* SHOULD send the Last-Modified value (using If-Modified-Since) if the request is not for a subrange, a single stored response is being validated, and that response contains a Last-Modified value.
* 要求がサブレンジでない場合は、ラスト修飾値を（if-modified-sinceを使用して）送信する必要があります。単一の保存された応答が検証され、その応答には永久修正値が含まれています。
* MAY send the Last-Modified value (using If-Unmodified-Since or If-Range) if the request is for a subrange, a single stored response is being validated, and that response contains only a Last-Modified value (not an entity tag).
* 要求がサブレンジの場合、ラスト修正値（IF-Unmodified-sinceまたはif-rangeを使用）を送信する場合があります。単一の保存された応答が検証され、その応答にはラスト変更値のみが含まれています（エンティティタグではありません）。
In most cases, both validators are generated in cache validation requests, even when entity tags are clearly superior, to allow old intermediaries that do not understand entity tag preconditions to respond appropriately.
ほとんどの場合、エンティティタグが明らかに優れている場合でも、両方のバリデーターはキャッシュ検証要求で生成され、エンティティタグの前提条件を適切に応答できるようにする古い仲介者が許可されます。
Each client in the request chain may have its own cache, so it is common for a cache at an intermediary to receive conditional requests from other (outbound) caches. Likewise, some user agents make use of conditional requests to limit data transfers to recently modified representations or to complete the transfer of a partially retrieved representation.
リクエストチェーンの各クライアントには独自のキャッシュがある場合があるため、仲介者のキャッシュが他の（アウトバウンド）キャッシュから条件付きリクエストを受信することが一般的です。同様に、一部のユーザーエージェントは、データ転送を最近修正された表現に制限する条件付きリクエストを使用して、部分的に取得した表現の転送を完了します。
If a cache receives a request that can be satisfied by reusing a stored 200 (OK) or 206 (Partial Content) response, as per Section 4, the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators contained within the stored response.
セクション4によると、キャッシュが200（OK）または206（部分コンテンツ）応答を再利用することで満たすことができるリクエストを受信した場合、キャッシュは、対応するリクエストで受け取った該当する条件付きヘッダーフィールドの前提条件を評価する必要があります。保存された応答内に含まれるバリデーター。
A cache MUST NOT evaluate conditional header fields that only apply to an origin server, occur in a request with semantics that cannot be satisfied with a cached response, or occur in a request with a target resource for which it has no stored responses; such preconditions are likely intended for some other (inbound) server.
キャッシュは、Origin Serverにのみ適用される条件付きヘッダーフィールドを評価してはなりません。キャッシュされた応答に満足できないセマンティクスでリクエストで発生したり、貯蔵された応答がないターゲットリソースを使用してリクエストで発生したりする必要があります。このような前提条件は、他の（インバウンド）サーバーを対象としている可能性があります。
The proper evaluation of conditional requests by a cache depends on the received precondition header fields and their precedence. In summary, the If-Match and If-Unmodified-Since conditional header fields are not applicable to a cache, and If-None-Match takes precedence over If-Modified-Since. See Section 13.2.2 of [HTTP] for a complete specification of precondition precedence.
キャッシュによる条件付き要求の適切な評価は、受信した前処理ヘッダーフィールドとその優先順位に依存します。要約すると、if-matchおよびif-unmodified-sinceの条件付きヘッダーフィールドはキャッシュには適用されず、if-none-matchがif modified-sinceよりも優先されます。前提条件の優先順位の完全な仕様については、[http]のセクション13.2.2を参照してください。
A request containing an If-None-Match header field (Section 13.1.2 of [HTTP]) indicates that the client wants to validate one or more of its own stored responses in comparison to the stored response chosen by the cache (as per Section 4).
if-none-matchヘッダーフィールド（[http]のセクション13.1.2）を含むリクエストは、クライアントがキャッシュによって選択された保存された応答と比較して（セクションに従って、保存された応答の1つ以上を検証したいことを示しています。4）。
If an If-None-Match header field is not present, a request containing an If-Modified-Since header field (Section 13.1.3 of [HTTP]) indicates that the client wants to validate one or more of its own stored responses by modification date.
if-none-matchヘッダーフィールドが存在しない場合、ifmodified-sinceヘッダーフィールド（[http]のセクション13.1.3）を含むリクエストは、クライアントが1つ以上の独自の保存された応答を検証したいことを示しています。変更日。
If a request contains an If-Modified-Since header field and the Last-Modified header field is not present in a stored response, a cache SHOULD use the stored response's Date field value (or, if no Date field is present, the time that the stored response was received) to evaluate the conditional.
リクエストには、if修正シンクのヘッダーフィールドが含まれており、ラスト修正ヘッダーフィールドが保存された応答に存在しない場合、キャッシュは保存された応答の日付フィールド値を使用する必要があります（または、日付フィールドが存在しない場合、保存された応答が受信されました）条件付きを評価しました。
A cache that implements partial responses to range requests, as defined in Section 14.2 of [HTTP], also needs to evaluate a received If-Range header field (Section 13.1.5 of [HTTP]) with respect to the cache's chosen response.
[http]のセクション14.2で定義されているように、範囲要求に対する部分的な応答を実装するキャッシュは、キャッシュの選択応答に関して受信されたif-rangeヘッダーフィールド（[http]のセクション13.1.5）を評価する必要があります。
When a cache decides to forward a request to revalidate its own stored responses for a request that contains an If-None-Match list of entity tags, the cache MAY combine the received list with a list of entity tags from its own stored set of responses (fresh or stale) and send the union of the two lists as a replacement If-None-Match header field value in the forwarded request. If a stored response contains only partial content, the cache MUST NOT include its entity tag in the union unless the request is for a range that would be fully satisfied by that partial stored response. If the response to the forwarded request is 304 (Not Modified) and has an ETag field value with an entity tag that is not in the client's list, the cache MUST generate a 200 (OK) response for the client by reusing its corresponding stored response, as updated by the 304 response metadata (Section 4.3.4).
キャッシュが、エンティティタグのif-noneマッチリストを含むリクエストに対して独自の保存された応答を再調整するリクエストを転送することを決定した場合、キャッシュは受信したリストと、独自の保存された応答セットからのエンティティタグのリストを組み合わせることができます（新鮮または古くなって）、2つのリストのユニオンを、転送された要求で交換用のIF-NONE-MATCHヘッダーフィールド値として送信します。保存された応答に部分的なコンテンツのみが含まれている場合、その部分的な保存された応答によって完全に満たされる範囲の要求がない限り、キャッシュに組合にエンティティタグを含めるべきではありません。転送された要求への応答が304（変更されていない）であり、クライアントのリストにないエンティティタグを使用してETAGフィールド値を持っている場合、キャッシュは、対応する保存された応答を再利用することにより、クライアントに200（OK）応答を生成する必要があります。、304応答メタデータ（セクション4.3.4）によって更新されます。
Cache handling of a response to a conditional request depends upon its status code:
条件付き要求に対する応答のキャッシュ処理は、ステータスコードによって異なります。
* A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see Section 4.3.4.
* 304（変更されていない）応答ステータスコードは、保存された応答を更新して再利用できることを示します。セクション4.3.4を参照してください。
* A full response (i.e., one containing content) indicates that none of the stored responses nominated in the conditional request are suitable. Instead, the cache MUST use the full response to satisfy the request. The cache MAY store such a full response, subject to its constraints (see Section 3).
* 完全な応答（つまり、コンテンツを含むもの）は、条件付きリクエストで指名された保存された応答のいずれも適切ではないことを示します。代わりに、キャッシュは完全な応答を使用してリクエストを満たす必要があります。キャッシュは、その制約を条件として、このような完全な応答を保存する場合があります（セクション3を参照）。
* However, if a cache receives a 5xx (Server Error) response while attempting to validate a response, it can either forward this response to the requesting client or act as if the server failed to respond. In the latter case, the cache can send a previously stored response, subject to its constraints on doing so (see Section 4.2.4), or retry the validation request.
* ただし、応答の検証中にキャッシュが5xx（サーバーエラー）応答を受信した場合、要求クライアントにこの応答を転送するか、サーバーが応答しなかったかのように動作することができます。後者の場合、キャッシュは、そうすることに対する制約を条件として、以前に保存された応答を送信することができます（セクション4.2.4を参照）、または検証要求を再試行します。
When a cache receives a 304 (Not Modified) response, it needs to identify stored responses that are suitable for updating with the new information provided, and then do so.
キャッシュが304（変更されていない）応答を受信した場合、提供された新しい情報で更新するのに適した保存された応答を識別してからそうする必要があります。
The initial set of stored responses to update are those that could have been chosen for that request -- i.e., those that meet the requirements in Section 4, except the last requirement to be fresh, able to be served stale, or just validated.
更新に対する保存された応答の最初のセットは、その要求のために選択される可能性のあるものです。つまり、新鮮であるか、古くすることができる、または検証されるという最後の要件を除き、セクション4の要件を満たすものです。
Then, that initial set of stored responses is further filtered by the first match of:
次に、保存された応答の最初のセットは、次の最初の一致によってさらにフィルタリングされます。
* If the new response contains one or more "strong validators" (see Section 8.8.1 of [HTTP]), then each of those strong validators identifies a selected representation for update. All the stored responses in the initial set with one of those same strong validators are identified for update. If none of the initial set contains at least one of the same strong validators, then the cache MUST NOT use the new response to update any stored responses.
* 新しい応答に1つ以上の「強力な検証装置」が含まれている場合（[http]のセクション8.8.1を参照）、それらの強力な検証器のそれぞれは、更新のために選択された表現を識別します。これらの同じ強力な検証器の1つを使用した最初のセットのすべての保存された応答は、更新のために識別されます。初期セットのいずれにも同じ強力なバリデーターの少なくとも1つが含まれていない場合、キャッシュは新しい応答を使用して保存された応答を更新してはなりません。
* If the new response contains no strong validators but does contain one or more "weak validators", and those validators correspond to one of the initial set's stored responses, then the most recent of those matching stored responses is identified for update.
* 新しい応答に強力な検証装置は含まれていませんが、1つ以上の「弱い検証因子」が含まれており、それらのバリデーターが初期セットの保存された応答の1つに対応している場合、それらの最新の保存された応答の最新が更新のために識別されます。
* If the new response does not include any form of validator (such as where a client generates an If-Modified-Since request from a source other than the Last-Modified response header field), and there is only one stored response in the initial set, and that stored response also lacks a validator, then that stored response is identified for update.
* 新しい応答に、バリデーターの形式が含まれていない場合（クライアントがラスト変更された応答ヘッダーフィールド以外のソースからif修正済みのリクエストを生成する場所など）、最初のセットには1つの保存された応答のみがあります、そしてその保存された応答にもバリデーターが欠けているため、保存された応答は更新のために識別されます。
For each stored response identified, the cache MUST update its header fields with the header fields provided in the 304 (Not Modified) response, as per Section 3.2.
特定された各応答ごとに、キャッシュはセクション3.2に従って、304（変更されていない）応答で提供されるヘッダーフィールドでヘッダーフィールドを更新する必要があります。
A response to the HEAD method is identical to what an equivalent request made with a GET would have been, without sending the content. This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the content is not desired even if it has changed.
ヘッドメソッドへの応答は、コンテンツを送信せずに、GETで行われた同等のリクエストがあったことと同じです。ヘッド応答のこの特性は、より効率的な条件付きGETリクエストメカニズムが利用できない場合（保存された応答にバリターが存在しないため）、またはコンテンツの送信が望ましくない場合でも、キャッシュされたGET応答を無効または更新するために使用できます。それは変わりました。
When a cache makes an inbound HEAD request for a target URI and receives a 200 (OK) response, the cache SHOULD update or invalidate each of its stored GET responses that could have been chosen for that request (see Section 4.1).
キャッシュがターゲットURIのインバウンドヘッドリクエストを行い、200（OK）応答を受信すると、キャッシュはその要求に対して選択される可能性のある保存された各回答を更新または無効にする必要があります（セクション4.1を参照）。
For each of the stored responses that could have been chosen, if the stored response and HEAD response have matching values for any received validator fields (ETag and Last-Modified) and, if the HEAD response has a Content-Length header field, the value of Content-Length matches that of the stored response, the cache SHOULD update the stored response as described below; otherwise, the cache SHOULD consider the stored response to be stale.
選択された可能性のある各応答の場合、保存された応答とヘッド応答が受信されたバリデーターフィールド（ETAGおよびラスト変更）の一致値があり、ヘッド応答にコンテンツレングスヘッダーフィールドがある場合、値は値です。保存された応答のコンテンツレングスと一致するコンテンツの長さは、以下に説明するように、キャッシュは保存された応答を更新する必要があります。それ以外の場合、キャッシュは、保存された応答が古くなっていると考える必要があります。
If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST use the header fields provided in the HEAD response to update the stored response (see Section 3.2).
キャッシュがヘッド応答で提供されたメタデータを使用して保存された応答を更新する場合、キャッシュはヘッド応答で提供されるヘッダーフィールドを使用して、保存された応答を更新する必要があります（セクション3.2を参照）。
Because unsafe request methods (Section 9.2.1 of [HTTP]) such as PUT, POST, or DELETE have the potential for changing state on the origin server, intervening caches are required to invalidate stored responses to keep their contents up to date.
Put、Post、Deleteなどの安全でない要求方法（[http]のセクション9.2.1）には、オリジンサーバー上の状態が変化する可能性があるため、介入されたキャッシュが介入して、内容を最新に保つために保存された応答を無効にする必要があります。
A cache MUST invalidate the target URI (Section 7.1 of [HTTP]) when it receives a non-error status code in response to an unsafe request method (including methods whose safety is unknown).
キャッシュは、安全でない要求方法（安全性が不明な方法を含む）に応じて非誤差ステータスコードを受信する場合、ターゲットURI（[HTTP]のセクション7.1）を無効にする必要があります。
A cache MAY invalidate other URIs when it receives a non-error status code in response to an unsafe request method (including methods whose safety is unknown). In particular, the URI(s) in the Location and Content-Location response header fields (if present) are candidates for invalidation; other URIs might be discovered through mechanisms not specified in this document. However, a cache MUST NOT trigger an invalidation under these conditions if the origin (Section 4.3.1 of [HTTP]) of the URI to be invalidated differs from that of the target URI (Section 7.1 of [HTTP]). This helps prevent denial-of-service attacks.
キャッシュは、安全でない要求方法（安全性が不明な方法を含む）に応じて非誤差ステータスコードを受信すると、他のURIを無効にする場合があります。特に、場所およびコンテンツロケーション応答ヘッダーフィールドのURI（存在する場合）は、無効化の候補です。他のURIは、このドキュメントで指定されていないメカニズムを通じて発見される可能性があります。ただし、URIの起源（[http]のセクション4.3.1）が無効になる場合、キャッシュはこれらの条件下で無効化をトリガーしてはなりません。これは、サービス拒否攻撃を防ぐのに役立ちます。
"Invalidate" means that the cache will either remove all stored responses whose target URI matches the given URI or mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request.
「無効化」とは、キャッシュが、ターゲットURIが与えられたURIと一致するすべての保存された応答を削除するか、それらを「無効」としてマークし、後続の要求に応じて送信する前に必須検証を必要とすることを意味します。
A "non-error response" is one with a 2xx (Successful) or 3xx (Redirection) status code.
「非誤差応答」とは、2xx（成功）または3xx（リダイレクト）ステータスコードを持つものです。
Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches it travels through.
これは、すべての適切な応答がグローバルに無効になっていることを保証しないことに注意してください。状態を変える要求は、それが移動するキャッシュの応答を無効にするだけです。
This section defines the syntax and semantics of HTTP fields related to caching.
このセクションでは、キャッシュに関連するHTTPフィールドの構文とセマンティクスを定義します。
The "Age" response header field conveys the sender's estimate of the time since the response was generated or successfully validated at the origin server. Age values are calculated as specified in Section 4.2.3.
「年齢」応答ヘッダーフィールドは、応答が生成されたか、Origin Serverで正常に検証されてから、送信者の推定値を伝えます。年齢値は、セクション4.2.3で指定されているように計算されます。
Age = delta-seconds
The Age field value is a non-negative integer, representing time in seconds (see Section 1.2.2).
年齢フィールド値は非陰性整数であり、秒単位の時間を表します（セクション1.2.2を参照）。
Although it is defined as a singleton header field, a cache encountering a message with a list-based Age field value SHOULD use the first member of the field value, discarding subsequent ones.
シングルトンヘッダーフィールドとして定義されていますが、リストベースの年齢フィールド値を持つメッセージに遭遇するキャッシュは、フィールド値の最初のメンバーを使用して、後続のキャッシュを破棄する必要があります。
If the field value (after discarding additional members, as per above) is invalid (e.g., it contains something other than a non-negative integer), a cache SHOULD ignore the field.
フィールド値（上記のように追加のメンバーを破棄した後）が無効である場合（たとえば、非陰性整数以外のものが含まれています）、キャッシュはフィールドを無視する必要があります。
The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was contacted.
年齢ヘッダーフィールドの存在は、この要求のためにOrigin Serverによって応答が生成または検証されなかったことを意味します。ただし、年齢ヘッダーフィールドの欠如は、起源と接触したことを意味しません。
The "Cache-Control" header field is used to list directives for caches along the request/response chain. Cache directives are unidirectional, in that the presence of a directive in a request does not imply that the same directive is present or copied in the response.
「キャッシュコントロール」ヘッダーフィールドは、要求/応答チェーンに沿ったキャッシュのディレクティブをリストするために使用されます。キャッシュ指令は単方向です。リクエストにディレクティブの存在が、同じ指令が応答に存在またはコピーされていることを意味しないという点では。
See Section 5.2.3 for information about how Cache-Control directives defined elsewhere are handled.
他の場所で定義されているキャッシュコントロールディレクティブの処理方法については、セクション5.2.3を参照してください。
A proxy, whether or not it implements a cache, MUST pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives might apply to all recipients along the request/response chain. It is not possible to target a directive to a specific cache.
プロキシは、キャッシュを実装するかどうかにかかわらず、要求/応答チェーンに沿ってすべての受信者に適用される可能性があるため、そのアプリケーションに対する重要性に関係なく、転送されたメッセージでキャッシュディレクティブを通過する必要があります。指令を特定のキャッシュにターゲットにすることはできません。
Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument that can use both token and quoted-string syntax. For the directives defined below that define arguments, recipients ought to accept both forms, even if a specific form is required for generation.
キャッシュディレクティブは、ケースインテンシテーブと比較されるトークンによって識別され、トークンと引用のストリング構文の両方を使用できるオプションの引数があります。引数を定義する以下に定義されている指令の場合、受信者は、生成に特定のフォームが必要であっても、両方のフォームを受け入れる必要があります。
Cache-Control = #cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ]
For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.
以下に定義されているキャッシュ指令の場合、特に明記しない限り、引数は定義されていません（許可されていません）。
This section defines cache request directives. They are advisory; caches MAY implement them, but are not required to.
このセクションでは、キャッシュ要求ディレクティブを定義します。彼らは助言です。キャッシュはそれらを実装するかもしれませんが、必要ではありません。
Argument syntax:
引数構文：
delta-seconds (see Section 1.2.2)
デルタ秒（セクション1.2.2を参照）
The max-age request directive indicates that the client prefers a response whose age is less than or equal to the specified number of seconds. Unless the max-stale request directive is also present, the client does not wish to receive a stale response.
Max-Age Request Directiveは、クライアントが指定された秒数よりも年齢が低い応答を好むことを示しています。Max Stale Request Directiveも存在しない限り、クライアントは古い応答を受信したくありません。
This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the quoted-string form.
この指令は、引数構文のトークン形式を使用します。送信者は、引用されたストリングフォームを生成してはなりません。
Argument syntax:
引数構文：
delta-seconds (see Section 1.2.2)
デルタ秒（セクション1.2.2を参照）
The max-stale request directive indicates that the client will accept a response that has exceeded its freshness lifetime. If a value is present, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client will accept a stale response of any age.
Max-Stale Request Directiveは、クライアントが新鮮さの寿命を超えた応答を受け入れることを示しています。値が存在する場合、クライアントは、指定された秒数以内に新鮮さの寿命を超えた応答を受け入れることをいとわない。値が最大に割り当てられていない場合、クライアントはあらゆる年齢の古い応答を受け入れます。
This directive uses the token form of the argument syntax: e.g., 'max-stale=10' not 'max-stale="10"'. A sender MUST NOT generate the quoted-string form.
このディレクティブは、引数構文のトークン形式を使用します。送信者は、引用されたストリングフォームを生成してはなりません。
Argument syntax:
引数構文：
delta-seconds (see Section 1.2.2)
デルタ秒（セクション1.2.2を参照）
The min-fresh request directive indicates that the client prefers a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
Min-Fresh Request Directiveは、クライアントが新鮮な寿命が現在の年齢と指定された時間を秒単位に劣らない応答を好むことを示しています。つまり、クライアントは、少なくとも指定された秒数の間、まだ新鮮な応答を望んでいます。
This directive uses the token form of the argument syntax: e.g., 'min-fresh=20' not 'min-fresh="20"'. A sender MUST NOT generate the quoted-string form.
この指令は、引数構文のトークン形式を使用します。送信者は、引用されたストリングフォームを生成してはなりません。
The no-cache request directive indicates that the client prefers a stored response not be used to satisfy the request without successful validation on the origin server.
ノーキャッシュ要求指令は、クライアントがオリジンサーバーでの検証を成功させずにリクエストを満たすために使用されない保存された応答を好むことを示しています。
The no-store request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
ストアなしの要求指令は、キャッシュがこの要求の一部またはそれに対する応答のいずれかを保存してはならないことを示しています。この指令は、プライベートキャッシュと共有キャッシュの両方に適用されます。このコンテキストで「保存してはならない」とは、キャッシュが情報を不揮発性ストレージに意図的に保存してはならないことを意味し、揮発性ストレージから情報をできるだけ早く削除しようとする最良の試みを行う必要があります。
This directive is not a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
この指令は、プライバシーを確保するための信頼できるまたは十分なメカニズムではありません。特に、悪意のあるまたは妥協したキャッシュは、この指令を認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。
Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already stored response.
このディレクティブを含む要求がキャッシュから満たされている場合、ストアなしリクエストディレクティブは既に保存されている応答に適用されないことに注意してください。
The no-transform request directive indicates that the client is asking for intermediaries to avoid transforming the content, as defined in Section 7.7 of [HTTP].
変換されないリクエスト指令は、[HTTP]のセクション7.7で定義されているように、クライアントがコンテンツの変換を避けるために仲介者を求めていることを示しています。
The only-if-cached request directive indicates that the client only wishes to obtain a stored response. Caches that honor this request directive SHOULD, upon receiving it, respond with either a stored response consistent with the other constraints of the request or a 504 (Gateway Timeout) status code.
キャッシュされた唯一の要求指令は、クライアントが保存された応答の取得のみを希望することを示します。このリクエスト指令を称えるキャッシュは、それを受信すると、リクエストの他の制約と一致する保存された応答または504（ゲートウェイタイムアウト）ステータスコードのいずれかで応答する必要があります。
This section defines cache response directives. A cache MUST obey the Cache-Control directives defined in this section.
このセクションでは、キャッシュ応答指令を定義します。キャッシュは、このセクションで定義されているキャッシュ制御指令に従う必要があります。
Argument syntax:
引数構文：
delta-seconds (see Section 1.2.2)
デルタ秒（セクション1.2.2を参照）
The max-age response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.
最大年齢の応答指令は、その年齢が指定された秒数よりも大きい後、応答が古く見なされることを示しています。
This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the quoted-string form.
この指令は、引数構文のトークン形式を使用します。送信者は、引用されたストリングフォームを生成してはなりません。
The must-revalidate response directive indicates that once the response has become stale, a cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3.
必見の応答指令は、応答が古くなったら、セクション4.3で定義されているように、原点によって正常に検証されるまで、キャッシュが別の要求を満たすためにその応答を再利用してはならないことを示しています。
The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances, a cache MUST NOT ignore the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate an error response rather than reuse the stale response. The generated status code SHOULD be 504 (Gateway Timeout) unless another error status code is more applicable.
特定のプロトコル機能の信頼できる操作をサポートするには、必見の指令が必要です。あらゆる状況で、キャッシュは必見の指令を無視してはなりません。特に、キャッシュが切断されている場合、キャッシュは古い応答を再利用するのではなく、エラー応答を生成する必要があります。生成されたステータスコードは、別のエラーステータスコードがより適用可能でない限り、504（ゲートウェイタイムアウト）でなければなりません。
The must-revalidate directive ought to be used by servers if and only if failure to validate a request could cause incorrect operation, such as a silently unexecuted financial transaction.
リクエストを検証しなかった場合にのみ、黙って不明確な金融取引などの誤った操作を引き起こす可能性がある場合にのみ、必見の指令をサーバーが使用する必要があります。
The must-revalidate directive also permits a shared cache to reuse a response to a request containing an Authorization header field (Section 11.6.2 of [HTTP]), subject to the above requirement on revalidation (Section 3.5).
必見の指令では、共有キャッシュは、再評価に関する上記の要件を条件として、認証ヘッダーフィールド（[HTTP]のセクション11.6.2）を含む要求に対する応答を再利用できます（セクション3.5）。
The must-understand response directive limits caching of the response to a cache that understands and conforms to the requirements for that response's status code.
必須の応答指令は、その応答のステータスコードの要件を理解し、適合させるキャッシュに対する応答のキャッシュを制限します。
A response that contains the must-understand directive SHOULD also contain the no-store directive. When a cache that implements the must-understand directive receives a response that includes it, the cache SHOULD ignore the no-store directive if it understands and implements the status code's caching requirements.
必見のディレクティブを含む応答には、ストアなしの指令も含める必要があります。必見のディレクティブを実装するキャッシュがそれを含む応答を受信する場合、ステータスコードのキャッシュ要件を理解し、実装する場合、キャッシュは非ストア指令を無視する必要があります。
Argument syntax:
引数構文：
#field-name
＃フィールド名
The no-cache response directive, in its unqualified form (without an argument), indicates that the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see Section 4.3.
資格のない形式（引数なし）のノーキャッシュ応答指令は、検証のために転送され、成功した応答を受信することなく、他の要求を満たすために応答を使用してはならないことを示します。セクション4.3を参照してください。
This allows an origin server to prevent a cache from using the response to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
これにより、Origin Serverは、古い応答を送信するように構成されているキャッシュであっても、要求を連絡せずに要求を満たすためにキャッシュを使用しないようにすることができます。
The qualified form of the no-cache response directive, with an argument that lists one or more field names, indicates that a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching, if the listed header fields are excluded from the subsequent response or the subsequent response has been successfully revalidated with the origin server (updating or removing those fields). This allows an origin server to prevent the reuse of certain header fields in a response, while still allowing caching of the rest of the response.
1つ以上のフィールド名をリストする引数を持つノーキャッシュ応答指令の適格な形式は、キャッシュが応答を使用して後続の要求を満たすことができることを示しています。後続の応答またはその後の応答から除外されているのは、Origin Server（これらのフィールドの更新または削除）で正常に再検証されました。これにより、Origin Serverは応答の特定のヘッダーフィールドの再利用を防ぎながら、残りの応答のキャッシュを可能にします。
The field names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
与えられたフィールド名は、この仕様で定義されたヘッダーフィールドのセットに限定されません。フィールド名はケースに依存しません。
This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists).
この指令は、引用された引数の引数形式の引数構文を使用します。送信者は、トークンフォームを生成してはなりません（単一入力リストには引用が必要ないように見える場合でも）。
| *Note:* The qualified form of the directive is often handled by
| caches as if an unqualified no-cache directive was received;
| that is, the special handling for the qualified form is not
| widely implemented.
The no-store response directive indicates that a cache MUST NOT store any part of either the immediate request or the response and MUST NOT use the response to satisfy any other request.
ストアなしの応答指令は、キャッシュが即時の要求または応答のいずれかの一部を保存してはならず、他のリクエストを満たすために応答を使用してはならないことを示しています。
This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
この指令は、プライベートキャッシュと共有キャッシュの両方に適用されます。このコンテキストで「保存してはならない」とは、キャッシュが情報を不揮発性ストレージに意図的に保存してはならないことを意味し、揮発性ストレージから情報をできるだけ早く削除しようとする最良の試みを行う必要があります。
This directive is not a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
この指令は、プライバシーを確保するための信頼できるまたは十分なメカニズムではありません。特に、悪意のあるまたは妥協したキャッシュは、この指令を認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。
Note that the must-understand cache directive overrides no-store in certain circumstances; see Section 5.2.2.3.
必見のキャッシュ指令は、特定の状況で店のないものを無効にすることに注意してください。セクション5.2.2.3を参照してください。
The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the content, as defined in Section 7.7 of [HTTP].
変換されない応答指令は、[HTTP]のセクション7.7で定義されているように、中間（キャッシュを実装するかどうかに関係なく）がコンテンツを変換してはならないことを示しています。
Argument syntax:
引数構文：
#field-name
＃フィールド名
The unqualified private response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user). It also indicates that a private cache MAY store the response, subject to the constraints defined in Section 3, even if the response would not otherwise be heuristically cacheable by a private cache.
資格のないプライベート応答指令は、共有キャッシュが応答を保存してはならないことを示しています（つまり、応答は単一のユーザーを対象としています）。また、応答がプライベートキャッシュによってヒューリスティックなキャッシュ可能ではない場合でも、セクション3で定義されている制約を条件として、プライベートキャッシュが応答を保存する可能性があることを示しています。
If a qualified private response directive is present, with an argument that lists one or more field names, then only the listed header fields are limited to a single user: a shared cache MUST NOT store the listed header fields if they are present in the original response but MAY store the remainder of the response message without those header fields, subject the constraints defined in Section 3.
資格のあるプライベート応答指令が存在し、1つ以上のフィールド名をリストする引数がある場合、リストされたヘッダーフィールドのみが単一のユーザーに限定されます。応答ですが、これらのヘッダーフィールドなしで応答メッセージの残りを保存する場合があり、セクション3で定義されている制約を課します。
The field names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
与えられたフィールド名は、この仕様で定義されたヘッダーフィールドのセットに限定されません。フィールド名はケースに依存しません。
This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists).
この指令は、引用された引数の引数形式の引数構文を使用します。送信者は、トークンフォームを生成してはなりません（単一入力リストには引用が必要ないように見える場合でも）。
| *Note:* This usage of the word "private" only controls where
| the response can be stored; it cannot ensure the privacy of the
| message content. Also, the qualified form of the directive is
| often handled by caches as if an unqualified private directive
| was received; that is, the special handling for the qualified
| form is not widely implemented.
The proxy-revalidate response directive indicates that once the response has become stale, a shared cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3. This is analogous to must-revalidate (Section 5.2.2.2), except that proxy-revalidate does not apply to private caches.
プロキシ-Revalidate応答指令は、応答が古くなったら、共有キャッシュがセクション4.3で定義されているように、原点によって正常に検証されるまで、別の要求を満たすためにその応答を再利用してはならないことを示しています。これは、責任者（セクション5.2.2.2）に類似していますが、代理再評価はプライベートキャッシュには適用されないことを除きます。
Note that proxy-revalidate on its own does not imply that a response is cacheable. For example, it might be combined with the public directive (Section 5.2.2.9), allowing the response to be cached while requiring only a shared cache to revalidate when stale.
プロキシ - 再バリデート自体は、応答がキャッシュ可能であることを意味するものではないことに注意してください。たとえば、パブリック指令（セクション5.2.2.9）と組み合わせることができ、古くなったときに共有キャッシュのみを再検証するために共有キャッシュのみを要求しながら、応答をキャッシュすることができます。
The public response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the constraints defined in Section 3. In other words, public explicitly marks the response as cacheable. For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (Section 3.5).
パブリック応答指令は、セクション3で定義されている制約を条件として、それ以外の場合は禁止されていても、キャッシュが応答を保存できることを示しています。たとえば、Publicは共有キャッシュを許可して、承認ヘッダーフィールドを含むリクエストへの応答を再利用します（セクション3.5）。
Note that it is unnecessary to add the public directive to a response that is already cacheable according to Section 3.
セクション3に従ってすでにキャッシュ可能な応答にパブリックディレクティブを追加する必要はないことに注意してください。
If a response with the public directive has no explicit freshness information, it is heuristically cacheable (Section 4.2.2).
パブリック指令を伴う応答に明示的な新鮮さ情報がない場合、それはヒューリスティックにキャッシュ可能です（セクション4.2.2）。
Argument syntax:
引数構文：
delta-seconds (see Section 1.2.2)
デルタ秒（セクション1.2.2を参照）
The s-maxage response directive indicates that, for a shared cache, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field.
S-Maxage Responseディレクティブは、共有キャッシュの場合、この指令で指定された最大年齢は、Max-Ageディレクティブまたは期限切れのヘッダーフィールドによって指定された最大年齢をオーバーライドすることを示しています。
The s-maxage directive incorporates the semantics of the proxy-revalidate response directive (Section 5.2.2.8) for a shared cache. A shared cache MUST NOT reuse a stale response with s-maxage to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3. This directive also permits a shared cache to reuse a response to a request containing an Authorization header field, subject to the above requirements on maximum age and revalidation (Section 3.5).
S-Maxageディレクティブには、共有キャッシュのプロキシ-Revalidate Response Directive（セクション5.2.2.8）のセマンティクスが組み込まれています。共有キャッシュは、セクション4.3で定義されているように、Originによって正常に検証されるまで、S-Maxageで古い応答を再利用して別の要求を満たす必要はありません。また、この指令は、共有キャッシュが、最大年齢と再検証に関する上記の要件を条件として、認証ヘッダーフィールドを含むリクエストへの応答を再利用することを許可します（セクション3.5）。
This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'. A sender MUST NOT generate the quoted-string form.
このディレクティブは、引数構文のトークン形式を使用します。送信者は、引用されたストリングフォームを生成してはなりません。
The Cache-Control header field can be extended through the use of one or more extension cache directives. A cache MUST ignore unrecognized cache directives.
キャッシュコントロールヘッダーフィールドは、1つ以上の拡張キャッシュディレクティブを使用して拡張できます。キャッシュは、認識されていないキャッシュ指令を無視する必要があります。
Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics of other directives.
情報拡張機能（キャッシュ動作の変更を必要としないもの）は、他の指令のセマンティクスを変更せずに追加できます。
Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive and the old directive are supplied, such that applications that do not understand the new directive will default to the behavior specified by the old directive, and those that understand the new directive will recognize it as modifying the requirements associated with the old directive. In this way, extensions to the existing cache directives can be made without breaking deployed caches.
動作拡張機能は、キャッシュ指令の既存のベースの修飾子として機能することにより機能するように設計されています。新しい指令と古い指令の両方が提供されます。そのため、新しい指令を理解していないアプリケーションは、古い指令によって指定された動作にデフォルトであり、新しい指令を理解しているものは、古い要件に関連する要件を変更するものとしてそれを認識します。指令。このようにして、既存のキャッシュディレクティブへの拡張は、展開されたキャッシュを破ることなく作成できます。
For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive: in addition to private caches, only a cache that is shared by members of the named community is allowed to cache the response. An origin server wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do so by including
たとえば、プライベート指令の修飾子として機能する「コミュニティ」と呼ばれる仮説的な新しい応答指令を検討してください。プライベートキャッシュに加えて、指定されたコミュニティのメンバーが共有するキャッシュのみが応答をキャッシュできます。UCIコミュニティが共有キャッシュでそれ以外の場合はプライベートな応答を使用できるようにしたいOrigin Serverは、それを含めることでそうすることができます
Cache-Control: private, community="UCI"
キャッシュコントロール：プライベート、community = "uci"
A cache that recognizes such a community cache directive could broaden its behavior in accordance with that extension. A cache that does not recognize the community cache directive would ignore it and adhere to the private directive.
このようなコミュニティキャッシュ指令を認識するキャッシュは、その拡張機能に従って動作を広げることができます。コミュニティキャッシュ指令を認識していないキャッシュは、それを無視し、プライベートディレクティブを遵守します。
New extension directives ought to consider defining:
新しい拡張ディレクティブは、次の定義を検討する必要があります。
* What it means for a directive to be specified multiple times,
* 指令が複数回指定されることの意味、
* When the directive does not take an argument, what it means when an argument is present,
* 指令が議論をしないとき、それが議論が存在するときにそれが何を意味するのか、
* When the directive requires an argument, what it means when it is missing, and
* 指令が引数を必要とする場合、それが欠落しているときの意味、および
* Whether the directive is specific to requests, specific to responses, or able to be used in either.
* 指令がリクエストに固有であるか、応答に固有の、またはどちらでも使用できるかどうか。
The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at <https://www.iana.org/assignments/http-cache-directives>.
「HyperText Transfer Protocol（HTTP）Cache Directive Registry」は、キャッシュディレクティブの名前空間を定義します。これは作成されており、現在は<https://www.iana.org/assignments/http-cache-directives>に維持されています。
A registration MUST include the following fields:
登録には、次のフィールドを含める必要があります。
* Cache Directive Name
* キャッシュディレクティブ名
* Pointer to specification text
* 仕様テキストへのポインタ
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
この名前空間に追加する値には、IETFレビューが必要です（[RFC8126]、セクション4.8を参照）。
The "Expires" response header field gives the date/time after which the response is considered stale. See Section 4.2 for further discussion of the freshness model.
「期限切れ」の応答ヘッダーフィールドは、日付/時刻を与え、その後、応答は古く見なされます。新鮮さモデルの詳細については、セクション4.2を参照してください。
The presence of an Expires header field does not imply that the original resource will change or cease to exist at, before, or after that time.
有効期限が切れるヘッダーフィールドの存在は、元のリソースが変化したり、その前、またはその後に存在しなくなることを意味するものではありません。
The Expires field value is an HTTP-date timestamp, as defined in Section 5.6.7 of [HTTP]. See also Section 4.2 for parsing requirements specific to caches.
有効期限は、[HTTP]のセクション5.6.7で定義されているように、HTTP-Dateタイムスタンプです。キャッシュに固有の解析要件については、セクション4.2も参照してください。
Expires = HTTP-date
For example
例えば
Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
キャッシュ受信者は、無効な日付形式、特に過去の時間を表す値「0」（つまり、「すでに期限切れ」）を解釈する必要があります。
If a response includes a Cache-Control header field with the max-age directive (Section 5.2.2.1), a recipient MUST ignore the Expires header field. Likewise, if a response includes the s-maxage directive (Section 5.2.2.10), a shared cache recipient MUST ignore the Expires header field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented the Cache-Control header field.
応答に、最大時代のディレクティブを備えたキャッシュコントロールヘッダーフィールド（セクション5.2.2.1）が含まれている場合、受信者は有効期限のあるヘッダーフィールドを無視する必要があります。同様に、応答にS-Maxageディレクティブ（セクション5.2.2.10）が含まれている場合、共有キャッシュ受信者は有効期限のあるヘッダーフィールドを無視する必要があります。どちらの場合も、有効期限が切れる値は、キャッシュコントロールヘッダーフィールドをまだ実装していない受信者を対象としています。
An origin server without a clock (Section 5.6.7 of [HTTP]) MUST NOT generate an Expires header field unless its value represents a fixed time in the past (always expired) or its value has been associated with the resource by a system with a clock.
クロックのないオリジンサーバー（[http]のセクション5.6.7）は、その値が過去の固定時間を表している場合（常に期限切れ）、またはその値がシステムによってリソースに関連付けられていない限り、ヘッダーフィールドの有効期限を生成してはなりません。クロック。
Historically, HTTP required the Expires field value to be no more than a year in the future. While longer freshness lifetimes are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use of 32-bit integers for time values), and many caches will evict a response far sooner than that.
歴史的に、HTTPは、期限切れのフィールド値を将来1年以下にする必要がありました。より長い鮮度の寿命はもはや禁止されていませんが、非常に大きな値が問題を引き起こすことが実証されています（例：時間の値に32ビット整数の使用によるクロックオーバーフロー）。
The "Pragma" request header field was defined for HTTP/1.0 caches, so that clients could specify a "no-cache" request (as Cache-Control was not defined until HTTP/1.1).
「プラグマ」要求ヘッダーフィールドはHTTP/1.0キャッシュ用に定義されていたため、クライアントは「キャッシュなし」要求を指定できます（HTTP/1.1までキャッシュコントロールが定義されなかったため）。
However, support for Cache-Control is now widespread. As a result, this specification deprecates Pragma.
ただし、キャッシュ制御のサポートは現在広まっています。その結果、この仕様はプラグマを非難します。
| *Note:* Because the meaning of "Pragma: no-cache" in responses
| was never specified, it does not provide a reliable replacement
| for "Cache-Control: no-cache" in them.
The "Warning" header field was used to carry additional information about the status or transformation of a message that might not be reflected in the status code. This specification obsoletes it, as it is not widely generated or surfaced to users. The information it carried can be gleaned from examining other header fields, such as Age.
「警告」ヘッダーフィールドは、ステータスコードに反映されない可能性のあるメッセージのステータスまたは変換に関する追加情報を伝達するために使用されました。この仕様は、ユーザーに広く生成または浮上していないため、それを廃止します。それが運んだ情報は、年齢などの他のヘッダーフィールドを調べることから収集することができます。
Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation retrieved earlier in a session.
HTTPを使用したアプリケーションは、多くの場合、追加のフォームのキャッシュを指定します。たとえば、Webブラウザーには、多くの場合、セッションの前半で取得した表現を再表示するために使用できる「バック」ボタンなどの履歴メカニズムがあります。
Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics.
同様に、一部のWebブラウザーは、ページビュー内に画像やその他の資産のキャッシュを実装しています。彼らはHTTPキャッシュセマンティクスを尊重する場合と尊重する場合もあります。
The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from an HTTP cache. For example, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime.
この仕様の要件は、HTTPキャッシュから取得した後のアプリケーションの使用方法に必ずしも適用されるわけではありません。たとえば、履歴メカニズムは、期限切れになっても以前の表現を表示でき、アプリケーションは新鮮さの寿命を超えて他の方法でキャッシュデータを使用できます。
This specification does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache-Control: no-store).
この仕様では、アプリケーションがHTTPキャッシングを考慮に入れることを禁止するものではありません。たとえば、履歴メカニズムは、ビューが古くなっていることをユーザーに伝えるか、キャッシュディレクティブ（例：キャッシュコントロール：ストアなし）を尊重する場合があります。
However, when an application caches data and does not make this apparent to or easily controllable by the user, it is strongly encouraged to define its operation with respect to HTTP cache directives so as not to surprise authors who expect caching semantics to be honored. For example, while it might be reasonable to define an application cache "above" HTTP that allows a response containing Cache-Control: no-store to be reused for requests that are directly related to the request that fetched it (such as those created during the same page load), it would likely be surprising and confusing to users and authors if it were allowed to be reused for requests unrelated in any way to the one from which it was obtained.
ただし、アプリケーションがデータをキャッシュし、ユーザーがこれを明らかにしたり、簡単に制御できるようにしない場合、キャッシュセマンティクスが尊重されることを期待している著者を驚かないように、HTTPキャッシュ指令に関する操作を定義することを強くお勧めします。たとえば、キャッシュコントロールを含む応答を許可する「上記の「上記」のアプリケーションキャッシュを定義することは合理的かもしれません：それを取得した要求に直接関連するリクエスト（同じページの読み込み）、それが得られたものと何らかの方法で無関係な要求に対して再利用されることを許可された場合、それはユーザーと著者にとって驚くべきことで混乱するでしょう。
This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP caching. More general security considerations are addressed in "HTTP/1.1" (Section 11 of [HTTP/1.1]) and "HTTP Semantics" (Section 17 of [HTTP]).
このセクションは、開発者、情報提供者、およびHTTPキャッシュに固有の既知のセキュリティに関するユーザーに通知することを目的としています。より一般的なセキュリティ上の考慮事項は、「http/1.1」（[http/1.1]のセクション11）および「httpセマンティクス」（[http]のセクション17）で説明されています。
Caches expose an additional attack surface because the contents of the cache represent an attractive target for malicious exploitation. Since cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.
キャッシュの内容は悪意のある搾取の魅力的なターゲットを表しているため、キャッシュは追加の攻撃面を公開します。HTTP要求が完了した後にキャッシュの内容が持続するため、ユーザーがネットワークから情報が削除されたとユーザーが信じている後も、キャッシュへの攻撃が情報を明らかにすることができます。したがって、キャッシュの内容は機密情報として保護する必要があります。
In particular, because private caches are restricted to a single user, they can be used to reconstruct a user's activity. As a result, it is important for user agents to allow end users to control them, for example, by allowing stored responses to be removed for some or all origin servers.
特に、プライベートキャッシュは単一のユーザーに制限されているため、ユーザーのアクティビティを再構築するために使用できます。その結果、ユーザーエージェントがエンドユーザーがそれらを制御できるようにすることが重要です。たとえば、一部またはすべてのオリジンサーバーに対して保存された応答を削除できるようにすることが重要です。
Storing malicious content in a cache can extend the reach of an attacker to affect multiple users. Such "cache poisoning" attacks happen when an attacker uses implementation flaws, elevated privileges, or other techniques to insert a response into a cache. This is especially effective when shared caches are used to distribute malicious content to many clients.
悪意のあるコンテンツをキャッシュに保存すると、攻撃者のリーチを拡張して複数のユーザーに影響を与えます。このような「キャッシュ中毒」攻撃は、攻撃者が実装の欠陥、特権の高まり、またはその他のテクニックを使用して応答をキャッシュに挿入すると発生します。これは、多くのクライアントに悪意のあるコンテンツを配布するために共有されたキャッシュが使用される場合に特に効果的です。
One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see Section 6.3 of [HTTP/1.1] for the relevant requirements regarding HTTP/1.1.
キャッシュ中毒の一般的な攻撃ベクトルの1つは、プロキシおよびユーザーエージェントでのメッセージ解析の違いを活用することです。HTTP/1.1に関する関連要件については、[HTTP/1.1]のセクション6.3を参照してください。
Because one of the primary uses of a cache is to optimize performance, its use can "leak" information about which resources have been previously requested.
キャッシュの主要な用途の1つはパフォーマンスを最適化することであるため、その使用は、以前に要求されたリソースに関する情報を「漏れ」できます。
For example, if a user visits a site and their browser caches some of its responses and then navigates to a second site, that site can attempt to load responses it knows exist on the first site. If they load quickly, it can be assumed that the user has visited that site, or even a specific page on it.
たとえば、ユーザーがサイトにアクセスし、ブラウザがその応答の一部をキャッシュしてから2番目のサイトに移動すると、そのサイトは最初のサイトに存在することがわかっている応答をロードしようとします。すぐに読み込まれた場合、ユーザーがそのサイト、またはその上の特定のページにアクセスしたと想定できます。
Such "timing attacks" can be mitigated by adding more information to the cache key, such as the identity of the referring site (to prevent the attack described above). This is sometimes called "double keying".
このような「タイミング攻撃」は、参照サイトのIDなどの情報をキャッシュキーに追加することで軽減できます（上記の攻撃を防ぐため）。これは「二重キーイング」と呼ばれることもあります。
Implementation and deployment flaws (often led to by the misunderstanding of cache operation) might lead to the caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.
実装と展開の欠陥（多くの場合、キャッシュ操作の誤解に導かれる）は、プライベートであると考えられている機密情報（例：認証資格情報）のキャッシュにつながり、不正な当事者にさらされる可能性があります。
Note that the Set-Cookie response header field [COOKIE] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers that wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.
Set-Cookie Response Headerフィールド[Cookie]はキャッシュを阻害しないことに注意してください。セットクッキーヘッダーフィールドを使用したキャッシュ可能な応答は、キャッシュへの後続の要求を満たすために使用できます（多くの場合）。これらの応答のキャッシングを制御したいサーバーは、適切なキャッシュコントロール応答ヘッダーフィールドを放出することをお勧めします。
The change controller for the following registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
次の登録の変更コントローラーは、「IETF（iesg@ietf.org） - インターネットエンジニアリングタスクフォース」です。
IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields>, as described in Section 18.4 of [HTTP], with the field names listed in the table below:
IANAは、[http]のセクション18.4で説明されているように、<https://www.iana.org/assignments/http-fields> <https://www.iana.org/assignments/http-fields>で「ハイパーテキスト転送プロトコル（http）フィールド名レジストリ」を更新しました。以下の表：
+===============+============+=========+==========+
| 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 | |
+---------------+------------+---------+----------+
Table 1
表1
IANA has updated the "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" at <https://www.iana.org/assignments/http-cache-directives> with the registration procedure per Section 5.2.4 and the cache directive names summarized in the table below.
IANAは、「ハイパーテキスト転送プロトコル（HTTP）キャッシュディレクティブレジストリ」を<https://www.iana.org/assignments/http-cache-directives>セクション5.2.4あたりの登録手順とCACHEディレクティブ名の登録手順で更新しました。以下の表。
+==================+==================+
| 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 |
+------------------+------------------+
Table 2
表2
IANA has added the following note to the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/ http-warn-codes> stating that "Warning" has been obsoleted:
IANAは、「HyperText Transfer Protocol（HTTP）WARN CODES CODES」レジストリに次のメモを追加しました。
| The Warning header field (and the warn codes that it uses) has | been obsoleted for HTTP per [RFC9111].
|警告ヘッダーフィールド（およびそれが使用する警告コード）には|[RFC9111]ごとにHTTPのために廃止されました。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[HTTP] Fielding、R.、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<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>.
[RFC5234] Crocker、D.、ed。P. Overell、「構文仕様のためのBNFの増強：ABNF：STD 68、RFC 5234、DOI 10.17487/RFC5234、2008年1月、<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>.
[RFC7405] Kyzivat、P。、「ABNFでのケースセンシティブストリングサポート」、RFC 7405、DOI 10.17487/RFC7405、2014年12月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[Cookie] Barth、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487/RFC6265、2011年4月、<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, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/1.1] Fielding、R.、ed。、Nottingham、M.、ed。、およびJ. Reschke、ed。、 "Http/1.1"、Std 99、RFC 9112、DOI 10.17487/RFC9112、2022年6月、<<https://www.rfc-editor.org/info/rfc9112>。
[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>.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、DOI 10.17487/RFC2616、1999年6月、<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>.
[RFC5861]ノッティンガム、M。、「古いコンテンツのHTTPキャッシュコントロール拡張」、RFC 5861、DOI 10.17487/RFC5861、2010年5月<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>.
[RFC7234] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：キャッシュ」、RFC 7234、DOI 10.17487/RFC7234、2014年6月、<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>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
In the collected ABNF below, list rules are expanded per Section 5.6.1 of [HTTP].
以下の収集されたABNFでは、[HTTP]のセクション5.6.1に従ってリストルールが拡張されています。
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>
Handling of duplicate and conflicting cache directives has been clarified. (Section 4.2.1)
重複および競合するキャッシュ指令の処理が明確にされています。（セクション4.2.1）
Cache invalidation of the URIs in the Location and Content-Location header fields is no longer required but is still allowed. (Section 4.4)
位置およびコンテンツロケーションヘッダーフィールドでのURIの無効化は不要になりましたが、それでも許可されています。（セクション4.4）
Cache invalidation of the URIs in the Location and Content-Location header fields is disallowed when the origin is different; previously, it was the host. (Section 4.4)
場所とコンテンツロケーションヘッダーフィールドでのURIの無効化は、原点が異なる場合に許可されます。以前はホストでした。（セクション4.4）
Handling invalid and multiple Age header field values has been clarified. (Section 5.1)
無効と複数の年齢のヘッダーフィールド値の処理が明確になりました。（セクション5.1）
Some cache directives defined by this specification now have stronger prohibitions against generating the quoted form of their values, since this has been found to create interoperability problems. Consumers of extension cache directives are no longer required to accept both token and quoted-string forms, but they still need to parse them properly for unknown extensions. (Section 5.2)
この仕様で定義された一部のキャッシュ指令は、相互運用性の問題を作成することがわかっているため、引用された形式の値を生成することに対して強い禁止を備えています。拡張キャッシュディレクティブの消費者は、トークンと引用の両方のフォームを受け入れる必要はなくなりましたが、未知の拡張機能のためにそれらを適切に解析する必要があります。（セクション5.2）
The public and private cache directives were clarified, so that they do not make responses reusable under any condition. (Section 5.2.2)
パブリックおよびプライベートキャッシュ指令は明確にされたため、どの条件でも応答が再利用可能になりません。（セクション5.2.2）
The must-understand cache directive was introduced; caches are no longer required to understand the semantics of new response status codes unless it is present. (Section 5.2.2.3)
必見のキャッシュ指令が導入されました。キャッシュは、存在しない限り、新しい応答ステータスコードのセマンティクスを理解するためにもはや必要ありません。（セクション5.2.2.3）
The Warning response header was obsoleted. Much of the information supported by Warning could be gleaned by examining the response, and the remaining information -- although potentially useful -- was entirely advisory. In practice, Warning was not added by caches or intermediaries. (Section 5.5)
警告応答ヘッダーは廃止されました。警告によってサポートされている情報の多くは、回答を調べることで収集することができ、残りの情報は（潜在的に有用ではありますが）完全に助言的でした。実際には、キャッシュや仲介者による警告は追加されませんでした。（セクション5.5）
Acknowledgements
謝辞
See Appendix "Acknowledgements" of [HTTP], which applies to this document as well.
[http]の付録「謝辞」を参照してください。これはこのドキュメントにも適用されます。
Index
索引
A C E F G H M N O P S V W
a c e f g h m n o p s v w
A
a
age Section 4.2 Age header field *_Section 5.1_*
年齢セクション4.2年齢ヘッダーフィールド *_セクション5.1_ *
C
c
cache Section 1 cache key Section 2; Section 2 Cache-Control header field *_Section 5.2_* collapsed requests Section 4
キャッシュセクション1キャッシュキーセクション2。セクション2キャッシュコントロールヘッダーフィールド * _Section 5.2_ *崩壊したリクエストセクション4
E
e
Expires header field *_Section 5.3_* explicit expiration time Section 4.2
ヘッダーフィールドの有効期限 * _セクション5.3_ *明示的な有効期間セクション4.2
F
f
Fields
Age *_Section 5.1_*; *_Section 5.1_*
Cache-Control *_Section 5.2_*
Expires *_Section 5.3_*; *_Section 5.3_*
Pragma *_Section 5.4_*; *_Section 5.4_*
Warning *_Section 5.5_*
fresh Section 4.2
freshness lifetime Section 4.2
G
g
Grammar
Age *_Section 5.1_*
Cache-Control *_Section 5.2_*
DIGIT *_Section 1.2_*
Expires *_Section 5.3_*
cache-directive *_Section 5.2_*
delta-seconds *_Section 1.2.2_*
H
h
Header Fields
Age *_Section 5.1_*; *_Section 5.1_*
Cache-Control *_Section 5.2_*
Expires *_Section 5.3_*; *_Section 5.3_*
Pragma *_Section 5.4_*; *_Section 5.4_*
Warning *_Section 5.5_*
heuristic expiration time Section 4.2
heuristically cacheable Section 4.2.2
M
m
max-age (cache directive) *_Section 5.2.1.1_*;
*_Section 5.2.2.1_*
max-stale (cache directive) *_Section 5.2.1.2_*
min-fresh (cache directive) *_Section 5.2.1.3_*
must-revalidate (cache directive) *_Section 5.2.2.2_*
must-understand (cache directive) *_Section 5.2.2.3_*
N
n
no-cache (cache directive) *_Section 5.2.1.4_*;
*_Section 5.2.2.4_*
no-store (cache directive) *_Section 5.2.1.5_*;
*_Section 5.2.2.5_*
no-transform (cache directive) *_Section 5.2.1.6_*;
*_Section 5.2.2.6_*
O
o
only-if-cached (cache directive) *_Section 5.2.1.7_*
唯一のキャッシュ（キャッシュディレクティブ） *_セクション5.2.1.7_ *
P
p
Pragma header field *_Section 5.4_*
private (cache directive) *_Section 5.2.2.7_*
private cache Section 1
proxy-revalidate (cache directive) *_Section 5.2.2.8_*
public (cache directive) *_Section 5.2.2.9_*
S
s
s-maxage (cache directive) *_Section 5.2.2.10_* shared cache Section 1 stale Section 4.2
S-Maxage（キャッシュディレクティブ） * _Section 5.2.2.10_ *共有キャッシュセクション1古いセクション4.2
V
v
validator Section 4.3.1
バリデーターセクション4.3.1
W
w
Warning header field *_Section 5.5_*
警告ヘッダーフィールド *_セクション5.5_ *
Authors' Addresses
著者のアドレス
Roy T. Fielding (editor) Adobe 345 Park Ave San Jose, CA 95110 United States of America Email: fielding@gbiv.com URI: https://roy.gbiv.com/
Roy T. Fielding（編集者）Adobe 345 Park Ave San Jose、CA 95110アメリカ合衆国電子メール：Fielding@gbiv.com URI：https：//roy.gbiv.com/
Mark Nottingham (editor) Fastly Prahran Australia Email: mnot@mnot.net URI: https://www.mnot.net/
マーク・ノッティンガム（編集者）急速にPrahran Australiaメール：mnot@mnot.net uri：https：//www.mnot.net/
Julian Reschke (editor)
greenbytes GmbH
Hafenweg 16
48155 Münster
Germany
Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/