HTTP/1.1 — キャッシュ法

1.1. 適合性, エラーの取り扱い

この文書内のキーワード "MUST" … 【以下、この段落の内容は IETF 日本語訳 共通ページに移譲。】 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

適合性の判定基準, および エラーの取り扱いに関する考慮点は、 [RFC7230] § 2.5 にて定義される。 Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

1.2. 構文の表記法

【 この節の他の内容は、 HTTP 日本語訳 共通ページに移譲。 】

総集的 ABNF にて、他の文書から取り込まれた規則, および すべてのリスト演算子を標準な ABNF 表記法に展開した，総集的な文法を示す。 This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.

delta-seconds
	= 1*DIGIT

3.1. 不完全な応答の格納法

応答メッセージは［ 接続が close されるに先立って，メッセージフレーム法（[RFC7230]）により指示される すべてのオクテットが受信された ］とき，完全であると見なされる。 A response message is considered complete when all of the octets indicated by the message framing ([RFC7230]) are received prior to the connection being closed.＼

3.2. 認証済み要請に対する応答の格納法

共用キャッシュは、［ Authorization ヘッダを伴う要請に対するキャッシュ済み応答 ］を利用して，後続の要請を満たしてはならない — ただし、応答内に［ そのような応答を格納することを許容するキャッシュ指令 ］が在る場合は除く。 A shared cache MUST NOT use a cached response to a request with an Authorization header field (Section 4.2 of [RFC7235]) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.

この仕様においては、次の Cache-Control 応答指令が，そのような効果を持つ： must-revalidate, public, s-maxage 。 In this specification, the following Cache-Control response directives (Section 5.2.2) have such an effect: must-revalidate, public, and s-maxage.

注記： 共用キャッシュが、［［ must-revalidate や s-maxage 応答指令を包含する ］, かつ［ 非新鮮である ］ような，キャッシュ済み応答 ］をサーブする（§ 4.2.4 ）ことは許容されない。 特に，［［ "max-age=0, must-revalidate" ］, あるいは "s-maxage=0" ］を伴う応答を、生成元サーバによる再検証を伴わずに，後続の要請を満たすために利用することはできない。 Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be served stale (Section 4.2.4) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy a subsequent request without revalidating it on the origin server.

3.3. 部分的内容の結合法

応答は、接続が尚早に close された, または 要請が 1 個以上の Range 指定子を利用した場合に、部分的な表現のみを転送することがある。 そのような転送が何度か行われたとき、キャッシュは，同じ表現のいくつかの範囲を受信し得る。 キャッシュは、これらの範囲を，［ それらすべてが同じ強い検証子を共有する, かつ キャッシュが [RFC7233] § 4.3 によるクライアント要件に準拠する ］ならば、単独の格納済み応答に結合して，その応答を今後の要請を満たすために再利用してよい。 A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers ([RFC7233]). 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 4.3 of [RFC7233].

キャッシュは、新たな応答と, 1 個以上の格納済み応答とを結合するときは，次をしなければならない： When combining the new response with one or more stored responses, a cache MUST:

• 格納済み応答内の［ warn-code 1xx を伴う Warning ヘッダ ］は，すべて削除する。 • delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
• 格納済み応答内の［ warn-code 2xx を伴う Warning ヘッダ ］は，すべて維持する。 • retain any Warning header fields in the stored response with warn-code 2xx; and,
• 新たな応答内に供された，他のヘッダ — ただし， Content-Range は除く — を用いて、［ 格納済み応答内の対応するヘッダすべてのインスタンス ］を代用する。 • use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response.

4.1. Vary による副次的キーの計算

キャッシュが［ 格納済み応答により満たせるような，要請 ］を受信したとき，その応答が Vary ヘッダを持つ場合には、［ そのヘッダ値に挙げられた，すべての選定用ヘッダ ］について，［ 元の要請（すなわち，格納済み応答に結び付けられているもの）と 今の要請が，以下に述べるように合致する ］場合を除き、その応答を利用してはならない： When a cache receives a request that can be satisfied by a stored response that has a Vary header field (Section 7.1.4 of [RFC7231]), it MUST NOT use that response unless all of the selecting header fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request.

