http-immutable-response-ja.html

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

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">
<script src="common0.js"></script>
<script src="http-common.js"></script>
<script src="common1.js" async></script>

<script >
</script>

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


●●options

spec_title:RFC 8246 — HTTP Immutable Responses
trans_update:2018-05-17
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc8246.html
abbr_url:HTTPimmutable
spec_status:IETFPR
no_original_dfn:true
ref_rfc:true
trans_1st_pub:2018-05-17

●●original_id_map
	introduction:section-1
	notational-conventions:section-1.1
	the-immutable-cache-control-extension:section-2
	about-intermediaries:section-2.1
	example:section-2.2
	security-considerations:section-3
	iana-considerations:section-4

references:rfc.references
normative:rfc.references.1
informative:rfc.references.2

●●link_map
	~RFCx/RFC7234 → ~HTTPcache
sdir.immutable:#cache-response-directive.immutable
qdir.no-cache:~HTTPcache#cache-request-directive.no-cache

鮮度~維持期間:~HTTPcache#freshness-lifetime
再検証-:~HTTPcache#validation.model
新鮮:~HTTPcache#fresh
非新鮮:~HTTPcache#stale

●●words_table1
RFC7234:RFC7234-ja.html

●●words_table
refresh::::リフレッシュ
reload::::リロード
load::::ロード
発行-:issue:~
維持期間:lifetime::~
再検証-:revalidate::~
再検証:revalidation::~
返信-:reply:~
	下位資源:sub-resource
迂回-:bypass:~
写真:photo:~
変種:variant:~
浪費-:waste:~
心配-:worry:~
確認-:confirm:~
正す:rectifyする:~
留置き:pinning::留め置き
破損:corruption::~
事態:incident::~
増幅-:amplify:~
	amplification
確か:certain:~

●●
	他の語（言い換え
可能性もある:possible
依存する〜:dependent
準拠する:compliant
~cache汚染:cache-poisoning
公表し直-:republish
挙げる:Three
他の:all
ある~pageの:a front-page newspaper
路を~~開く:create a vector
60 分:one hour
もある:some
より前に:old
改変されていない:unmodified
個:instances
意味論:semantic meaning
過去:old

	他の語
一部を成さない:not part of
方が〜でない：~less
soft::::ソフト的
下で:under
際して:upon
も:as well
〜前 以後:up to
ことになり:in turn
または:either
見る:see
何百もの:hundreds of 
~version付き:versioned
期間:period of time／:period
~~同時に:at the same time
長大な:very large
とらない:takes no

●●ref_normative
[RFC2119]
    Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, ~RFC2119, March 1997
[RFC7232]
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, ~RFC7232, June 2014
[RFC7234]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP): Caching”, ~RFC7234, June 2014
[RFC8174]
    Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, ~RFC8174, May 2017.

●●ref_informative
[REQPERPAGE]
    HTTP Archive, “Total Requests per Page” URL: http://httparchive.org/interesting.php#reqTotal

●●
Author's Address
Patrick McManus
Mozilla
EMail: mcmanus@ducksong.com

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


●●spec_metadata

公表者
	Internet Engineering Task Force (IETF)
RFC
	8246
分類
	Standards Track
ISSN
	2070-1721
編集
	P. McManus, Mozilla
日付
	2017 年 9 月
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc8246

</script>

</head>
<body>


<header>
	<hgroup>
<h1>変異不能な HTTP 応答</h1>
<p>RFC 8246 — HTTP Immutable Responses</p>
	</hgroup>
</header>

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

