Prefetching and cookie changes

[jeremyroman]

Even though prefetches have a short lifetime, it is possible for a prefetched response to be "stale" by the time it is used due to a change in the user state (e.g., logging out).

This could be surprising as the user expects to observe this change, or in the worst case, a security issue if they have logged out on a public device and the next user is able to access a prefetched page (though this is not the only way this can happen). Developers can work around this by not using prefetch or prerender, but we'd like for them to not have to make that tradeoff.

However, Vary: Cookie is infamous for being too big a hammer, since many origins set a variety of cookies which shouldn't invalidate huge swathes of the cache.

Instead, browsers should respect response header fields which allow more specific cache invalidation, most likely by cookie name.

---

This is consistent with the Cookie-Indices proposal, which describes this like:

Vary: Cookie
Cookie-Indices: sessionid, userlang

If prefetching can be consistent with how ordinary HTTP caches work, that would be ideal -- it would reduce developer toil.

It remains to be determined how we should deal with cases where a prefetched response contains an effective Set-Cookie header (or in the case of prerendering, script) which changes the value of the header, invalidating itself. Hopefully that's not common.

[slava-uxd]

This issue arises in my use case:

I am passing color mode (dark or light) to the server using a cookie. The cookie value changes with JavaScript when user interacts with the color mode toggle.

The preloaded pages are requested before that, so it is done with a cookie that has outdated value for color mode.

What do I need to do "refresh" or "re-trigger" pre-rendering again after cookie value has changed?

[domenic]

There are a number of options here.

This issue proposes that, in the future, you can say something like Cookie-Indices: colormode. In that case, if the user changes the color mode, we will discard the prerendered page. There would be no automatic retrigger and so you'd just lose prerendering in such cases, which is kind of sad.

The better solution is to make your prerendered page reactive to color mode changes. The way you would do this is the same way you would make a second tab reactive to color mode changes. That is, if the user opens your site in tab A and tab B, and changes the color mode in tab A, how would you code your site so that tab B instantly updates as well? Two options I can think of are:

• The CookieStore change event, if you want to stay cookie-centric; or
• BroadcastChannel, if you want to use a separate communications channel that doesn't require disk writes and reads

There may be others.

If, for some reason, you only want to process updates in prerendered pages, and not in the tab A/tab B situation I described above, then you use the same techniques as listed above, but guard your code using document.prerendering.