• 所与の選定用ヘッダに対し， 2 つの要請のそれが互いに合致するための必要十分条件は、［ それぞれの要請に，次に挙げるいくつかを適用することにより、一方の要請のヘッダ値を他方のそれに変形できるとき ］と定義される： The selecting 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:

  • ヘッダの構文にて許容される所で，空白を追加する／除去する。 • adding or removing whitespace, where allowed in the header field's syntax
  • 同じヘッダ名の，複数のヘッダを結合する（ [RFC7230] § 3.2 を見よ）。 • combining multiple header fields with the same field name (see Section 3.2 of [RFC7230])
  • 両ヘッダ値を、［ ヘッダの仕様に則って，意味論が一致することが既知である ］ような仕方で正規化する（例：［ 順序が有意でない所では，ヘッダ値を並び替える ］, ［ 文字大小無視と定義されている所では，小文字（または大文字）のみに正規化する ］, 等々）。 • 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.
• Vary ヘッダ値 "*" は、常に合致しない。 【他方のそれも "*" であっても】 A Vary header field-value of "*" always fails to match.

格納済み応答のうち，すべての選定用ヘッダについて合致するものは、 被選定応答 と呼ばれる。 The stored response with matching selecting header fields is known as the selected response.

複数の被選定応答（ Vary ヘッダを伴わない応答も含む）が可用な場合、キャッシュは，利用する 1 つを選択する必要がある。 選定用ヘッダがそのための既知な仕組みを備える場合（例： Accept や それに類する要請ヘッダ上の，品質値）、その仕組みが，選好される応答を選定するために利用されてよい — それ以外の所では、 § 4 に従って （ Date ヘッダにより決定される）最も近過去の応答が利用される。 If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on Accept and similar request header fields), that mechanism MAY be used to select preferred responses; of the remainder, the most recent response (as determined by the Date header field) is used, as per Section 4.

可用な被選定応答が無い場合、キャッシュは，提示された要請を満たせない — その場合、概して，要請内に示される生成元サーバへ回送される（場合によっては条件付きにして — § 4.3 を見よ）。 If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin server in a (possibly conditional; see Section 4.3) request.

4.2. 鮮度

齢が鮮度維持期間を超過していない応答は、 新鮮 （ fresh ）であるとされる。 逆に，それを超過した応答は、 非新鮮 （ stale ）とされる。 A fresh response is one whose age has not yet exceeded its freshness lifetime. Conversely, a stale response is one where it has.

【 この定義は，超過したかどうかを計算できることが前提にある。 （§ 4.2.4 の説明に従うなら、計算できない場合は，新鮮と見なされる？） 】

応答の 鮮度維持期間 とは、［ それが生成元サーバにより生成された時刻から，その失効時刻まで ］の期間である。 失効時刻 とは、それを過ぎて以降は，［ 格納済み応答は、更なる検証を伴わない限り，キャッシュにより利用できない ］とされる時刻である。 明示的な失効時刻 とは、生成元サーバが意図する失効時刻である。 一方で， 経験的な失効時刻 とは、明示的な失効時刻が可用でないときに，キャッシュによりあてがわれる失効時刻である。 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.

応答の 齢 とは、生成元サーバにより［ それが生成された, もしくは 成功裡に検証された ］ときから，経過した時間である。 A response's age is the time that has passed since it was generated by, or successfully validated with, the origin server.

キャッシュ内の応答は、新鮮である間は，［ 生成元サーバに接触することなく，後続の要請を満たす ］ために利用できる — それに伴い，効率を改善させる。 When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.

生成元サーバにとり，鮮度を決定するための主たる仕組みは、［ Expires ヘッダ, または max-age 応答指令 ］を利用して，未来の明示的な失効時刻を供することである。 一般に，生成元サーバは、［［ およそ，それまでは［ 表現が意味論的に有意な仕方で変化しない ］と見込まれる ］ような、未来の失効時刻 ］を，明示的な失効時刻として応答にあてがうことになる。 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.8). 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.

生成元サーバが、キャッシュに対し，毎要請ごとの検証を強制したいときには、過去を指す明示的な失効時刻をあてがって，応答がすでに非新鮮であることを指示できる。 準拠キャッシュは、通常は，非新鮮 キャッシュ済み応答を［ 後続の要請用に再利用する（§ 4.2.4 を見よ） ］前に，検証することになる。 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).

生成元サーバは，［ 常に，明示的な失効時刻を供する ］わけではないので、キャッシュには，一定の状況下で，失効時刻を決定する経験則を利用することも許容される（ § 4.2.2 を見よ）。 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).

