http-cache-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>RFC 9111 — HTTP Caching （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">

<script src="common0.js"></script>
<script src="http-common.js"></script>
<script src="common1.js" async></script>

<script type="text/plain" id="_source_data">

●●options
spec_title:HTTP Caching
	spec_date:2022-06-06
trans_update:2022-12-08
source_checked:220600
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc9111.html
abbr_url:HTTPcache
spec_status:IETFSTD
no_original_dfn:true
ref_rfc:true
trans_1st_pub:2019-11-22


●●class_map

●●tag_map


●●original_id_map

●●mdn_urls
field.age:HTTP/Headers/Age
field.cache-control:HTTP/Headers/Cache-Control
field.pragma:HTTP/Headers/Pragma
field.warning:HTTP/Headers/Warning
field.expires:HTTP/Headers/Expires

●●link_map

h.Content-MD5:~RFCx/rfc2616#section-14.15


	●指令

qdir.max-age:#cache-request-directive.max-age
qdir.max-stale:#cache-request-directive.max-stale
qdir.min-fresh:#cache-request-directive.min-fresh
qdir.no-cache:#cache-request-directive.no-cache
qdir.no-store:#cache-request-directive.no-store
qdir.no-transform:#cache-request-directive.no-transform
qdir.only-if-cached:#cache-request-directive.only-if-cached

sdir.max-age:#cache-response-directive.max-age
sdir.must-revalidate:#cache-response-directive.must-revalidate
sdir.must-understand:#cache-response-directive.must-understand
sdir.no-cache:#cache-response-directive.no-cache
sdir.no-store:#cache-response-directive.no-store
sdir.no-transform:#cache-response-directive.no-transform
sdir.private:#cache-response-directive.private
sdir.proxy-revalidate:#cache-response-directive.proxy-revalidate
sdir.public:#cache-response-directive.public
sdir.s-maxage:#cache-response-directive.s-maxage

	●用語
~cache:~HTTPcache#cache
切断されて:~HTTPcache#disconnected

検証:#validation.model
検証-:#validation.model
再検証-:#validation.model
再検証:#validation.model
	検証ng:#validation.model
	再検証ng:#validation.model
新鮮:~HTTPcache#fresh
	新鮮であるresponse_is_fresh
非新鮮:~HTTPcache#stale
鮮度:~HTTPcache#expiration.model
	#freshness
鮮度~維持期間:~HTTPcache#freshness-lifetime
失効~時刻:~HTTPcache#expiration-time
明示的な失効~時刻:#explicit-expiration-time
経験的な失効~時刻:#heuristic-expiration-time
経験的:#heuristic.freshness

齢:#age
要請~指令:#cache-request-directive
応答~指令:#cache-response-directive
~cache制御 応答~指令:#cache-response-directive
~cache~key:#cache-key
無効化-:#invalidate
拡張~cache指令:#cache.control.extensions
共有-:#shared-cache
~errorでない応答:#non-error-response
縮約する:#collapse-requests

cite.~HTTP~cache指令~registry:~IANA-a/http-cache-directives
cite.~HTTP~field名~registry:~IANA-a/http-fields

生成元:~HTTPinfra#uri-origin
~listに基づいて:~HTTPinfra#list-based-field

	●変数
V.齢~値:#age_value
V.滞在~時間:#resident_time
V.現在時:#now
V.現在の齢:#current_age
V.要請~時刻:#request_time
V.応答~時刻:#response_time
V.補正済み初期~齢:#corrected_initial_age
V.見かけ齢:#apparent_age

V.補正済み齢~値:#corrected_age_value
V.日時~値:#date_value
V.鮮度~維持期間:#freshness_lifetime
V.応答~遅延:#response_delay
	V.response_is_fresh:#response_is_fresh

	●§
1:#caching
1.1:#requirements.notation
1.2:#notation
1.2.1:#abnf.imported
1.2.2:#delta-seconds
2:#caching.overview
3:#response.cacheability
3.1:#storing.fields
3.2:#update
3.3:#incomplete.responses
3.4:#combining.responses
3.5:#caching.authenticated.responses
4:#constructing.responses.from.caches
4.1:#caching.negotiated.responses
4.2:#expiration.model
4.2.1:#calculating.freshness.lifetime
4.2.2:#heuristic.freshness
4.2.3:#age.calculations
4.2.4:#serving.stale.responses
4.3:#validation.model
4.3.1:#validation.sent
4.3.2:#validation.received
4.3.3:#validation.response
4.3.4:#freshening.responses
4.3.5:#head.effects
4.4:#invalidation
5:#header.field.definitions
5.1:#field.age
5.2:#field.cache-control
5.2.1:#cache-request-directive
5.2.1.1:#cache-request-directive.max-age
5.2.1.2:#cache-request-directive.max-stale
5.2.1.3:#cache-request-directive.min-fresh
5.2.1.4:#cache-request-directive.no-cache
5.2.1.5:#cache-request-directive.no-store
5.2.1.6:#cache-request-directive.no-transform
5.2.1.7:#cache-request-directive.only-if-cached
5.2.2:#cache-response-directive
5.2.2.1:#cache-response-directive.max-age
5.2.2.2:#cache-response-directive.must-revalidate
5.2.2.3:#cache-response-directive.must-understand
5.2.2.4:#cache-response-directive.no-cache
5.2.2.5:#cache-response-directive.no-store
5.2.2.6:#cache-response-directive.no-transform
5.2.2.7:#cache-response-directive.private
5.2.2.8:#cache-response-directive.proxy-revalidate
5.2.2.9:#cache-response-directive.public
5.2.2.10:#cache-response-directive.s-maxage
5.2.3:#cache.control.extensions
5.2.4:#cache.directive.registry
5.3:#field.expires
5.4:#field.pragma
5.5:#field.warning
6:#history.lists
7:#security.considerations
7.1:#cache.poisoning
7.2:#security.timing
7.3:#caching.of.sensitive.information
8:#iana.considerations
8.1:#field.name.registration
8.2:#cache.directive.registration
8.3:#warn.code.registration
9:#rfc.references
A:#collected.abnf
B:#changes.from.rfc.7234

●●words_table1
RFC7234:RFC7234-ja.html

●●words_table

	●cache（時間
同期調整:skew::~::スキュー
失効:expiration::~
失効時期:expiry::~
時間帯:time zone::~
	秒数:time in seconds:~
	足した:plusした:~
齢:age::~
経過-:pass:~
delta:
現在時:now:~
維持期間:lifetime::~
分解能:resolution:~
総和:sum:~

	1 年:one-year
	~~期間:time
	~~未来でない:equal to or earlier than
	~~過去:less than
	ずっと早くに:far sooner
	一年以内:no more than a year in the future
	境に:before, or after
	旧:old
	無限:infinity
	迅速に:promptly
	UTC
	NTP

	●cache
refresh:::更新::リフレッシュ
reload:::再読み込み::リロード
	^en:canned
切断-:disconnect:~
検証子:validator::~
検証ng:validating::検証
再検証-:revalidate::~
再検証ng:revalidating::再検証
有効:valid::~
再検証:revalidation::~
私用:private::~::プライベート
補正済み:corrected:~
滞在:resident:~
滞在-:reside:~
識別情報:identity:~
縮約-:collapse:~
miss:
格納:storage::~

	完全なものに:complete
	`max^op:If the result is negative, the result is replaced by zero
	格納する前に:before storage

	●保安
魅力的:attractive:~
配布-:distribute:~
欠陥:flaw:~
特権拡大:privilege escalation:~
表口:surface::口
末端:end:~
盗聴:eavesdropping:~

	する攻撃は〜 ~~拡大され得る:can extend the reach of an attacker

	●仕様
略語:abbreviation:~
	最低限の:worst-case
都合よく:convenientに:~
契約:contract:~
否定的:negative:~
今日:today:~
素材:material:~
	再利用-法:reusing
下位system:subsystem:下位 system:下位システム
検査ng:checking:検査
見かけ:apparent:~
特質:property:~:::プロパティ
誤理解:misunderstanding:~
候補:candidate:~
例外的:exceptional:~
	例外的に:exceptional basis
省略:omission:~
惑わす:confuseする:~
驚かす:surpriseする:~
驚かさ:surpriseしな:~
慣例:convention:~
廃用d:obsoleted:廃用
注力-:focus:~

	~~処理:operation
	~~可能性:potential
	~~報告もなく実行されなかった:silently unexecuted
	~~妨げ:inhibit
	~~普段より:-
	かどうかが一貫でない:inconsistently
	ように見えても:believe
	一助:help
	判っている:have been demonstrated
	受信した〜:the presented 〜
	度を越して:extremely
	必要yでない:not necessarily
	波及-:influence
	確からしい:plausible
	考えられ:thought
	~~該当する:appropriate
	逆に:conversely
	問われる:matter
	~~伝える:tell
	^en:nominated
	`Vary$h 内に挙げられた:nominated
	広く行き渡って:widespread
	面する:surface
	〜に従う下で:subject to 〜
	いる限りにおいて:provided
	その結果:thereby
	誤って:mistakenly
	選好-可能:preferable
	正確aでなく:inaccurate
	作業-不能に:not be workable
	~~明らかに:apparent
	何ら:in any way
	~~上層:above
	要約すると:In summary
	方が〜優れる:superior
	〜する限りにおいて:provided

	●未分類
並替える:reorderする:並び替える
不揮発:non-volatile:~
揮発:volatile:~
提示-:present:~
通過中:transit 中:~
抹消:evict:~
金融取引:financial transaction:~
割合:fraction:~
返信:reply:~
	現在:current:~
接触-:contact:~
変形-:transform:~
最新状態:up to date:~
単方向:unidirectional:~
地域的:local:~:::ローカル
	置換:replacement
asset::::アセット
帯域外の:out-of-band:~
素早く:quickに:~
合成-:synthesize:~
消費器:consumer::~
消費:consumption:~
発-:emit:~
算術-:arithmetic:~
構成-:compose:~
順位付け:ranking:~
下位範囲:subrange:~
warn-code:
	^en:double keying
	member
	拾える:gleanできる
	“戻る” "Back"
	そのまま書き出:write through
	保持:hold
	欠く:missing
	渡り歩く:travels through
	通過:pass through
	通過中:in transit
	過ぎていない:earlier than or equal to
	その結果:with the effect of
	旧い:old
	ひどく旧い:very old

	●言い換え
	表示し直す:redisplay
	再利用-可能:reusable
	より強い:stronger
	強く禁制され:have stronger prohibitions
	生じる:create
	格納できる:caching of
	引数を伴う:qualified form
	引数を伴わない:unqualified／:unqualified form
	生じた方:occurrence
	〜が無くても:already
	受信した:incoming
	内容~符号法:content-coding
	繋がりを断つ:creating a disconnect between
	拡張~cache指令:extension directives
	拡張~cache指令:cache extension

	●他
	A:first
	B:second
	ある種の:some
	こともある:sometimes
	それ以外の:remaining
	~~以前に:earlier
	より大きい:greater
	一部分:part
	作り上げ:make
	全体が収まる:wholly within
	全面的に／全く:entirely
	大部分:Much of
	残りの部分:rest
	うちいずれか:some or all of
	した結果の:post-
	他に:no more
	広く:widely

●●ref_normative

[HTTP]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP Semantics＞, STD 97, ~RFC9110, June 2022
    URL: https://httpwg.org/specs/rfc9110.html
[RFC2119]
    Bradner, S., ＜Key words for use in RFCs to Indicate Requirement Levels＞, BCP 14, ~RFC2119, March 1997
[RFC5234]
    Crocker, D., Ed. and P. Overell, ＜Augmented BNF for Syntax Specifications: ABNF＞, STD 68, ~RFC5234, January 2008
[RFC7405]
    Kyzivat, P., ＜Case-Sensitive String Support in ABNF＞, ~RFC7405, December 2014
[RFC8174]
    Leiba, B., ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞, BCP 14, ~RFC8174, May 2017

●●ref_informative

[COOKIE]
    Barth, A., ＜HTTP State Management Mechanism＞, ~RFC6265, April 2011
[HTTP/1.1]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP/1.1＞, STD 99, ~RFC9112
    URL: https://httpwg.org/specs/rfc9112.html
[RFC2616]
    Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, ＜Hypertext Transfer Protocol -- HTTP/1.1＞, ~RFC2616, June 1999
[RFC5861]
    Nottingham, M., ＜HTTP Cache-Control Extensions for Stale Content＞, ~RFC5861, May 2010
[RFC7234]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Caching＞, ~RFC7234, June 2014
[RFC8126]
    Cotton, M., Leiba, B., and T. Narten, ＜Guidelines for Writing an IANA Considerations Section in RFCs＞, BCP 26, ~RFC8126, June 2017


●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により Internet Standard として公表された，
<a href="~SPEC_URL">HTTP Caching</a> （RFC 9111）
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata
公表者
	Internet Engineering Task Force (IETF)
RFC
	9111
廃用
	<a href="#RFC7234">7234</a>
分類
	Standards Track
日付
	2022 年 6 月
編集
	R. Fielding, Editor (Adobe)
	M. Nottingham, Editor (Fastly)
	J. Reschke, Editor (greenbytes)
履歴
	https://datatracker.ietf.org/doc/rfc9111/
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc9111
</script>

</head>
<body>


<header>
	<hgroup>
<h1>HTTP キャッシュ法</h1>
<p>RFC 9111 — HTTP Caching</p>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section>
◎要約

<p>
~HTTP（ `Hypertext Transfer Protocol^en ）は、
分散型の協調的な~hypertext情報~system用の，
`~stateless$な応用~levelの~protocolである。
この文書は、 ~HTTP~cacheと~~関連の［
~cacheの挙動を制御する／
~cache可能な応答~messageを指示する
］各種~headerを定義する。
◎
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.
</p>

<p>
この文書は、 `RFC7234$r を廃用にする。
◎
This document obsoletes RFC 7234.
</p>

	</section>
	<section id="rfc.status">
<h2 title="Status of This Memo">このメモの位置付け</h2>

<p class="trans-note">【
この節の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#status$に移譲。
】</p>

	</section>
	<section id="rfc.copyrightnotice">
<h2 title="Copyright Notice">著作権の告知</h2>

<p lang="en">
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
</p>

<p class="trans-note">【
以下、この節の他の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#copyright-notice$に移譲。
】</p>

	</section>

<main id="MAIN0">

	<section id="caching">
<h2 title="Introduction">1. 序論</h2>

<p>
~HTTP（ `Hypertext Transfer Protocol^en ）は、［
~networkに基づく，~hypertext情報~system
］と柔軟にヤリトリするために［
拡張-可能な意味論, および自己-記述的な~message
］を利用する，`~stateless$な応用~levelの［
要請, 応答
］~protocolである。
~HTTPは、
概して，分散型の情報~system用に利用される
— 応答~cacheをそこで利用すれば、
処理能を改善できる。
この文書は、
~HTTPに関係する，応答~messageの~cache法と再利用-法を成す側面を定義する。
◎
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.
</p>

<p>
~HTTP
`~cache@
（ `cache^en ）は、
応答~messageの局所的な格納域であり，
その中に格納される~messageたちの［
格納, 検索取得, 削除
］を制御する下位systemである。
~cacheは、未来の等価な要請に対する［
応答~時間や~network帯域幅の消費
］を抑制するために，~cache可能な応答を格納する。
どの［
`~client$／`~server$
］も，~cacheを利用してヨイ
— `~tunnel$として動作しているときは、
利用し得ないが。
◎
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]).
</p>

