Description
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, userlangIf 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.