Intent to Prototype + PSA: making Back/Forward Cache work despite Cache-control: no-store
Kenji Baheux
bcc: blink-dev, chromium-dev
Hi,
Contact emails
kenji...@chromium.org, fer...@chromium.org, deno...@chromium.org
Specification
We would like to share our current plan to make Back/Forward Cache (BFCache) work despite the presence of Cache-control: no-store (CCNS) HTTP headers. Please, have a look, share around, and let us know if there is room for improvements or big concerns.
Context
The CCNS HTTP header is designed to prevent HTTP caches from storing a response.
While this wasn’t required by any specification*, all implementations of BFCache are currently ignoring pages with CCNS. This means that many back/forward navigations are much slower than necessary.
Since BFCache has long been a thing, many websites have built a dependency on the unintended interaction between CCNS and BFCaches. In particular, CCNS is used on pages potentially containing personalized details (i.e. logged in state). The expectation vis-a-vis BFCache & CCNS is that if a user logs out from the website, then the previously visited pages can’t be restored when another user hits the back button.
*: Strictly speaking, the specification for the Cache-Control header doesn’t apply to BFCaches, because those are not HTTP caches.
Goals
We would like to:
Improve back/forward navigations for websites using CCNS...
... while preventing any significant surprises, and...
offer better guidance for the future, with the benefit of hindsight.
Tentative timeline
Heads-up (this announcement) + call for feedback + adjustments if needed.
M100+ (Chrome Canary): work-in-progress implementation behind a command line (see the hands-on section); partners checks.
TBD: Trial run (monitor metrics & feedback from community).
TBD: Launch or adjust + try again.
In a nutshell (see this doc for all the details)
Our tentative proposal consists of storing CCNS pages in BFCache with the behaviors and carve-outs detailed below.
Note that this is subject to changes, based on feedback from the community, and learnings from experimentation. We also intend to work with other browser vendors and standard bodies on refining & specifying these behaviors, and carve-outs.
Behaviors
Evict same-site pages when any HTTP-only cookie changes.
Evict same-site pages when the HTTP header Clear-Site-Data includes any of the following values: "cache", “executionContexts”, “*” (to be confirmed with spec editors).
Evict pages if their HTTP-Authentication state changes.
Carve-outs:
In any of the following conditions, CCNS pages will NOT be stored in BFCache:
When the user has disabled JavaScript.
When the CCNS page has no HTTP-only cookies. Note: this also covers the cases in which the user has disabled cookies.
When the behavior is disabled by the administrator of an enterprise/education deployment, via a dedicated group policy. Note: to minimize surprises, the group policy will default to disabling this new behavior, if any other group policy is set (i.e. requiring no action to preserve the status quo). This defaulting behavior may change in the future depending on what we will learn about these managed environments.
Let us know if you are aware of any significant scenarios that we missed, or for which the proposed plan would create new problems:
Reply to this thread with your feedback.
Or start a new thread on bfcac...@chromium.org with [CCNS] in the subject line
Hands-on
An experimental version can be enabled via the command line option below:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-http-only-cookie-change
Note: this is a work-in-progress implementation, and some secondary aspects are currently missing. Notably, the Clear-Site-Data behavior is not implemented yet.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No support on WebView planned at the moment.
Is this feature fully tested by web-platform-tests?
No.
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1228611
Link to entry on the Chrome Platform Status