1. 序論
現代の~HTTP配備は、 複数~層からなる~cachingを利用することが多い。 例えば,ある~web~siteは、 当の`生成元~server$自身が使役する~cacheを利用することもあれば,[ `生成元~server$と同じ~network内に ある~caching層を配備する/ ~Internet全体に分散された いくつかの~CDNを利用する/ ~browserによる~cachingから便益を得る ]こともあろう。 ◎ Modern deployments of HTTP often use multiple layers of caching. For example, a website might use a cache on the origin server itself; it might deploy a caching layer in the same network as the origin server, it might use one or more CDNs that are distributed throughout the Internet, and it might benefit from browser caching as well.
これら異なる~classに属する~cacheは、 別々に制御する方が望ましいことも多い。 そのためには、[ `~cache指令$の~targetを ある~classに属する~cacheに限る ]ような何らかの手段が必要yである。 例えば、 ある公表者が[ 自身に関係性がある~cache(~CDN~cacheなど)の内容を無効~化する仕組み ]を備えている場合、 そこにだけ,他の~cacheより手厚い施策をアテガいたいと求めることもあろう。 ◎ Because it is often desirable to control these different classes of caches separately, some means of targeting cache directives at them is necessary. For example, if a publisher has a mechanism to invalidate the contents of a cache that it has a relationship with (such as a CDN cache), they might be more comfortable assigning a more generous caching policy to it while still wanting to restrict the behavior of other caches.
`Cache-Control$h 応答~header `HTTP-CACHING$r は、 ~cachingの挙動を指令するために広く利用される。 しかしながら、 ~targetを差別化するものは限られる: 一部の`~cache指令$は,特定の~classに属する~cacheを~targetにするが (例: `s-maxage$sdir 指令の場合,`共用~cache$)、 既存の`~cache指令$すべてに一貫して可用な~target法はない (例: `stale-while-revalidate$sdir )。 このことは,とりわけ、 潜在的な~targetの数と伴に~caching拡張の数が増すに伴い,問題になり得る。 ◎ The HTTP Cache-Control response header field (defined in Section 5.2 of [HTTP-CACHING]) is widely used to direct caching behavior. However, it is relatively undifferentiated; while some cache directives (e.g., s-maxage) are targeted at a specific class of caches (for s-maxage, shared caches), targeting is not consistently available across all existing cache directives (e.g., stale-while-revalidate). This is problematic especially as the number of caching extensions grows along with the number of potential targets.
一部の実装は、 この課題を克服するため,場当的な制御の仕組みを定義したが、 それらは,相互運用能に乏しい。 `2@#targeted§では、 ~HTTP応答~headerを利用する~targeted~cache制御~用に, 標準な~frameworkを定義する。 `3@#cdn-cache-control§では、 そのような~headerとして, `CDN-Cache-Control^h 応答~headerを定義する。 ◎ Some implementations have defined ad hoc control mechanisms to overcome this issue, but their interoperability is low. Section 2 defines a standard framework for targeted cache control using HTTP response headers, and Section 3 defines one such header: the CDN-Cache-Control response header field.
1.1. 表記上の規約
この文書~内の~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.
2. ~targeted~cache制御~header
`~targeted~cache制御~header^dfn — 以下では、 `~targeted~field@ と称される† — は、 その意味論は `Cache-Control$h 応答~headerと同じであるが, その`~field名$は[ その`~field値$に与えられた`~cache指令$の~targetを指示する,別個な名前 ]にされた~HTTP応答~headerである。 ◎ A Targeted Cache-Control Header Field (hereafter "targeted field") is an HTTP response header field that has the same semantics as the Cache-Control response header field ([HTTP-CACHING], Section 5.2). However, it has a distinct field name that indicates the target for its cache directives.
【† なぜ,より汎用な語 “`~field$” が利用されるのかは不明。 (将来には、 `~trailer$としても利用される何らかの拡張が意図されているのかも?) 】
例えば、 次は: ◎ For example:
CDN-Cache-Control: max-age=60
`~targeted~field$であり、 `3@#cdn-cache-control§にて定義されるとおり,~CDNに適用される。 ◎ is a targeted field that applies to CDNs, as defined in Section 3.
2.1. 構文
`~targeted~field$は、 `有構造~field$であり,`~sf辞書$ `STRUCTURED-FIELDS$r を値にとる。 この辞書を成す各~memberは、 ~HTTP~cache応答~指令を与える — `標準な応答~指令@~HTTPcache#cache-response-directive$, `拡張~応答~指令@~HTTPcache#cache.control.extensions$ `HTTP-CACHING$r どちらも含めて。 `~targeted~field$の構文は, `Cache-Control$h ~fieldと一致する部分も多いが、 ~errorの取扱いに相違点がある — `有構造~field$用の構文解析器に代えて `Cache-Control$h 用の構文解析器を利用すると, 相互運用能の課題を導入し得ることに注意。 ◎ Targeted fields are Dictionary Structured Fields (Section 3.2 of [STRUCTURED-FIELDS]). Each member of the Dictionary is an HTTP cache response directive (Section 5.2.2 of [HTTP-CACHING]) including extension response directives (as per Section 5.2.3 of [HTTP-CACHING]). Note that while targeted fields often have the same syntax as Cache-Control fields, differences in error handling mean that using a Cache-Control parser rather than a Structured Fields parser can introduce interoperability issues.
`~cache指令$は、 `有構造~data型$の用語では定義されてないので、 それらの値を適切な型に対応付けることが必要yである。 `HTTP-CACHING$r `Cache-Control§h は、 `~cache指令$の値【 `HTTP-CACHING^r では “引数” と称される】を[ 無し / `quoted-string$p / `token$p ]いずれかとして定義する。 ◎ Because cache directives are not defined in terms of structured data types, it is necessary to map their values into the appropriate types. Section 5.2 of [HTTP-CACHING] defines cache directive values to be either absent, a quoted-string, or a token.
このことは、 `~cache指令$の値を, 次に従って`有構造~data型$ `STRUCTURED-FIELDS$r に対応付けることを意味する: ◎ This means that cache directives that\
-
値は無いならば`~sf真偽値$ ◎ have no value will be mapped to a Boolean (Section 3.3.6 of [STRUCTURED-FIELDS]).\
【 真偽値 ~T をとる。 この値は、 直列化する際には省略されるので,構文の後方-互換性は保たれる。 一方で, ~F を利用した場合、 そうならない。 】
- `quoted-string$p をとるときは、 `~sf文字列$ ◎ When the value is a quoted-string, it will be mapped to a String (Section 3.3.3 of [STRUCTURED-FIELDS]), and when it is a token,\
- `token$p をとるときは、 当の値の内容に応じて,次に挙げるいずれか ⇒ `~sf~token$/ `~sf整数$/ `~sf~decimal$ ◎ it will map to a Token (Section 3.3.4 of [STRUCTURED-FIELDS]), an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]), or a Decimal (Section 3.3.2 of [STRUCTURED-FIELDS]), depending on the content of the value.
例えば、 次に挙げる指令 `HTTP-CACHING$r に対しては: ◎ For example,\
- `max-age$sdir 指令は、 `~sf整数$を値にとる。 ◎ the max-age directive (Section 5.2.2.1 of [HTTP-CACHING]) has an integer value;\
- `no-store$sdir 指令は、 常に`~sf真偽値$ ~T をとる。 ◎ no-store (Section 5.2.2.5 of [HTTP-CACHING]) always has a Boolean true value,\
- `no-cache$sdir 指令は、 次のいずれかを値にとる ⇒# `~sf真偽値$ ~T / ~commaで区切られた~listを成す一連の`~field名$を包含している`~sf文字列$† ◎ and no-cache (Section 5.2.2.4 of [HTTP-CACHING]) has a value that can be either Boolean true or a string containing a comma-delimited list of field names.
【† `~sf内縁~list$に対応付けないのは不自然にも思われるが、 そうすると,構文の後方-互換性が得られなくなるからかもしれない。 】
実装は、 当の`~cache指令$に対し,[ 上述したとおり推定される拘束 ]に違反する値を`生成-$してはナラナイ。 特に,文字列~値のうち最初の文字が[ `ALPHA$P, "`*^c" ]でないものは、 他の型に誤認されないよう,`~sf文字列$として`生成-$しなければナラナイ。 ◎ Implementations MUST NOT generate values that violate these inferred constraints on the cache directive's value. In particular, string values whose first character is not alphabetic or "*" MUST be generated as Strings so that they are not mistaken for other types.
実装は、[ 上述したとおり推定される拘束 ]に違反する値を消費するベキでない。 例えば、 `~sf~decimal$を値に伴う `max-age$sdir を消費している実装が, 値を`~sf整数$に型強制すると、 他の実装と異なる挙動になり,相互運用能の課題をもたらし得る。 ◎ Implementations SHOULD NOT consume values that violate these inferred constraints. For example, a consuming implementation that coerces a max-age with a decimal value into an integer would behave differently than other implementations, potentially causing interoperability issues.
`~cache指令$の値に伴って受信した`~sf~parameter群$は、 他の取扱いが明示的に指定されない限り, 無視されることになる。 ◎ Parameters received on cache directives are to be ignored, unless other handling is explicitly specified.
所与の応答~内の ある`~targeted~field$に対し, その値が空な場合, あるいは構文解析~errorに遭遇した場合、 `~cache$は,その~fieldを無視しなければナラナイ (すなわち、 当の~fieldは無かったかのように挙動する — 他の~cache制御の仕組みがあれば、 それに~fall-backすると見込まれる)。 ◎ If a targeted field in a given response is empty, or a parsing error is encountered, that field MUST be ignored by the cache (i.e., it behaves as if the field were not present, likely falling back to other cache-control mechanisms present).
2.2. ~cacheの挙動
この仕様を実装する~cacheは、 `~target~list@ を保守することになる。 それは、[ ~cacheが~caching施策~用に利用する`~targeted~field$ ]の名前からなる有順序~listである。 それらの順序は、 最も適用-可能なものが最初に来るよう,優先度を反映する。 `~target~list$は、 実装に依存して, 固定されることも, 利用者が環境設定-可能なことも, 要請ごとに生成されることもあろう。 ◎ A cache that implements this specification maintains a target list. A target list is an ordered list of the targeted field names that it uses for caching policy, with the order reflecting priority from most applicable to least. The target list might be fixed, user configurable, or generated per request, depending upon the implementation.
例えば、 ある~CDN~cacheが[ `CDN-Cache-Control$h, 当の~CDNに特有な `ExampleCDN-Cache-Control^h ]両~headerを~supportしていて, 後者は前者を上書きしているならば、 その`~target~list$は,順に[ `ExampleCDN-Cache-Control^c, `CDN-Cache-Control^c ]からなる。 ◎ For example, a CDN cache might support both CDN-Cache-Control and a header specific to that CDN, ExampleCDN-Cache-Control, with the latter overriding the former. Its target list would be: • [ExampleCDN-Cache-Control, CDN-Cache-Control]
この仕様を実装する~cacheは、 受信した各~応答 %応答 に対し, 次に従わなければナラナイ:
-
当の~cacheの`~target~list$を成す ~EACH( %~field名 ) に対し:
- %~header節 ~LET %応答 の`~header節$
- ~IF[ %~header節 内に`~field名$が %~field名 に合致する~fieldは無い ] ⇒ ~CONTINUE
- %~field値 ~LET %~header節 における %~field名 の`~field値$
- ~IF[ %~field値 は空である ]~OR[ %~field値 は妥当でない ] ⇒ ~CONTINUE
- %~field値 を利用して %応答 用の~caching施策を決定する — %応答 内の[ `Cache-Control$h, `Expires$h ]~headerは無視する
- ~RET
- (適用される~targeted~fieldは無かった。) ~HTTPにより要求されるとおり,他の~cache制御の仕組みに~fall-backする。 `HTTP-CACHING$r
`~targeted~field$を利用する~cacheは: ◎ ↓
- 自身の`~target~list$には無い`~targeted~field$により, 自身の挙動を変更してはナラナイ — それらは、 そのまま通過させなければナラナイ。 ◎ Targeted fields that are not on a cache's target list MUST NOT change that cache's behavior and MUST be passed through.
- 次に挙げる`~cache指令$の意味論を実装しなければナラナイ ⇒# `max-age$sdir, `must-revalidate$sdir, `no-store$sdir, `no-cache$sdir, `private$sdir ◎ Caches that use a targeted field MUST implement the semantics of the following cache directives: • max-age • must-revalidate • no-store • no-cache • private
- 他の`~cache指令$のうち `Cache-Control$h 応答~headerにて~supportするものも, 実装するベキである(拡張`~cache指令$も含めて)。 ◎ Furthermore, they SHOULD implement other cache directives (including extension cache directives) that they support in the Cache-Control response header field.
`~targeted~field$における[ 各`~cache指令$の意味論, それらの優先順位 ]は、 `Cache-Control$h におけるそれと同じになる。 特に、[ `no-store$sdir / `no-cache$sdir ]は, `max-age$sdir を運用-不能にする。 また、 認識されない拡張~指令は,無視される。 ◎ The semantics and precedence of cache directives in a targeted field are the same as those in Cache-Control. In particular, no-store and no-cache make max-age inoperative, and unrecognized extension directives are ignored.
2.3. ~HTTP鮮度との相互作用
~HTTP~cache法は、 単独の鮮度~model — `HTTP-CACHING$r `4.2@~HTTPcache#expiration.model§にて定義される,`端点間$な~model — を備える。 追加的な鮮度の仕組みが,要請の経路に沿いにある~cacheのうち一部に限り (例えば、`~targeted~field$を利用して) 可用にされた場合、 それら~cacheどうしの相互作用を注意深く考慮する必要がある。 特に,~targetにされた~cacheにおいては、 可用な`鮮度~維持期間$が他の~cacheより長くなるかもしれない — その結果、 他の~cacheにとって尚早に(あるいは,即時にさえ)`非新鮮$に見える応答を~serveして, ~cache効率に負な影響iを及ぼすかもしれない。 ◎ HTTP caching has a single, end-to-end freshness model defined in Section 4.2 of [HTTP-CACHING]. When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered. In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to those other caches, negatively impacting cache efficiency.
例えば、 ある~CDN~cacheに格納-済みな応答が, 次の~headerを伴って~serveされたとする: ◎ For example, a response stored by a CDN cache might be served with the following headers:
Age: 1800 Cache-Control: max-age=600 CDN-Cache-Control: max-age=3600
この応答は、 ~CDN視点からは,~cacheされてから 30分【 1800秒 】までは`新鮮$な一方で、 他の~cacheにとっては,すでに`非新鮮$である。 さらなる論点は、 `AGE-PENALTY$r を見よ。 ◎ From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from the standpoint of other caches, this response is already stale. See [AGE-PENALTY] for more discussion.
~targetにされた~cacheに首尾一貫性を保つ強い仕組みがあるときは (例:`生成元~server$が,~cache済み応答を事前に能動的に無効~化する能を有するとき)、 これらの効果を軽減することが望ましいことが多い。 配備においては、 次に挙げる技法が見られる: ◎ When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects. Some techniques seen in deployments include:
- `Age$h ~headerを除去する ◎ Removing the Age header field
- `Date$h ~headerの値を現在の時刻に更新する ◎ Updating the Date header field value to the current time
- `Expires$h ~headerの値を[ 現在の時刻に `Cache-Control$h の `max-age$sdir 指令の値を加えた結果 ]に更新する ◎ Updating the Expires header field value to the current time, plus any Cache-Control: max-age value
この仕様は、 実装に対し,これらの効果を軽減するための特定の要件を何も設置しないが、 `~targeted~field$の定義は,それを行い得る。 ◎ This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so.
2.4. ~targeted~fieldの定義-法
特定0の~classに属する~cache用の`~targeted~field$は、 `~HTTP~field名~registry@~IANA-a/http-fields/$cite 内に登録を要請することにより定義できる。 ◎ A targeted field for a particular class of cache can be defined by requesting registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (<https://www.iana.org/assignments/http-fields/>).
登録~要請は、 仕様~文書として,この文書を利用できる — その事例では、 ~comment欄は,[ 当の`~targeted~field$は、 どの~classに属する~cacheに適用されるか ]を明瞭に定義するべきである。 代替として, 当の~field用に文書化されたものが他にある場合、 それを仕様~文書として利用できる。 ◎ Registration requests can use this document as the specification document; in which case, the Comments field should clearly define the class of caches that the targeted field applies to. Alternatively, if other documentation for the field has been created, it can be used as the specification document.
慣行により、 `~targeted~field$は,接尾辞 "`-Cache-Control^c" を伴う — 例: `ExampleCDN-Cache-Control^h 。 しかしながら,この接尾辞~自体を`~targeted~field$を識別するために利用してはナラナイ — それは慣行でしかない。 ◎ By convention, targeted fields have the suffix "-Cache-Control", e.g., "ExampleCDN-Cache-Control". However, this suffix MUST NOT be used on its own to identify targeted fields; it is only a convention.
3. `CDN-Cache-Control^h ~targeted ~field
`CDN-Cache-Control^h 応答~headerは、 `~targeted~field$【!§ 2@#targeted§】であり、[ `生成元~server$と`~client$の間に差挟まれた, 他の~cacheとは別々に応答を取扱うかもしれない~CDN~cache ]の挙動を制御することを許容する。 ◎ The CDN-Cache-Control response header field is a targeted field (Section 2) that allows origin servers to control the behavior of CDN caches interposed between them and clients separately from other caches that might handle the response.
それは、 `生成元~server$に利するよう運用される分散型の~networkの一部を成す~cache (~CDNと共通的に呼ばれる)に適用される。 ◎ It applies to caches that are part of a distributed network that operate on behalf of an origin server (commonly called a CDN).
`CDN-Cache-Control^h を利用する~CDN~cacheは、 概して,この~headerを`下流$の~CDN~cacheも利用できるよう回送することになる。 しかしながら、 それが望ましくないときは,この~headerを除去してもヨイ (例えば、 `下流$にて利用されないことが既知なので,そうするよう環境設定されているとき)。 ◎ CDN caches that use CDN-Cache-Control will typically forward this header so that downstream CDN caches can use it as well. However, they MAY remove it when this is undesirable (for example, when configured to do so because it is known not to be used downstream).
3.1. 例
例えば,次の~headerたちは、 当の応答を[ ~CDN~cache (すなわち、 自身の`~target~list$に `CDN-Cache-Control$h を~~含む~cache) に対しては 600秒まで/ 他の`共用~cache$に対しては 120秒 まで/ 残りの~cacheに対しては 60秒 まで ]`新鮮$であると見なすよう指図することになる: ◎ For example, the following header fields would instruct a CDN cache (i.e., a cache with a target list of [CDN-Cache-Control]) to consider the response fresh for 600 seconds, other shared caches to consider the response fresh for 120 seconds, and any remaining caches to consider the response fresh for 60 seconds:
Cache-Control: max-age=60, s-maxage=120 CDN-Cache-Control: max-age=600
次の~headerたちは、 ~CDN~cacheに対しては,当の応答を 600秒まで`新鮮$と見なすよう指図する一方で、 他すべての~cacheに対しては,当の応答を格納することを防止する: ◎ These header fields would instruct a CDN cache to consider the response fresh for 600 seconds, while all other caches would be prevented from storing it:
CDN-Cache-Control: max-age=600 Cache-Control: no-store
次においては、 `CDN-Cache-Control$h ~headerが無いので, すべての~cacheに対し,当の応答を格納することを防止することになる: ◎ Because CDN-Cache-Control is not present, this header field would prevent all caches from storing the response:
Cache-Control: no-store
一方で,次においては、 ~CDN~cacheを除くすべての~cacheに対し,当の応答を格納することを防止することになる: ◎ Whereas these would prevent all caches except for CDN caches from storing the response:
Cache-Control: no-store CDN-Cache-Control: none
( `none^c は、 登録-済み`~cache指令$ではないことに注意 — それが,ここにあるのは、 空な値を伴う~headerを送信すると無視されるので,それを避けるためである。) ◎ (Note that 'none' is not a registered cache directive; it is here to avoid sending a header field with an empty value, which would be ignored.)
4. ~IANA考慮点
~IANAは、 `HTTP$r により定義される `~HTTP~field名~registry@~IANA-a/http-fields/$cite に,次の~entryを登録した: ◎ IANA has registered the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by [HTTP]:
- ~field名 ⇒ `CDN-Cache-Control$h ◎ Field Name: • CDN-Cache-Control
- 位置付け ⇒ 恒久的 ◎ Status: • permanent
- 仕様~文書 ⇒ RFC 9213 ◎ Specification Document: • RFC 9213
- ~comment ⇒ 内容~送達~networkを~targetにする`~cache指令$ ◎ Comments: • Cache directives targeted at content delivery networks
5. ~securityの考慮点
`~HTTP~cache法^cite `HTTP-CACHING$r による~securityの考慮点が適用される。 ◎ The security considerations of HTTP caching [HTTP-CACHING] apply.
ある応答~内に複数の~caching施策を運ぶ能は、 異なる~systemどうしで応答が どう~cacheされるかについて混同をもたらし得る — その結果、 敏感な情報を伴う応答が意図nに反して再利用されることにもなり得る。 この理由から、 ~~十分な注意が必要である【!care must be exercised】。 ◎ The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different systems, potentially resulting in unintentional reuse of responses with sensitive information. For this reason, care must be exercised.