Intent to Prototype + PSA: making Back/Forward Cache work despite Cache-control: no-store

Skip to first unread message

Kenji Baheux

Feb 16, 2022, 9:57:41 PM2/16/22

bcc: blink-dev, chromium-dev


Contact emails,,


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.


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


We would like to:

  1. Improve back/forward navigations for websites using CCNS...

  2. ... while preventing any significant surprises, and...

  3. offer better guidance for the future, with the benefit of hindsight.

Tentative timeline

  1. Heads-up (this announcement) + call for feedback + adjustments if needed.

  2. M100+ (Chrome Canary): work-in-progress implementation behind a command line (see the hands-on section); partners checks.

  3. TBD: Trial run (monitor metrics & feedback from community).

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


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


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 with [CCNS] in the subject line


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?


Tracking bug

Link to entry on the Chrome Platform Status

Martin Šrámek

Mar 1, 2022, 5:45:16 PM3/1/22
Hi folks,

I'd like to signal-boost this and ask for ample developer feedback.

This proposal is making two core assumptions:

1. That developers who use the CCNS header intend to specifically prevent the usage of HTTP Cache. My hypothesis is that developers use the header as a more general semantic expression of their intent to treat the resource as ephemeral. It's just that back in the day when CCNS was spec'd, the HTTP cache was the only way a resource could be persisted, and so we ended up equating the developer intent with the specific technology.

If there are use cases to exclude a resource from the HTTP Cache but not BFCache, I'd be interested in hearing about them from developers.

2. That observing sign-out via cookies gives us a solid grasp of situations where the user is signing out, and more importantly that signing out is the only situation where the developer would want a resource to be ephemeral. I appreciate that you have considered some other options how a sign out could happen, but ultimately all of those are heuristics. Heuristics are very useful for the browser to try and do the right thing in the absence of a signal from the developer, but here we already have a signal.

I'd be interested in hearing from developers if there are other common situations that such heuristics may be overlooking.

Without positive feedback from developers on this Intent, the privacy and security teams are opposed to shipping it. If we still want to leave the doors open for use cases where HTTP caching is undesired but BF caching is, we suggest introducing an opt-in header that will serve as a carveout from CCNS instead.

Best regards,

Chromium Developers mailing list:
View archives, change email options, or unsubscribe:
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Kenji Baheux

Apr 13, 2022, 2:23:13 AM4/13/22
to bfcache-dev, Martin Šrámek,, Fergal Daly,, Kenji Baheux

On Wednesday, March 2, 2022 at 7:45:16 AM UTC+9 Martin Šrámek wrote:
Hi folks,

I'd like to signal-boost this and ask for ample developer feedback.

We reached out to external partners and ran a survey.

High level takeaways from the survey:
  • Sample size: 370+ respondents (web developers)
  • 74% thought it was appealing to make Back/Forward Cache (BFCache) work despite the presence of Cache-control: no-store (CCNS) HTTP headers.
  • 84% were supportive of us pursuing the proposal after reading our public doc.

Direct partners outreach echoed this supportive sentiment, and even included folks who removed their CCNS headers right away :)

I hope this helps address your initial concerns.
To unsubscribe from this group and stop receiving emails from it, send an email to

Martin Šrámek

Apr 14, 2022, 8:04:55 AM4/14/22
to Kenji Baheux,, Fergal Daly,
Thanks a lot for the offline discussions and following up, Kenji!

This does address our concerns.


To unsubscribe from this group and stop receiving emails from it, send an email to
Reply all
Reply to author
0 new messages