RFC7234-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>RFC 7234 — HTTP/1.1: 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="RFC723X.js"></script>
<script src="common1.js" async></script>

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


●●options

spec_title:RFC 7234 — HTTP/1.1: Caching
trans_update:2019-10-29
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc7234.html
spec_status:IETFPR
abbr_url:7234
no_original_dfn:true
trans_1st_pub:2014-12-07

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

●●link_map

	●指令

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
qdir.stale-if-error:~RFCx/rfc5861#section-4

sdir.max-age:#cache-response-directive.max-age
sdir.must-revalidate:#cache-response-directive.must-revalidate
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
sdir.stale-if-error:~RFCx/rfc5861#section-4
sdir.stale-while-revalidate:~RFCx/rfc5861#section-3

	●warn-code

wc.1xx:#warn.1xx
wc.2xx:#warn.2xx
wc.110:#warn.110
wc.111:#warn.111
wc.112:#warn.112
wc.113:#warn.113
wc.199:#warn.199
wc.214:#warn.214
wc.299:#warn.299

	110:Response is Stale
	111:Revalidation Failed
	112:Disconnected Operation
	113:Heuristic Expiration
	199:Miscellaneous Warning
	214:Transformation Applied
	299:Miscellaneous Persistent Warning


検証:#validating
	#section-4.3
検証する:#validating
検証され:#validating
検証処理:#validating
再検証処理:#revalidating
再検証:#revalidating
再検証する:#revalidating
警告:#header.warning
	validation
新鮮:#fresh
	新鮮であるresponse_is_fresh
非新鮮:#stale
鮮度:#expiration.model
新鮮化-:#serving.stale.responses
	#freshness
鮮度維持期間:#freshness-lifetime
失効~時刻:#expiration-time
明示的な失効~時刻:#explicit-expiration-time
経験的な失効~時刻:#heuristic-expiration-time
経験的な計算:#heuristic.freshness
経験的な:#heuristic-expiration-time
齢:#age
~cache制御 応答~指令:#cache-response-directive
	秒数:#delta-seconds
被選定:#selected-response
被選定~応答:#selected-response
~cache指令:#cache-directive

~cache~key:#cache-key
無効化し:#invalidate
無効化する:#invalidate
無効化:#invalidation
	非~error状態s~code:#non-error-status-code

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

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

共有され:#shared-cache
~cache制御~拡張:#cache.control.extensions
拡張:#cache.control.extensions
	~cache拡張
	#cache-control-extension


●●section_map


1:caching
1.1:conformance
1.2:notation
1.2.1:delta-seconds
2:caching.overview
3:response.cacheability
3.1:incomplete.responses
3.2:caching.authenticated.responses
3.3:combining.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:header.age
5.2:header.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.must-revalidate
5.2.2.2:cache-response-directive.no-cache
5.2.2.3:cache-response-directive.no-store
5.2.2.4:cache-response-directive.no-transform
5.2.2.5:cache-response-directive.public
5.2.2.6:cache-response-directive.private
5.2.2.7:cache-response-directive.proxy-revalidate
5.2.2.8:cache-response-directive.max-age
5.2.2.9:cache-response-directive.s-maxage
5.2.3:cache.control.extensions
5.3:header.expires
5.4:header.pragma
5.5:header.warning
5.5.1:warn.110
5.5.2:warn.111
5.5.3:warn.112
5.5.4:warn.113
5.5.5:warn.199
5.5.6:warn.214
5.5.7:warn.299
6:history.lists
7:iana.considerations
7.1:cache.directive.registry
7.1.1:cache.directive.registry.procedure
7.1.2:cache.directive.considerations
7.1.3:cache.directive.registration
7.2:warn.code.registry
7.2.1:warn.code.registry.procedure
7.2.2:warn.code.registration
7.3:header.field.registration
8:security.considerations
9:acks
10:rfc.references
A:changes.from.rfc.2616
B:imported.abnf
C:collected.abnf


●●words_table1

●●words_table


refresh:::更新::リフレッシュ
reload:::再読み込み::リロード
	＊
canned:

鮮度維持期間:freshness lifetime::~
新鮮:fresh::~
非新鮮:stale::~
新鮮化-:freshen::~
	新鮮化-法:freshening
鮮度:freshness::~

同期調整:skew::~::スキュー
失効:expiration::~
失効時期:expiry::~
切断-:disconnect:~
切離され:disconnectされ:~
検証処理:validating::~
検証子:validator::~
再検証-:revalidate::~
再検証処理:revalidating::~
有効:valid::~
無効化-:invalidate::~
無効化:invalidation::~
再検証:revalidation::~
時間帯:time zone::~
私用:private::~::プライベート
24hours:24 hours:24 時間
	~~経過〜:amount of
秒数:time in seconds:~
足した:plusした:~
齢:age::~

再利用ng:reusing:再利用
下位system:subsystem:下位 system:下位システム
検査ng:checking:検査
一部分:part:~
念頭:mind:~
速く:quickに:~
経過-:pass:~
delta:
補正済み:corrected:~
滞在:resident:~
滞在-:reside:~
現在時:now:~
並替える:reorderする:並び替える
不揮発:non-volatile:~
揮発:volatile:~
通過中:transit 中:~
分解能:resolution:~
略語:abbreviation:~
配布-:distribute:~
魅力的な:attractive:~
抹消:evict:~
最新状態:up to date:~
金融取引:financial transaction:~
最低限の:worst-case:~
割合:fraction:~
不可逆:lossy:~
付随-:accompany:~
返信:reply:~
多用:very use:~
現在:current:~
見かけ:apparent:~
接触-:contact:~
誤理解:misunderstanding:~
増幅-:amplify:~
変形-:transform:~
特質:property:~:::プロパティ
単方向:unidirectional:~
一体化-:unify:~
都合よく:convenientに:~
地域的:local::~::ローカル
置換:replacement:代用
理由付け:reasoning:~
算術-:arithmetic:~
発-:emit:~

●●
~~処理:operation
保持:hold
member
通過:pass through
旧:old
通過中:in transit
~~本質的:essence
逆に:conversely
確からしい:plausible
アリな限り迅速に:as promptly as possible
残りの部分:rest
度を越して:extremely
目的を以って:purposeful
~~訂正:rectify
1 年:one-year
一部分:part
広げられる:broaden:
あり続ける:remain
考えられ:thought
不正になる可能性がある:possible incorrectness introduced
~~妨げ:inhibit
より大きい:greater
問われる:matter
せずに済ませられる:eliminating
一年以内:no more than a year in the future
度を越して:extremely
ずっと早くに:far sooner
have been demonstrated:判っている
緊密に連携する:good internal connectivity
~~可能性:potential
該当する:appropriate
渡り歩く:travels through
境に:before, or after
~~以前に:earlier
欠く:missing
波及-:influence
一助:help
~~確信を持てる:confident in
否定的:negative
過ぎていない:earlier than or equal to
~~挙げられた:nominate
受信された／今の:presented
~~期間time
~~過去:less than
~~未来でない:equal to or earlier than
~~実用的な:sensible
無限:infinity
場合によっては:possibly
度を越して:extremely
全体が収まる:wholly within
作り上げ:make
そのまま書き出:write through
~~対して:with respect to
~~報告もなく実行されなかった:silently unexecuted
目的を以って:purposeful
付け加える~~可能性がある:expose additional potential
ように見えても:believe
全面的に／全く:entirely


●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により PROPOSED STANDARD として公表された，
RFC 7234
<a href="~SPEC_URL">Hypertext Transfer Protocol (HTTP/1.1): Caching</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

公表者
	Internet Engineering Task Force (IETF)
RFC
	7234
廃用
	<a href="https://www.rfc-editor.org/rfc/rfc2616">RFC 2616</a> を廃用にする
	<a href="https://www.rfc-editor.org/rfc/rfc9111">RFC 9111</a> により廃用にされた
分類
	Standards Track
ISSN
	2070-1721
編集
	R. Fielding, Adobe
	M. Nottingham, Akamai
	J. Reschke, greenbytes
日付
	2014 年 6 月
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc7234

</script>

</head>
<body>

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

<div id="MAIN" hidden>

<p class="trans-note">【
この~RFCは、
今や，`現在の~HTTP中核~仕様＠~HTTPcommon#core-specifications$（ ~RFC 9111 ）により廃用にされた。
】</p>

	<section>
◎要約

<p>
~HTTP（ Hypertext Transfer Protocol ）は、分散型の協調的な~hypertext情報~system用の、`~stateless$な~app~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>

	</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 © 2014 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="section-1">
<h2 title="Introduction">1. 序論</h2>

<p>
~HTTPは、概して，分散型の情報~system用に利用され、そこでの処理能は，応答~cacheの利用により改善し得る。
この文書は、`~HTTP11$に関係する，応答~messageの~cachingと再利用ngの側面を定義する。
◎
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages.
</p>

<p>
~HTTP
`~cache@
は、応答~messageの局所的な格納域であり，その中に格納される~messageたちの［
~storage, 検索取得, 削除
］を制御する下位systemである。
~cacheは、未来の等価な要請に対する［
応答~時間や~network帯域幅の消費量
］を抑制するために，~cache可能な応答を格納する。
どの`~client$／`~server$も~cacheを使役してヨイ
— `~tunnel$として動作する~serverは，~cacheを利用できないが。
◎
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 in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel.
</p>

<p>
`共用~cache@
は，複数の利用者により再利用されるような応答を格納する~cacheである
— それは、（常にではないが）通例的に，`媒介者$の一部分として配備される。
対照的に，
`私用~cache@
は、単独の利用者ごとに専用であり，~UAの~componentとして配備されることが多い。
◎
A shared cache is a cache that stores responses to be reused 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>
`~HTTP11$における~cachingの目標は、先立つ応答~messageを再利用して，現在の要請を充足することにより、処理能を有意に改善することである。
【†~cacheに】格納-済みな応答は
— `4.2$sec にて定義されるように —
応答が `検証$（
`生成元~server$による［
この要請~用の~cache済み応答が有効であり続ける
］かどうかの検査ng
）を伴わずに再利用できるとき，`新鮮$であると見なされる。
したがって，`新鮮$な応答は、再利用されるごとに
遅延と~network~overhead
の両者を抑制し得る。
~cache済み応答が`新鮮$でないときでも，［
`検証$により新鮮化できる, または
生成元~serverが可用でない（`4.2.4$sec）
］ときは、依然として再利用できることもある。
◎
The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in Section 4.2, if the response 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 it is reused. When a cached response is not fresh, it might still be reusable if it can be freshened by validation (Section 4.3) or if the origin is unavailable (Section 4.2.4).
</p>

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

		<section id="section-1.1">
<h3 title="Conformance and Error Handling">1.1. 適合性, ~errorの取扱い</h3>

<p>
この文書~内の~keyword "MUST" …
【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】
◎
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
</p>

<p>
適合性の判定基準, および
~errorの取扱いに関する考慮点は、
`7230-2.5$rfc にて定義される。
◎
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
</p>

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

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

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

			<section id="section-1.2.1">
<h4 title="Delta Seconds">1.2.1. ~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 either 2147483648 (2^31) or the greatest positive integer it can conveniently represent.
</p>

<p class="note">注記：
ここでの値 2147483648 は、歴史的な理由による
— それは実質的に無限（ 68 年~以上）を表現する。
この値は~binary形として格納される必要はない
— 実装は、［
その数を直に表現できないような算術-型により計算が遂行される
］ときでも、桁溢れが生じた場合には，~canned文字列†として生産できる。
ここで問われるのは、
桁溢れが検出され，今後の計算において負な値に扱われないことである。
【† 単に，その数を表現する文字列？ または、ある上限~整数を表現する定義済み文字列？】
◎
Note: The value 2147483648 is here for historical reasons, effectively represents infinity (over 68 years), and does not need to be stored in binary form; an implementation could produce it as a canned 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="section-2">
<h2 title="Overview of Cache Operation">2. ~cache運用の概観</h2>