<p>
`immutable$sdir ~HTTP応答 `Cache-Control$h 拡張は、［
`資源$は、その`鮮度~維持期間$の間は，更新されないものと識別されるようにする
］ことを，`~server$に許容する。
これは、［
その資源は、~cache済みで新鮮な間は改変されないことが確かであり，`~client$は決して`再検証-$する必要はない
］ようになることを確保する。
◎
The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.
</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 © 2017 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="introduction">
<h2 title="Introduction">1. 序論</h2>

<p>
~HTTPによる`鮮度~維持期間$の仕組み `RFC7234$r は、［
指定された期間までは、未来の要請に対し，安全に，格納-済み応答を再利用して充足する
］ことを，`~client$【が使役する`~cache$】に許容する。
しかしながら、その期間の間，`資源$が改変される可能性も依然としてある。
◎
HTTP’s freshness lifetime mechanism [RFC7234] allows a client to safely reuse a stored response to satisfy future requests for a specified period of time. However, it is still possible that the resource will be modified during that period.
</p>

<p>
一例として，ある~pageの写真が，`鮮度~維持期間$が 60 分にされている場合、利用者は 60 分前より過去に~cacheされた写真を見ることはないことを意味する。
しかしながら，写真はいつでも更新され得るので、他の利用者は
— 60 分前 以後に~cacheされた内容に依存して —
異なる写真を見ているかもしれない。
これは、 `RFC7234$r が定義する~cache法の仕組みに準拠する。
◎
For instance, a front-page newspaper photo with a freshness lifetime of one hour would mean that no user would see a cached photo more than one hour old. However, the photo could be updated at any time, resulting in different users seeing different photos depending on the contents of their caches for up to one hour. This is compliant with the caching mechanism defined in [RFC7234].
</p>

<p>
自身の~cache済み応答に更新は無いことを確認する必要がある利用者は、概して，
自身の`~UA$において~reload （または~refresh）の仕組みを利用する。
これは，`条件付き要請$を`生成-$することになり、［
新たな`表現$, または改変されていなければ `304$st 応答
］が返される。
~HTMLを解して，依存する下位資源を~fetchする~UAは、それらに共通な~pageのすべての部位を~refreshするときに，何百もの条件付き要請を発行するかもしれない。
`REQPERPAGE$r
◎
Users that need to confirm there have been no updates to their cached responses typically use the reload (or refresh) mechanism in their user agents. This in turn generates a conditional request [RFC7232], and either a new representation or, if unmodified, a 304 (Not Modified) response [RFC7232] is returned. A user agent that understands HTML and fetches its dependent sub-resources might issue hundreds of conditional requests to refresh all portions of a common page [REQPERPAGE].
</p>

<p>
しかしながら，内容~providerには、下位資源には “~version付き” ~URLを利用するので，複数の変種を決して作成しないものもある。
これらの`資源$を更新する必要があるときは、単純に，新たな~URLの下で公表される
— 概して，~path内にその~versionの資源~用の一意な識別子を埋込んで，下位資源への参照は 新たな~path情報で更新される。
◎
However, some content providers never create more than one variant of a sub-resource, because they use “versioned” URLs. When these resources need an update, they are simply published under a new URL, typically embedding an identifier unique to that version of the resource in the path, and references to the sub-resource are updated with the new path information.
</p>

<p>
例えば，
`https://www.example.com/101016/main.css^c
は、
`https://www.example.com/102026/main.css^c
として公表し直され，更新されるかもしれない
— それを参照する どの~linkも~~同時に変更した上で。
この設計~patternは、未来~のいつ更新されるか推測することなく，長大な`鮮度~維持期間$を下位資源~用に利用することを許容する。
◎
For example, https://www.example.com/101016/main.css might be updated and republished as https://www.example.com/102026/main.css, with any links that reference it being changed at the same time. This design pattern allows a very large freshness lifetime to be used for the sub-resource without guessing when it will be updated in the future.
</p>

<p>
あいにく，`~UA$は、この~version付き~URL設計~patternが，いつ利用されるかを知らない。
結果として，利用者~駆動な~refreshは、依然として 各~下位資源ごとに `304$st0 応答を返すような，浪費される条件付き要請に翻訳される。
◎
Unfortunately, the user agent does not know when this versioned URL design pattern is used. As a result, user-driven refreshes still translate into wasted conditional requests for each sub-resource as each will return 304 responses.
</p>