<p>
`共用~cache@
（ `shared cache^en ）は、［
複数の利用者が再利用するための応答
］を格納する~cacheである
— それは、
（常にではないが）通例的に，`媒介者$の一部分として配備される。
対照的に，
`私用~cache@
（ `private cache^en ）は、
単独の利用者ごとに専用であり，~UAの~componentとして配備されることが多い。
◎
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.
</p>

<p>
~HTTP~cachingの目標は、
先立つ応答~messageを再利用して現在の要請を満足することにより，処理能を有意に改善することである。
~cacheは、
自身に格納-済みな応答を
— `鮮度§にて定義されるように —
`検証$（`生成元~server$による［
この要請~用の~cache済み応答が有効であり続ける
］かどうかの検査ng
）を伴わずに再利用できるならば，`新鮮$であると見なす。
したがって，`新鮮$な応答は、
~cacheがそれを再利用する度に，遅延, ~network~overheadの両者を抑制し得る。
~cache済み応答は、
`新鮮$でないときでも，［
`検証$により新鮮~化できる／生成元~serverが可用でない
］ときは再利用できることもある
（ `4.2.4§ ）。
◎
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).
</p>

<p class="trans-note">【
この仕様の語 “格納-済み（ `stored^en ）” は、
 “~cacheに格納-済み” の略記として用いられている。
“~cache済み（ `cached^en ）” も同義と見受けられる。
】</p>

<p>
この文書は、
`RFC7234$r を廃用にする
— 変更点は、
`B§ に要約されている。
◎
This document obsoletes RFC 7234, with the changes being summarized in Appendix B.
</p>

		<section id="requirements.notation">
<h3 title="Requirements Notation">1.1. 要件の表記法</h3>

<p>
この文書~内の~keyword "MUST" …
【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】
◎
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.
</p>

<p>
適合性の判定基準, ~errorの取扱いに関する考慮点は、
`適合性§ `HTTP$r
に定義される。
◎
Section 2 of [HTTP] defines conformance criteria and contains considerations regarding error handling.
</p>

		</section>
		<section id="notation">
<h3 title="Syntax Notation">1.2. 構文の表記法</h3>

<p class="trans-note">【
この節の他の内容は、
`~HTTP日本語訳 共通~page＠~HTTPcommon#syntax-notation$に移譲。
】</p>

<p>
`A§ にて、
すべての~list演算子を標準な~ABNF表記法に展開した，総集的な文法を示す。
◎
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], extended with the notation for case-sensitivity in strings defined in [RFC7405].
◎
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.
</p>

			<section id="abnf.imported">
<h4 title="Imported Rules">1.2.1. 取込まれた規則</h4>

<p>
次に挙げる規則は、
`HTTP$r にて定義される
⇒＃
`HTTP-date$p,
`OWS$p,
`field-name$p,
`quoted-string$p,
`token$p,
◎
↑The following core rule is included by reference, as defined in [RFC5234], Appendix B.1: DIGIT (decimal 0-9).
◎
[HTTP] defines the following rules:

HTTP-date     = &lt;HTTP-date, see [HTTP], Section 5.6.7&gt;
OWS           = &lt;OWS, see [HTTP], Section 5.6.3&gt;
field-name    = &lt;field-name, see [HTTP], Section 5.1&gt;
quoted-string = &lt;quoted-string, see [HTTP], Section 5.6.4&gt;
token         = &lt;token, see [HTTP], Section 5.6.2&gt;
</p>

			</section>
			<section id="delta-seconds">
<h4 title="Delta Seconds">1.2.2. ~delta秒</h4>

<p>
`delta-seconds$p 規則は、
秒数を表現する，負でない整数を指定する。
◎
The delta-seconds rule specifies a non-negative integer, representing time in seconds.
</p>

<pre class="bnf">
`delta-seconds@p
	= 1*`DIGIT$P
</pre>

<p>
`受信者$は、［
`delta-seconds$p 値を構文解析して~binary形に変換する
］際には，［
少なくとも 31~bit以上, かつ負でない整数の範囲をとる，算術-型
］を利用する~OUGHT。
`delta-seconds$p 値を受信した~cacheは、
その値が［
自身が表現できる最~大な整数より大きい場合／
自身による後続な計算にて桁溢れする場合
］には，［
2147483648（ 2 の 31 乗）, または
都合よく表現できる最~大な正な整数
］と見なさなければナラナイ。
◎
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.
</p>

<p class="note">注記：
ここでの値 2147483648 は、
歴史的な理由による
— それは無限（ 68 年~以上）を表現する。
この値は~binary形として格納される必要はない
— 実装は、［
その数を直に表現できないような算術-型により計算が遂行される
］ときでも、
桁溢れが生じた場合には，文字列として生産できる。
ここで問われるのは、
桁溢れが検出され，今後の計算において負な値に扱われないことである。
◎
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.
</p>

			</section>
		</section>
	</section>
	<section id="caching.overview">
<h2 title="Overview of Cache Operation">2. ~cache運用の概観</h2>

<p>
~cacheを適正に運用することで、
~HTTP転送の意味論を保全しつつ，すでに~cache内に保持されている情報の伝送を抑制できるようになる。
~HTTPの一般的な各種用語と中核~概念は、
`HTTP$r `3＠~HTTPinfra#terminology§ を見よ。
◎
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.
</p>

<p>
~HTTPにおける~cachingは，全面的に`任意選択^2119な特能であるが、［
~cache済み応答を再利用することは望ましいものであり、
そのような再利用は，それを防止する［
要件や局所的な環境設定
］が無ければ，既定の挙動である
］ものと見做せる。
したがって，~HTTP~cacheに課される要件は、
~cacheに対し，［
特定0の応答を，常に格納して再利用する
］ことを義務付けるのではなく，［
再利用できない応答を格納すること ／
格納-済み応答を不適切に再利用すること
］を防止することに注力される。
◎
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.
</p>

<p>
`~cache~key@
（ `cache key^en ）は，格納-済み応答を選ぶために~cacheが利用する情報であり、
最小でも，格納-済み応答を検索取得するために利用される［
`要請~method$,
`~target~URI$
］から構成される
— ~methodは、［
格納-済み応答は，どの状況下で後続な要請を満足するために利用できるか
］を決定する。
しかしながら，
今日における多くの~HTTP~cacheの共通的な利用では、
`GET$m に対する応答しか~cacheしていないので，
~cache~keyとして~URIしか利用していない。
◎
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.
</p>

<p>
~cacheは、［
`内容~折衝$の~subjectである`要請~target$
］用に複数の応答を格納するかもしれない。
~cacheは、
元の要請~内の~headerのうち一部を
— `4.1§ に従って，
`Vary$h 応答~header内の情報を利用して —
~cache~keyの中へ組入れることにより，これらの応答を相違化する。
◎
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.
</p>

<p>
~cacheは、
~cache~keyの中に追加的な素材を組入れるかもしれない。
例えば，~UA~cacheは、
ある種の~privacy~riskを避けるため，参照元~siteの同一性も内包して~cache~keyを “二重化する” かもしれない
（ `7.2§ を見よ）。
◎
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).
</p>

<p>
~cacheが最も共通的に格納するものは、
検索取得~要請に対する成功裡な結果
— すなわち、
`GET$m 要請に対する `200$st 応答であって，`~target資源$の`表現$を包含するもの —
である。
しかしながら，［
~redirect／
否定的な結果（例： `404$st ）／
`不完全$【または部分的】な結果（例： `206$st ）／
`GET$m 以外の~methodに対する応答
］を格納することもアリである
— 当の~methodの定義が、
そのような~cache法を許容していて，~cache~key用の利用に相応しい何かを定義するならば。
◎
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.
</p>

<p>
~cacheは、［
`生成元~server$に接触できないか, 要請を回送する経路を見出せなくなった
］とき，
`切断されて@
いる（ `disconnected^en ）とされる。
`切断されて$いる~cacheであっても、
一部の状況下では`非新鮮$な応答を~serveし得る
（ `4.2.4§ ）。
◎
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).
</p>

	</section>
	<section id="response.cacheability">
<h2 title="Storing Responses in Caches">3. ~cache内への応答の格納-法</h2>

<p>
~cacheが［
ある要請に対する応答
］を格納し得るのは、
~AND↓ が満たされる場合に限られる
— 他の応答は格納してはナラナイ：
◎
A cache MUST NOT store a response to a request unless:
</p>
<ul>
	<li>
~cacheは、
`要請~method$を解する。†
◎
the request method is understood by the cache;
</li>
	<li>
応答は`最終-応答$である。
◎
the response status code is final (see Section 15 of [HTTP]);
</li>
	<li>
応答の`状態s~code$は［
`206$st0 ／ `304$st0
］であるか,
応答~内に `must-understand$sdir ~cache指令が在る場合に限り
⇒
~cacheは、
応答の状態s~codeを解する。†
◎
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;
</li>
	<li>
応答~内に `no-store$sdir `~cache指令$は無い。
◎
the no-store cache directive is not present in the response (see Section 5.2.2.5);
</li>
	<li>
<p>
~cacheが`共用~cache$である場合に限り， ~AND↓ が満たされる：
◎
↓</p>
		<ul>
			<li>
<p>
~OR↓：
</p>
				<ul>
					<li>
応答~内に `private$sdir ~cache指令は無い。
</li>
					<li>
応答~内に 【引数を伴う】 `private$sdir ~cache指令が在って，
【引数に基づいて】改変された応答を`共用~cache$に格納することは許容される。
</li>
				</ul>
◎
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);
</li>
			<li>
<p>
~OR↓：
</p>
				<ul>
					<li>
要請~内に `Authorization$h ~headerは無い。
</li>
					<li>
応答~内に`共用~cache$に~cacheすることを明示的に許容する~cache指令が在る
（ `3.5§ を見よ）。
</li>
				</ul>
◎
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
</li>
		</ul>
	</li>
	<li>
<p>
応答は、
次に挙げるいずれかを包含する：
◎
the response contains at least one of the following:
</p>
		<ul>
			<li>
`public$sdir ~cache指令
◎
a public response directive (see Section 5.2.2.9);
</li>
			<li>
`共用~cache$でない場合に限り
⇒
`private$sdir ~cache指令
◎
a private response directive, if the cache is not shared (see Section 5.2.2.7);
</li>
			<li>
`Expires$h ~header
◎
an Expires header field (see Section 5.3);
</li>
			<li>
`max-age$sdir ~cache指令
◎
a max-age response directive (see Section 5.2.2.1);
</li>
			<li>
`共用~cache$である場合に限り
⇒
`s-maxage$sdir ~cache指令
◎
if the cache is shared: an s-maxage response directive (see Section 5.2.2.10);
</li>
			<li>
~cacheされることを許容する，`拡張~cache指令$
◎
a cache extension that allows it to be cached (see Section 5.2.3); or
</li>
			<li>
`経験的に~cache可能$であるものと定義された`状態s~code$
◎
a status code that is defined as heuristically cacheable (see Section 4.2.2).
</li>
		</ul>
	</li>
</ul>

<p class="note">注記：
`拡張~cache指令$は、
上に挙げた どの要件も上書きし得る。
◎
Note that a cache extension can override any of the requirements listed; see Section 5.2.3.
</p>

<p>†
この文脈において，~cacheが［
`要請~method$／`応答~状態s~code$
］を “解する” とは、
~cacheは，それを認識した上で［
指定された，~cache法に関係する挙動
］すべてを実装することをいう。
◎
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.
</p>

<p class="note">注記：
通常の運用においては、
一部の~cacheは，［
~cache検証子も`明示的な失効~時刻$も無い応答
］を格納しない
— そのような応答は、
通例的に，格納しても有用にならないので。
しかしながら、
~cacheがそのような応答を格納することも，禁制されない。
◎
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.
</p>

		<section id="storing.fields">
<h3 title="Storing Header and Trailer Fields">3.1. ~header／~trailerの格納-法</h3>

<p>
~cacheは、
応答を格納するときには，応答~内に受信した~header
— 自身が認識しないものも含む —
も含めて格納しなければナラナイ。
これは、
新たな~HTTP~headerが成功裡に配備できることを確約する。
しかしながら，次に挙げる例外がある：
◎
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:
</p>
<ul>
	<li>
<p>
次に挙げる~fieldは、
~messageを回送する前に除去することが要求される。
これは、
格納する前にそうするよう実装してもヨイ：
</p>
		<ul>
			<li>
`Connection$h ~header。
</li>
			<li>
その`~field名$が `Connection$h ~headerの`~field値$に~listされたもの。
</li>
			<li>
その意味論にて，除去するよう要求されるもの
— 例えば， `Connection§h に挙げられたものなど。
</li>
		</ul>
◎
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.
◎
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.
</li>
	<li>
［
`no-cache$sdir ／ `private$sdir
］~cache指令は、［
すべての~cache／`共用~cache$
］による~headerの格納を防止する引数をとり得る。
◎
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.
</li>
	<li>
`~proxy$に特有な~headerのうち，要請を回送するときに~cacheが利用するものは、
~cacheが当の~proxyの識別情報を~cache~keyの中に組入れる場合を除き，
格納してはナラナイ。
該当するものは、
実質的に，次に挙げるものに制限される
⇒＃
`Proxy-Authenticate$h,
`Proxy-Authentication-Info$h,
`Proxy-Authorization$h
◎
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]).
</li>
</ul>

<p>
~cacheは、
`~trailer$に対しては
⇒＃
~headerとは別々に格納しても，破棄してもヨイ。
~headerと`結合-$してはナラナイ。
◎
Caches MAY either store trailer fields separate from header fields or discard them. Caches MUST NOT combine trailer fields with header fields.
</p>

		</section>
		<section id="update">
<h3 title="Updating Stored Header Fields">3.2. 格納-済み~headerの更新-法</h3>

<p>
~cacheには、
いくつかの状況において，格納-済み応答の~headerたちを別の（概して，より新たな）応答で更新することが要求される。
例えば、［
`3.4§／`4.3.4§／`4.3.5§ 
］を見よ。
◎
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.
</p>

<p>
~cacheは，そうするときは、
供された応答~内の各~headerを格納-済み応答に追加しなければナラナイ
— すでに在るものは，その`~field値$を置換して。
ただし、
次に挙げる例外に該当する~headerは除く：
◎
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:
</p>

<ul>
	<li>
`3.1§ により，格納しないものとされるもの。
◎
Header fields excepted from storage in Section 3.1,
</li>
	<li>
下で述べるとおり、
~cacheに格納-済みな応答が依存しているもの。
◎
Header fields that the cache's stored response depends upon, as described below,
</li>
	<li>
下で述べるとおり、
受信者により，自動的に処理されて除去されるもの。
◎
Header fields that are automatically processed and removed by the recipient, as described below, and
</li>
	<li>
`Content-Length$h ~header。
◎
The Content-Length header field.
</li>
</ul>

<p>
一部の事例では，（とりわけ~UAにおける）~cacheは、
受信した応答に代えて，それを処理した結果を格納する
— その処理に影響する~headerを更新すると，一貫しない挙動や~securityの課題をもたらし得る。
~cacheは，この状況においては、
格納-済みな応答を更新するときに，該当する~headerを例外的に省略してもヨイ
— ただし，そのような省略は、［
格納-済みな応答の完全性を確約するために必要yな~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.
</p>

<p>
例えば，ある~browserは、
応答を受信している間に その`内容~符号法$を復号して，自身が格納した~dataと応答の元の~metadataとの繋がりを断つかもしれない。
その格納-済み~metadataを異なる `Content-Encoding$h ~headerで更新すると，問題になり得る。
同様に，ある~browserは、
応答~内に受信した`内容$に代えて，それを構文解析した結果の~HTML~treeを格納するかもしれない。
この事例で `Content-Type$h ~headerを更新すると、
作業-不能になる
— 構文解析において為された形式についての前提は、
今や無効になるので。
◎
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.
</p>

<p>
さらには，一部の~field
— `Content-Range$h ~headerなど —
は、
~HTTP実装により自動的に処理され，除去される。
実装は、
そのような~headerを
— その処理が実際には生じないときでも —
更新から自動的に省略してもヨイ。
◎
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.
</p>