<p>
~cacheを適正に運用することで、~HTTP転送（ `7231$R ）の意味論を保全しつつ，すでに~cache内に保持されている情報については転送しなくて済むようになる。
~HTTPにおける~cachingは，全面的に`任意選択^2119の特能であるが、［
~cache済み応答の再利用ngは望ましいものであり、そのような再利用は，それを防止するような［
要件や局所的な環境設定
］が無ければ，既定の挙動である
］ものと見做せる。
したがって，~HTTP~cacheに課される要件は、~cacheに対し，［
常に，特定0の応答を格納して再利用する
］ことを義務付けるのではなく，［［
再利用できない応答の格納-法 ／
格納-済み応答の不適切な再利用ng
］を防止する
］ことに力点が置かれる。
◎
Proper cache operation preserves the semantics of HTTP transfers ([RFC7231]) while eliminating the transfer of information already held in the cache. 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~entryは、
`~cache~key@,
および 1 個~以上の［
先立つ要請に対応ng~HTTP応答であって，同じ~keyを利用するもの
］からなる。
~cache~entryに最も共通的な形は、検索取得~要請に対する成功裡な結果である：
すなわち，
`GET$m 要請に対する `200$st 応答であって，`要請~target$により識別された`資源$の`表現$を包含するものである。
しかしながら，［
恒久的~redirect【 `301$st 】,
否定的な結果（例： `404$st ）,
`不完全$
【または部分的】
な結果（例： `206$st ）,
`GET$m 以外の~methodに対する応答
］も，その~methodの定義により［
そのような~cachingが許容されていて, かつ
`~cache~key$として利用するに相応しい何かが定義されている
］ならば、~cacheすることはアリである。
◎
Each cache entry consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response to a GET request, which contains a representation of the resource identified by the request target (Section 4.3.1 of [RFC7231]). However, it is also possible to cache permanent 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~key$は、`要請~method$と`~target~URI$からなる。
しかしながら，今日における~HTTP~cacheに共通的にある利用では、概して， `GET$m に対する応答の~cachingに制限されるので、多くの~cacheは，他の~methodを単純に拒み，~URIのみを首な`~cache~key$として利用している。
◎
The primary cache key consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.
</p>

<p>
`要請~target$が，`内容~折衝$の~subjectである場合、その~cache~entryは，複数の格納-済み応答からなることもある
— それぞれが，元の要請の`選定用~header$たちの値による副次的~key（ `4.1$sec ）により，相違化されるような。
◎
If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated by a secondary key for the values of the original request's selecting header fields (Section 4.1).
</p>

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

<p>
~cacheがある要請に対する応答を格納し得るのは、次のいずれも満たされる場合に限られる
— 他の応答は格納してはナラナイ：
◎
A cache MUST NOT store a response to any request, unless:
</p>

<ul>
	<li>
~cacheは、`要請~method$を解する。†
◎
↓</li>
	<li>
要請~methodは、~cache可能であるものと定義されている。
◎
• The request method is understood by the cache and defined as being cacheable, and
</li>
	<li>
~cacheは、`応答~状態s~code$を解する。†
◎
• the response status code is understood by the cache, and
</li>
	<li>
要請~headerに， `no-store$qdir `~cache指令$は出現していない。
◎
↓</li>
	<li>
応答~headerに， `no-store$sdir `~cache指令$は出現していない。
◎
• the "no-store" cache directive (see Section 5.2) does not appear in request or response header fields, and
</li>
	<li>
<p>
~cacheは`共用~cache$でないか, または［
`共用~cache$であって，次のいずれも満たされる
］：
◎
↓</p>
		<ul>
			<li>
応答~内に `private$sdir 応答~指令は出現していない。
◎
• the "private" response directive (see Section 5.2.2.6) does not appear in the response, if the cache is shared, and
</li>
			<li>
要請~内に `Authorization$h ~headerは出現していない
— ただし、応答により明示的に格納-が許容されている場合を除く（`3.2$secを見よ）。
◎
• the Authorization header field (see Section 4.2 of [RFC7235]) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see Section 3.2), and
</li>
		</ul>
	</li>
	<li>
<p>
応答は、次のいずれかを満たす：
◎
• the response either:
</p>
		<ul>
			<li>
`Expires$h ~headerを包含している。
◎
* contains an Expires header field (see Section 5.3), or
</li>
			<li>
`max-age$sdir 応答~指令を包含している。
◎
* contains a max-age response directive (see Section 5.2.2.8), or
</li>
			<li>
`s-maxage$sdir 応答~指令を包含している, かつ ~cacheは`共有され$ている。
◎
* contains a s-maxage response directive (see Section 5.2.2.9) and the cache is shared, or
</li>
			<li>
［
~cacheされることを許容する，`~cache制御~拡張$
］を包含している。
◎
* contains a Cache Control Extension (see Section 5.2.3) that allows it to be cached, or
</li>
			<li>
`状態s~code$により，`既定で~cache可能である$ものと定義されている（`4.2.2$secを見よ）。
◎
* has a status code that is defined as cacheable by default (see Section 4.2.2), or
</li>
			<li>
`public$sdir 応答~指令を包含している。
◎
* contains a public response directive (see Section 5.2.2.5).
</li>
		</ul>
	</li>
</ul>

<p class="note">注記：
上に挙げた，どの要件も，`~cache制御~拡張$により上書きされ得る。
◎
Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3.
</p>

<p>†
この文脈においては、~cacheは，［
`要請~method$／`応答~状態s~code$
を認識した上で，［
指定された，~cachingに関係する挙動
］すべてを実装する
］ならば、それを “解する” とされる。
◎
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="section-3.1">
<h3 title="Storing Incomplete Responses">3.1. 不完全な応答の格納-法</h3>

<p>
応答~messageは［
接続が~closeされるに先立って，~message~frame法（`7230$R）により指示される すべての~octetが受信された
］とき，`完全$であると見なされる。
◎
A response message is considered complete when all of the octets indicated by the message framing ([RFC7230]) are received prior to the connection being closed.＼
</p>

<div class="p">
<p>
~cacheは：
◎
↓</p>

<ul>
	<li>
［
`要請~method$は `GET$m, かつ
`応答~状態s~code$は `200$st, かつ
応答の`~header節$については~~全体が受信された
］場合、その応答を
— その`不完全$な~message本体を不完全であると記録した上で —
~cacheに格納してヨイ。
同様に， `206$st 応答についても、それが不完全な `200$st 応答であったかのように格納してヨイ。
◎
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 an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content) response MAY be stored as if it were an incomplete 200 (OK) cache entry.＼
</li>
	<li>
しかしながら，［［
`Range$h, `Content-Range$h
］~headerを~supportしない
］または［
それらの~headerに利用された`範囲~単位$を解さない
］ならば、内容が［
`不完全$, または`部分的$
］な応答を格納してはナラナイ。
◎
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.
</li>
	<li>
不完全な格納-済み応答を、［
後続な`範囲~要請$を為すことにより得られた成功裡な応答
］を［
`3.3$secにて定義されるように，格納-済みな~entryたちと結合する
］ことにより，完全にしてヨイ。
◎
A cache MAY complete a stored incomplete response by making a subsequent range request ([RFC7233]) and combining the successful response with the stored entry, as defined in Section 3.3.＼
</li>
	<li>
次が満たされない限り、`不完全$な応答を，要請に対する回答として利用してはナラナイ
⇒
［
応答は【前項のように】完全に作り上げられた
］か，または［
要請は`部分的~要請$であって，［
不完全な応答の中に全体が収まるような範囲
］を指定している
］
◎
A cache MUST NOT use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies a range that is wholly within the incomplete response.＼
</li>
	<li>
`部分的~応答$を`~client$に送信するときは、状態s~code `206$st を利用するなどにより，明示的にそうであるものと~markしなければナラナイ。
◎
A cache MUST NOT send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
</li>
</ul>

</div>

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

<p>
`共用~cache$は、［
`Authorization$h ~headerを伴う要請に対する~cache済み応答
］を利用して，後続な要請を充足してはナラナイ
— ただし、応答~内に［
そのような応答を格納することを許容する`~cache指令$
］が在る場合は除く。
◎
A shared cache MUST NOT use a cached response to a request with an Authorization header field (Section 4.2 of [RFC7235]) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
</p>

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

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

		</section>
		<section id="section-3.3">
<h3 title="Combining Partial Content">3.3. 部分的~内容の結合-法</h3>

<p>
応答は、接続が尚早に~closeされた, または
要請が 1 個~以上の `Range$p 指定子を利用した場合に、`部分的$な表現のみを転送することがある。
そのような転送が何度か行われたとき、~cacheは，同じ表現のいくつかの範囲を受信し得る。
~cacheは、これらの範囲を，［
それらすべてが同じ`強い検証子$を共有する, かつ
~cacheが `7233-4.3$rfc による~client要件に準拠する
］ならば、単独の格納-済み応答に結合して，その応答を今後の要請を充足するために再利用してヨイ。
◎
A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers ([RFC7233]). After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in Section 4.3 of [RFC7233].
</p>

<p>
~cacheは、新たな応答と, 1 個~以上の格納-済み応答とを結合するときは，次をしなければナラナイ：
◎
When combining the new response with one or more stored responses, a cache MUST:
</p>

<ul>
	<li>
格納-済み応答~内の［
`warn-code$p `1xx$wc を伴う `Warning$h ~header
］は，すべて削除する。
◎
• delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
</li>
	<li>
格納-済み応答~内の［
`warn-code$p `2xx$wc を伴う `Warning$h ~header
］は，すべて維持する。
◎
• retain any Warning header fields in the stored response with warn-code 2xx; and,
</li>
	<li>
新たな応答~内に供された，他の~header
— ただし， `Content-Range$h は除く —
を用いて、［
格納-済み応答~内の対応ng~headerすべての~instance
］を置換する。
◎
• use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response.
</li>
</ul>

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

<p>
受信された `要請^var に対し、~cacheが，自身に格納-済みな応答（以下，単に `応答^var ）を再利用できるためには、次のすべてが~~満たされなければナラナイ：
◎
When presented with a request, a cache MUST NOT reuse a stored response, unless:
</p>

<ul>
	<li>
`応答^var の `実効~要請~URI$と,  `要請^var に提示されたそれが合致する。
◎
• The presented effective request URI (Section 5.5 of [RFC7230]) and that of the stored response match, and
</li>
	<li>
`応答^var に結付けられた要請~methodは、 `応答^var を `要請^var 用に利用することを許容している。
◎
• the request method associated with the stored response allows it to be used for the presented request, and
</li>
	<li>
`応答^var に~~挙げられた どの`選定用~header$（もしあれば）も，
`要請^var に提示されたそれに合致する（`4.1$secを見よ）
◎
• selecting header fields nominated by the stored response (if any) match those presented (see Section 4.1), and
</li>
	<li>
<p>
`応答^var は成功裡に`検証され$ている, または
次のいずれも満たされる：
</p>
		<ul >
			<li>
`要請^var は、
`no-cache^dir `Pragma$h も
`no-cache$qdir ~cache指令も包含しない。
◎
• the presented request does not contain the no-cache pragma (Section 5.4), nor the no-cache cache directive (Section 5.2.1), unless the stored response is successfully validated (Section 4.3), and
</li>
			<li>
`応答^var は、 `no-cache$sdir 応答~cache指令を包含しない。
◎
• the stored response does not contain the no-cache cache directive (Section 5.2.2.2), unless it is successfully validated (Section 4.3), and
</li>
		</ul>
	</li>
	<li>
<p>
`応答^var は、次のいずれかを満たす：
◎
• the stored response is either:
</p>
		<ul>
			<li>
`新鮮$である。
◎
* fresh (see Section 4.2), or
</li>
			<li>
`非新鮮$であっても~serveすることが許容されている。
◎
* allowed to be served stale (see Section 4.2.4), or
</li>
			<li>
成功裡に`検証され$ている。
◎
* successfully validated (see Section 4.3).
</li>
		</ul>
	</li>
</ul>

<p class="note">注記：
上に挙げた，どの要件も，`~cache制御~拡張$により上書きされ得る。
◎
Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3.
</p>

<p>
~cacheは：
</p>

<ul>
	<li>
`検証$を伴わない要請を充足するために，格納-済み応答を利用するときには、［
格納-済み応答の `現在~齢$var に等しい値にされた `Age$h ~header
］を，応答~内に`生成し$なければナラナイ
— 応答~内にその~headerが在るならそれを置換して。
◎
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には、［
要請が回送されて, 対応ng応答が受信される
］までは、そのような要請に対する返信を`生成する$ことは，許容されない。
◎
A cache MUST write through requests with methods that are unsafe (Section 4.2.1 of [RFC7231]) 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$secを見よ。
◎
Also, note that unsafe requests might invalidate already-stored responses; see Section 4.4.
</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 response (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>
`時計$が可用でないときは、格納-済み応答を，`再検証する$ことなく利用してはナラナイ
— どの利用においても。
◎
A cache that does not have a clock available MUST NOT use stored responses without revalidating them upon every use.
</li>
</ul>

		<section id="section-4.1">
<h3 title="Calculating Secondary Keys with Vary">4.1. `Vary^h による副次的~keyの計算</h3>

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