応答は、次を満たすならば 新鮮である ものと決定される ：( 鮮度維持期間 > 現在齢 ) 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.

クライアントは、要請内に［ max-age や min-fresh ］キャッシュ指令を送信して，対応する応答に対する鮮度の計算を 拘束する／緩める ことができる。 Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the corresponding response (Section 5.2.1).

日時の構文解析法によくある問題を避けるため、キャッシュ受信者は，鮮度を計算するときには： When calculating freshness, to avoid common problems in date parsing:

• すべての日時 形式は，文字大小区別として指定されているが、［ day, week, time-zone ］の名前†は，文字大小無視で合致させるべきである。 【† day-name, GMT の他に month も含まれる？ 】 • Although all date formats are specified to be case-sensitive, a cache recipient SHOULD match day, week, and time-zone names case-insensitively.
• 自身の内部実装による時刻の分解能が HTTP-date 値のそれより粗い場合、構文解析した Expires 日時を，［ 受信された値を超えない最も近い時刻 ］として，内部的に表現しなければならない。 • 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.
• 地域的な時間帯を，［ 齢や失効時刻 ］の［ 計算, および比較 ］に波及させてはならない。 • A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
• 失効時刻の計算時には、［［ "GMT", "UTC" 以外の時間帯 略語 ］が伴われた日時 ］は，無効と見なすべきである。 • A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.

注記： 鮮度が適用されるのは、キャッシュ運用に限られる — 表示の更新や, リソースの再読み込みを UA に強制する用途には利用できない。 キャッシュと履歴の仕組みとの相違点は、§ 6 に説明される。 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.

4.3. 検証

4.4. 無効化

［ PUT, POST, DELETE ］などの，安全でない要請メソッドは、生成元サーバ上の状態を変更する可能性があるので、介在しているキャッシュは，それらを利用して 自身の内容を最新状態に保つことができる。 Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them to keep their contents up to date.

注記： これは、該当するすべての応答が無効化されることを保証しない。 例えば，状態変更要請は、それが渡り歩くキャッシュ内の応答については，無効化するであろうが、他のキャッシュ内の関連する応答は，依然として格納されたままになるであろう。 Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it has not.

5.1. Age

Age ヘッダは、送信者により見積もられた［ 応答が生成元サーバにて，生成された／成功裡に検証された ］ときからの経過時間 — 齢 — を伝達する。 齢値の計算法は § 4.2.3 にて指定される。 The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server. Age values are calculated as specified in Section 4.2.3.

Age
	= delta-seconds

Age ヘッダ値は、秒数を表現する負でない整数である（§ 1.2.1 を見よ）。 The Age field-value is a non-negative integer, representing time in seconds (see Section 1.2.1).

【応答の受信者にとっては，】 Age ヘッダが在ることは、この要請に対する応答が，生成元サーバにより［ 生成されていない／検証されていない ］ことを含意する。 しかしながら， Age ヘッダを欠くからといって、生成元が接触されたことを含意するとは限らない — 応答は， Age を実装しない HTTP/1.0 キャッシュから受信されることもあるので。 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, since the response might have been received from an HTTP/1.0 cache that does not implement Age.

5.2. Cache-Control

Cache-Control ヘッダは、 キャッシュ制御指令† — 要請／応答の連鎖沿いにあるキャッシュたちのふるまいを制御するための指令 — を指定するために，利用される。 そのような指令は、要請に指令が在っても［ 応答にも，同じ指令が与えられる ］ことを含意しない点で，単方向である。 The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.

キャッシュは、この節にて定義される，各種 Cache-Control 指令の要件を順守しなければならない。 他所で定義される Cache-Control 指令の取り扱い法についての情報は、 § 5.2.3 を見よ。 A cache MUST obey the requirements of the Cache-Control directives defined in this section. See Section 5.2.3 for information about how Cache-Control directives defined elsewhere are handled.

注記： HTTP/1.0 キャッシュには、 Cache-Control を実装しないものもある。 Note: Some HTTP/1.0 caches might not implement Cache-Control.

プロキシは、回送されるメッセージにおける どのキャッシュ指令も，通過させなければならない — プロキシ自身がキャッシュを実装するかどうかに関わらず, あるいは その指令を有意に適用できるかどうかに関わらず — 指令は、要請／応答の連鎖沿いにある すべての受信者に適用可能になり得るものであり、特定のキャッシュのみを適用対象にできないので。 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 be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific cache.