<p>
接頭辞 `Content-^c は、［
それを伴う~headerを更新から省略するよう通達するもの
］ではないことに注意。
この接頭辞は、
~HTTPではなく~MIME~header用の慣例である。
◎
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.
</p>

		</section>
		<section id="incomplete.responses">
<h3 title="Storing Incomplete Responses">3.3. 不完全な応答の格納-法</h3>

<p>
~cacheは、
`完全$でない応答【！[HTTP] § 6.1】であっても，［
それが応対した要請の`~method$は `GET$m
］かつ［
応答の`状態s~code$は `200$st
］かつ［
応答の`~header節$全体を受信した
］場合には、
それを`不完全$であるものと記録する限りにおいて，格納してもヨイ。
同様に， `206$st 応答についても、
それが`不完全$な `200$st 応答であったかのように格納してヨイ。
しかしながら，~cacheは、［
`Range$h, `Content-Range$h
］~headerを~supportしない, または［
それらの~headerに利用された`範囲~単位$を解さない
］ならば，内容が［
`不完全$／`部分的$
］な応答を格納してはナラナイ。
◎
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.
</p>

<p class="trans-note">【
すなわち、
格納-済み応答においては，`不完全$か`部分的$かは区別されず、
いずれにせよ（`部分的な応答$であるかのように）範囲を記録することになる。
】</p>

<p>
~cacheは、［
後続な`範囲~要請$を為すこと（ `Range§h `HTTP$r ）により得られた成功裡な応答
］を［
`3.4§ に従って，格納-済み応答たちと結合する
］ことにより，`不完全$な格納-済み応答を`完全$なものにしてもヨイ。
◎
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.＼
</p>

<p>
~cacheは、
次のいずれかに該当する場合を除き，`不完全$な応答を要請に対する回答に利用してはナラナイ：
◎
A cache MUST NOT use an incomplete response to answer requests unless＼
</p>
<ul>
	<li>
当の応答は【前~段落に述べたとおり】完全なものにされた。
◎
the response has been made complete, or＼
</li>
	<li>
<p>
当の要請は、
部分的【`範囲~要請$】であって，それが指定している範囲は`不完全$な応答の中に収まる。
◎
the request is partial and specifies a range wholly within the incomplete response.＼
</p>

<p>
この場合に`~client$へ送信する`不完全$な応答は、
状態s~code `206$st を利用して，明示的に`部分的な応答$であるものと~markしなければナラナイ。
◎
A cache MUST NOT send a partial response to a client without explicitly marking it using the 206 (Partial Content) status code.
</p>
	</li>
</ul>

		</section>
		<section id="combining.responses">
<h3 title="Combining Partial Content">3.4. 部分的な内容の結合-法</h3>

<p>
応答は、［
接続が尚早に~closeされた
］または［
当の要請が `Range$h にて 1 個~以上の範囲~指定子（ `range-spec$p ）を利用した
］場合に，`部分的$な表現のみを転送することがある。
そのような転送が何度か行われたとき、
~cacheは，同じ表現の各部を成す いくつかの範囲を受信し得る。
~cacheは、
これらの範囲を
— ［
それらすべてが同じ`強い検証子$を共有する
］かつ［
当の~cacheは、
`HTTP$r `範囲の結合-法＠~HTTPsem#combining.byte.ranges§
に与える~client要件に準拠する
］ならば —
単独の格納-済み応答の中へ結合して，結果の応答を今後の要請を満足するために再利用してもヨイ。
◎
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].
</p>

<p>
~cacheは，［
新たな応答と 1 個~以上の格納-済み応答とを結合する
］ときは、
`3.2§ に従う下で，［
新たな応答~内に供された各~header
］を利用して［
格納-済み応答~内の各~header
］を更新しなければナラナイ。
◎
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.
</p>

		</section>
		<section id="caching.authenticated.responses">
<h3 title="Storing Responses to Authenticated Requests">3.5. 認証-済み要請に対する応答の格納-法</h3>

<div class="p">
<p>
`共用~cache$は、［
`Authorization$h ~headerを伴う要請に対する~cache済み応答
］を利用して，後続な要請を満足してはナラナイ
— ただし、
~AND↓ が満たされる場合は除く：
</p>
<ul>
	<li>
当の応答は `Cache-Control$h ~fieldを包含していて、
その`~field値$は［
当の応答を格納することを許容する`応答~指令$
］を伴う
</li>
	<li>
当の~cacheは、
前項に該当する どの指令に対しても，［
その指令による，当の応答~用の要件
］に適合する
</li>
</ul>
◎
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.
</div>

<p>
この仕様においては、
次に挙げる`応答~指令$に，そのような効果がある
⇒＃
`must-revalidate$sdir,
`public$sdir,
`s-maxage$sdir
◎
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).
</p>

		</section>
	</section>
	<section id="constructing.responses.from.caches">
<h2 title="Constructing Responses from Caches">4. ~cacheからの応答の構築-法</h2>

<p>
受信した【！the presented】 %要請 に対し，~cacheが自身に格納-済みな応答（以下，単に %応答 ）を再利用できるためには、
~AND↓ が満たされなければナラナイ：
◎
When presented with a request, a cache MUST NOT reuse a stored response unless:
</p>
<ul>
	<li>
%応答 の`~target~URI$と %要請 内に提示されたそれは合致する
◎
the presented target URI (Section 7.1 of [HTTP]) and that of the stored response match, and
</li>
	<li>
%応答 が応対した要請の~methodは、
%応答 を %要請 用に利用することを許容している
◎
the request method associated with the stored response allows it to be used for the presented request, and
</li>
	<li>
%応答 の `Vary$h 内に挙げられた【！nominated】どの要請~header（もしあれば）も，
%要請 に提示されたそれに合致する
（ `4.1§ を見よ）
◎
request header fields nominated by the stored response (if any) match those presented (see Section 4.1), and
</li>
	<li>
<p>
~OR↓：
</p>
		<ul>
			<li>
%応答 は成功裡に`検証-$された
</li>
			<li>
%応答 は `no-cache$sdir `応答~指令$を包含しない
</li>
		</ul>
◎
the stored response does not contain the no-cache directive (Section 5.2.2.4), unless it is successfully validated (Section 4.3), and
</li>
	<li>
<p id="_ecxluded-condition-for-freshening">
~OR↓：
</p>
		<ul>
			<li>
%応答 は`新鮮$である
</li>
			<li>
%応答 は`非新鮮$であっても~serveすることが許容されている（ `4.2.4§ ）
</li>
			<li>
%応答 は成功裡に`検証-$された
</li>
		</ul>
◎
the stored response is one of the following:
• fresh (see Section 4.2), or
• allowed to be served stale (see Section 4.2.4), or
• successfully validated (see Section 4.3).
</li>
</ul>

<p class="note">注記：
`拡張~cache指令$は、
上に挙げた どの要件も上書きし得る。
◎
Note that a cache extension can override any of the requirements listed; see Section 5.2.3.
</p>

<p>
~cacheは：
</p>
<ul>
	<li>
格納-済み応答 %応答 を［
`検証$を伴わずに，要請を満足するために利用する
］ときは、
%応答 内に［
%応答 の `現在の齢$V に等しい値を伴う `Age$h ~header
］を`生成-$しなければナラナイ
— その~headerが %応答 内に在る場合は，それを置換して。
`4.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.
</li>
	<li>
<p>
`安全$でない~methodを伴う要請 %要請 に対しては、
`生成元~server$に向けて，そのまま書き出さなければナラナイ
— すなわち、
~cacheには，［
%要請 が回送され，対する応答が受信される
］までは［
%要請 に対する返信を`生成-$すること
］は許容されない。
◎
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.
</p>

<p>
`安全$でない要請は、
すでに格納-済みな応答を無効化し得ることに注意
— `4.4§ を見よ。
◎
Also, note that unsafe requests might invalidate already-stored responses; see Section 4.4.
</p>
	</li>
	<li>
<p>
［
格納-済み／格納-可能
］な応答を［
複数の要請を満足する
］ために利用できる
— それらに再利用することが許容される限りにおいて。
◎
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.＼
</p>

<p>
これは、
~cacheが複数個の要請を
`縮約する@
— ~cache~missに際して，受信した複数個の要請を 1 個の回送~要請に結合する —
ことにより，［
`生成元~server$／~network
］の負荷を抑制することを可能化する。
しかしながら，［
縮約される要請のうち，返された応答を当の~cacheが利用し得ないもの
］がある場合、
それを満足するためには回送する必要があるので，
追加的な待時間を導入することになり得ることに注意。
◎
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.
</p>
	</li>
	<li>
相応しい格納-済み応答が複数ある場合、
（ `Date$h ~headerにより決定される）最も近過去なものを利用しなければナラナイ。
また、要請を
— 次のいずれかを伴わせた上で —
回送することにより，利用する応答を一義化できる
⇒＃
"`Cache-Control: max-age=0^c" ／
"`Cache-Control: no-cache^c"
◎
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.
</li>
	<li>
`時計$を備えていない~cacheは、
格納-済み応答を
— どの利用に際しても —
`再検証-$しなければナラナイ。
◎
A cache without a clock (Section 5.6.7 of [HTTP]) MUST revalidate stored responses upon every use.
</li>
</ul>

		<section id="caching.negotiated.responses">
<h3 title="Calculating Cache Keys with the Vary Header Field">4.1. `Vary^h ~headerによる~cache~keyの計算-法</h3>

<p>
~cacheは、
受信した要請が［
ある格納-済み応答 %格納-済み応答 により満足できる場合
］でも，［
%格納-済み応答 が `Vary$h ~headerを包含する場合
］には［
`再検証$を伴うことなく %格納-済み応答 を利用して
］はナラナイ
— ただし、［
%格納-済み応答 の `Vary$h `~field値$に挙げられた【！nominated】，すべての要請~header
］に関して，［
当の要請~内の それらの~field,
元の要請（すなわち，%格納-済み応答 を~cacheに格納させた要請）内の それらの~field
］が以下に述べるように合致する場合は除く：
◎
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).
</p>
<ul>
	<li>
<p>
所与の~headerに対し，
2 つの要請における それらが互いに合致するための必要十分条件は、［
それぞれの要請に，次に挙げるいくつかを適用することにより、
一方の要請の`~field値$を他方のそれに変形できるとき
］と定義される：
◎
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:
</p>
		<ul>
			<li>
~headerの構文にて許容される所で，空白を追加する／除去する。
◎
adding or removing whitespace, where allowed in the header field's syntax
</li>
			<li>
同じ`~field名$を伴う複数の`~field行l$を`結合-$する
（ `HTTP$r `5.2＠~HTTPinfra#field.lines§ ）。
◎
combining multiple header field lines with the same field name (see Section 5.2 of [HTTP])
</li>
			<li>
各`~field値$を［
~headerの仕様に則って，意味論が一致することが既知である
］ような仕方で正規化する
（例：［
順序が有意でない所では，`~field値$を並替える
］, ［
文字大小無視と定義されている所では，小文字（または大文字）のみに正規化する
］, 等々）。
◎
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)
</li>
		</ul>
	</li>
	<li>
（正規化を終えた後に，†）当の~headerが［
片方の要請にしか無い場合は合致しない／
どちらの要請にも無い場合は合致する
］とする。
【† 前項により、要請の意味論が~headerの有無に応じて変化しない場合も，合致すると解釈できよう。】
◎
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.
</li>
	<li>
%格納-済み応答 の `Vary$h `~field値$を成す ある~memberが "`*^c" の場合、
この合致-は常に失敗するとする。
◎
A stored response with a Vary header field value containing a member "*" always fails to match.
</li>
</ul>

<p>
【`~cache~key$に】合致する格納-済み応答が複数ある場合、
~cacheは，利用する 1 つを選ぶ必要がある。
応答の `Vary$h 内に挙げられた【！nominated】要請~headerには［
順位付け選好~用の既知な仕組み
］がある場合
（例：［
`Accept$h や それに類する要請~header
］内の`品質値$）、
その仕組みを利用して，選好される応答を選んでもヨイ。
そのような仕組みは可用でないか，等しく選好される複数個の応答が導かれる場合、
`4§ に従って，（ `Date$h ~headerにより決定される）最も近過去な応答が選ばれる。
◎
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.
</p>

<p>
一部の資源は、
既定の応答
（すなわち，当の要請が選好を何も表出しなかったとき送信されるもの）
から `Vary$h ~headerを誤って省略する
— その結果、
後続な要請に対し，［
より選好-可能な他の応答が可用なとき
］でも既定の応答を選ぶことになる。
~cacheは，ある`~target~URI$用に複数の格納-済み応答を有している場合には、
それらのうち［
`Vary$h ~headerは省略されていない, かつ
その`~field値$は妥当であるもの
］から最も近過去なものを選ぶベキである
（ `4.2.3§ を見よ）。
◎
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.
</p>

<p>
合致する格納-済み応答は無い場合、
~cacheは，受信した【！the presented】要請を満足できない。
その場合，当の要請は、
概して，`生成元~server$へ回送される
— それには、［
当の~cacheがすでに格納した応答は何であるかを述べる`事前条件$
］も追加され得る
（`検証§を見よ）。
◎
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).
</p>

		</section>
		<section id="expiration.model">
<h3 title="Freshness">4.2. 鮮度</h3>

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

<p class="trans-note">【
この定義は，超過したかどうか計算できることが前提にある。
（ `4.2.4§ の記述に従うなら、
計算できない場合は，新鮮と見なされる？）
】</p>

<p>
応答の
`鮮度~維持期間@
（ `freshness lifetime^en ）とは、［
それが`生成元~server$により`生成-$された時刻から，その`失効~時刻$まで
］の~~期間である。
`失効~時刻@
（ `expiration time^en ）とは、
それを過ぎて以降は，［
格納-済み応答は、
更なる`検証$を伴わない限り，~cacheにより利用できない
］とされる時刻である。
`明示的な失効~時刻@
（ `explicit expiration time^en ）とは、
`生成元~server$が意図する`失効~時刻$である。
一方で，
`経験的な失効~時刻@
（ `heuristic expiration time^en ）とは、
`明示的な失効~時刻$が可用でないときに，~cacheによりアテガわれる`失効~時刻$である。
◎
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.
</p>

<p>
応答の
`齢@
（ `age^en ）とは、
`生成元~server$により［
それが`生成-$された, もしくは
成功裡に`検証-$された
］ときから，経過した時間である。
◎
A response's "age" is the time that has passed since it was generated by, or successfully validated with, the origin server.
</p>

<p>
~cache内の応答は、
`新鮮$である間は［
`生成元~server$に接触することなく，後続な要請を満足する
］ために利用でき、
それにより，効率を改善する。
◎
When a response is fresh, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.
</p>

<p>
`生成元~server$にとり，`鮮度$を決定するための首な仕組みは、［
`Expires$h ~header／ `max-age$sdir 応答~指令
］を利用して，未来の`明示的な失効~時刻$を供することである。
一般に，`生成元~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.
</p>