<ul>
	<li>
<p>
所与の`選定用~header$に対し， 2 つの要請のそれが互いに合致するための必要十分条件は、［
それぞれの要請に，次に挙げるいくつかを適用することにより、一方の要請の`~header値$を他方のそれに変形できるとき
］と定義される：
◎
The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in the second request by applying any of the following:
</p>

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

<p>
格納-済み応答のうち，すべての`選定用~header$について合致するものは、
`被選定~応答@
と呼ばれる。
◎
The stored response with matching selecting header fields is known as the selected response.
</p>

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

<p>
可用な`被選定~応答$が無い場合、~cacheは，提示された要請を充足できない
— その場合、概して，要請~内に示される`生成元~server$へ回送される（場合によっては条件付きにして — `4.3$secを見よ）。
◎
If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin server in a (possibly conditional; see Section 4.3) request.
</p>

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

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

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

<p>
応答の
`鮮度維持期間@
とは、［
それが`生成元~server$により`生成され$た時刻から，その`失効~時刻$まで
］の~~期間である。
`失効~時刻@
とは、それを過ぎて以降は，［
格納-済み応答は、更なる`検証$を伴わない限り，~cacheにより利用できない
］とされる時刻である。
`明示的な失効~時刻@
とは、`生成元~server$が意図する`失効~時刻$である。
一方で，
`経験的な失効~時刻@
とは、`明示的な失効~時刻$が可用でないときに，~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>
応答の
`齢@
とは、`生成元~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" in the cache, 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.8). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation is not likely to change in a semantically significant way before the expiration time is reached.
</p>

<p>
`生成元~server$が、~cacheに対し，毎~要請ごとの`検証$を強制したいときには、過去を~~指す`明示的な失効~時刻$をアテガって，応答がすでに`非新鮮$であることを指示できる。
準拠~cacheは、通常は，`非新鮮$ ~cache済み応答を［
後続な要請~用に再利用する（`4.2.4$secを見よ）
］前に，`検証する$ことになる。
◎
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$secを見よ）。
◎
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>
応答は、次を満たすならば
<dfn id="response_is_fresh">`新鮮$である</dfn>
ものと決定される
⇒
( `鮮度維持期間$var &gt; `現在~齢$var )
◎
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
］`~cache指令$を送信して，対応ng応答に対する`鮮度$の計算を
拘束する／緩める
ことができる。
◎
Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the corresponding response (Section 5.2.1).
</p>

<p>
`日時$の構文解析-法に共通的にある問題を避けるため、~cache`受信者$は，鮮度を計算するときには：
◎
When calculating freshness, to avoid common problems in date parsing:
</p>

<ul>
	<li>
すべての`日時$ 形式は，文字大小区別として指定されているが、［
day, week, time-zone
］の名前†は，文字大小無視で合致させるベキである。
【† `day-name$p, `GMT$p の他に `month$p も含まれる？ 】
◎
• Although all date formats are specified to be case-sensitive, a cache recipient SHOULD match day, week, and time-zone names 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", "`UTC^c"
以外の時間帯 略語
］が伴われた`日時$
］は，無効と見なすベキである。
◎
• A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.
</li>
</ul>

<p class="note">注記：
鮮度が適用されるのは、~cache運用に限られる
— 表示の~refreshや, `資源$の~reloadを~UAに強制する用途には利用できない。
~cacheと履歴の仕組みとの相違点は、`6$secに説明される。
◎
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="section-4.2.1">
<h4 title="Calculating Freshness Lifetime">4.2.1. 鮮度維持期間の計算</h4>

<p>
~cacheは、次のうち，最初に合致する項目による値を利用して，応答の`鮮度維持期間$を計算できる（その計算結果は、
`鮮度維持期間@var
と記される）：
◎
A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of the following:
</p>

<ul>
	<li>
~cacheは`共有され$ている, かつ
`s-maxage$sdir 応答~指令が在る場合
⇒
その値
◎
• If the cache is shared and the s-maxage response directive (Section 5.2.2.9) is present, use its value, or
</li>
	<li>