Cache-Control
	= 1#cache-directive

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

特に言明されない限り、以下に定義されるキャッシュ指令には，引数は定義されない（許容されない）。 For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.

delta-seconds

delta-seconds

delta-seconds

#field-name

#field-name

delta-seconds

delta-seconds

Cache-Control: private, community="XYZ"

5.3. Expires

Expires ヘッダは、［ それ以降は 応答が非新鮮になると見なされる，日時／時刻 ］を与える。 鮮度のモデルについての更なる論点は、 § 4.2 を見よ。 The "Expires" header field gives the date/time after which the response is considered stale. See Section 4.2 for further discussion of the freshness model.

Expires ヘッダが在ることは［ 元のリソースが，その時刻を境に変化したり, 存在するようになる／しなくなる ］ことを含意するものではない。 The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.

Expires は、 HTTP-date による時刻印を値にとる。 The Expires value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231].

Expires
	= HTTP-date

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

キャッシュ受信者は、形式が無効な日時を，値 "0" に解釈しなければならない — これは、過去の時刻を表現する（すなわち， “すでに失効した”）。 A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").

応答が max-age 指令を伴う Cache-Control ヘッダを内包する場合、受信者は Expires ヘッダを無視しなければならない。 同様に，応答が s-maxage 指令を内包する場合、共用キャッシュ受信者は， Expires ヘッダを無視しなければならない。 いずれの場合も、 Expires の値は，もっぱら［ Cache-Control ヘッダをまだ実装していない受信者 ］用に意図されたものである。 If a response includes a Cache-Control field with the max-age directive (Section 5.2.2.8), a recipient MUST ignore the Expires field. Likewise, if a response includes the s-maxage directive (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented the Cache-Control field.

歴史的に，HTTP は、 Expires ヘッダ値が，一年以内の未来になることを要求していた。 長い鮮度維持期間は，もはや禁制されなくなったが、 度を越して巨大な値は，問題を起こすことが判っているので（例：時刻値用の 32 ビット整数の利用に因る，時計の桁溢れ）、多くのキャッシュは，それより ずっと早くに応答を抹消する。 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.

5.4. Pragma

【 このヘッダは、 この RFC の改訂 RFC 9111 により， 正式に非推奨にされた。 】

Pragma ヘッダは、 HTTP/1.0 キャッシュとの後方互換性を許容する — クライアントが，自身が解する no-cache 要請を指定できるようにするために（ Cache-Control は、 HTTP/1.1 になるまで，定義されていなかったので）。 Pragma は，［ Cache-Control ヘッダも，要請に在る, かつ解される ］ときには、無視される。 The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored.

HTTP/1.0 においては、 Pragma は，［［ 実装が受信者用に指定する，指令 ］用の，拡張可能なヘッダ ］として定義されていた。 相互運用能を改善するため、この仕様は，そのような拡張を非推奨にする。 In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification deprecates such extensions to improve interoperability.

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

要請内に Cache-Control ヘッダが無い下では、キャッシュは，［ no-cache 要請 pragma-directive ］を［ Cache-Control: no-cache が在ったときと同じ効果を持つ ］と見なさなければならない。 When the Cache-Control header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see Section 5.2.1).

クライアントは、 no-cache 要請を送信するときには， Pragma, Cache-Control 両指令を内包するべき.である — Cache-Control に対する no-cache を，［ HTTP/1.1 キャッシュに対しては，他の Cache-Control 応答指令 要請指令†をターゲットにする ］ために，目的を以って省略する場合を除いて。 例えば、次のもの： When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:

【† 正誤表#4674 による修正（Verified: 2016-04-26 ） 】

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

は、 HTTP/1.1 キャッシュに対しては，齢が 30 秒を超えない応答に限ってサーブするように拘束する一方で， Cache-Control を解さない実装に対しては，キャッシュ済み応答をサーブさせなくする。 will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand Cache-Control from serving a cached response.

注記： 応答においては、 Pragma: no-cache の意味は指定されていない — それは，応答における Cache-Control: no-cache に代わる依拠可能な代用を供さない。 Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them.

5.5. Warning