<p>
`生成元~server$は、
~cacheに対し，【ある資源への】各~要請に毎回`検証$を強制したいときには、
過去を~~指す`明示的な失効~時刻$をアテガって，
応答がすでに`非新鮮$であることを指示できる。
準拠~cacheは、
通常は，`非新鮮$な~cache済み応答を
— 後続な要請~用に再利用する前に —
`検証-$することになる
（ `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).
</p>

<p>
`生成元~server$は，`明示的な失効~時刻$を常に供するとは限らないので、
~cacheには，一定の状況下において［
`失効~時刻$を決定する経験則を利用する
］ことも許容される
（ `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).
</p>

<p>
応答は、［
`現在の齢$V ~LT `鮮度~維持期間$V
］が満たされる間は，
<dfn id="response_is_fresh">`新鮮$である</dfn>
ものと決定される。
◎
The calculation to determine if a response is fresh is:
◎
response_is_fresh = (freshness_lifetime &gt; current_age)
◎
freshness_lifetime is defined in Section 4.2.1; current_age is defined in Section 4.2.3.
</p>

<p>
`~client$は、［
`max-age$qdir ／ `min-fresh$qdir
］要請~指令を送信して，［
対応する応答~用の`鮮度$の計算
］に対する制限sを示唆できる。
しかしながら、
~cacheには，それらを尊守することは要求されない。
◎
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.
</p>

<p>
日時（ `HTTP-date$p ）の構文解析-法に共通的にある問題を避けるため、
~cache`受信者$は，鮮度を計算するときには：
◎
When calculating freshness, to avoid common problems in date parsing:
</p>
<ul>
	<li>
すべての日時~形式は，文字大小区別として指定されているが、
当の`~field値$を文字大小無視で照合するベキである。
◎
Although all date formats are specified to be case-sensitive, a cache recipient SHOULD match the field value case-insensitively.
</li>
	<li>
自身の内部~実装による時刻の分解能が `HTTP-date$p 値のそれより粗い場合、
構文解析した `Expires$h 日時を［
受信した値を超えない最も近い時刻
］として内部的に表現しなければナラナイ。【！＊】
◎
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.
</li>
	<li>
地域的な時間帯を［
`齢$や`失効~時刻$
］の［
計算, 比較
］に波及させてはナラナイ。
◎
A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
</li>
	<li>
失効~時刻の計算-時には、［
"`GMT^c" 以外を時間帯 略語として伴う日時
］を無効と見なすベキである。
◎
A cache recipient SHOULD consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
</li>
</ul>

<p class="note">注記：
鮮度が適用されるのは、
~cache運用に限られる
— 表示の~refreshや, `資源$の~reloadを~UAに強制する用途には利用できない。
~cacheと履歴の仕組みとの相違点は、
`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.
</p>

			<section id="calculating.freshness.lifetime">
<h4 title="Calculating Freshness Lifetime">4.2.1. 鮮度~維持期間の計算</h4>

<p>
~cacheは、
次に挙げる規則を順に評価して，［
最初に合致する項目にて与える値
］を利用して，応答の`鮮度~維持期間$を計算できる
（その計算結果は、
`鮮度~維持期間@V
と称される）：
◎
A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by evaluating the following rules and using the first match:
</p>
<ol>
	<li>
~cacheは`共有-$されている, かつ
`s-maxage$sdir 応答~指令が在る場合
⇒
その値
◎
If the cache is shared and the s-maxage response directive (Section 5.2.2.10) is present, use its value, or
</li>
	<li>
`max-age$sdir 応答~指令が在る場合
⇒
その値
◎
If the max-age response directive (Section 5.2.2.1) is present, use its value, or
</li>
	<li>
`Expires$h 応答~headerが在る場合
⇒
その値 ~MINUS `Date$h 応答~headerの値
（ `Date^h が無い場合、
`Date§h に従って，~messageを受信した時刻を利用する）
◎
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
</li>
	<li>
他の場合
⇒
応答~内には`明示的な失効~時刻$は無い。
`経験的$な`鮮度~維持期間$が適用-可能になり得る。
◎
Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see Section 4.2.2.
</li>
</ol>

<p class="note">注記：
この計算には、
次が意図される
⇒
アリなときは、
`生成元~server$から供された時計~情報を利用して，時計~同期調整を抑制する。
◎
Note that this calculation is intended to reduce clock skew by using the clock information provided by the origin server whenever possible.
</p>

<p>
所与の指令~用の値が複数個~在る場合
（例：
`Expires$h ~header`~field行l$が複数個 ／
"`Cache-Control: max-age^c" 指令が複数個）、［
最初に生じたものを利用するか，応答は`非新鮮$と見なす
］べきである。
複数個の指令が競合する場合
（例： `max-age$sdir, `no-cache$sdir どちらも在る）、
最も制約的な指令が尊守されるべきである。
~cacheには、
無効な鮮度~情報を伴う応答
（例： `max-age^dir 指令の内容は整数でない）
を`非新鮮$と見なすことが奨励される。
◎
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.
</p>

			</section>
			<section id="heuristic.freshness">
<h4 title="Calculating Heuristic Freshness">4.2.2. 鮮度の経験的な計算-法</h4>

<p>
`生成元~server$は，常に`明示的な失効~時刻$を供するとは限らない。
したがって，時刻が明示的に指定されていないときは、
~cacheは，［
確からしい`失効~時刻$を見積もる
］ために［
他の`~field値$（ `Last-Modified$h による時刻など）を利用する~algo
］を使役して，`経験的な失効~時刻$をアテガってもヨイ。
この仕様は、
特定の~algoは供さないが，
それらの結果に対する~~最低限の拘束を課す。
◎
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.
</p>

<p>
~cacheは、
格納-済み応答~内に`明示的な失効~時刻$が在るときには，
`鮮度$を決定する経験則を利用してはナラナイ。
何故なら、
`3§ による要件により，経験則を利用し得るのは［
明示的な鮮度を伴わない応答のうち，次のいずれかに該当するもの
］に限られるので：
◎
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＼
</p>
<ul>
	<li>
`状態s~code$は
`経験的に~cache可能@
（ `heuristically cacheable^en ）であると定義されたもの
（例： `HTTP$r `状態s~codeの概観＠~HTTPsem#overview.of.status.codes§に挙げられたもの）。
◎
on responses without explicit freshness whose status codes are defined as "heuristically cacheable" (e.g., see Section 15.1 of [HTTP]) and＼
</li>
	<li>
明示的に`~cache可能$であると~markされたもの
（例： `public$sdir 応答~指令により）。
◎
on responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a public response directive).
</li>
</ul>

<p>
以前までの仕様は、
“`経験的に~cache可能$”
な`状態s~code$を
“既定で~cache可能”
と称していたことに注意。
◎
Note that in previous specifications, heuristically cacheable response status codes were called "cacheable by default".
</p>

<p>
応答に `Last-Modified$h ~headerが在る場合、
~cacheには，［
その時刻から現在時までの時区間に対する ある割合
］を超えないものを経験的な失効~値として利用することが奨励される。
この割合の代表的な設定は `10%^ 程度になるであろう。
◎
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%.
</p>

<p class="note">注記：
~HTTP仕様の以前の~version（ `2616/13.9$rfc ）では、［
~query成分を伴う~URI（すなわち， "`?^c" を包含する~URI）
］に対しては，~cacheによる`経験的$な鮮度の計算-法を禁制していたが、
実施においては，これは広く実装されていない。
したがって，`生成元~server$には、
~cachingを防止したいと望む場合には，明示的な指令を送信することが奨励される
（例： `Cache-Control: no-cache^c ）。
◎
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.
</p>

			</section>
			<section id="age.calculations">
<h4 title="Calculating Age">4.2.3. 齢の計算-法</h4>

<p>
`Age$h ~headerは、［
応答~messageが~cacheから得されるときに見積もられた`齢$
］を伝達するために利用される。
その`~field値$は、
~cacheにより見積もられた，［
`生成元~server$が，当の応答を［
`生成-$した, または`検証-$した
］ときからの秒~数
］である。
したがって `Age^h 値は、
応答が［
`生成元~server$からの経路~沿いにある，各~cache
］に滞在していた時間の総和と［
~network経路に沿って通過中の時間
］を足したものになる。
◎
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.
</p>

<div class="p">
<p>
`齢$の計算には、
以下に挙げる~dataが利用される
— まず，以下の記述に利用される語の意味を与える：
</p>
<ul>
	<li>
%応答
⇒
齢を計算する対象である，格納-済み応答。
</li>
	<li>
%要請
⇒
%応答 が応対した（ %応答 を格納-済みにさせた）要請。
【原文の記述からは，はっきりしないが、成功裡に再検証させた要請があれば，それを指すようにも思われる。】
</li>
	<li>
%時計
⇒
当の~cache実装の`時計$。
</li>
</ul>
◎
Age calculation uses the following data:
</div>
<dl>
	<dt>
`齢~値@V
◎
"age_value"
</dt>
	<dd>
%応答 の `Age$h ~headerの値を，算術-演算に適切な形で表す値
— 可用でない場合†は 0。
【† 例えば、最も`上流$にある~cacheが，その応答の再利用を初めて試みるとき】
◎
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.
</dd>

	<dt>
`日時~値@V
◎
"date_value"
</dt>
	<dd>
%応答 の `Date$h ~headerの値を，算術-演算に適切な形で表す値。
この~headerの定義, および それを伴わない応答に関する要件は、
`Date§h を見よ。
◎
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.
</dd>

	<dt>
`現在時@V
◎
"now"
</dt>
	<dd>
%時計 の現在の値。
◎
The term "now" means the current value of this implementation's clock (Section 5.6.7 of [HTTP]).
</dd>

	<dt>
`要請~時刻@V
◎
"request_time"
</dt>
	<dd>
%要請 を受信した時点における， %時計 の値。
◎
The value of the clock at the time of the request that resulted in the stored response.
</dd>

	<dt>
`応答~時刻@V
◎
"response_time"
</dt>
	<dd>
%応答 を受信した時点における， %時計 の値。
◎
The value of the clock at the time the response was received.
</dd>
</dl>

<p>
%応答 の`齢$は、
まったく独立な 2 つの仕方で計算できる：
◎
A response's age can be calculated in two entirely independent ways:
</p>
<ul>
	<li>
`見かけ齢@V
⇒
%時計 と`生成元~server$の`時計$とが，適度にきちんと同期されている場合に限り、
次で与えられる
⇒
`max^op( 0, `応答~時刻$V ~MINUS `日時~値$V )
◎
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.
</li>
	<li>
<p>
`補正済み齢~値@V
⇒
%応答 の経路~沿いにある どの~cacheも `~HTTP11$ 以上を実装する場合に限り、
次で与えられる
⇒
`齢~値$V ~PLUS %応答~遅延；
%応答~遅延 = ( `応答~時刻$V ~MINUS `要請~時刻$V )
</p>

<p>
~cacheは、
この値を［
%応答 を受信した時刻ではなく，
%要請 が起動された時刻
］から相対的に解釈しなければナラナイ。
◎
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.
• apparent_age = max(0, response_time - date_value);
• response_delay = response_time - request_time;
• corrected_age_value = age_value + response_delay;
</p>
	</li>
</ul>

<p>
`補正済み齢~値$V を【下の，結果を与える式に利用される】 `補正済み初期~齢$V に代えて利用してもヨイ。
［
`Age$h を正しく挿入しないかもしれない，ひどく旧い~cache実装
］が在る状況下では、
次のように，より保守的に `補正済み初期~齢$V を計算できる
⇒
`補正済み初期~齢@V = `max^op( `見かけ齢$V, `補正済み齢~値$V )
◎
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_initial_age = max(apparent_age, corrected_age_value);
</p>

<p>
以上により，
%応答 の現在の`齢$（ `現在の齢$V ）を計算できる
— ［
%応答 が`生成元~server$により最後に`検証-$されたとき
］から `補正済み初期~齢$V までの時間（秒）を加算して
⇒＃
`滞在~時間@V = `現在時$V ~MINUS `応答~時刻$V；
`現在の齢@V = `補正済み初期~齢$V ~PLUS `滞在~時間$V
◎
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.
• resident_time = now - response_time;
• current_age = corrected_initial_age + resident_time;
</p>

			</section>
			<section id="serving.stale.responses">
<h4 title="Serving Stale Responses">4.2.4. 非新鮮な応答の~serve法</h4>

<p>
応答が`非新鮮$であるとは、［
明示的な失効時期~情報が在る, または
失効時期の`経験的$な計算が許容されている
］ものであって，`鮮度$の計算に則って`新鮮$でないとされたものになる。
◎
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.
</p>

<p>
~cacheは、
~protocol内の明示的な`~cache指令$
— 例えば，次に挙げる`応答~指令$ —
により禁制されている場合は，
`非新鮮$な応答を`生成-$してはナラナイ
⇒＃
`no-cache$sdir ／
`must-revalidate$sdir ／
適用-可能な `s-maxage$sdir ／
適用-可能な `proxy-revalidate$sdir
◎
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).
</p>

<p>
~cacheは、
次のいずれかに該当する場合を除き，
`非新鮮$な応答を生成してはナラナイ：
◎
A cache MUST NOT generate a stale response unless＼
</p>
<ul>
	<li>
`切断されて$いる
◎
it is disconnected or＼
</li>
	<li>
そうすることが［
`~client$, `生成元~server$
］いずれかにより明示的に許可されている
— 例
⇒＃
`max-stale$qdir 要請~指令により／
`拡張~cache指令$により（ `RFC5861$r に定義されるものなど）／
帯域外の契約に則った環境設定により
◎
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).
</li>
</ul>

			</section>
		</section>
		<section id="validation.model">
<h3 title="Validation">4.3. 検証</h3>

<div class="p">
<p>
~cacheは、［
要請された~URI用の格納-済み応答は 1 個以上~在る
］が，そのどれも~serveできないときは
（例：それらが`新鮮$でないとき, または 1 つに選べないとき（ `4.1§ を見よ））、
要請を回送するときに`条件付き要請$の仕組みを利用して，
`内方$にある次の~serverに次を行う機会を与えることができる：
◎
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＼
</p>
<ul>
	<li>
利用する有効な格納-済み応答を選ぶ。
◎
to choose a valid stored response to use,＼
</li>
	<li>
その処理nにおいて格納-済み~metadataを更新する。
◎
updating the stored metadata in the process, or＼
</li>
	<li>
格納-済み応答（たち）を新たな応答で置換する。
◎
to replace the stored response(s) with a new response.＼
</li>
</ul>

<p>
この処理nは、
格納-済み応答の［
`検証ng^dfn（ `validating^en ） ／
`再検証ng^dfn（ `revalidating^en ）
］として知られている。
◎
This process is known as "validating" or "revalidating" the stored response.
</p>
</div>

			<section id="validation.sent">
<h4 title="Sending a Validation Request">4.3.1. 検証~要請の送信-法</h4>

<p>
~cacheは，`検証$用に`条件付き要請$を`生成-$するときは、
満足しようと試みている要請から開始するか，
あるいは要請を独立に起動している場合は、
格納-済み応答を利用して要請を合成する
— ［
`~method$,
`~target~URI$,
`Vary$h ~headerにより識別される要請~headerたち（ `4.1§ ）
］を複製することにより。
◎
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).
</p>

<p>
次に、
1 つ以上の`事前条件~header$で，その要請を更新する。
これらは、
同じ~URIを持つ格納-済み応答（たち）を~sourceとする`検証子$~metadataを包含する。
これは概して、
同じ`~cache~key$を伴う格納-済み応答に限り含むことになる
— ~cacheには、［
自身が送信している要請~headerでは選べない応答
］を検証することも許容されるが
（ `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).
</p>

<p>
次に，`事前条件~header$は、
各`受信者$により［
`資源$の現在の`表現$に等価な格納-済み応答は在るかどうか
］を決定するために比較される。
◎
The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource.
</p>

<p>
そのような`検証子$の一つは、
`Last-Modified$h ~headerにて与えられる時刻印である
— それは、
次に挙げる所で利用できる：
◎
One such validator is the timestamp given in a Last-Modified header field (Section 8.8.2 of [HTTP]),＼
</p>
<ul>
	<li>
応答を`検証-$するためとして，
`If-Modified-Since$h ~header内で。
◎
which can be used in an If-Modified-Since header field for response validation,＼
</li>
	<li>
`表現$を選定するためとして，［
`If-Unmodified-Since$h ／ `If-Range$h
］~header内で
（すなわち，`~client$は、
以前に得した［
その時刻印を伴う`表現$
］を特定的に指している）。
◎
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).
</li>
</ul>