`max-age$sdir 応答~指令が在る場合
⇒
その値
◎
• If the max-age response directive (Section 5.2.2.8) is present, use its value, or
</li>
	<li>
`Expires$h 応答~headerが在る場合
⇒
(その値) − (`Date$h 応答~headerの値)
◎
• If the Expires response header field (Section 5.3) is present, use its value minus the value of the Date response header field, or
</li>
	<li>
他の場合：
応答~内には`明示的な失効~時刻$は無い。
`経験的な$`鮮度維持期間$が適用-可能になり得る
— `4.2.2$secを見よ。
◎
• Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see Section 4.2.2.
</li>
</ul>

<p class="note">注記：
この計算は，時計~同期調整に脆弱でない
— すべての情報は、`生成元~server$から来るので。
◎
Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.
</p>

<p>
所与の指令~用の値が複数~在る場合（例：
複数の `Expires$h ~header,
複数の "`Cache-Control: max-age^c" 指令）、その指令の値は，無効と見なされる。
~cacheには、［
無効な`鮮度$~情報を持つ応答
］を，`非新鮮$と見なすことが奨励される。
◎
When there is more than one value present for a given directive (e.g., two Expires header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid. Caches are encouraged to consider responses that have invalid freshness information to be stale.
</p>

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

<p>
`生成元~server$は，常に`明示的な失効~時刻$を供するわけではない。
したがって，明示的~時刻が指定されていないときは、~cacheは，［
確からしい`失効~時刻$を見積もる
］ために［
他の~header値（ `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 header field values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case constraints on their results.
</p>

<p>
~cacheは、格納-済み応答~内に`明示的な失効~時刻$が在るときには，`鮮度$を決定する経験則を利用してはナラナイ。
何故なら、`3$sec による要件が実質的に意味するのは、経験則を利用し得るのは，明示的な鮮度を伴わない応答のうち，［
状態s~codeが`既定で~cache可能である$ものと定義された応答, あるいは
明示的に~cache可能であると~markされた応答（例： `public$sdir 応答~指令により）
］のみであることなので。
◎
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, this means that, effectively, heuristics can only be used on responses without explicit freshness whose status codes are defined as cacheable by default (see Section 6.1 of [RFC7231]), and those responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive).
</p>

<p>
応答が `Last-Modified$h ~headerを持つ場合、~cacheには，［
その時刻から現在時までの時区間に対する ある割合
］を超えないような，`経験的な$失効~値を利用することが奨励される。
この割合の代表的な設定は 10% 程度になるであろう。
◎
If the response has a Last-Modified header field (Section 2.2 of [RFC7232]), 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>
`鮮度維持期間$を計算する際に，経験則を利用する~cacheは、応答の `現在~齢$var が~24hoursを超える場合には，応答~内に［
`warn-code$p `113$wc を伴う `Warning$h ~header
］を`生成する$ベキである
— そのような`警告$がすでに在るときは除いて。
◎
When a heuristic is used to calculate freshness lifetime, a cache SHOULD generate a Warning header field with a 113 warn-code (see Section 5.5.4) in the response if its current_age is more than 24 hours and such a warning is not already present.
</p>

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

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

<p>
`Age$h ~headerは、応答~messageが~cacheから得されるとき見積もられた`齢$を伝達するために，利用される。
`Age$h ~headerの値は、~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 response was generated or validated by the origin server. In essence, the Age value is 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 amount of time it has been in transit along network paths.
</p>

<p>
`齢$の計算には次の~dataが利用される：
◎
The following data is used for the age calculation:
</p>

<dl>
	<dt>【まず，以下の記述に用いられている語の意味を補足する：】</dt>
	<dd class="trans-note">
		<dl>
			<dt>`応答^var</dt>
			<dd>
齢を計算する対象の，格納-済み応答。
</dd>
			<dt>`要請^var</dt>
			<dd>
`応答^var を格納-済みにさせた要請。
（原文の記述からは，はっきりしないが、成功裡に再検証させた要請があれば，それを指すようにも思われる。）
</dd>
			<dt>`~host^var</dt>
			<dd>
当該の~cacheを使役している~HTTP通信の参加者。
</dd>
			<dt>`時計^var</dt>
			<dd>
`~host^var に局所的な時計。
</dd>

		</dl>
	</dd>

	<dt>`齢~値@var</dt>
	<dd>
`応答^var の `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>`日時~値@var</dt>
	<dd>
`応答^var の `Date$h ~headerの値を，算術-演算に適切な形で表す値。
`Date$h ~headerの定義, および それを伴わない応答に関する要件は、
`7231-7.1.1.2$rfcを見よ。【！＊】
◎
The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See Section 7.1.1.2 of [RFC7231] for the definition of the Date header field, and for requirements regarding responses without it.
</dd>

	<dt>`現在時@var</dt>
	<dd>
`~host^var がこの計算を遂行している時点での， `時計^var の現在の値。
`~host^var は、 NTP `5905$R, または
何らかの類似な~protocolを利用して， `時計^var を UTC（協定世界時, Coordinated Universal Time ）に同期させる~OUGHT。
◎
The term "now" means "the current value of the clock at the host performing the calculation". A host ought to use NTP ([RFC5905]) or some similar protocol to synchronize its clocks to Coordinated Universal Time.
</dd>

	<dt>`要請~時刻@var</dt>
	<dd>
`要請^var が受信された時点での， `時計^var の値。
◎
The current value of the clock at the host at the time the request resulting in the stored response was made.
</dd>

	<dt>`応答~時刻@var</dt>
	<dd>
`応答^var が受信された時点での， `時計^var の値。
◎
The current value of the clock at the host at the time the response was received.
</dd>
</dl>

<div class="p">
<p>
`応答^var の`齢$は、全く独立な 2 つの仕方で計算できる：
</p>

<ul>
	<li>
`見かけ齢@var = `max^op( 0, `応答~時刻$var − `日時~値$var )
⇒
`時計^var と, `生成元~server$の`時計$とが、適度によく同期されているならば。
【！負な結果は~zeroに置換される。】
</li>
	<li>
`補正済み齢~値@var = `齢~値$var + `応答~遅延^var,<br>
`応答~遅延^var = ( `応答~時刻$var − `要請~時刻$var )
⇒
`応答^var の経路~沿いにある すべての~cacheが，`~HTTP11$を実装するならば。
~cacheは、この値を，［
`応答^var が受信された時刻ではなく， `要請^var が起動された時刻
］から相対的に解釈しなければナラナイ。
</li>
</ul>

◎
A response's age can be calculated in two entirely independent ways:
• 1. the "apparent_age": response_time minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative, the result is replaced by zero.
• 2. the "corrected_age_value", if all of the caches along the response path implement HTTP/1.1. 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;
</div>

<p>
これらは，次のように結合される
⇒
`補正済み初期~齢@var = `max^op( `見かけ齢$var, `補正済み齢~値$var )
◎
These are combined as
• corrected_initial_age = max( apparent_age, corrected_age_value );
</p>

<p>
…ただし、~cacheが `Age$h ~headerの値（ `齢~値$var ）に~~確信を持てる場合（例えば，`応答^var の `Via$h ~header内に~HTTP10を示唆する hop がないなど）には、
`補正済み初期~齢$var の代わりに `補正済み齢~値$var が利用されてヨイ。
◎
unless the cache is confident in the value of the Age header field (e.g., because there are no HTTP/1.0 hops in the Via header field), in which case the corrected_age_value MAY be used as the corrected_initial_age.
</p>

<p>
しかる後、 `応答^var の `現在~齢$var を計算できる
— `応答^var が`生成元~server$により
最後に`検証され$たときから `補正済み初期~齢$var までの~~経過~時間（秒）を加えて
⇒
`滞在~時間@var = `現在時$var − `応答~時刻$var,
`現在~齢@var = `補正済み初期~齢$var + `滞在~時間$var
◎
The current_age of a stored response can then be calculated by adding the amount of 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="section-4.2.4">
<h4 title="Serving Stale Responses">4.2.4. 非新鮮 応答の~serve法</h4>

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

<ul>

	<li>
<p>
~protocol内の明示的な`~cache指令$
— 例えば，次に挙げる指令 —
により禁制されている場合は，`非新鮮$ 応答を`生成し$てはナラナイ：
</p>
		<ul>
			<li>
`no-store$qdir／ `no-cache$qdir 要請~cache指令
</li>
			<li>
`no-store$sdir／ `no-cache$sdir 応答~cache指令
</li>
			<li>
`must-revalidate$sdir 応答~cache指令
</li>
			<li>
適用-可能な `s-maxage$sdir ／ `proxy-revalidate$sdir 応答~cache指令
</li>
		</ul>

◎
A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).
</li>
	<li>
<p>
次の場合を除き、`非新鮮$ 応答を送信してはナラナイ：
◎
A cache MUST NOT send stale responses unless＼
</p>
		<ul>
			<li>
接続が切断されたとき（すなわち，`生成元~server$に接触できない, あるいは【要請を】回送する経路を見出せない）。
◎
it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or＼
</li>
			<li>
そうすることが明示的に許容されているとき（例： `max-stale$qdir 要請~指令により）。
◎
doing so is explicitly allowed (e.g., by the max-stale request directive; see Section 5.2.1).
</li>
		</ul>
	</li>
	<li>
<p >
`非新鮮$ 応答~内には，［
`warn-code$p `110$wcを伴う `Warning$h ~header
］を`生成する$ベキである。
◎
A cache SHOULD generate a Warning header field with the 110 warn-code (see Section 5.5.1) in stale responses.＼
</p>

<p>
同様に，~cacheが
【`内方$から】
切断されている場合は、`非新鮮$ 応答~内に，［
`warn-code$p `112$wc を伴う `Warning$h ~header
］を
【も？】
`生成する$ベキである。
◎
Likewise, a cache SHOULD generate a 112 warn-code (see Section 5.5.3) in stale responses if the cache is disconnected.
</p>
	</li>
	<li>
`Age$h ~headerを持たない応答を回送するときには、応答がすでに`非新鮮$であっても，新たな `Warning$h ~headerを`生成する$ベキでない。
~cacheは、単に通過中に`非新鮮$になった応答は，`検証する$必要はない。
◎
A cache SHOULD NOT generate a new Warning header field when forwarding a response that does not have an Age header field, even if the response is already stale. A cache need not validate a response that merely became stale in transit.
</li>
</ul>

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

<div class="p">
<p>
~cacheが，［
要請された~URI用に 1 つ以上の格納-済み応答を持つ
］が、それらのどれをも~serveできないときは（例：
それらが`新鮮$でないとき, または
1 つに選定できない（ `4.1$sec ）ことから
）、要請を回送する際に，`条件付き要請$の仕組みを利用して、次の`内方$~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 selected; see Section 4.1), it can use the conditional request mechanism [RFC7232] in the forwarded request to give the next inbound server an opportunity＼
</p>

<ul>
	<li>
利用する有効な格納-済み応答を選定する。
◎
to select 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は、格納-済み応答の
— 
`検証処理@ ／ `再検証処理@
として知られている。
◎
This process is known as "validating" or "revalidating" the stored response.
</p>
</div>

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

<p>
~cache`検証$用に`条件付き要請$を送信する~cacheは、［
その格納-済み応答（たち）からの`検証子$~metadata
］を包含している， 1 つ以上の`事前条件~header$を送信する
— しかる後、それらは，`受信者$たちにより［
格納-済み応答が`資源$の現在の`表現$に等価である
］かどうかを決定するために比較される。
◎
When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing validator metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent to a current representation of the resource.
</p>

<p>
そのような`検証子$の一つは、 `Last-Modified$h ~headerにて与えられる時刻印である
— それは、［
応答を`検証する$ために
`If-Modified-Since$h ~headerにて
］, あるいは［
`表現$を選定するために
`If-Unmodified-Since$h ／ `If-Range$h ~headerにて
］，利用できる（すなわち，~clientは、以前に得した［
その時刻印を伴う`表現$
］を，特に指している）。
◎
One such validator is the timestamp given in a Last-Modified header field (Section 2.2 of [RFC7232]), which can be used in an If-Modified-Since header field for response validation, or in an If-Unmodified-Since or If-Range header field for representation selection (i.e., the client is referring specifically to a previously obtained representation with that timestamp).
</p>

<p>
`検証子$には、 `ETag$h ~header内に与えられる `entity-tag$p もある。
1 個~以上の格納-済み応答を指示する 1 個~以上の `entity-tag$p を、［
応答を`検証する$ためとして
`If-None-Match$h ~headerにて
］, あるいは［
`表現$を選定するためとして
`If-Match$h ／ `If-Range$h
~headerにて
］，利用できる（すなわち，~clientは、以前に得した［
~listされた `entity-tag$p を伴う， 1 個~以上の`表現$
］を，特に指している）。
◎
Another validator is the entity-tag given in an ETag header field (Section 2.3 of [RFC7232]). One or more entity-tags, indicating one or more stored responses, can be used in an If-None-Match header field for response validation, or in an If-Match or If-Range header field for representation selection (i.e., the client is referring specifically to one or more previously obtained representations with the listed entity-tags).
</p>

			</section>
			<section id="section-4.3.2">
<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
］応答を再利用することで充足できるような，要請
］を受信したときは、
要請~内に見出された`条件付き~header$による`事前条件$たちのうち：
◎
If a cache receives a request that can be satisfied by reusing one of its stored 200 (OK) or 206 (Partial Content) responses,＼
</p>

<ul>
	<li>
自身に適用-可能なものを，［
`被選定~応答$の中に包含されている対応ng`検証子$たち
］に~~対して`評価-$するベキである
— ただし、
◎
the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators contained within the selected response.＼
</li>
	<li>
<p>
次のいずれかに該当する事前条件は、評価してはナラナイ：
◎
A cache MUST NOT evaluate conditional header fields that are＼
</p>

		<ul>
			<li>
`生成元~server$のみに適用-可能であるもの
◎
only applicable to an origin server,＼
</li>
			<li>
~cache済み応答により充足し得ない意味論を伴うもの
◎
found in a request with semantics that cannot be satisfied with a cached response, or＼
</li>
			<li>
格納-済み応答を持たない~target`資源$に適用されるもの
◎
applied to 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>

	</li>
</ul>
</div>

<p>
~cacheによる`条件付き要請$の適正な評価は、［
受信された`事前条件~header$たち, およびそれらの優先順（ `7232-6$rfc ）
］に依存する。
`If-Match$h ／ `If-Unmodified-Since$h 
条件付き~headerは、~cacheには適用-可能でない。
◎
The proper evaluation of conditional requests by a cache depends on the received precondition header fields and their precedence, as defined in Section 6 of [RFC7232]. The If-Match and If-Unmodified-Since conditional header fields are not applicable to a cache.
</p>

<p>
`If-None-Match$h ~headerを包含する要請は、［
`~client$が，［
1 個~以上の自前の格納-済み応答
］と, ［
~cacheにより格納-済みな`被選定~応答$が何であれ，それら
］とを比較して`検証する$ことを求めている
］ことを指示する。
その`~header値$が［
"`*^c" である, または［
`entity-tag$p の~listであって，そのうち いずれかが［
格納-済みな`被選定~応答$の `entity-tag$p
］に合致する
【すなわち，評価の結果が偽になる】
］］場合、~cache`受信者$は，その合致した応答を送信する代わりに，（その応答の~metadataを利用して，） `304$st 応答を`生成する$ベキである。
◎
A request containing an If-None-Match header field (Section 3.2 of [RFC7232]) indicates that the client wants to validate one or more of its own stored responses in comparison to whichever stored response is selected by the cache. If the field-value is "*", or if the field-value is a list of entity-tags and at least one of them matches the entity-tag of the selected stored response, a cache recipient SHOULD generate a 304 (Not Modified) response (using the metadata of the selected stored response) instead of sending that stored response.
</p>

<div class="p">
<p>
~cacheは、［
`If-None-Match$h による`entity-tag$p の~list（以下， `L^var と記す）を包含する要請
］用に，自前の格納-済み応答たちを`再検証する$と裁定したときには：
◎
When a cache decides 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値を，［
`L^var と［
各［
自前の格納-済み応答（`新鮮$も`非新鮮$も）
］の `entity-tag$p たちからなる~list
］とを結合した結果の和集合
］に置き換えて送信してヨイ
— ただし，
◎
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.＼
</li>
	<li>
`部分的$な内容を包含するような格納-済み応答の `entity-tag$p は、この和集合からは除外しなければナラナイ
— ただし，要請が`範囲~要請$であり，その部分的な格納-済み応答で全部的に充足されることになる場合は除く。
◎
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>
回送した要請に対する応答 `R^var が，［
`304$st である, かつ
`ETag$h ~headerを伴う, かつ
その~header値は `L^var 内に無い `entity-tag$p を含む
］場合、その `entity-tag$p に対応ng格納-済み応答を再利用しつつ,
`R^var の~metadataで更新した上で（`4.3.4$sec）、~clientに対し `200$st 応答を`生成し$なければナラナイ
◎
If the response to the forwarded request is 304 (Not Modified) and has an ETag header 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>

<div class="p">
<p>
`If-None-Match$h ~headerは無いが，
`If-Modified-Since$h ~headerは包含する要請（以下，その~header値に~~供された値による時刻を `時刻印^var と記す）は、［
`~client$が，［
1 個~以上の 自前の格納-済み応答を，改変~日時について`検証する$
］ことを求めている
］ことを指示する。
~cache`受信者$は、［
格納-済みな`被選定~応答$（以下 `R^var と記す）について，次のいずれかが真
］ならば、（ `R^var の~metadataを利用して，） `304$st 応答を`生成する$ベキである：
◎
If an If-None-Match header field is not present, a request containing an If-Modified-Since header field (Section 3.3 of [RFC7232]) indicates that the client wants to validate one or more of its own stored responses by modification date. A cache recipient SHOULD generate a 304 (Not Modified) response (using the metadata of the selected stored response) if one of the following cases is true:＼
</p>

<ul>
	<li>
`R^var は `Last-Modified$h ~headerを持っていて，その値による時刻は `時刻印^var を過ぎていない
◎
1) the selected stored response has a Last-Modified field-value that is earlier than or equal to the conditional timestamp;＼
</li>
	<li>
`R^var は `Last-Modified$h ~headerを持たないが、
`Date$h ~headerは持っていて，その値による時刻は `時刻印^var を過ぎていない
］
◎
2) no Last-Modified field is present in the selected stored response, but it has a Date field-value that is earlier than or equal to the conditional timestamp; or,＼
</li>
	<li>
`R^var は `Last-Modified$h も `Date$h も持たないが、
`R^var は，~cacheにおいて `時刻印^var を過ぎていない時刻に受信されたものと記録されている。
◎
3) neither Last-Modified nor Date is present in the selected stored response, but the cache recorded it as having been received at a time earlier than or equal to the conditional timestamp.
</li>
</ul>

</div>

<p>
`範囲~要請$に対する`部分的~応答$を実装する
~cacheは、
`7233$Rにて定義されるように，
受信された `If-Range$h ~headerを
自身に格納-済みな`被選定~応答$に~~対して評価する必要もある。
◎
A cache that implements partial responses to range requests, as defined in [RFC7233], also needs to evaluate a received If-Range header field (Section 3.2 of [RFC7233]) with respect to its selected stored response.
</p>

			</section>
			<section id="section-4.3.3">
<h4 title="Handling a Validation Response">4.3.3. 検証~応答の取扱い</h4>

<p>
~cacheによる，［
`条件付き要請$に対する応答
］の取扱いは、その状態s~codeに依存する：
◎
Cache handling of a response to a conditional request is dependent upon its status code:
</p>

<ul>
	<li>
`応答~状態s~code$ `304$st は、［
格納-済み応答を，更新できる／再利用できる
］ことを指示する
— `4.3.4$secを見よ。
◎
• A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see Section 4.3.4.
</li>
	<li>
全部的な応答（すなわち，~payload本体を伴うもの）は、［
`条件付き要請$~内に~~挙げられた，どの格納-済み応答
］も，相応でないことを指示する。
代わりに，~cacheは、要請を充足するために，その全部的な応答を利用しなければナラナイ
— また、格納-済み応答（たち）を置換してヨイ。
◎
• A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request is suitable. Instead, the cache MUST use the full response to satisfy the request and MAY replace the stored response(s).
</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, or
</li>
			<li>
~serverが応答-に失敗したかのように動作する。
この場合、以前に格納-済みな応答を送信してヨイ（ `4.2.4$secを見よ）。
◎
act as if the server failed to respond. In the latter case, the cache MAY send a previously stored response (see Section 4.2.4).
</li>
		</ul>
	</li>
</ul>

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

<p>
`304$st 応答（以下，この節を通して `304 応答^var と記す）を受信した~cacheは、同じ`~cache~key$用の格納-済み `200$st 応答が 1 個~以上あるときは（以下，それらの集合を `S^var と記す）、［
`S^var の中のどれが `304 応答^var により更新されるか
］を選定した上で、それらを，
`304 応答^var 内に供された新たな情報を用いて更新する必要がある。
◎
When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored response(s) with the new information provided in the 304 response.
</p>

<p>
更新~対象として選定される格納-済み応答は、 `304 応答^var の検証子に応じて，次で与えられる：
◎
The stored response to update is identified by using the first match (if any) of the following:
</p>

<dl class="switch">
	<dt>
`304 応答^var は`強い検証子$を包含する場合：
◎
• If the new response contains a strong validator (see Section 2.1 of [RFC7232]), then＼
</dt>
	<dd>
その強い検証子が，更新する`選定された表現$を識別する
— すなわち、 `S^var 内の，同じ強い検証子を伴うものすべてが選定される。
◎
that strong validator identifies the selected representation for update. All of the stored responses with the same strong validator are selected.＼
</dd>
	<dd>
そのような格納-済み応答が無い場合、~cacheは， `304 応答^var を どの格納-済み応答の更新にも利用してはナラナイ。
【この記述から、仮に `304 応答^var が弱い検証子も包含していたとしても，次項は適用されないと見られる。】
◎
If none of the stored responses contain the same strong validator, then the cache MUST NOT use the new response to update any stored responses.
</dd>

	<dt>
`304 応答^var は`弱い検証子$を包含する場合：
◎
• If the new response contains a weak validator＼
</dt>
	<dd>
`S^var 内にその検証子に合致するものがあれば、それらのうち最も近過去のものが選定される。
◎
and that validator corresponds to one of the cache's stored responses, then he most recent of those matching stored responses is selected for update.
</dd>

	<dt>
`304 応答^var は`検証子$を含まない場合：
◎
• If the new response does not include any form of validator＼
</dt>
	<dd>
（例えば、~clientが `Last-Modified$h 応答~header以外の~sourceから， `If-Modified-Since$h 要請を`生成し$たなど。）
◎
(such as in the case where a client generates an If-Modified-Since request from a source other than the Last-Modified response header field),＼
</dd>
	<dd>
`S^var が唯一つの格納-済み応答からなる, かつ
その応答も`検証子$を欠如するならば、その応答が選定される。
◎
and there is only one stored response, and that stored response also lacks a validator, then that stored response is selected for update.
</dd>
</dl>

<p>
更新~対象の格納-済み応答が選定されたならば、~cacheは，その各 `応答^var に対し，次をしなければナラナイ：
◎
If a stored response is selected for update, the cache MUST:
</p>

<ol>
	<li>
`応答^var 内の［
`warn-code$p `1xx$wc を伴う
`Warning$h ~header
］は，すべて削除する。
◎
• delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
</li>
	<li>
`応答^var 内の［
`warn-code$p `2xx$wc を伴う `Warning$h ~header
］は，すべて維持する。
◎
• retain any Warning header fields in the stored response with warn-code 2xx; and,
</li>
	<li>
`304 応答^var 内に供された他の各~header `h^var に対し：
`応答^var 内の［
`h^var に対応する~headerの~instanceたち
］を， `h^var で置換する。
◎
• use other header fields provided in the 304 (Not Modified) response to replace all instances of the corresponding header fields in the stored response.
</li>
</ol>

			</section>
			<section id="section-4.3.5">
<h4 title="Freshening Responses via 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, except it lacks a body. 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 representation body is not desired even if it has changed.
</li>
</ul>
</div>

<p>
~cacheが［
所与の`要請~target$用に，`内方$へ `HEAD$m 要請を為して,
`200$st 応答（以下 `HEAD 応答^var と記す）を受信した
］ときは、［
その要請~用に選定し得た，自身に格納-済みな［
`GET$m に対する応答
］］のそれぞれを，更新するか, または無効化するベキである（ `4.1$secを見よ）。
すなわち，…
◎
When a cache makes an inbound HEAD request for a given request target and receives a 200 (OK) response, the cache SHOULD update or invalidate each of its stored GET responses that could have been selected for that request (see Section 4.1).
</p>

<div class="p">
<p>
~cacheは、選定し得た，各 格納-済み応答 `応答^var に対し：
◎
For each of the stored responses that could have been selected,＼
</p>

<ol>
	<li>
<p>
次のいずれも満たされるならば、
下に述べるように `応答^var を更新するベキである：
</p>
		<ul>
			<li>
受信されたどの`検証子~header$（ `ETag$h, `Last-Modified$h ）に対しても，
`応答^var と `HEAD 応答^var は合致する値を持つ。
</li>
			<li>
`HEAD 応答^var も `応答^var も
`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>
他の場合、 `応答^var を`非新鮮$であると見なすベキである。
◎
otherwise, the cache SHOULD consider the stored response to be stale.
</li>
</ol>
</div>

<p>
~cacheが格納-済み応答 `応答^var を，
`HEAD 応答^var 内に供された~metadataで更新するときは、次を行わなければナラナイ：
◎
If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST:
</p>

<ol>
	<li>
`応答^var 内の［
`warn-code$p `1xx$wc を伴う `Warning$h ~header
］は，すべて削除する。
◎
• delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
</li>
	<li>

`応答^var 内の［
`warn-code$p `2xx$wc を伴う `Warning$h ~header
］は，すべて維持する。
◎
• retain any Warning header fields in the stored response with warn-code 2xx; and,
</li>
	<li>
<p>
`HEAD 応答^var 内に供された他の各~header `h^var に対し，
`Cache-Control$h ~headerにより制約されるものは除き：
</p>
		<ol>
			<li>
`応答^var 内に `h^var と同じ名前の~headerたちがあれば，それらを `h^var で置換する。
</li>
			<li>
他の場合、 `応答^var の`~header節$に `h^var を付加する。
</li>
		</ol>
◎
• use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the Cache-Control header field.
</li>
</ol>

			</section>
		</section>
		<section id="section-4.4">
<h3 title="Invalidation">4.4. 無効化</h3>

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

<div class="p">
<p>
~cacheは、［
`安全$でない, または安全かどうか未知である
］ような要請~methodに対する応答~内に，非~error `状態s~code$
— `2xx$st または `3xx$st —
を受信したときには：
</p>

<ul>
	<li>
`実効~要請~URI$を`無効化し$なければナラナイ。
</li>
	<li>
<p>
加えて、要請~methodが`安全$でない場合には：
`Location$h ／ `Content-Location$h
応答~headerによる `URI^var についても，その~host部分が`実効~要請~URI$内の~host部分と、
</p>
		<ul>
			<li>
同じならば：
`URI^var を`無効化し$なければナラナイ。
</li>
			<li>
同じでないならば：
`URI^var を`無効化し$てはナラナイ
— これは、~DoS攻撃を防止する一助になる。
</li>
		</ul>
	</li>
</ul>

◎
A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.
◎
However, a cache MUST NOT invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host part in the effective request URI (Section 5.5 of [RFC7230]). This helps prevent denial-of-service attacks.
◎
A cache MUST invalidate the effective request URI (Section 5.5 of [RFC7230]) when it receives a non-error response to a request with a method whose safety is unknown.
</div>

<div class="p">
<p>
ここでの，~URIを
`無効化する@
とは、~cacheが，［
その~URIに関係する，すべての格納-済み応答
］に対し、次のいずれかを行うことを意味する：
◎
Here, a "non-error response" is one with a 2xx (Successful) or 3xx (Redirection) status code. "Invalidate" means that the cache will either＼
</p>

<ul>
	<li>
それらの応答をすべて除去する。
◎
remove all stored responses related to the effective request URI or＼
</li>
	<li>
それらの応答を “無効” と~markした上で、後続な要請に対する応答として送信できるようになる前に，`検証$を義務付ける。
◎
will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request.
</li>
</ul>

</div>

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

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

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

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

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

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

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

<p>
【応答の受信者にとっては，】
`Age$h ~headerが在ることは、この要請に対する応答が，`生成元~server$により［
`生成され$ていない／`検証され$ていない
］ことを含意する。
しかしながら， `Age$h ~headerを欠如するからといって、生成元が接触されたことを含意するとは限らない
— 応答は， `Age^h を実装しない~HTTP10~cacheから受信されることもあるので。
◎
The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was contacted, since the response might have been received from an HTTP/1.0 cache that does not implement Age.
</p>

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

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

<div class="trans-note">
<p>【†
単に，
`指令^dfn,
`~cache指令^dfn
とも記される。
あるいは
<dfn>`Cache-Control^h 指令</dfn>
とも記される
— 他の仕様が、 
“~cache制御~指令”
を利用する，何らかの他の~headerを定義する可能性も排除されないが。
】【
要請／応答
にて指定される~cache指令は、
`要請~指令^dfn／`応答~指令^dfn
とも記される。
】</p>

</div>

<p>
~cacheは、この節にて定義される，各種 `Cache-Control$h 指令の要件を順守しなければナラナイ。
他所で定義される `Cache-Control$h 指令の取扱い法についての情報は、
`5.2.3$secを見よ。
◎
A cache MUST obey the requirements of the Cache-Control directives defined in this section. See Section 5.2.3 for information about how Cache-Control directives defined elsewhere are handled.
</p>

<p class="note">注記：
~HTTP10~cacheには、 `Cache-Control$h を実装しないものもある。
◎
Note: Some HTTP/1.0 caches might not implement Cache-Control.
</p>

<p>
`~proxy$は、回送される~messageにおける どの`~cache指令$も，通過させなければナラナイ
— ~proxy自身が~cacheを実装するかどうかに関わらず, あるいは
その指令を有意に適用できるかどうかに関わらず —
指令は、要請／応答の`連鎖$沿いにある すべての`受信者$に適用-可能になり得るものであり、特定の~cacheのみを~~適用対象にできないので。
◎
A proxy, whether or not it implements a cache, MUST pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific cache.
</p>

<div class="p">
<p>
`~cache指令$は、文字大小無視 `token$p により識別され，省略可能な引数もとり得る。
引数には，［
`token$p, `quoted-string$p
］のいずれの構文も利用され得る。
`受信者$は：
◎
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.＼
</p>

<ul>
	<li>
この仕様にて定義される指令に対しては、（引数を定義するものであれば）両~構文とも受容する~OUGHT
— 片方が選好されると文書化されているものもあるが。
◎
For the directives defined below that define arguments, recipients ought to accept both forms, even if one is documented to be preferred.＼
</li>
	<li>
この仕様にて定義されない指令に対しては、両~構文とも受容しなければナラナイ。
◎
For any directive not defined by this specification, a recipient MUST accept both forms.
</li>
</ul>
</div>

<pre class="bnf">
`Cache-Control@p
	= 1#`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="section-5.2.1">
<h4 title="Request Cache-Control Directives">5.2.1. 要請 `Cache-Control^h 指令</h4>

				<section id="section-5.2.1.1">
<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 is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept 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 SHOULD NOT generate the quoted-string form.
</p>

				</section>
				<section id="section-5.2.1.2">
<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$は、指定された~~延長~時間まで，`鮮度維持期間$を超過した応答を受容する用意がある
］ことを指示する。
~~延長~時間は、引数に値がアテガわれて［
いるならば それに指定された秒~数 ／
いないならば 無限
］になる。
◎
The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness lifetime. If max-stale is assigned a value, 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 is willing to 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 SHOULD NOT generate the quoted-string form.
</p>

				</section>
				<section id="section-5.2.1.3">
<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 is willing to accept 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 SHOULD NOT generate the quoted-string form.
</p>

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

<p>
`no-cache^qdir 要請~指令は、［
~cacheは、`生成元~server$上での成功裡な`検証$を伴わずに，この要請を充足するために格納-済み応答を利用してはナラナイ
］ことを指示する。
◎
The "no-cache" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server.
</p>

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

<div class="p">
<p>
`no-store^qdir 要請~指令は、
`私用~cache$, `共用~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. "MUST NOT store" in this context means that the cache＼
</p>

<ul>
	<li>
不揮発~storageに意図的にその情報を格納してはナラナイ。
◎
MUST NOT intentionally store the information in non-volatile storage, and＼
</li>
	<li>
それを回送したならば、アリな限り迅速に, その情報を揮発~storageから除去することに極力努めなければナラナイ。
◎
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を確保するための仕組みとして，依拠-可能でも, 足るものでも<strong>ない</strong>。
特に、悪意的な, あるいは弱体化された~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="section-5.2.1.6">
<h5>5.2.1.6. `no-transform^qdir</h5>

<p>
`no-transform^qdir 要請~指令は、［
`媒介者$は（~cacheを実装するかどうかに関わらず），~payloadを`形式変換-$してはナラナイ
］ことを指示する。
◎
The "no-transform" request directive indicates that an intermediary (whether or not it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230].
</p>

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

<p>
`only-if-cached^qdir 要請~指令は、［
`~client$が，格納-済み応答を得することのみを望む
］ことを指示する。
この指令を受信した~cacheは、［
要請による他の拘束に整合な，格納-済み応答
］を利用して応答する, あるいは
`504$st で応答するベキである。
［
緊密に連携し, 一体化された~systemとして運用されている，一群の~cache
］に属する~cacheは、そのような要請を，その~cache群の中で回送してヨイ。
◎
The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache MAY forward such a request within that group of caches.
</p>

				</section>
			</section>
			<section id="section-5.2.2">
<h4 title="Response Cache-Control Directives">5.2.2. 応答 `Cache-Control^h 指令</h4>

				<section id="section-5.2.2.1">
<h5>5.2.2.1. `must-revalidate^sdir</h5>

<p>
`must-revalidate^sdir 応答~指令は、~cacheに対し，［
`非新鮮$になった応答は，［
`生成元~server$上で成功裡に`検証され$ないまま，後続な要請を充足する
］ために利用されてはナラナイ
］ことを指示する。
◎
The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.
</p>

<p>
`must-revalidate^sdir 指令は、ある種の~protocol特能~用に依拠-可能な運用を~supportするために，必要yである。
~cacheは、どのような状況下でも， `must-revalidate^sdir 指令を順守しなければナラナイ
— 特に，~cacheは、何らかの事由で`生成元~server$に到達できない場合には，
`504$st 応答を`生成し$なければナラナイ。
◎
The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.
</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 on the representation could result in incorrect operation, such as a silently unexecuted financial transaction.
</p>

				</section>
				<section id="section-5.2.2.2">
<h5>5.2.2.2. `no-cache^sdir</h5>

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

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

<p>
【引数を伴わない】
`no-cache^sdir 応答~指令は、［
その応答は，［
`生成元~server$上で成功裡に`検証され$ないまま，後続な要請を充足する
］ために，利用されてはナラナイ
］ことを指示する。
これにより，`生成元~server$は、［
~cacheが`非新鮮$ 応答を送信するように環境設定されていたとしても，~cacheが~serverに接触しないまま，要請を充足するために その種の応答を利用する
］ことを，防止できるようになる。
◎
The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it 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 個~以上の`~header名$を指定する場合、~cacheは：
◎
If the no-cache response directive specifies one or more field-names, then＼
</p>

<ul>
	<li>
~cachingに対する他の制約の~subjectの下で、その応答を，後続な要請を充足するために利用してヨイ。
◎
a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching.＼
</li>
	<li>
しかしながら，引数に~listされた どの~headerも、`生成元~server$上での成功裡な`再検証$を伴わないまま，後続な要請に対する応答~内に送信してはナラナイ。
◎
However, any header fields in the response that have the field-name(s) listed MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server.＼
</li>
</ul>

<p>
これにより，`生成元~server$は、応答~内における一定の~headerの再利用を，応答の残りの部分の~cachingは許容しつつ，防止できるようになる。
◎
This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
</p>
</div>

<p>
引数に与え得る~header名は、この仕様にて定義される各種~headerに制限されない。
~header名は、文字大小無視である。
◎
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">注記：
多くの~HTTP10~cacheの実装に移植（ back-port ）されてはいるが、中には，この指令を認識しない, あるいは順守しない~HTTP10~cacheもある。
また、引数をとる【！header名を伴う】 `no-cache^sdir 応答~指令は、~cacheからは，引数なしの【！unqualified】 `no-cache^sdir 指令が受信されたかのように取扱われることが多い
— すなわち，引数~付き【！qualified form】に対する特別な取扱いは、広範に実装されていない。
◎
Note: Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented.
</p>

				</section>
				<section id="section-5.2.2.3">
<h5>5.2.2.3. `no-store^sdir</h5>

<div class="p">
<p>
`no-store^sdir 応答~指令は、
`私用~cache$, `共用~cache$
のいずれにも適用され，［
~cacheは、［
直の†要請 or 応答
］のいずれに対しても，その どの部分も格納してはナラナイ
］ことを指示する。
【† 応答を生じさせた要請が~storageに残っている場合は，それも抹消する？】
【！複製】
— すなわち，~cacheは：
◎
The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache＼
</p>
<ul>
	<li>
不揮発~storageに意図的にその情報を格納してはナラナイ。
◎
MUST NOT intentionally store the information in non-volatile storage, and＼
</li>
	<li>
それを回送したならば、アリな限り迅速に, その情報を揮発~storageから除去することに極力努めなければナラナイ。
◎
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を確保するための仕組みとして，依拠-可能でも, 足るものでも<strong>ない</strong>。
特に、悪意的な, あるいは弱体化された~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>

				</section>
				<section id="section-5.2.2.4">
<h5>5.2.2.4. `no-transform^sdir</h5>

<p>
`no-transform^sdir 応答~指令は、［
`媒介者$は（~cacheを実装するかどうかに関わらず），~payloadを`形式変換-$してはナラナイ
］ことを指示する。
◎
The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230].
</p>

				</section>
				<section id="section-5.2.2.5">