【 このヘッダは、 この RFC の改訂 RFC 9111 により， 正式に廃用にされた （この節を成す内容も，すべて除去された）。 】

Warning ヘッダは、 警告 — ［ 状態°コード内に反映されないこともあり得るような，メッセージの状態°や形式変換 ］についての追加の情報 — を運ぶために利用される。 この情報は、概して，［ キャッシュ処理や形式変換が適用されたため，メッセージのペイロードが不正になる可能性がある ］ことを警告するために利用される。 The "Warning" header field is used to carry additional information about the status or transformation of a message that might not be reflected in the status code. This information is typically used to warn about possible incorrectness introduced by caching operations or transformations applied to the payload of the message.

警告は、キャッシュに関係する目的にも, 他の目的にも利用できる。 警告の利用により、これらの応答は，真の失敗を表すエラー状態°コードから判別できるようになる。 Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguishes these responses from true failures.

Warning ヘッダは、一般に，どのメッセージにも適用できるが、一部の warn-code はキャッシュに特有であり，応答メッセージのみに適用され得る。 Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only be applied to response messages.

Warning
	= 1#warning-value

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

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

warn-agent は、 Warning ヘッダを追加しているサーバの名前, または仮名（ pseudonym ）である。 デバッグ時に利用するときは、単独の "-" が推奨される。 the name or pseudonym of the server adding the Warning header field, for use in debugging a single "-" is recommended when agent unknown

（生成元サーバもキャッシュも，）同じ応答内に，複数の警告を生成し得る — 複数の警告間で， warn-code 番号が同じ かつ warn-text のみ相違する場合も含めて。 Multiple warnings can be generated in a response (either by the origin server or by a cache), including multiple warnings with the same warn-code number that only differ in warn-text.

UA が， 1 個以上の Warning ヘッダを受信したときには、可能な限り多くのそれらを, 応答内に現れる順序で，利用者に向けて伝えるべきである。 送信者が，複数の Warning ヘッダを生成するときには、この UA のふるまいを念頭に置いて，それらを順序付けることが奨励される。 新たな Warning ヘッダを生成する送信者は、それらを，既存の どの Warning ヘッダよりも後に付加しなければならない。 A user agent that receives one or more Warning header fields SHOULD inform the user of as many of them as possible, in the order that they appear in the response. Senders that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. A sender that generates new Warning header fields MUST append them after any existing Warning header fields.

警告には， 3 桁の warn-code があてがわれる。 最初の桁は、［［ 検証された後に Warning を格納済み応答から削除する ］ことが要求される ］かどうかを指示する： Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from a stored response after validation:

• warn-code 1xx は、応答の鮮度や検証の状態°を述べるものであり， それらは，検証後にはキャッシュにより削除されなければならない。 それらは、キャッシュによってのみ，キャッシュ済みエントリを検証するときに生成され得る — 他のどの状況においても，生成されてはならない。 • 1xx warn-codes describe the freshness or validation status of the response, and so they MUST be deleted by a cache after validation. They can only be generated by a cache when validating a cached entry, and MUST NOT be generated in any other situation.
• warn-code 2xx は、検証により訂正し得ないような，表現の何らかの側面を述べる（例えば，表現の不可逆圧縮） — 検証後にキャッシュにより削除されてはならない。 ただし、全部的な応答が送信された【？】場合は，削除されなければならない。 • 2xx warn-codes describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression of the representation) and they MUST NOT be deleted by a cache after validation, unless a full response is sent, in which case they MUST be.

送信者は、［［ HTTP/1.0 のみを実装することが既知である受信者 ］に向けて送信されるメッセージ ］内に， 1 個以上の warn-code 1xx を生成するときには、 対応する各 warning-value 内に［ そのメッセージ内の Date ヘッダに合致する warn-date ］を内包しなければならない。 例えば： If a sender generates one or more 1xx warn-codes in a message to be sent to a recipient known to implement only HTTP/1.0, the sender MUST include in each corresponding warning-value a warn-date that matches the Date header field in the message. For example:

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

警告には，エラーについて述べる 警告テキスト（ warn-text ） が付随する。 例えばログをとるためなど。 それはもっぱら助言であり，その内容は warn-code の解釈には影響しない。 Warnings have accompanying warn-text that describes the error, e.g., for logging. It is advisory only, and its content does not affect interpretation of the warn-code.