<p>
`検証子$には、
`ETag$h ~field内に与えられる`実体~tag$もある。
［
1 個~以上の格納-済み応答を指示する 1 個~以上の`実体~tag$
］は、
次に挙げる所で利用できる：
◎
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＼
</p>
<ul>
	<li>
応答を`検証-$するためとして，
`If-None-Match$h ~header内で。
◎
in an If-None-Match header field for response validation,＼
</li>
	<li>
`表現$を選定するためとして，［
`If-Match$h ／ `If-Range$h
］~header内で
（すなわち，~clientは、
以前に得した［
~listされた`実体~tag$を伴う， 1 個~以上の`表現$
］を特定的に指している）。
◎
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).
</li>
</ul>

<p>
~cacheは、
格納-済み応答の検証~用に`条件付き要請$を`生成-$するときは：
◎
When generating a conditional request for validation, a cache:
</p>
<ul>
	<li>
［
当の`実体~tag$を供している 1 個以上の格納-済み応答
］を検証しているならば
⇒
関連な`実体~tag$を
（ `If-Match$h, `If-None-Match$h, `If-Range$h いずれかを利用して）
送信しなければナラナイ。
◎
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.
</li>
	<li>
［
当の要請は下位範囲~用ではない【`範囲~要請$ではない】
］かつ［
検証している格納-済み応答は 1 個だけであり、
それは `Last-Modified$h 値を包含する
］ならば
⇒
`Last-Modified$h 値を
（ `If-Modified-Since$h を利用して）
送信するベキである。
◎
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.
</li>
	<li>
［
当の要請は下位範囲~用である
］かつ［
検証している格納-済み応答は 1 個だけであり、
それは `Last-Modified$h 値を包含するが`実体~tag$は包含しない
］ならば
⇒
`Last-Modified$h 値を
（ `If-Unmodified-Since$h, `If-Range$h いずれかを利用して）
送信してもヨイ。
◎
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).
</li>
</ul>

<p>
ほとんどの事例では、
~cache検証~要請~内には，両~検証子とも`生成-$される
— `実体~tag$の方が明瞭に優れるときでも、［
`実体~tag$による事前条件を解さない旧い`媒介者$が適切に応答する
］ことを許容するため。
◎
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.
</p>

			</section>
			<section id="validation.received">
<h4 title="Handling a Received Validation Request">4.3.2. 受信した検証~要請の取扱い</h4>

<p>
要請の`連鎖$沿いにある 各`~client$は，自前の~cacheを備えることもあるので、
`媒介者$における~cacheが［
他の（`外方$にある）~cacheから`条件付き要請$を受信する
］ことは，共通的にある。
同様に，一部の~UAは、
`条件付き要請$を次のために用立てる
⇒＃
近過去に改変された`表現$に対しては，その~data転送を制限する／
`部分的$に検索取得された表現の転送を完了する
◎
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.
</p>

<div class="p">
<p>
要請 %要請 を受信した~cacheは、［
自身に格納-済みな［
`200$st ／ `206$st
］応答 %応答 を `4§ に従って再利用すること
］で %要請 を満足できるならば、［
%要請 内に見出された各 `条件付き要請~header$による`事前条件$のうち，自身に適用-可能なもの
］を［
%応答 が包含している対応する`検証子$
］に対し評価するベキである。
◎
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.
</p>

<p>
~cacheは、
次のいずれかに該当する事前条件は，評価してはナラナイ：
◎
A cache MUST NOT evaluate conditional header fields that＼
</p>
<ul>
	<li>
`生成元~server$に限り適用されるもの
◎
only apply to an origin server,＼
</li>
	<li>
当の要請は、
次のいずれかに該当する
⇒＃
その意味論は、~cache済み応答では満足し得ない／
その`~target資源$用の格納-済み応答は無い
◎
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;＼
</li>
</ul>

<p>
これらの事前条件は、
他の何らかの（`内方$にある）`~server$用に意図されている見込みが高いので。
◎
such preconditions are likely intended for some other (inbound) server.
</p>

</div>

<p>
~cacheによる`条件付き要請$の適正な評価は、［
受信された`事前条件~header$たち, それらの優先順
］に依存する。
要約すると，条件付き~headerのうち［
`If-Match$h, `If-Unmodified-Since$h
］は、
~cacheには適用-可能でなく，
`If-None-Match$h は `If-Modified-Since$h より優先される。
事前条件の優先順についての完全な仕様は、
`HTTP$r `事前条件の優先順＠~HTTPsem#precedence§を見よ。
◎
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.
</p>

<p>
`If-None-Match$h ~headerを包含する要請は、
次を指示する
⇒
`~client$は、
自前の格納-済み応答（たち）と~cacheにより（ `4§ に従って）選ばれる格納-済み応答（たち）とを
— 後者が何であれ —
比較して`検証-$するよう求めている。
◎
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).
</p>

<p>
`If-None-Match$h ~headerは無いが
`If-Modified-Since$h ~headerを包含する要請は、
次を指示する
⇒
`~client$は、
自前の格納-済み応答（たち）について，その改変~日時を`検証-$するよう求めている。
◎
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.
</p>

<p>
要請は `If-Modified-Since$h ~headerを包含するが，格納-済み応答 %応答 内に `Last-Modified$h ~headerは無い場合、
~cacheは， %応答 の `Date$h ~field値
（ `Date^h が無い場合は %応答 を受信した時刻）
を利用して，その`事前条件~header$【！条件付き】を評価するベキである。
◎
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.
</p>

<p>
`範囲~要請$に対する`部分的な応答$を実装する~cacheは、
`Range§h `HTTP$r にて定義されるとおり，
受信した `If-Range$h ~headerを自身が選んだ格納-済み応答に関して評価する必要もある。
◎
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.
</p>

<div class="p">
<p>
~cacheは、［
`If-None-Match$h による`実体~tag$の~list %~tag~list を包含する要請
］用に，［
自前の格納-済み応答たち %応答~群 を`再検証-$する
］ために要請を回送するものと裁定したときは：
◎
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,＼
</p>
<ul>
	<li>
回送する要請の `If-None-Match$h ~headerの`~field値$を次に置換して送信してもヨイ
⇒
%~tag~list と［
%応答~群 を成す各~応答（`新鮮$か否かは問わない）の`実体~tag$からなる~list
］とを結合した結果の和集合
— ただし
⇒
［
各~応答のうち，`部分的$な内容を包含するもの
］の`実体~tag$は、
この和集合から除外しなければナラナイ
— ただし
⇒
要請が`範囲~要請$であり，そのような部分的な応答で全部的に満足されることになる場合は除く
◎
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.＼
</li>
	<li>
回送した要請に対する応答 %応答 が［
`304$st である
］かつ［
`ETag$h ~headerを伴う
］かつ［
その`~field値$は %~tag~list 内に無い`実体~tag$を含む
］場合
⇒
その`実体~tag$に対応する格納-済み応答を再利用しつつ，
%応答 の~metadataでそれを更新した上で（ `4.3.4§ ）、
~clientに対し `200$st 応答を`生成-$しなければナラナイ
◎
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).
</li>
</ul>
</div>

			</section>
			<section id="validation.response">
<h4 title="Handling a Validation Response">4.3.3. 検証~応答【検証~要請に対する応答】の取扱い</h4>

<p>
~cacheによる［
`条件付き要請$に対する応答
］の取扱いは、
その`状態s~code$に依存する：
◎
Cache handling of a response to a conditional request depends upon its status code:
</p>
<ul>
	<li>
状態s~code `304$st は、
格納-済み応答を［
更新できる／再利用できる
］ことを指示する。
◎
A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see Section 4.3.4.
</li>
	<li>
全部的な応答（すなわち，`内容$を伴うもの）は、［
`条件付き要請$内に `nominate^en された【？】，どの格納-済み応答
］も相応でないことを指示する。
代わりに，~cacheは、
要請を満足するためには，その全部的な応答を利用しなければナラナイ。
~cacheは、
そのような全部的な応答を
— `3§ による拘束に従う下で —
格納してもヨイ。
◎
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).
</li>
	<li>
<p>
しかしながら，~cacheは、［
応答の`検証$を試みている間に `5xx$st 応答を受信した
］ときには，次のいずれかを行える：
◎
However, if a cache receives a 5xx (Server Error) response while attempting to validate a response, it can either＼
</p>
		<ul>
			<li>
要請している~clientへ，この `5xx^st0 応答を回送する。
◎
forward this response to the requesting client＼
</li>
			<li>
<p>
~serverが応答-に失敗したかのように動作する。
この場合、
次のいずれかを行える：
</p>
				<ul>
					<li>
以前に格納-済みな応答を
— `4.2.4§ による拘束に従う下で —
送信する。
</li>
					<li>
検証~要請を試行する。
</li>
				</ul>
◎
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.
</li>
		</ul>
	</li>
</ul>

			</section>
			<section id="freshening.responses">
<h4 title="Freshening Stored Responses upon Validation">4.3.4. 検証に際しての，格納-済み応答の新鮮~化法</h4>

<p>
`304$st 応答
— 以下，この節を通して `304 応答^V と記す —
を受信した~cacheは、
格納-済み応答のうち［
`304 応答^V から供される新たな情報
］で更新するのに相応しいものを識別して，それを行う必要がある
— そのような格納-済み応答たちが成す集合は、
次に従って決定される：
◎
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.
</p>
<ol>
	<li>
%初期~集合 ~LET 格納-済み応答のうち［
`4§ の冒頭に与えた要件~listのうち`最後の要件＠#_ecxluded-condition-for-freshening$以外は すべて満たすもの
（すなわち，【最後の要件も満たすならば】 `304 応答^V が応対した要請~用に選ばれ得たもの）
］たちが成す集合
◎
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.
◎
Then, that initial set of stored responses is further filtered by the first match of:
</li>
	<li>
<p>
~IF［
`304 応答^V は 1 個以上の
<dfn>`強い検証子$</dfn>
を包含する
（これらの各~検証子は、［
更新-対象になる，ある`選定された表現$
］を識別する）
］
⇒
~RET %初期~集合 を成す応答のうち［
`304 応答^V が包含する いずれかの`強い検証子$と同じ`強い検証子$を伴うもの
］たちが成す集合
◎
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.＼
</p>

<p>
該当するものが無い場合（すなわち、空~集合を返す）、
`304 応答^V を格納-済み応答の更新に利用してはナラナイ。
【この要件は、以下において空~集合を返す段には指定されていない。】
◎
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.
</p>
	</li>
	<li>
~IF［
`304 応答^V は 1 個以上の
<dfn>`弱い検証子$</dfn>
を包含する
］
⇒
~IF［
%初期~集合 を成す応答として［
`304 応答^V が包含する いずれかの`弱い検証子$に合致するもの
］は在る
］
⇒
~RET ［
該当する応答のうち，最も近過去なもの
］たちが成す集合
◎
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.
</li>
	<li>
~ELSE
（ `304 応答^V は`検証子$を内包しない
— 例： `304 応答^V が応対した要請は、
`~client$が `Last-Modified$h 応答~header以外の~sourceから`生成-$した
`If-Modified-Since$h 要請である）
⇒
~IF［
%初期~集合 を成す【！格納-済み】応答は 1 個だけであり，それも`検証子$を欠如する
］
⇒
~RET %初期~集合
◎
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.
</li>
	<li>
~RET 空~集合
◎
↑</li>
</ol>

<p>
~cacheは、
上で決定した［
更新-対象として識別された格納-済み応答たちが成す集合
］を成す各 %応答 に対し
⇒
`3.2§ に従う下で，［
`304 応答^V 内に供された各~header
］を利用して［
%応答 内の各~header
］を更新しなければナラナイ。
◎
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.
</p>

			</section>
			<section id="head.effects">
<h4 title="Freshening Responses with HEAD">4.3.5. `HEAD^m による応答の新鮮~化法</h4>

<div class="p">
<p>
`HEAD$m ~methodに対する応答は、
`内容$を送信しないことを除き，［
`GET$m を伴って為される等価な要請
］に対する応答と一致する。
この `HEAD$m 応答の特質を、
次の場合に［
~cacheされた `GET$m 応答を無効化したり更新する
］ことに利用できる：
◎
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＼
</p>
<ul>
	<li>
より効率的な条件付き `GET$m 要請の仕組みが
（格納-済み応答~内に`検証子$が無いことに因り）
可用でない場合。
◎
if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or＼
</li>
	<li>
`内容$が変化したときでも，その伝送は欲されない場合。
◎
if transmission of the content is not desired even if it has changed.
</li>
</ul>
</div>

<p>
~cacheは、
ある`~target~URI$用に`内方$へ `HEAD$m 要請を為したとき，
それに対し `200$st 応答
— 以下 `HEAD 応答^V と記す —
を受信したときは、
自身に格納-済みな［
当の要請~用に選ばれ得た
（ `4.1§ を見よ），各［
`GET$m に対する応答
］ %応答
］を以下に従って［
更新するか, 無効化する
］ベキである：
◎
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).
◎
For each of the stored responses that could have been chosen,＼
</p>
<ol>
	<li>
<p>
~AND↓ が満たされるならば、
下に述べるとおりに %応答 を更新するベキである：
</p>
		<ul>
			<li>
受信したどの`検証子~field$
（ `ETag$h, `Last-Modified$h ）
に対しても，
%応答, `HEAD 応答^V には その~headerが在って, 両者の値は合致する。
</li>
			<li>
`HEAD 応答^V, %応答 には `Content-Length$h ~headerが在って, 両者の値は合致する。
</li>
		</ul>
◎
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;＼
</li>
	<li>
他の場合、
%応答 は`非新鮮$であると見なすベキである。
◎
otherwise, the cache SHOULD consider the stored response to be stale.
</li>
</ol>

<p>
~cacheは， %応答 を `HEAD 応答^V 内に供された~metadataで更新する場合には、
`3.2§ に従う下で，［
`HEAD 応答^V 内に供された各~header
］を利用して［
%応答 内の各~header
］を更新しなければナラナイ。
◎
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).
</p>

			</section>
		</section>
		<section id="invalidation">
<h3 title="Invalidating Stored Responses">4.4. 格納-済み応答の無効化-法</h3>

<p>
［
`PUT$m, `POST$m, `DELETE$m
］などの`安全$でない要請~methodは，
`生成元~server$上の【資源の】状態を変更する~~可能性があるので、
介在している~cacheは，格納-済みな応答を無効化して自身の内容を最新状態に保つことが要求される。
◎
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.
</p>

<div class="p">
<p>
~cacheは、［
`安全$でない／安全かどうか未知である
］要請~methodに対し，`~errorでない応答$を受信したときには：
◎
↓</p>
<ul>
	<li>
その`~target~URI$を`無効化-$しなければナラナイ。
◎
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).
</li>
	<li>
<p>
他の~URIに対しても、
その`生成元$が`~target~URI$のそれと：
</p>
		<ul>
			<li>