<h5>5.2.2.5. `public^sdir</h5>

<p>
`public^sdir 応答~指令は、［
どの~cacheも，応答を格納してヨイ
］ことを指示する
— 応答が［
通常は~cache可能でない, あるいは
`私用~cache$においてのみ~cache可能である
］ときでも。
（［
`Authorization$h を包含する要請に対する応答
］における `public^sdir の利用に関係する，追加的な詳細は、`3.2$sec を見よ。
［
`状態s~code$が`既定で~cache可能である$と定義されていないことに因り，通常は格納されないような応答（`4.2.2$secを見よ）
］に， `public^sdir がどう影響するかについての詳細は、`3$sec を見よ。）
◎
The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.
(See Section 3.2 for additional details related to the use of public in response to a request containing Authorization, and Section 3 for details of how public affects responses that would normally not be stored, due to their status codes not being defined as cacheable by default; see Section 4.2.2.)
</p>

【！Errata ID: 4616 Rejected】

				</section>
				<section id="section-5.2.2.6">
<h5>5.2.2.6. `private^sdir</h5>

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

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

<p>
`private^sdir 応答~指令は［
応答~messageは、単独の利用者~用に意図されているものであり，`共用~cache$により格納されてはナラナイ
］ことを指示する。
`私用~cache$は、応答を格納して，今後の要請に対しそれを再利用してヨイ
— 応答が通常は~cache可能でないとしても。
◎
The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.
</p>

<p>
`private^sdir 応答~指令に， 1 個~以上の`~header名$が~listされている場合、この要件は，
それらの~header名に結付けられた`~header値$に制限される。
すなわち，`共用~cache$は、それらの~header名を持つ~headerたちを格納してはナラナイ一方で、応答~messageの残りの部分は，格納してヨイ。
◎
If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated with the listed response header fields. That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message.
</p>

<p>
引数に与え得る~header名は、この仕様にて定義される各種~headerに制限されない。
~header名は、文字大小無視である。
【！複製】
◎
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^sdir の利用eは、応答を格納できるかどうかのみを制御する
— それは，~message内容の~privacyを確保するものではない。
また、引数をとる【！header名を伴う】 `private^sdir 応答~指令は、~cacheからは，引数なしの【！unqualified】 `private^sdir が受信されたかのように取扱われることが多い
— すなわち，引数~付き【！qualified】の形に対する特別な取扱いは、広範に実装されていない。
◎
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, private response directives with field-names are often handled by caches as if an unqualified private directive was received; i.e., the special handling for the qualified form is not widely implemented.
</p>

				</section>
				<section id="section-5.2.2.7">
<h5>5.2.2.7. `proxy-revalidate^sdir</h5>