<p>
`immutable^dir ~HTTP応答 `Cache-Control$h 拡張は、［
応答は、その`鮮度~維持期間$の間は，更新されないものと識別されるようにする
］ことを，`~server$に許容する。
◎
The immutable HTTP response Cache-Control extension allows servers to identify responses that will not be updated during their freshness lifetimes.
</p>

<p>
これは，実質的に、［
そのような応答に対しては
— 更新されたかどうか心配することなく —
安全に，条件付き要請【`~cache検証~要請$】を飛ばせる
］ことを，`~client$に伝える。
◎
This effectively informs clients that any conditional request for that response can be safely skipped without worrying that it has been updated.
</p>

		<section id="notational-conventions">
<h2 title="Notational Conventions">1.1. 表記規約</h2>

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

		</section>
		<section id="_conventions">
<h3>【この訳に特有な表記規約】</h3>

<p>
この訳では、
この仕様が公表された当時の~HTTP仕様（ `RFC7234$r 他）を参照している箇所を，
現在の中核~HTTP仕様~内の`等価な記述を指すよう改めている＠~HTTPcommon#_terms-convention$。
</p>

		</section>
	</section>
	<section id="the-immutable-cache-control-extension">
<h2 title="The Immutable Cache-Control Extension">2. `immutable^dir `Cache-Control^h 拡張</h2>

<p>
~HTTP応答~内の
`immutable@sdir
`Cache-Control$h 拡張は、次を指示する
⇒
`生成元~server$は、応答の`鮮度~維持期間$の間に，当の`資源$の`表現$を更新することはない。
◎
When present in an HTTP response, the immutable Cache-Control extension indicates that the origin server will not update the representation of that resource during the freshness lifetime of the response.
</p>

<p>
`~client$は、そのような応答の`鮮度~維持期間$の間は，条件付き要請を発行するベキでない（例：~reloadに際して）
— 利用者により明示的に上書きされない限り（例： ~reloadを強制するなど）。
◎
Clients SHOULD NOT issue a conditional request during the response’s freshness lifetime (e.g., upon a reload) unless explicitly overridden by the user (e.g., a force reload).
</p>

<p>
`immutable^dir  拡張が適用されるのは、格納-済み応答の`鮮度~維持期間$の間に限られる。
`非新鮮$な応答は、`再検証-$するベキである
— それらには、通常は， `immutable^dir 拡張は無いので。
◎
The immutable extension only applies during the freshness lifetime of the stored response. Stale responses SHOULD be revalidated as they normally would be in the absence of the immutable extension.
</p>

<div class="p">
<p>
`immutable^dir `Cache-Control$h 拡張は：
</p>

<ul>
	<li>
引数をとらない
— 引数が在っても、意味は無く，無視されなければナラナイ。
</li>
	<li>
複数~個~在っても， 1 個~在るときと等価になる。
</li>
	<li>
要請~内に在っても効果は無い。
</li>
</ul>

◎
The immutable extension takes no arguments. If any arguments are present, they have no meaning and MUST be ignored. Multiple instances of the immutable extension are equivalent to one instance. The presence of an immutable Cache-Control extension in a request has no effect.
</div>


		<section id="about-intermediaries">
<h3 title="About Intermediaries">2.1. `媒介者$について</h3>