一致するならば、
`無効化-$してもヨイ。
特に，［
`Location$h ／ `Content-Location$h
］応答~header（もし在れば）内の~URIは、
無効化の候補になる
— 他の~URIも、
この文書に指定されない仕組みを通して発見されるかもしれない。
</li>
			<li>
一致しないならば、
`無効化-$してはナラナイ。
これは、
~DoS攻撃を防止する一助になる。
</li>
		</ul>
◎
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.
</li>
</ul>
</div>

<p>
所与の~URIを
`無効化-@
（ `invalidate^en ）するとは、
~cacheは，［
格納-済み応答のうち，その`~target~URI$が所与の~URIに合致するもの
］を［
すべて除去する
］か［
すべて “無効” と~markして、
後続な要請に対する応答として送信できるようになる前に，`検証$を義務付ける
］ことを意味する。
◎
"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.
</p>

<p>
`~errorでない応答@
（ `non-error response^en ）とは、
その`状態s~code$は［
`2xx$st ／ `3xx$st
］である応答をいう。
◎
A "non-error response" is one with a 2xx (Successful) or 3xx (Redirection) status code.
</p>

<p class="note">注記：
これは、
~~該当するすべての応答を大域的に無効化することは保証しない。
状態変更~要請が無効化するのは、
それが渡り歩く~cache内の応答に限られることになろう。
◎
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.
</p>

		</section>
	</section>
	<section id="header.field.definitions">
<h2 title="Field Definitions">5. ~field定義</h2>

<p>
この節では、［
~cache法に関係する各種~HTTP`~field$
］の構文と意味論を定義する。
◎
This section defines the syntax and semantics of HTTP fields related to caching.
</p>

		<section id="field.age">
<h3>5.1. `Age^h</h3>

<p>
`Age$h 応答~headerは、
応答の`齢$を伝達する。
それは、
送信者により `4.2.3§ に従って見積もられた［
当の応答が`生成元~server$にて，`生成-$されたか, 成功裡に`検証-$された
］ときからの時間を与える。
◎
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.
</p>

<pre class="bnf">
`Age@p
	= `delta-seconds$p
</pre>

<p>
`Age^h `~field値$は、
秒数を表現する負でない整数である
（ `1.2.2§ を見よ）。
◎
The Age field value is a non-negative integer, representing time in seconds (see Section 1.2.2).
</p>

<p>
`Age^h は`単数~field$として定義されているが、
~cacheは，次に従うベキである：
◎
Although it is defined as a singleton header field,＼
</p>
<ul>
	<li>
~messageに伴われる `Age^h の`~field値$が`~listに基づいて$いる場合、
最初の~memberだけを利用して，後続なものは破棄する。
◎
a cache encountering a message with a list-based Age field value SHOULD use the first member of the field value, discarding subsequent ones.
</li>
	<li>
前項を適用した結果の`~field値$が妥当でない
（例：負でない整数~以外の何かを包含する）
場合、
当の `Age^h ~fieldを無視する。
◎
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.
</li>
</ul>

<p>
【応答の受信者にとっては，】
`Age$h ~headerが在ることは、
この要請に対する応答が，`生成元~server$により［
`生成-$されなかった／`検証-$されなかった
］ことを含意する。
しかしながら、［
`Age$h ~headerの欠如が，生成元に接触したことを含意する
］ことにはならない。
◎
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.
</p>

		</section>
		<section id="field.cache-control">
<h3>5.2. `Cache-Control^h</h3>

<p>
`Cache-Control^h ~headerは、
`~cache指令@
（ `cache directive^en ）†
— ［
要請／応答
］の`連鎖$沿いにある~cacheたちの挙動を制御するための指令 —
を~listするために利用される。
指令は，単方向であり、
要請~内にそれが在っても，対する応答~内に同じ指令が［
在る／複製される
］ことは含意しない。
◎
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.
</p>

<div class="trans-note">
<p>【
単に “指令” とも略称される。
あるいは “`Cache-Control^en 指令” （ “~cache制御~指令” ）と称される箇所もあるが、
この訳では， “~cache指令” と表記する。
［
要請／応答
］内に指定される~cache指令は、［
“`要請~指令$” ／ “`応答~指令$”
］とも称される。
】</p>

</div>

<p>
他所で定義される`~cache指令$の取扱い法についての情報は、
`拡張~cache指令§を見よ。
◎
See Section 5.2.3 for information about how Cache-Control directives defined elsewhere are handled.
</p>

<p>
`~proxy$は、
自身が回送する~message内にある どの`~cache指令$も
— 自身が［
~cacheを実装するかどうか, その指令を有意に~cacheに適用できるかどうか
］に関わらず —
通過させなければナラナイ。
指令は、［
要請／応答
］の`連鎖$沿いにある すべての`受信者$に適用されるかもしれず，
特定の~cacheのみを~targetにできないので。
◎
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.
</p>

<p>
`~cache指令$は、
文字大小無視 `token$p により識別され，省略可能な引数もとり得る。
引数には，［
`token$p, `quoted-string$p
］どちらの構文も利用し得る。
`受信者$は、
この仕様が定義する指令に対しては，
（引数を定義するものであれば）両~構文とも受容する~OUGHT
— 生成においては片方だけが要求されるものもあるが。
◎
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.
</p>

<pre class="bnf">
`Cache-Control@p
	= #`cache-directive$p

`cache-directive@p
	= `token$p [ "=" ( `token$p / `quoted-string$p ) ]
</pre>

<p>
以下に定義される各種`~cache指令$に対しては、
他が言明されない限り，これらの引数は定義されない（許容されない）：
◎
For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.
</p>

			<section id="cache-request-directive">
<h4 title="Request Directives">5.2.1. 要請~指令</h4>

<p>
この節は、
各種~cache要請~指令を定義する。
これらは助言的である
— ~cacheは、
これらを実装してもヨイが，要求されてはいない。
◎
This section defines cache request directives. They are advisory; caches MAY implement them, but are not required to.
</p>

				<section id="cache-request-directive.max-age">
<h5>5.2.1.1. `max-age^qdir</h5>

<p>
引数の構文：
◎
Argument syntax:
</p>

<pre class="bnf">
`delta-seconds$p
</pre>

<p>
`max-age^qdir 要請~指令は、
次を指示する
⇒
`~client$は、
`齢$が指定された秒~数~以下の応答を選好する。
`max-stale^qdir 要請~指令も在る場合を除き、
~clientは，`非新鮮$な応答は受信したくないと望んでいる。
◎
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.
</p>

<p>
この指令は、
引数~構文として `token$p 形
（例： <samp>`max-age^dir=5</samp> ）
を利用する。
送信者は、 `quoted-string$p 形
（例： <samp>`max-age^dir="5"</samp> ）
を`生成-$してはナラナイ。
◎
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.
</p>

				</section>
				<section id="cache-request-directive.max-stale">
<h5>5.2.1.2. `max-stale^qdir</h5>

<p>
引数の構文：
◎
Argument syntax:
</p>

<pre class="bnf">
`delta-seconds$p
</pre>

<p>
`max-stale^qdir 要請~指令は、
次を指示する
⇒
`~client$は、
`鮮度~維持期間$を超過した`非新鮮$な応答を
⇒＃
引数に値が在るならば それに指定された秒~数までは受容する用意がある ／
~ELSE_ `齢$を問わず 受容する
◎
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.
</p>

<p>
この指令は、
引数~構文として `token$p 形
（例： <samp>`max-stale^dir=10</samp> ）
を利用する。
送信者は、 `quoted-string$p 形
（例： <samp>`max-stale^dir="10"</samp> ）
を`生成-$してはナラナイ。
◎
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.
</p>

				</section>
				<section id="cache-request-directive.min-fresh">
<h5>5.2.1.3. `min-fresh^qdir</h5>

<p>
引数の構文：
◎
Argument syntax:
</p>

<pre class="bnf">
`delta-seconds$p
</pre>

<p>
`min-fresh^qdir 要請~指令は、
次を指示する
⇒
`~client$は，［
`鮮度~維持期間$が，指定された秒数を応答の現在の`齢$に足した結果~以上
］である応答を選好する。
すなわち，~clientは、
少なくとも指定された秒~数までは，応答が`新鮮$であり続けるよう求めている。
◎
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.
</p>

<p>
この指令は、
引数~構文として `token$p 形
（例： <samp>`max-fresh^dir=20</samp> ）
を利用する。
送信者は、 `quoted-string$p 形
（例： <samp>`max-fresh^dir="20"</samp> ）
を`生成-$してはナラナイ。
◎
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.
</p>

				</section>
				<section id="cache-request-directive.no-cache">
<h5>5.2.1.4. `no-cache^qdir</h5>

<p>
`no-cache^qdir 要請~指令は、
次を指示する
⇒
`~client$は、［
格納-済み応答は、
`生成元~server$上で成功裡に`検証-$されない限り，要請を満足するために利用しない
］ことを選好する。
◎
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.
</p>

				</section>
				<section id="cache-request-directive.no-store">
<h5>5.2.1.5. `no-store^qdir</h5>

<div class="p">
<p>
`no-store^qdir 要請~指令は、［
`私用~cache$, `共用~cache$
］どちらにも適用され，次を指示する
⇒
~cacheは、［
この要請, 対する応答
］を成す どの部分も “格納してはナラナイ”。
◎
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.＼
</p>

<p>
“格納してはナラナイ” とは、
~cacheは：
◎
"MUST NOT store" in this context means that the cache＼
</p>
<ul>
	<li>
不揮発 記憶域に意図的にその情報を格納してはナラナイ。
◎
MUST NOT intentionally store the information in non-volatile storage and＼
</li>
	<li>
応答を回送したならば、［
アリな限り迅速に，その情報を揮発 記憶域から除去する
］ことに極力努めなければナラナイ。
◎
MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
</li>
</ul>

</div>

<p>
この指令は、
~privacyを確保するための仕組みとして，依拠-可能でも, 足るものでもない。
特に、［
悪意的な~cache／弱体化された~cache
］は，この指令を認識しなかったり順守しないかもしれず、
通信~networkは盗聴に対し脆弱になるかもしれない。
◎
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.
</p>

<p class="note">注記：
この指令を包含する要請が，~cacheに格納-済みな応答により満足された場合、
`no-store^qdir 要請~指令は，その格納-済み応答には適用されない。
◎
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.
</p>

				</section>
				<section id="cache-request-directive.no-transform">
<h5>5.2.1.6. `no-transform^qdir</h5>

<p>
`no-transform^qdir 要請~指令は、
次を指示する
⇒
`~client$は、
`内容$を`形式変換-$するのは避けるよう，`媒介者$たちに依頼している。
◎
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].
</p>

				</section>
				<section id="cache-request-directive.only-if-cached">
<h5>5.2.1.7. `only-if-cached^qdir</h5>

<p>
`only-if-cached^qdir 要請~指令は、
次を指示する
⇒
`~client$は、
格納-済み応答を得することのみを望む。
◎
The only-if-cached request directive indicates that the client only wishes to obtain a stored response.＼
</p>

<p>
この要請を尊守する~cacheは、
その受信に際して，次のいずれかで応答するベキである
⇒
要請による他の拘束に整合な格納-済み応答／
`504$st
◎
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.
</p>

				</section>
			</section>
			<section id="cache-response-directive">
<h4 title="Response Directives">5.2.2. 応答~指令</h4>

<p>
この節は、
各種 ~cache応答~指令を定義する。
~cacheは、
この節に定義される`~cache指令$を順守しなければナラナイ。
◎
This section defines cache response directives. A cache MUST obey the Cache-Control directives defined in this section.
</p>

				<section id="cache-response-directive.max-age">
<h5>5.2.2.1. `max-age^sdir</h5>

<p>
引数の構文：
◎
Argument syntax:
</p>

<pre class="bnf">
`delta-seconds$p
</pre>

<p>
`max-age$sdir 応答~指令は、
次を指示する
⇒
この応答は、
その`齢$が指定された秒~数を超えた後は，`非新鮮$になると見なされる。
◎
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.
</p>

<p>
この指令は、
引数~構文として `token$p 形
（例： <samp>`max-age^dir=5</samp> ）
を利用する。
送信者は、 `quoted-string$p 形
（例： <samp>`max-age^dir="5"</samp> ）
を`生成-$してはナラナイ。
◎
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.
</p>

				</section>
				<section id="cache-response-directive.must-revalidate">
<h5>5.2.2.2. `must-revalidate^sdir</h5>

<p>
`must-revalidate^sdir 応答~指令は、
次を指示する
⇒
~cacheは、
この応答が`非新鮮$になったなら
— それが`生成元~server$により成功裡に`検証-$されるまでは —
別の要請を満足するために再利用してはナラナイ。
◎
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.
</p>

<p>
`must-revalidate^sdir 指令は、
ある種の~protocol特能~用に依拠-可能な運用を~supportするために，必要yである。
~cacheは、
どのような状況下でも， `must-revalidate^sdir 指令を無視してはナラナイ。
特に，~cacheは、
`切断されて$いる場合には
— `非新鮮$になった応答は再利用せずに —
~error応答を`生成-$しなければナラナイ。
`生成-$する`状態s~code$は、
他の~error状態s~codeの方が適切になる場合を除き，
`504$st にするベキである。
◎
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.
</p>

<p>
`~server$が `must-revalidate^sdir 指令を利用するのは、
次のときに限る~OUGHT
⇒
要請の`検証$に失敗した結果が，不正な運用を生じさせ得るとき
— ~~報告もなく実行されなかった金融取引など。
◎
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.
</p>

<p>
`must-revalidate^sdir 指令は、
`共用~cache$が［
`Authorization$h ~headerを包含している要請に対し，応答を再利用する
］ことを許可する
— それは、
再検証に対する要件（ `3.5§ ）の~subjectになる。
◎
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).
</p>

				</section>
				<section id="cache-response-directive.must-understand">
<h5>5.2.2.3. `must-understand^sdir</h5>

<p>
`must-understand^sdir 応答~指令は、
次を指示する
⇒
この応答を格納できる~cacheは、［
その`状態s~code$用の要件を解する, かつ それに適合するもの
］に制限される。
◎
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.
</p>

<p>
`must-understand^sdir を包含する応答は、
`no-store$sdir 指令も包含するベキである。
`must-understand^sdir を実装する~cacheは、
それを内包する応答を受信したときは，［
応答の状態s~codeによる~cache法の要件
］を［
解する，かつ実装する
］ならば `no-store^sdir 指令を無視するベキである。
◎
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.
</p>

				</section>
				<section id="cache-response-directive.no-cache">
<h5>5.2.2.4. `no-cache^sdir</h5>

<p>
引数の構文：
◎
Argument syntax:
</p>

<pre class="bnf">
#`field-name$p
</pre>

<p>
引数を伴わない `no-cache^sdir 応答~指令は、
次を指示する
⇒
この応答は、
`検証$用に回送して成功裡に応答を受信しない限り，
他の要請を満足するために利用してはナラナイ。
◎
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.
</p>

<p>
これにより，`生成元~server$は、［
~cacheが`非新鮮$な応答を送信するよう環境設定されていた
］としても，［
~cacheが~serverに接触しないまま，
その種の応答を要請を満足するために利用する
］ことを防止できるようになる。
◎
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.
</p>

<div class="p">
<p>
`no-cache^sdir 応答~指令が，引数に 1 個~以上の`~field名$を~listしている場合、
次を指示する
⇒
~cacheは、
当の応答に次のいずれかを施したならば，それを
— ~cache法に対する他の制約に従う下で —
後続な要請を満足するために利用してもヨイ：
</p>
<ul>
	<li>
送信する【！subsequent】応答からは、
~listされた~headerすべてを除外する
</li>
	<li>
当の応答は、
`生成元~server$により成功裡に`再検証-$された
（それらの~fieldは、更新されるか除去された）
</li>
</ul>
◎
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).＼
</div>