<p>
`proxy-revalidate^sdir 応答~指令は、`私用~cache$には適用されないことを除いて，
`must-revalidate$sdir 応答~指令と同じ意味を持つ。
◎
The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches.
</p>

				</section>
				<section id="section-5.2.2.8">
<h5>5.2.2.8. `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 SHOULD NOT generate the quoted-string form.
</p>

				</section>
				<section id="section-5.2.2.9">
<h5>5.2.2.9. `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
により指定された最大~齢
］を上書きする
］ことを指示する。
`s-maxage^sdir 指令は、 `proxy-revalidate$sdir 応答~指令の意味論も含意する。
◎
The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
</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 SHOULD NOT generate the quoted-string form.
</p>

				</section>
			</section>
			<section id="section-5.2.3">
<h4 title="Cache Control Extensions">5.2.3. ~cache制御~拡張</h4>

<p>
`Cache-Control$h ~headerは［
それぞれが省略可能な値を伴い得るような， 1 個~以上の~cache拡張~token
］の利用を通して拡張できる。
~cacheは、未認識`~cache指令$を無視しなければナラナイ。
◎
The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional value. A cache MUST ignore unrecognized cache directives.
</p>

<p>
~cacheの挙動~変更-を要求しない拡張（ “informational” 拡張）
を、他の指令の意味論を変更することなく，追加できる。
◎
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” 拡張）は、［
既存の`~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>
新~指令を解さない~appは、既定で，旧~指令により指定される挙動になる。
◎
applications that do not understand the new directive will default to the behavior specified by the old directive, and＼
</li>
	<li>
新~指令を解する~appは、それを，旧~指令に結付けられた要件を改変するものとして認識する。
◎
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-control directives can be made without breaking deployed caches.
</p>
</div>

<div class="example">
<p>
例えば，
`private$sdir 指令に対する改変子として動作する，
`community^dir と呼ばれる，新たな応答~指令を仮に考える：
それは、`私用~cache$に加えて，［
ある団体
— “community” —
の~member間でのみ，`共有され$る
］ような，どの~cacheも、応答を~cacheすることが許容されるとする。
`生成元~server$は、［
“XYZ” community が，彼らの`共用~cache$において［
さもなければ `private$sdir になるような応答
］を利用する
］ことを許容したいと望むなら、次のように［
`XYZ^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, any cache that is shared only 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="XYZ"
</pre>

<p>
そのような `community^dir ~cache拡張を認識する~cacheは、その`拡張$に則って，その挙動を広げられる。
`community^dir ~cache拡張を認識しない~cacheは、それを無視して， `private$sdir 指令を固守することになる。
◎
A cache that recognizes such a community cache-extension could broaden its behavior in accordance with that extension. A cache that does not recognize the community cache-extension would ignore it and adhere to the private directive.
</p>
</div>

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

<p>
`Expires^h ~headerは、［
それ以降は 応答が`非新鮮$になると見なされる，日時／時刻
］を与える。
`鮮度$の~modelについての更なる論点は、 `4.2$secを見よ。
◎
The "Expires" header field gives the date/time after which the response is considered stale. See Section 4.2 for further discussion of the freshness model.
</p>

<p>
`Expires$h ~headerが在ることは［
元の`資源$が，その時刻を境に変化したり, 存在するようになる／しなくなる
］ことを含意するものではない。
◎
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
</p>

