変異不能な HTTP 応答

1. 序論

~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.

一例として，ある~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].

自身の~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].

しかしながら，内容~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.

例えば， `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.

あいにく，`~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.

`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.

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

2. `immutable^dir `Cache-Control^h 拡張

~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.

`~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).

`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.

Cache-Control: max-age=31536000, immutable

3. ~securityの考慮点

`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:

• `~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.
• `~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.
• `~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.

4. ~IANA考慮点

`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].

• ~cache指令： `immutable$sdir ◎ Cache Directive: immutable
• 参照： RFC 8246 ◎ Reference: RFC 8246

謝辞

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.