<p>
これにより，`生成元~server$は、
応答~内における一定の~headerの再利用を
— 応答を成す残りの部分を~cacheするのは許容しつつ —
防止できるようになる。
◎
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.
</p>

<p>
引数に与え得る`~field名$は、
この仕様が定義するものに制限されない。
~field名は、
文字大小無視である。
◎
The field names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
</p>

<p>
この指令は、
引数の構文として `quoted-string$p を利用する
— 送信者は、
`token$p 形を`生成-$するベキでない
（引用符が不要に見える，単独の~entryからなる~listであっても）。
◎
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).
</p>

<p class="note">注記：
引数を伴う `no-cache^sdir 応答~指令は、
~cacheからは，引数を伴わずに受信したかのように取扱われることが多い
— すなわち，引数を伴うものに対する特別な取扱いは、
広く実装されていない。
◎
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.
</p>

				</section>
				<section id="cache-response-directive.no-store">
<h5>5.2.2.5. `no-store^sdir</h5>

<div class="p">
<p>
`no-store^sdir 応答~指令は、［
`私用~cache$, `共用~cache$
］どちらにも適用され，次を指示する：
◎
The no-store response directive indicates that a cache＼
</p>

<ul>
	<li>
~cacheは、［
直の†要請, この応答
］を成す どの部分も格納してはナラナイ。
【† 当の応答が応対した要請が記憶域に残っている場合、それも抹消することと見受けられる。】
◎
MUST NOT store any part of either the immediate request or the response＼
</li>
	<li>
~cacheは、
この応答を利用して他の要請を満足してはナラナイ
◎
and MUST NOT use the response to satisfy any other request.
</li>
</ul>

<p>
格納してはナラナイとは、
~cacheは：
◎
↑This directive applies to both private and shared caches.
◎
"MUST NOT store" in this context means that the cache＼
</p>
<ul>
	<li>
不揮発 記憶域に意図的にその情報を格納してはナラナイ。
◎
MUST NOT intentionally store the information in non-volatile storage and＼
</li>
	<li>
応答を回送したなら、［
アリな限り迅速に，その情報を揮発 記憶域から除去する
］ことに極力努めなければナラナイ。
◎
MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
</li>
</ul>
</div>

<p>
この指令は、
~privacyを確保するための仕組みとして，依拠-可能でも, 足るものでもない。
特に、［
悪意的な~cache／弱体化された~cache
］は，この指令を認識しなかったり順守しないかもしれず、
通信~networkは盗聴に対し脆弱になるかもしれない。
◎
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.
</p>

<p>
`must-understand$sdir ~cache指令は、
一定の状況下においては `no-store^sdir を上書きすることに注意
— `must-understand§sdir を見よ。
◎
Note that the must-understand cache directive overrides no-store in certain circumstances; see Section 5.2.2.3.
</p>

				</section>
				<section id="cache-response-directive.no-transform">
<h5>5.2.2.6. `no-transform^sdir</h5>

<p>
`no-transform^sdir 応答~指令は、
次を指示する
⇒
`媒介者$は（~cacheを実装するかどうかに関わらず）、
この応答の`内容$を`形式変換-$してはナラナイ。
◎
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].
</p>

				</section>
				<section id="cache-response-directive.private">
<h5>5.2.2.7. `private^sdir</h5>

<p>
引数の構文：
◎
Argument syntax:
</p>

<pre class="bnf">
#`field-name$p
</pre>

<p>
引数を伴わない `private^sdir 応答~指令は、
次を指示する：
◎
The unqualified private response directive＼
</p>
<ul>
	<li>
`共用~cache$は、
この応答を格納してはナラナイ
（すなわち、当の応答は，単独の利用者~用に意図されている）。
◎
indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user).＼
</li>
	<li>
`私用~cache$は、
この応答を
— `3§ に定義される拘束に従う下で —
格納してもヨイ
— 他により，［
この応答は、
`私用~cache$により`経験的に~cache可能$でない
］とされていても。
◎
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.
</li>
</ul>

<p>
`private^sdir 応答~指令が，引数に 1 個~以上の`~field名$を~listしている場合、
次を指示する
⇒
単独の利用者に制限されるのは、
~listされた~headerに限られる。
`共用~cache$は、
~listされた~headerを
— それらが元の応答に在っても —
格納してはナラナイが，［
それら以外の，応答~messageを成す残りの部分
］は
— `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.
</p>

<p>
引数に与え得る`~field名$は、
この仕様が定義する それらに制限されない。
~field名は、
文字大小無視である。
◎
The field names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
</p>

<p>
この指令は、
引数の構文として `quoted-string$p を利用する：
送信者は `token$p 形を`生成-$するベキでない
（引用符が不要に見える，単独の~entryからなる~listであっても）。
◎
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).
</p>

<p class="note">注記：
この単語 “私用（ `private^en ）” の用法は、
応答を格納できるかどうかを制御するだけであり，
~message内容の~privacyを確保するものではない。
また，引数を伴う `private^sdir 応答~指令は、
~cacheからは，引数を伴わずに受信したかのように取扱われることが多い
— すなわち，引数を伴うものに対する特別な取扱いは、
広く実装されていない。
◎
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.
</p>

				</section>
				<section id="cache-response-directive.proxy-revalidate">
<h5>5.2.2.8. `proxy-revalidate^sdir</h5>

<p>
`proxy-revalidate^sdir 応答~指令は、
次を指示する
⇒
`共用~cache$は、
この応答が`非新鮮$になったなら
— それが`生成元~server$により成功裡に`検証-$されるまでは —
別の要請を満足するために再利用してはナラナイ。
◎
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.＼
</p>

<p>
これは、
`私用~cache$には適用されないことを除いて，
`must-revalidate$sdir 応答~指令に相似的である。
◎
This is analogous to must-revalidate (Section 5.2.2.2), except that proxy-revalidate does not apply to private caches.
</p>

<p class="note">注記：
`proxy-revalidate^dir それ自体は、
応答は~cache可能であることは含意しない。
例えば， `public$sdir 指令と組合せることで、
応答を~cacheすることは許容しつつ，`共用~cache$に限り［
`非新鮮$なったそれを`再検証-$する
］よう要求することもできる。
◎
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.
</p>

				</section>
				<section id="cache-response-directive.public">
<h5>5.2.2.9. `public^sdir</h5>

<p>
`public^sdir 応答~指令は、
次を指示する
⇒
~cacheは、
この応答を
— `3§ に定義される拘束に従う下で —
格納してもヨイ
— 他により，そうすることは禁制されていても。
◎
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.＼
</p>

<p>
言い換えれば， `public^sdir は、
応答は`~cache可能$であるものと明示的に~markする
— 例えば、
`共用~cache$が［
`Authorization$h ~headerを包含している要請に対する応答
］を再利用すること（ `3.5§ ）も許可する。
◎
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).
</p>

<p class="note">注記：
`3§ に則って~cache可能になる応答には、
`public^sdir 指令が無くても，
【~cache可能にする目的で】 `public^sdir 指令を追加することは必要yでない。
◎
Note that it is unnecessary to add the public directive to a response that is already cacheable according to Section 3.
</p>

<p>
`public^sdir 指令を伴う応答は、
明示的な鮮度~情報が無いならば，`経験的に~cache可能$になる。
◎
If a response with the public directive has no explicit freshness information, it is heuristically cacheable (Section 4.2.2).
</p>

				</section>
				<section id="cache-response-directive.s-maxage">
<h5>5.2.2.10. `s-maxage^sdir</h5>

<p>
引数の構文：
◎
Argument syntax:
</p>

<pre class="bnf">
`delta-seconds$p
</pre>

<p>
`s-maxage^sdir 応答~指令は、
`共用~cache$に対し，次を指示する
⇒
この指令が指定する最大~齢は、［
`max-age$sdir 指令／ `Expires$h ~header
］により指定された最大~齢を上書きする
◎
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.
</p>

<p>
`s-maxage^sdir 応答~指令は、
`共用~cache$に対しては，
`proxy-revalidate$sdir 応答~指令の意味論を組入れる。
すなわち，`共用~cache$は、
`s-maxage^dir を伴う`非新鮮$になった応答を
— それが`生成元~server$により成功裡に`検証-$されるまでは —
別の要請を満足するために再利用してはナラナイ。
この指令はまた、
`共用~cache$が［
`Authorization$h ~headerを包含している要請に対し，応答を再利用する
］ことも許可する
— それは、［
上述した最大~齢に対する要件, 再検証に対する要件（ `3.5§ ）
］の~subjectになる。
◎
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).
</p>

<p>
この指令は、
引数~構文として `token$p 形
（例： <samp>`s-maxage^dir=10</samp> ）
を利用する。
送信者は、 `quoted-string$p 形
（例： <samp>`s-maxage^dir="10"</samp> ）
を`生成-$してはナラナイ。
◎
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.
</p>

				</section>
			</section>
			<section id="cache.control.extensions">
<h4 title="Extension Directives">5.2.3. 拡張~cache指令</h4>

<p>
`Cache-Control$h ~headerは、
1 個~以上の拡張`~cache指令$の利用を通して拡張できる。
~cacheは、
認識できない`~cache指令$を無視しなければナラナイ。
◎
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.
</p>

<p>
拡張のうち，~cacheの挙動における変更を要求しないもの（ “`informational^en” 拡張）は、
他の指令の意味論を変更することなく，追加できる。
◎
Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics of other directives.
</p>

<div class="p">
<p>
挙動を変更する拡張（ “`behavioral^en” 拡張）は、
既存の`~cache指令$に基づく挙動に対する改変子として動作するように設計されている
— すなわち，新旧 両~指令が給されたときは、
次のようになる：
◎
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＼
</p>
<ul>
	<li>
新~指令を解さない応用は、
既定で，旧~指令により指定される挙動になる。
◎
applications that do not understand the new directive will default to the behavior specified by the old directive, and＼
</li>
	<li>
新~指令を解する応用は、
それを，旧~指令に結付けられた要件を改変するものとして認識する。
◎
those that understand the new directive will recognize it as modifying the requirements associated with the old directive.＼
</li>
</ul>

<p>
このようにして、
配備-済みな~cacheを非互換化することなく，既存の~cache指令を拡張できるようになる。
◎
In this way, extensions to the existing cache directives can be made without breaking deployed caches.
</p>
</div>

<div class="example">
<p>
例えば、
`community^dir と呼ばれる，新たな応答~指令を仮に考える。
それは，［
`private$sdir 指令に対する改変子
］として動作し、
`私用~cache$に加えて，［
ある “community” の~memberたちに`共有-$される~cache
］に限り［
応答を~cacheすることが許容される
］とする。
`生成元~server$は、［
“UCI” community が，彼らの`共用~cache$において［
さもなければ `private$sdir になるような応答
］を利用する
］ことを許容したいと望むなら、
次のように［
`UCI^c を値にとる `community^dir
］を含ませる：
◎
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
</p>

<pre class="lang-http">
Cache-Control: private, community="UCI"
</pre>

<p>
そのような拡張`~cache指令$ `community^dir を認識する~cacheは、
それに則って，自身の挙動を広げられる。
`community^dir ~cache指令を認識しない~cacheは、
それを無視して，
`private$sdir 指令を固守することになる。
◎
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.
</p>
</div>

<p>
新たな拡張~cache指令は、
次を定義することを考慮する~OUGHT：
◎
New extension directives ought to consider defining:
</p>
<ul>
	<li>
その指令が複数~個 指定されたとき，何を意味するか？
◎
What it means for a directive to be specified multiple times,
</li>
	<li>
その指令が引数をとらないのは いつか？
引数が在るときは何を意味するか？
◎
When the directive does not take an argument, what it means when an argument is present,
</li>
	<li>
その指令が引数を要求するのは いつか？
引数を欠くときは何を意味するか？
◎
When the directive requires an argument, what it means when it is missing, and
</li>
	<li>
その指令は［
要請, 応答
］どちらかのみに特有か？
あるいは どちらにも利用-可能か？
◎
Whether the directive is specific to requests, specific to responses, or able to be used in either.
</li>
</ul>

			</section>
			<section id="cache.directive.registry">
<h4 title="Cache Directive Registry">5.2.4. ~cache指令~registry</h4>

<p>
`~cache指令$用の名前空間を定義するための
`~HTTP~cache指令~registry$cite
が、
新たに作成され，保守されている。
◎
The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at &lt;https://www.iana.org/assignments/http-cache-directives&gt;.
</p>

<p>
登録にあたっては，次の~fieldを含めなければナラナイ：
◎
A registration MUST include the following fields:
</p>
<ul>
	<li>
当の`~cache指令$の名前
◎
Cache Directive Name
</li>
	<li>
仕様~textへの~pointer
◎
Pointer to specification text
</li>
</ul>

<p>
この名前空間に追加される値は
`~IETFによる考査$を要する。
◎
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
</p>

			</section>
		</section>
		<section id="field.expires">
<h3>5.3. `Expires^h</h3>

<p>
`Expires^h 応答~headerは、［
当の応答は，それ以降は`非新鮮$になる
］と見なされる［
日時／時刻
］を与える。
鮮度~modelについての更なる論点は、
`鮮度§を見よ。
◎
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.
</p>

<p>
`Expires^h ~headerが在っても、
元の`資源$が，その時刻を境に［
変化する／それまでは存在する／その後には存在しなくなる
］ことは含意しない。
◎
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.
</p>

<p>
`Expires^h `~field値$は、
`HTTP-date$p による時刻印をとる。
~cacheに特有な構文解析~要件については、
`鮮度§も見よ。
◎
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.
</p>

【！ Errata ID: 4479 Rejected 】

<pre class="bnf">
`Expires@p
	= `HTTP-date$p
</pre>

<div class="example">
<p>
例：
◎
For example
</p>

<pre class="lang-http">
Expires: Thu, 01 Dec 1994 16:00:00 GMT
</pre>

</div>

<p>
~cache`受信者$は、
形式が無効な日時を，値 "`0^c" に解釈しなければナラナイ
— これは、
過去の時刻を表現する
（すなわち， “すでに失効した”）。
◎
A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
</p>

<p>
応答が `max-age$sdir 指令を伴う `Cache-Control$h ~headerを内包する場合、
`受信者$は `Expires^h ~headerを無視しなければナラナイ。
同様に，応答が `s-maxage$sdir 指令を内包する場合、
`共用~cache$受信者は， `Expires^h ~headerを無視しなければナラナイ。
いずれの場合も、
`Expires^h の値は，もっぱら［
`Cache-Control$h ~headerをまだ実装していない`受信者$
］用に意図されたものである。
◎
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.
</p>

<div class="p">
<p>
`時計$を備えていない`生成元~server$は、
`Expires^h ~headerを`生成-$してはナラナイ
— ただし、
それが次に挙げるいずれかの値をとる場合は除く：
◎
An origin server without a clock (Section 5.6.7 of [HTTP]) MUST NOT generate an Expires header field unless its value＼
</p>
<ul>
	<li>
過去の固定的な時刻を表現する
（ “常に，すでに失効した” ）。
◎
represents a fixed time in the past (always expired) or＼
</li>
	<li>
`時計$を備える~systemにより，`資源$に結付けられた値。
◎
its value has been associated with the resource by a system with a clock.
</li>
</ul>
</div>

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

		</section>
		<section id="field.pragma">
<h3>5.4. `Pragma^h</h3>

<p>
`Pragma^h 要請~headerは、
~HTTP10~cache用に定義された
— `~client$が， “no-cache” 要請も指定できるようにするために
（ `Cache-Control$h が定義されたのは、 ~HTTP11 になってからなので）。
◎
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).
</p>