<p>
`Expires$h は、
`HTTP-date$p による時刻印を値にとる。
◎
The Expires value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231].
</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 field with the max-age directive (Section 5.2.2.8), a recipient MUST ignore the Expires field. Likewise, if a response includes the s-maxage directive (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented the Cache-Control field.
</p>

<div class="p">
<p>
`時計$を備えていない`生成元~server$は、
`Expires$h ~headerを`生成し$てはナラナイ
— ただし、その値が次のいずれかの値をとる場合は除く：
◎
An origin server without a clock MUST NOT generate an Expires 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 or user with a reliable clock.
</li>
</ul>
</div>

<p>
歴史的に，~HTTPは、
`Expires$h `~header値$が，一年以内の未来になることを要求していた。
長い`鮮度維持期間$は，もはや禁制されなくなったが、
度を越して巨大な値は，問題を起こすことが判っているので（例：時刻~値~用の 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="section-5.4">
<h3>5.4. `Pragma^h</h3>

<p class="trans-note">【
この~headerは、
この~RFCの改訂 ~RFC 9111 により，
正式に`非推奨にされた＠~HTTPcache#field.pragma$。
】</p>

<p>
`Pragma^h ~headerは、~HTTP10~cacheとの後方~互換性を許容する
— 
~clientが，自身が解する `no-cache^dir 要請を指定できるようにするために（ `Cache-Control$h は、~HTTP11になるまで，定義されていなかったので）。
`Pragma^h は，［
`Cache-Control$h ~headerも，要請に在る, かつ解される
］ときには、無視される。
◎
The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored.
</p>

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

<pre class="bnf">
`Pragma@p
	= 1#`pragma-directive$p
`pragma-directive@p
	= "no-cache"
	/ `extension-pragma$p
`extension-pragma@p
	= `token$p [ "=" ( `token$p / `quoted-string$p ) ]
</pre>

<p>
要請~内に
`Cache-Control$h ~headerが無い下では、~cacheは，［
`no-cache^dir 要請 `pragma-directive$p
］を［
<code >`Cache-Control$p: `no-cache$qdir</code>
が在ったときと同じ効果を持つ
］と見なさなければナラナイ。
◎
When the Cache-Control header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see Section 5.2.1).
</p>

<p>
`~client$は、
`no-cache^dir 要請を送信するときには，
`Pragma^h, `Cache-Control^h 両~指令を内包する~OUGHT
— `Cache-Control$h に対する `no-cache$qdir を，［
`~HTTP11$~cacheに対しては，他の `Cache-Control$h <del>応答~指令</del> <ins>要請~指令</ins>†を~targetにする
］ために，目的を以って省略する場合を除いて。
例えば、次のもの：
◎
When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:
</p>

<p class="trans-note">【†
`4674$errataによる~~修正（Verified: 2016-04-26 ）
】</p>

<div class="example">

<pre class="lang-http">
GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache
</pre>

</div>

<p>
は、~HTTP11~cacheに対しては，齢が 30 秒を超えない応答に限って~serveするように拘束する一方で，
`Cache-Control$h を解さない実装に対しては，~cache済み応答を~serveさせなくする。
◎
will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand Cache-Control from serving a cached response.
</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 is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them.
</p>

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

<p class="trans-note">【
この~headerは、
この~RFCの改訂 ~RFC 9111 により，
正式に`廃用にされた＠~HTTPcache#field.warning$
（この節を成す内容も，すべて除去された）。
】</p>

<p>
`Warning^h ~headerは、
`警告^dfn
— ［
`状態s~code$内に反映されないこともあり得るような，~messageの状態sや`形式変換$
］についての追加的な情報 —
を運ぶために利用される。
この情報は、概して，［
~caching【！＊演算】や`形式変換$が適用されたため，~messageの~payloadが不正になる可能性がある
］ことを警告するために利用される。
◎
The "Warning" header field is used to carry additional information about the status or transformation of a message that might not be reflected in the status code. This information is typically used to warn about possible incorrectness introduced by caching operations or transformations applied to the payload of the message.
</p>

<p>
`警告$は、~cacheに関係する目的にも, 他の目的にも利用できる。
`警告$の利用により、これらの応答は，真の失敗を表す~error`状態s~code$から判別できるようになる。
◎
Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguishes these responses from true failures.
</p>

<p>
`Warning^h ~headerは、一般に，どの~messageにも適用できるが、一部の `warn-code$p は~cacheに特有であり，応答~messageのみに適用され得る。
◎
Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only be applied to response messages.
</p>

<pre class="bnf">
`Warning@p
	= 1#`warning-value$p

`warning-value@p
	= `warn-code$p `SP$P `warn-agent$p `SP$P `warn-text$p [ `SP$P `warn-date$p ]

`warn-code@p
	= 3`DIGIT$P
`warn-agent@p
	= ( `uri-host$p [ ":" `port$p ] )
	/ `pseudonym$p
`warn-text@p
	= `quoted-string$p
`warn-date@p
	= `DQUOTE$P `HTTP-date$p `DQUOTE$P
</pre>

<p>
`warn-agent$p は、
`Warning$h ~headerを追加している`~server$の名前, または仮名（ `pseudonym^p ）である。
~debug時に利用するときは、単独の "`-^c" が推奨される。
◎
the name or pseudonym of the server adding
the Warning header field, for use in debugging
a single "-" is recommended when agent unknown
</p>

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

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

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

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

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

<div class="example">
<pre class="lang-http">
HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
</pre>
</div>

<p>
`警告$には，~errorについて述べる
`警告~text@（ `warn-text$p ）
が付随する。
例えば~logをとるためなど。
それはもっぱら助言的であり，その内容は `warn-code$p の解釈には影響しない。
◎
Warnings have accompanying warn-text that describes the error, e.g., for logging. It is advisory only, and its content does not affect interpretation of the warn-code.
</p>

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

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

			<section id="section-5.5.1">
<h4>5.5.1. <code>Warning: `110^wc</code> — `Response is Stale^ph</h4>

<p>
~cacheは、［
送信されてきた応答が`非新鮮$である
］ときには、これを`生成する$ベキである。
◎
A cache SHOULD generate this whenever the sent response is stale.
</p>

			</section>
			<section id="section-5.5.2">
<h4>5.5.2. <code>Warning: `111^wc</code> — `Revalidation Failed^ph</h4>

<p>
~cacheは、［［
`~server$に到達できないことに因り，応答を`検証する$試みが失敗した
］ために，`非新鮮$ 応答を送信する
］ときには、これを`生成する$ベキである。
◎
A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server.
</p>

			</section>
			<section id="section-5.5.3">
<h4>5.5.3. <code>Warning: `112^wc</code> — `Disconnected Operation^ph</h4>

<p>
~cacheは、［
~networkの他の部分から，ある期間, 意図的に切断された
］場合には、これを`生成する$ベキである。
◎
A cache SHOULD generate this if it is intentionally disconnected from the rest of the network for a period of time.
</p>

			</section>
			<section id="section-5.5.4">
<h4>5.5.4. <code>Warning: `113^wc</code> — `Heuristic Expiration^ph</h4>

<p>
~cacheは、［
~24hoursを超える`鮮度維持期間$を 経験的に選択した, かつ
応答の`齢$が~24hoursを超えている
］場合には、これを`生成する$ベキである。
◎
A cache SHOULD generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
</p>

			</section>
			<section id="section-5.5.5">
<h4>5.5.5. <code>Warning: `199^wc</code> —  `Miscellaneous Warning^ph</h4>

<p>
`警告~text$は、［
ヒト利用者に呈示されたり, ~logがとられる
］ような，任意な情報を内包し得る。
この`警告$を受信した~systemは、利用者に`警告$を呈示する以外に，どのような自動化された動作も してはナラナイ。
◎
The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user.
</p>

			</section>
			<section id="section-5.5.6">
<h4>5.5.6. <code>Warning: `214^wc</code> — `Transformation Applied^ph</h4>

<p>
`表現$に何らかの`形式変換$
— ［
`content-coding$p ／ `media-type$p
］を変更する, あるいは `表現~data$を改変する, 等々 —
を適用する`~proxy$は、この `warn-code$p を応答に追加しなければナラナイ
— 応答~内にすでに出現していない限り。
◎
This Warning code MUST be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, or modifying the representation data, unless this Warning code already appears in the response.
</p>

			</section>
			<section id="section-5.5.7">
<h4>5.5.7. <code>Warning: `299^wc</code> — `Miscellaneous Persistent Warning^ph</h4>

<p>
`警告~text$は、［
ヒト利用者に呈示されたり, ~logがとられる
］ような，任意な情報を内包し得る。
この`警告$を受信した~systemは、どのような自動化された動作も してはナラナイ。
【！複製】
◎
The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action.
</p>

			</section>
		</section>
	</section>
	<section id="section-6">
<h2 title="History Lists">6. 履歴~list</h2>

<p>
~UAは、 “戻る” ~buttonや履歴~listなど，その~sessionで~~以前に検索取得された`表現$を再~表示するために利用できるような，履歴の仕組みを備えることが多い。
◎
User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.
</p>

<p>
履歴の仕組みに`鮮度$の~modelが適用されるとは限らない。
すなわち、履歴の仕組みは，以前に失効した`表現$も表示できる。
◎
The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.
</p>

<p>
これは、履歴の仕組みが，［
利用者に向けて ~viewが`非新鮮$かもしれないことを示したり，
`~cache指令$（例：
<code>`Cache-Control$p: `no-store$sdir</code>
）を尊守する
］ことを禁制するものではない。
◎
This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).
</p>

	</section>
	<section id="section-7">
<h2 title="IANA Considerations">7. IANA 考慮点</h2>

		<section id="section-7.1">
<h3 title="Cache Directive Registry">7.1. ~cache指令~registry</h3>

<p>
`~cache指令$用の名前空間を定義するための
`Hypertext Transfer Protocol (HTTP) Cache Directive Registry＠~IANA-a/http-cache-directives$
（HTTP ~cache指令~registry）が、新たに作成され，保守されている。
◎
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;http://www.iana.org/assignments/http-cache-directives&gt;.
</p>

			<section id="section-7.1.1">
<h4 title="Procedure">7.1.1. 手続-</h4>

<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 [RFC5226], Section 4.1).
</p>

			</section>
			<section id="section-7.1.2">
<h4 title="Considerations for New Cache Control Directives">7.1.2. 新たな~cache制御~指令に対する考慮点</h4>

<p>
新たな拡張~指令は、次を定義することを考慮する~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,
</li>
	<li>
その指令は要請のみ, あるいは応答のみに特有か？
両者ともに利用できるか？
◎
• Whether the directive is specific to requests, responses, or able to be used in either.
</li>
</ul>

<p>
`5.2.3$secも見よ。
◎
See also Section 5.2.3.
</p>

			</section>
			<section id="section-7.1.3">
<h4 title="Registrations">7.1.3. 登録</h4>

<p>
~registryは、以下の登録により拡充された：
◎
The registry has been populated with the registrations below:
</p>

<table><thead>
<tr><td>要請~cache指令
<td>応答~cache指令
<tbody>

<tr><td>`max-age$qdir
<td>`max-age$sdir

<tr><td>`max-stale$qdir
<td>—

<tr><td>`min-fresh$qdir
<td>—

<tr><td>—
<td>`must-revalidate$sdir

<tr><td>`no-cache$qdir
<td>`no-cache$sdir

<tr><td>`no-store$qdir
<td>`no-store$sdir

<tr><td>`no-transform$qdir
<td>`no-transform$sdir

<tr><td>`only-if-cached$qdir
<td>—

<tr><td>—
<td>`private$sdir

<tr><td>—
<td>`proxy-revalidate$sdir

<tr><td>—
<td>`public$sdir

<tr><td>—
<td>`s-maxage$sdir

<tr><td>`stale-if-error$qdir
<td>`stale-if-error$sdir

<tr><td>—
<td>`stale-while-revalidate$sdir
</table>

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

			</section>
		</section>
		<section id="section-7.2">
<h3 title="Warn Code Registry">7.2. `warn-code^p ~registry</h3>

<p>
`warn-code$p 用の名前空間を定義する~registryが、新たに作成され，
`Hypertext Transfer Protocol（ HTTP ）Warn Codes＠~IANA-a/http-warn-codes$
にて保守されている。
◎
The " (HTTP) Warn Codes" registry defines the namespace for warn codes. It has been created and is now maintained at &lt;http://www.iana.org/assignments/http-warn-codes&gt;.
</p>

			<section id="section-7.2.1">
<h4 title="Procedure">7.2.1. 手続-</h4>

<p>
登録にあたっては，次の~fieldが含まれなければナラナイ：
◎
A registration MUST include the following fields:
</p>

<ul>
	<li>
`warn-code$p（ 3 桁）
◎
• Warn Code (3 digits)
</li>
	<li>
短い記述
◎
• Short Description
</li>
	<li>
仕様~textへの~pointer
◎
• Pointer to specification text
</li>
</ul>

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

			</section>
			<section id="section-7.2.2">
<h4 title="Registrations">7.2.2. 登録</h4>

<p>
~registryは、以下の登録により拡充された：
◎
The registry has been populated with the registrations below:
</p>

<table><thead>
<tr><td>Warn Code
<td>短い記述
<td>【短い記述】
<tbody>

<tr><td>`110$wc
<td>`Response is Stale^ph
<td>応答は`非新鮮$

<tr><td>`111$wc
<td>`Revalidation Failed^ph
<td>`再検証$に失敗した

<tr><td>`112$wc
<td>`Disconnected Operation^ph
<td>~~処理は切断された

<tr><td>`113$wc
<td>`Heuristic Expiration^ph
<td>経験的~失効

<tr><td>`199$wc
<td>`Miscellaneous Warning^ph
<td>その他の警告

<tr><td>`214$wc
<td>`Transformation Applied^ph
<td>形式変換が適用された

<tr><td>`299$wc
<td>`Miscellaneous Persistent Warning^ph
<td>その他の持続的~警告
</table>

<pre lang="en" class="_en">
   +-----------+----------------------------------+---------------+
   | Warn Code | Short Description                | Reference     |
   +-----------+----------------------------------+---------------+
   | 110       | Response is Stale                | Section 5.5.1 |
   | 111       | Revalidation Failed              | Section 5.5.2 |
   | 112       | Disconnected Operation           | Section 5.5.3 |
   | 113       | Heuristic Expiration             | Section 5.5.4 |
   | 199       | Miscellaneous Warning            | Section 5.5.5 |
   | 214       | Transformation Applied           | Section 5.5.6 |
   | 299       | Miscellaneous Persistent Warning | Section 5.5.7 |
   +-----------+----------------------------------+---------------+
</pre>

			</section>
		</section>
		<section id="section-7.3">
<h3 title="Header Field Registration">7.3. ~header登録</h3>

<p>
~HTTP~headerは、
`Message Headers＠~IANA-a/message-headers/$
~registryの中に登録される。
◎
HTTP header fields are registered within the "Message Headers" registry maintained at &lt;http://www.iana.org/assignments/message-headers/&gt;.
</p>

<p>
この文書は、次の~HTTP~headerを定義する。
それに伴い
"Permanent Message Header Field Names"
~registryも更新された（`BCP90$rを見よ）。
◎
This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).
</p>

<table><thead>
<tr><td>~header名
<td>~protocol
<td>位置付け
<tbody>

<tr><td>`Age$h
<td>http
<td>standard

<tr><td>`Cache-Control$h
<td>http
<td>standard

<tr><td>`Expires$h
<td>http
<td>standard

<tr><td>`Pragma$h
<td>http
<td>standard

<tr><td>`Warning$h
<td>http
<td>standard
</table>

<pre lang="en" class="_en">
   +-------------------+----------+----------+-------------+
   | Header Field Name | Protocol | Status   | Reference   |
   +-------------------+----------+----------+-------------+
   | Age               | http     | standard | Section 5.1 |
   | Cache-Control     | http     | standard | Section 5.2 |
   | Expires           | http     | standard | Section 5.3 |
   | Pragma            | http     | standard | Section 5.4 |
   | Warning           | http     | standard | Section 5.5 |
   +-------------------+----------+----------+-------------+
</pre>

<p>
変更~制御者は~IETF-orgである。
◎
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
</p>

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

<p>
この節は、［
開発者／情報~provider／利用者
］向けに，
~HTTP~cachingに特有な，既知な~securityの懸念を伝えることを~~意図している。
より一般的な~securityの考慮点は、
~HTTP~messaging `7230-9$rfc, および
~HTTP意味論 `7231-9$rfc にて取組まれている。
◎
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 messaging [RFC7230] and semantics [RFC7231].
</p>

<p>
~cacheは、脆弱性を付け加える~~可能性がある
— ~cacheの内容は，悪意的な【！＊】悪用にとって魅力的な~targetを表現するので。
~cacheの内容は，~HTTP要請が完了した後も持続するので、利用者からは~networkから情報が除去されたように見えても、~cacheに対する攻撃により，長期間 情報を露呈する。
したがって，~cache内容は、敏感な情報として保護される必要がある。
◎
Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because 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$内に格納されることにより、様々な攻撃が増幅され得る
— そのような “~cache汚染” 攻撃は、［
多数の~clientに向けて悪意的な~payloadを配布する
］ような~cacheを利用する。
それは、攻撃者が［
実装の欠陥, 特権拡大, その他の技法
］を利用して，そのような応答を~cacheの中へ挿入できるときには、とりわけ効果的になる。
~cache汚染に共通的にある攻撃~行路の一つは、`~proxy$と`~UA$における~message構文解析-法の相違点を悪用するものである
— 関連な要件については `7230-3.3.3$rfcを見よ。
◎
In particular, various attacks might be amplified by being stored in a shared cache; such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see Section 3.3.3 of [RFC7230] for the relevant requirements.
</p>

<p>
同様に、実装の欠陥（あるいは~cache運用の誤理解）は、私用と考えられる敏感な情報（例：認証~資格証）の~cachingを導き、権限付与されていない主体に公開されるかもしれない。
◎
Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.
</p>

<p>
更には、~cacheの多用は，~privacyの懸念ももたらし得る。
例えば、利用者 A, B が~cacheを共有していて，利用者 A がある~siteを閲覧したなら、利用者 B は
— ~cacheのおかけで，そこからの`資源$がより速く読込まれることから —
利用者 A が その~siteに居たことを検出できるようになる。
◎
Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it load more quickly, thanks to the cache.
</p>

<p class="note">注記：
`Set-Cookie$h 応答~header `6265$R は、~cachingを~~妨げない
— `Set-Cookie$h ~headerを伴う~cache可能な応答は、~cacheに対する後続な要請を充足するために利用できる（また，利用されることが多い）。
`~server$には、これらの応答の~cachingを制御したいときには，適切な `Cache-Control$h 応答~headerを発することが，奨励される。
◎
Note that the Set-Cookie response header field [RFC6265] 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 who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.
</p>

	</section>
	<section id="section-9">
<h2 title="Acknowledgments">9. 謝辞</h2>

<p class="trans-note">【
この節の内容は、
`RFC723X 共通~page＠~723X#acknowledgments$
に移譲。
】
◎
See Section 10 of [RFC7230].
</p>

	</section>
	<section id="section-10">
<h2 title="References">10. 参照文献</h2>

<p class="trans-note">【
この節の内容は、
`RFC723X 共通~page＠~723X#references$
に移譲。
】</p>

	</section>
	<section id="appendix-A">
<h2 title="Appendix A. Changes from RFC 2616">付録 A. RFC 2616 からの変更点</h2>

<ul >

	<li>
明確化のため、仕様は，相当に書き直された。
◎
The specification has been substantially rewritten for clarity.
</li>
	<li>
認証-済み応答を~cacheできるための条件が、明確化された。
（`3.2$sec）
◎
The conditions under which an authenticated response can be cached have been clarified. (Section 3.2)
</li>
	<li>
新たな`状態s~code$は、今や，その［
~cacheに`経験的な$`鮮度$を利用することも許容される
］ように定義できる。
~cacheには、今や，~query成分を伴う~URI用に`経験的な$`鮮度$を計算することも許容される。
（`4.2.2$sec）
◎
New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate heuristic freshness for URIs with query components. (Section 4.2.2)
</li>
	<li>
`齢$を計算するための~algoは、より非~保守的にされた。
~cacheには、今や，［
【"GMT", "UTC" 以外の】
時間帯を伴う`日時$を無効であったかのように取扱う
］ことが要求される
— それを正確aに推測することはアリでないので。
（`4.2.3$sec）
◎
The algorithm for calculating age is now less conservative. Caches are now required to handle dates with time zones as if they're invalid, because it's not possible to accurately guess. (Section 4.2.3)
</li>
	<li>
`Content-Location$h 応答~headerは、
もはや，［
`検証する$ときに，利用する適切な応答を決定する
］ためには利用されなくされた。
（`4.3$sec）
◎
The Content-Location response header field is no longer used to determine the appropriate response to use when validating. (Section 4.3)
</li>
	<li>
利用する［
~cache済みな折衝された応答
］を選定するための~algoは、いくつかの仕方で明確化された。
特に、今や，［
`選定用~header$たちを処理する際の，~headerに特有な正準-化
］は，明示的に許容される。
（`4.1$sec）
◎
The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now explicitly allows header-specific canonicalization when processing selecting header fields. (Section 4.1)
</li>
	<li>
無効化を遂行するときの~DoS攻撃の回避法に関する要件が，明確化された。
（`4.4$sec）
◎
Requirements regarding denial-of-service attack avoidance when performing invalidation have been clarified. (Section 4.4)
</li>
	<li>
~cacheの無効化が生じるのは、応答が成功裡に受信されたときに限られる。
（`4.4$sec）
◎
Cache invalidation only occurs when a successful response is received. (Section 4.4)
</li>
	<li>
`~cache指令$は、文字大小無視であると明示的に定義された。
今や、 1 個のみが予期されている所での，複数の~cache指令の~instanceの取扱いが定義された。
（`5.2$sec）
◎
Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only one is expected is now defined. (Section 5.2)
</li>
	<li>
`no-store$qdir 要請~指令は、応答には適用されない
— すなわち，~cacheは `no-store$qdir を伴う要請を充足でき，それを無効化しない。
（`5.2.1.5$sec）
◎
The "no-store" request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it and does not invalidate it. (Section 5.2.1.5)
</li>
	<li>
引数~付きの
`private$sdir ／ `no-cache^dir
`~cache指令$は、広範に実装されていないことが注記された
— 例えば，
"`private=foo^c" は、多くの~cacheから単純に `private^c に解釈される。
加えて，引数~付き `no-cache^dir の意味が明確化された。
（`5.2.2$sec）
◎
The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; for example, "private=foo" is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. (Section 5.2.2)
</li>
	<li>
`no-cache$sdir 応答~指令の意味が明確化された。
（`5.2.2.2$sec）
◎
The "no-cache" response directive's meaning has been clarified. (Section 5.2.2.2)
</li>
	<li>
`Expires$h ~header値に対する 1 年の上限は除去され、代わりに，~~実用的な値を利用する理由付けが与えられた。
（`5.3$sec）
◎
The one-year limit on Expires header field values has been removed; instead, the reasoning for using a sensible value is given. (Section 5.3)
</li>
	<li>
`Pragma$h ~headerは、今や，後方~互換性のためのみに定義される。
将来の pragma は非推奨にされた。
（`5.4$sec）
◎
The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (Section 5.4)
</li>
	<li>
`Warning$h ~headerの生成規則と処理に関する一部の要件は緩められた
— それは広範に実装されていないので。
更には、
`Warning$h ~headerは，もはや `2047$R 符号化法を利用せず，複数の言語も許容しない
— これらの側面は実装されていないので。
（`5.5$sec）
◎
Some requirements regarding production and processing of the Warning header fields have been relaxed, as it is not widely implemented. Furthermore, the Warning header field no longer uses RFC 2047 encoding, nor does it allow multiple languages, as these aspects were not implemented. (Section 5.5)
</li>
	<li>
この仕様は、
Cache Directive, および Warn Code
~registryを導入し、新たな`~cache指令$に対する考慮点を定義する。
（`7.1$sec, `7.2$sec）
◎
This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. (Section 7.1 and Section 7.2)
</li>
</ul>

	</section>
	<section id="appendix-B">
<h2 title="Appendix B. Imported ABNF">付録 B. 取込まれた~ABNF</h2>
	</section>
	<section id="appendix-C">
<h2 title="Appendix C. Collected ABNF" data-cycling=".bnf">付録 C. 総集的~ABNF</h2>

<p class="trans-note">【
付録 B, C の内容は、
`総集的~ABNF＠~723Xabnf#abnf-7234$
に移譲。
】</p>

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