<p>
`immutable$sdir 応答の意味論は、それを受信した`~client$が［
`~proxy$, `~UA$
］どちらであっても同じになる。
したがって~proxyは、 `immutable^dir 拡張を包含している`新鮮$な応答については，条件付きで再検証するのを飛ばすベキである
— ~clientから検証が必要yであるものと通達された場合（例： `no-cache$qdir `Cache-Control^h 要請~指令 `RFC7234$r ）は除き。
◎
An immutable response has the same semantic meaning when received by proxy clients as it does when received by user-agent-based clients. Therefore, proxies SHOULD skip conditionally revalidating fresh responses containing the immutable extension unless there is a signal from the client that a validation is necessary (e.g., a no-cache Cache-Control request directive defined in Section 5.2.1.4 of [RFC7234]).
</p>

<p>
~proxyは、条件付き再検証を迂回するために `immutable$sdir 拡張を利用するときには、自身が受信した要請~headerに基づいて［
要請している`~client$に対し［
`304$st0, `200$st0
］どちらの応答で返信するか
］を選択できる。
◎
A proxy that uses the immutable extension to bypass a conditional revalidation can choose whether to reply with a 304 or 200 response to its requesting client based on the request headers the proxy received.
</p>

		</section>
		<section id="example">
<h3 title="Example">2.2. 例</h3>

<pre class="lang-http">
Cache-Control: max-age=31536000, immutable
</pre>

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

<p>
`immutable$sdir の仕組みは、ソフト的な留置き（ `soft pinning^en ）の形として動作し
— 他の留置きの仕組みと同じく —
~cache破損の事態を増幅する行路を~~開く。
そのような事態には、~cache汚染~攻撃も含まれる。
この~riskの軽減策として、次に挙げる仕組みが示唆される：
◎
The immutable mechanism acts as form of soft pinning and, as with all pinning mechanisms, creates a vector for amplification of cache corruption incidents. These incidents include cache-poisoning attacks. Three mechanisms are suggested for mitigation of this risk:
</p>

<ul>
	<li>
`~client$は、［
~HTTPSなどの，認証-済み文脈
］の一部を成さない`資源$からの `immutable$sdir 拡張を，無視するベキである。
認証-済み資源の方が、~cache汚染には脆弱でない。
◎
Clients SHOULD ignore the immutable extension from resources that are not part of an authenticated context such as HTTPS. Authenticated resources are less vulnerable to cache poisoning.
</li>
	<li>
`~UA$は、 2 つの~refreshの仕組み
— ~reload, および 何らかの形で~reloadを強制する —
を供することが多い。
後者は、中断された~load, および他の破損を正すために利用される。
これらの~reload
— 概して `no-cache$qdir 要請~属性を通して指示される —
に際しては、 `immutable$sdir 拡張も無視するベキである。
◎
User agents often provide two different refresh mechanisms: reload and some form of force-reload. The latter is used to rectify interrupted loads and other corruption. These reloads, typically indicated through no-cache request attributes, SHOULD ignore the immutable extension as well.
</li>
	<li>
`~client$は、［
格納-済み応答の~sizeは正しい応答~sizeである
］ことの強い指示を供さない`資源$
— `接続の~closeで区切られた応答＠~HTTPv1#message.body.length$など —
に対しては、 `immutable$sdir 拡張を無視するベキである。
◎
Clients SHOULD ignore the immutable extension for resources that do not provide a strong indication that the stored response size is the correct response size such as responses delimited by connection close.
</li>
</ul>

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

<p>
`immutable$sdir 拡張は、
`RFC7234$r `§ ~cache指令~registry＠~RFC7234#cache.directive.registry§
に述べられる指針の下で，
`~HTTP~cache指令~registry＠~IANA-a/http-cache-directives$cite
に登録された：
◎
The immutable extension has been registered in the “Hypertext Transfer Protocol (HTTP) Cache Directive Registry” per the guidelines described in Section 7.1 of [RFC7234].
</p>

<ul>
	<li>
~cache指令： `immutable$sdir
◎
Cache Directive: immutable
</li>
	<li>
参照： RFC 8246
◎
Reference: RFC 8246
</li>
</ul>

	</section>
	<section id="acknowledgments">
<h2 title="Acknowledgments">謝辞</h2>

<p lang="en">
Thank you to Ben Maurer for partnership in developing and testing this idea. Thank you to Amos Jeffries for help with proxy interactions and to Mark Nottingham for help with the documentation.
</p>

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