<p>
しかしながら、
`Cache-Control$h の~supportは，今や広く行き渡っている。
よって、
この仕様は `Pragma^h を非推奨にする。
◎
However, support for Cache-Control is now widespread. As a result, this specification deprecates Pragma.
</p>

<p class="note">注記：
応答においては、
<code>Pragma: `no-cache^dir</code>
の意味が指定されることは決してない
— それは，応答における
<code>Cache-Control: `no-cache$sdir</code>
に代わる依拠-可能な置換を供さない。
◎
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.
</p>

		</section>
		<section id="field.warning">
<h3>5.5. `Warning^h</h3>

<p>
`Warning^h ~headerは、［
`状態s~code$内に反映されないこともあるような，~messageの状態sや`形式変換$についての追加的な情報
］を運ぶために利用されていた。
この仕様は、
これを廃用にする
— 広く`生成-$されたり, 利用者が面するものではないので。
それが運んでいた情報は、
`Age$h などの他の~headerを精査すれば拾える。
◎
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.
</p>

		</section>
	</section>
	<section id="history.lists">
<h2 title="Relationship to Applications and Other Caches">6. 応用／他の~cacheとの関係性</h2>

<p>
~HTTPを利用している応用は、
追加的な形を成す~cache法を指定することが多い。
例えば，~web~browserは、
履歴の仕組みを備えることが多い
— ある~sessionにおいて，~~以前に検索取得した表現を表示し直すような、
“戻る” ~buttonを利用できるなど。
◎
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.
</p>

<p>
同様に，~page~viewの中の画像 その他の~assetの~cache法を実装する~Web~browserもある
— それらには、
~HTTP~cache法の意味論を尊守するものも，しないものもある。
◎
Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics.
</p>

<p>
この仕様における要件は、［
応用が，~HTTP~cacheから検索取得した~dataを その後どう利用するか
］に適用することは，必要yでない。
例えば
⇒＃
履歴の仕組みは、以前の表現を — それが失効しようが — 表示できる。
応用は、~cacheされた~dataを — それが`鮮度~維持期間$を超えていようが — 他の仕方で利用できる。
◎
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.
</p>


<p>
この仕様は、
応用が~HTTP~cache法を織り込むことを禁制するものではない
— 例えば，履歴の仕組みは
⇒＃
~viewは非新鮮であることを利用者に~~伝えるかもしれない。
`~cache指令$（例： `Cache-Control: no-store^c ）を尊守するかもしれない。
◎
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).
</p>

<p>
しかしながら，~dataを~cacheする応用は、
そのことを利用者から［
~~明らか／容易に制御-可能
］にしないときは，その~HTTP`~cache指令$に関する運用を［
~cache法の意味論は尊守されるものと期待する作者
］を驚かさないように定義することが強く奨励される。
例えば，［
~HTTPの “~~上層” にある応用~cache
］が［
`Cache-Control: no-store^c を包含している応答
］を［
それを~fetchした要請に直に関係する要請
（同じ~page読込nの間に作成されたものなど）
用に再利用すること
］を許容するように定義することは，適理かもしれないが、［
それとは何ら無関係な要請~用にも再利用すること
］を許容した場合，利用者や作者を驚かすか惑わすことになる見込みが高い。
◎
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.
</p>

	</section>
	<section id="security.considerations">
<h2 title="Security Considerations">7. ~securityの考慮点</h2>

<p>
この節は、［
開発者／情報~provider／利用者
］向けに，［
~HTTP~cache法に特有な，既知な~securityの懸念
］を伝えることが意味される。
より一般な~securityの考慮点は、
`HTTP/1.1$r `~securityの考慮点＠~HTTPv1#security.considerations§,
`HTTP$r `~securityの考慮点＠~HTTPinfra#security.considerations§
にて取組まれている。
◎
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]).
</p>

<p>
~cacheは、
追加的な攻撃~表口を公開する
— ~cache内容は、
悪意的な悪用にとって魅力的な~targetを表現するので。
~cache内容は，~HTTP要請が完了した後も持続するので、
利用者からは~networkから情報が除去されたように見えても，
~cacheに対する攻撃により長期間 情報が露呈され得る。
したがって、
~cache内容は，敏感な情報として保護される必要がある。
◎
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.
</p>

<p>
特に，`私用~cache$は、
単独の利用者に制約されるので，
利用者の活動を構築し直すために利用され得る。
結果として、
それを制御することを末端~利用者に許容すること
— 例：［
一部／すべて
］の`生成元~server$用に格納した応答を除去することを許容するなど —
は，~UAにとって重要になる。
◎
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.
</p>

		<section id="cache.poisoning">
<h3 title="Cache Poisoning">7.1. ~cache汚染</h3>

<p>
~cache内に悪意的な`内容$を格納する攻撃は、
複数の利用者に影響するよう~~拡大され得る。
そのような “~cache汚染” 攻撃は、
攻撃者が［
実装の欠陥, 特権拡大, その他の技法
］を利用して，~cacheの中へ応答を挿入するときに起こる。
これは、［
多数の`~client$に悪意的な`内容$を配布するために，`共用~cache$が利用される
］とき，とりわけ効果的になる。
◎
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.
</p>

<p>
~cache汚染に共通的にある攻撃~行路の一つは、
`~proxy$と`~UA$における~message構文解析-法の相違点を悪用するものである
— ~HTTP11 に関連な要件については、
`HTTP/1.1$r `~message本体の長さ＠~HTTPv1#message.body.length§を見よ。
◎
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.
</p>

		</section>
		<section id="security.timing">
<h3 title="Timing Attacks">7.2. 計時~攻撃</h3>

<p>
~cacheの首な利用の一つは，処理能を最適化することにあるので、
そのような利用は，以前に どの資源が要請されたかについての情報を “漏洩し得る” 。
◎
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.
</p>

<p>
例えば、
利用者がある~site A を訪問して，利用者の~browserが A からの応答をいくつか~cacheしてから，
別の~site B へ~navigateしたとするとき、
~site B は，~site A に存在することが既知な応答を読込もうと試みれる。
それが，~~普段より素早く読込まれた場合、
~site B は，利用者が~site A を
— ~site A のある特定の~pageさえも —
訪問したものと見做せる。
◎
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.
</p>

<p>
そのような “計時~攻撃” は、
~cache~keyにもっと情報を追加することで軽減し得る
— （上に述べた攻撃を防止するために）参照元~site【すなわち~referrer】の同一性を追加するなど。
これは、
“~keyの二重化（ `double keying^en ）” と呼ばれることもある。
◎
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".
</p>

		</section>
		<section id="caching.of.sensitive.information">
<h3 title="Caching of Sensitive Information">7.3. 敏感な情報の~cache法</h3>

<p>
実装や配備における欠陥（~cache運用の誤理解により導かれることが多い）は、
私用と考えられる敏感な情報（例：認証~用の資格証）を~cacheすることへ至らせ，
権限付与されていない主体に公開されるかもしれない。
◎
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.
</p>

<p class="note">注記：
`Set-Cookie$h 応答~header `COOKIE$r は、
~cachingを~~妨げない
— `Set-Cookie$h ~headerを伴う`~cache可能$な応答は、
~cacheに対する後続な要請を満足するために利用できる
（また，利用されることが多い）。
`~server$には、［
これらの応答の~cache法を制御したいとき
］には［
適切な `Cache-Control$h 応答~headerを発する
］ことが奨励される。
◎
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.
</p>

		</section>
	</section>
	<section id="iana.considerations">
<h2 title="IANA Considerations">8. ~IANA考慮点</h2>

<p>
以下に挙げる登録の変更~制御者は、
“~IETF（ iesg@ietf.org, `Internet Engineering Task Force^en ）”
である。
◎
The change controller for the following registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
</p>

		<section id="field.name.registration">
<h3 title="Field Name Registration">8.1. ~field名の登録</h3>

<p>
~IANAは、
`~HTTP~field名~registry$cite
（ `Hypertext Transfer Protocol (HTTP) Field Name Registry^en ）
を
`HTTP$r `18.4＠~HTTPinfra#field.name.registration§に従って更新した
— 次の表tに挙げる~field名を伴うよう：
◎
IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at &lt;https://www.iana.org/assignments/http-fields&gt;, as described in Section 18.4 of [HTTP], with the field names listed in the table below:
</p>

<div>
<table id="iana.header.registration.table"><thead>
<tr><th>~field名
<th>位置付け
<th>§
<th>~comment
<tbody>

<tr><td>`Age^h
<td>`恒久的^i
<td>`5.1§
<td>

<tr><td>`Cache-Control^h
<td>`恒久的^i
<td>`5.2§
<td>

<tr><td>`Expires^h
<td>`恒久的^i
<td>`5.3§
<td>

<tr><td>`Pragma^h
<td>`非推奨d^i
<td>`5.4§
<td>

<tr><td>`Warning^h
<td>`廃用d^i
<td>`5.5§
<td>
</table>
◎
Table 1
Field Name｜Status｜Section｜Comments
Age｜permanent｜5.1｜
Cache-Control｜permanent｜5.2｜
Expires｜permanent｜5.3｜
Pragma｜deprecated｜5.4｜
Warning｜obsoleted｜5.5｜
</div>

		</section>
		<section id="cache.directive.registration">
<h3 title="Cache Directive Registration">8.2. ~cache指令の登録</h3>

<p>
~IANAは、
`~HTTP~cache指令~registry$cite
（ `Hypertext Transfer Protocol (HTTP) Cache Directive Registry^en ）
を
`5.2.4§ の登録~手続-に従って更新した
— 次の表tに要約される指令~名を伴うよう：
◎
IANA has updated the "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" at &lt;https://www.iana.org/assignments/http-cache-directives&gt; with the registration procedure per Section 5.2.4 and the cache directive names summarized in the table below.
</p>

<div>
<table id="iana.cache.directive.registration.table"><thead>
<tr><th>~cache指令
<th>§（要請~用）
<th>§（応答~用）
<tbody>

<tr><td>`max-age^dir
<td>`5.2.1.1§
<td>`5.2.2.1§

<tr><td>`max-stale^dir
<td>`5.2.1.2§
<td>

<tr><td>`min-fresh^dir
<td>`5.2.1.3§
<td>

<tr><td>`must-revalidate^dir
<td>
<td>`5.2.2.2§

<tr><td>`must-understand^dir
<td>
<td>`5.2.2.3§

<tr><td>`no-cache^dir
<td>`5.2.1.4§
<td>`5.2.2.4§

<tr><td>`no-store^dir
<td>`5.2.1.5§
<td>`5.2.2.5§

<tr><td>`no-transform^dir
<td>`5.2.1.6§
<td>`5.2.2.6§

<tr><td>`only-if-cached^dir
<td>`5.2.1.7§
<td>

<tr><td>`private^dir
<td>
<td>`5.2.2.7§

<tr><td>`proxy-revalidate^dir
<td>
<td>`5.2.2.8§

<tr><td>`public^dir
<td>
<td>`5.2.2.9§

<tr><td>`s-maxage^dir
<td>`5.2.2.10§
</table>
◎
Table 2
Cache Directive｜Section
max-age｜5.2.1.1, 5.2.2.1
max-stale｜5.2.1.2
min-fresh｜5.2.1.3
must-revalidate｜5.2.2.2
must-understand｜5.2.2.3
no-cache｜5.2.1.4, 5.2.2.4
no-store｜5.2.1.5, 5.2.2.5
no-transform｜5.2.1.6, 5.2.2.6
only-if-cached｜5.2.1.7
private｜5.2.2.7
proxy-revalidate｜5.2.2.8
public｜5.2.2.9
s-maxage｜5.2.2.10
</div>

		</section>
		<section id="warn.code.registration">
<h3 title="Warn Code Registry">8.3. ~warn-code~registry</h3>

<p>
~IANAは、
`~HTTP~warn-code~registry＠~IANA-a/http-warn-codes$cite
（ `Hypertext Transfer Protocol (HTTP) Warn Codes^en ）
に，［
"`Warning$h" ~headerは廃用にされたこと
］を言明している次の注記を追加した
⇒
<q lang="en">
The Warning header field (and the warn codes that it uses) has been obsoleted for HTTP per [RFC9111].
</q>
【 “~HTTP用の `Warning^h ~header（および，それが利用する `warn-code＠~RFC7234#p.warn-code$p ）は、 `RFC9111^r に従って廃用にされた。” 】
◎
IANA has added the following note to the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at &lt;https://www.iana.org/assignments/http-warn-codes&gt; stating that "Warning" has been obsoleted:
• The Warning header field (and the warn codes that it uses) has been obsoleted for HTTP per [RFC9111].
</p>

		</section>
	</section>
	<section id="collected.abnf">
<h2 title="Collected ABNF">付録 A. 総集的~ABNF</h2>

【この節は未訳。】

	</section>
	<section id="changes.from.rfc.7234">
<h2 title="Changes from RFC 7234">付録 B. RFC 7234 からの変更点</h2>

<p>
［
重複-／競合-
］している~cache指令の取扱いを明確化した。
（ `4.2.1§ ）
◎
Handling of duplicate and conflicting cache directives has been clarified. (Section 4.2.1)
</p>

<p>
~cacheにおける［
`Location$h ／ `Content-Location$h
］~header内の~URIの無効化は、
もはや要求されない
— 依然として許容されるが。
（ `4.4§ ）
◎
Cache invalidation of the URIs in the Location and Content-Location header fields is no longer required but is still allowed. (Section 4.4)
</p>

<p>
~cacheにおける［
`Location$h ／ `Content-Location$h
］~header内の~URIの無効化は、
`生成元$が異なるときは許容されない
— 以前までは、
~hostが異なるときであった。
（ `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)
</p>

<p>
`Age$h ~header［
の値が妥当でない／が複数個ある
］場合の取扱いを明確化した。
（ `Age§h ）
◎
Handling invalid and multiple Age header field values has been clarified. (Section 5.1)
</p>

<p>
この仕様により定義される~cache指令のうち一部は、
今や `quoted-string$p 形による値を`生成-$することは，より強く禁制される
— さもなければ，相互運用能の問題が生じることが見出されたので。
拡張~cache指令の消費器には、［
`token$p, `quoted-string$p
］両~形とも受容することはもはや要求されないが、
未知な拡張に対しては依然として，それらを適正に構文解析する必要がある。
（ `5.2§ ）
◎
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)
</p>

<p>
［
`public$sdir, `private$sdir
］~cache指令を［
どの条件~下でも応答を再利用-可能にしない
］よう明確化した。
【！5.2.2#cache-response-directive】
◎
The public and private cache directives were clarified, so that they do not make responses reusable under any condition. (Section 5.2.2)
</p>

<p>
`must-understand$sdir ~cache指令が導入された。
~cacheには，それが無い場合には、
新たな応答~状態s~codeの意味論を解することは，もはや要求されない。
◎
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)
</p>

<p>
`Warning$h 応答~headerは廃用にされた。
`Warning^h が~supportする情報の大部分は、
応答を精査すれば拾える
— 残りの情報も有用にはなり得るが，全面的に助言的であり、
実施においては，~cacheや`媒介者$は `Warning^h を追加していなかった。
（ `5.5§ ）
◎
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)
</p>

	</section>
	<section id="acks">
<h2 title="Acknowledgements">謝辞</h2>

<p>
`HTTP$r `謝辞＠~HTTPinfra#acks§
を見よ。
◎
See Appendix "Acknowledgements" of [HTTP].
</p>

	</section>
	<section id="rfc.authors">
<h2 title="Authors' Addresses">著作者の~address</h2>

<p>
`HTTP$r `著作者の~address＠~HTTPinfra#rfc.authors§
と同じ【なので、この訳では省略する】。
</p>

	</section>
</main></div>