Warning ヘッダを［ 利用する／評価する／表示する ］受信者は、同じメッセージ内に Date 値と異なる warn-date を受信した場合には ：そのメッセージを［ 格納する／回送する／利用する ］前に，その warn-date を包含する warning-value を除外しなければならない。 これにより，受信者は、キャッシュ検証の後に，不適正に維持されていた warning-value を除外できるようになる。 このとき，すべての warning-value が除外されたならば、 Warning ヘッダも除外しなければならない。 If a recipient that uses, evaluates, or displays Warning header fields receives a warn-date that is different from the Date value in the same message, the recipient MUST exclude the warning-value containing that warn-date before storing, forwarding, or using the message. This allows recipients to exclude warning-values that were improperly retained after a cache validation. If all of the warning-values are excluded, the recipient MUST exclude the Warning header field as well.

以下の warn-code が，この仕様により定義される。 それぞれには、推奨される英語の warn-text, および その意味の説明が伴われる。 追加の warn-code を定義するための手続きは、§ 7.2.1 にて述べる。 The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. The procedure for defining additional warn codes is described in Section 7.2.1.

7.1. キャッシュ指令レジストリ

キャッシュ指令用の名前空間を定義するための Hypertext Transfer Protocol (HTTP) Cache Directive Registry （HTTP キャッシュ指令レジストリ）が、新たに作成され，保守されている。 The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at <http://www.iana.org/assignments/http-cache-directives>.

   +------------------------+----------------------------------+
   | Cache Directive        | Reference                        |
   +------------------------+----------------------------------+
   | max-age                | Section 5.2.1.1, Section 5.2.2.8 |
   | max-stale              | Section 5.2.1.2                  |
   | min-fresh              | Section 5.2.1.3                  |
   | must-revalidate        | Section 5.2.2.1                  |
   | no-cache               | Section 5.2.1.4, Section 5.2.2.2 |
   | no-store               | Section 5.2.1.5, Section 5.2.2.3 |
   | no-transform           | Section 5.2.1.6, Section 5.2.2.4 |
   | only-if-cached         | Section 5.2.1.7                  |
   | private                | Section 5.2.2.6                  |
   | proxy-revalidate       | Section 5.2.2.7                  |
   | public                 | Section 5.2.2.5                  |
   | s-maxage               | Section 5.2.2.9                  |
   | stale-if-error         | [RFC5861], Section 4             |
   | stale-while-revalidate | [RFC5861], Section 3             |
   +------------------------+----------------------------------+

7.2. warn-code レジストリ

warn-code 用の名前空間を定義するレジストリが、新たに作成され， Hypertext Transfer Protocol（ HTTP ）Warn Codes にて保守されている。 The " (HTTP) Warn Codes" registry defines the namespace for warn codes. It has been created and is now maintained at <http://www.iana.org/assignments/http-warn-codes>.

   +-----------+----------------------------------+---------------+
   | Warn Code | Short Description                | Reference     |
   +-----------+----------------------------------+---------------+
   | 110       | Response is Stale                | Section 5.5.1 |
   | 111       | Revalidation Failed              | Section 5.5.2 |
   | 112       | Disconnected Operation           | Section 5.5.3 |
   | 113       | Heuristic Expiration             | Section 5.5.4 |
   | 199       | Miscellaneous Warning            | Section 5.5.5 |
   | 214       | Transformation Applied           | Section 5.5.6 |
   | 299       | Miscellaneous Persistent Warning | Section 5.5.7 |
   +-----------+----------------------------------+---------------+

7.3. ヘッダ登録

HTTP ヘッダは、 Message Headers レジストリの中に登録される。 HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.

この文書は、次の HTTP ヘッダを定義する。 それに伴い "Permanent Message Header Field Names" レジストリも更新された（[BCP90]を見よ）。 This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).

   +-------------------+----------+----------+-------------+
   | Header Field Name | Protocol | Status   | Reference   |
   +-------------------+----------+----------+-------------+
   | Age               | http     | standard | Section 5.1 |
   | Cache-Control     | http     | standard | Section 5.2 |
   | Expires           | http     | standard | Section 5.3 |
   | Pragma            | http     | standard | Section 5.4 |
   | Warning           | http     | standard | Section 5.5 |
   +-------------------+----------+----------+-------------+

変更制御者は “IETF (iesg@ietf.org) — Internet Engineering Task Force” である。 The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".