no-store and other caches

[mnot]

We say that we don't restrict how other caches (e.g., higher-layer in the browser, back/forward) interpret cache directives, but I think it would be useful to give a bit more guidance here, as this causes a lot of confusion and interoperability problems (since the browsers still haven't sorted out the various other caches' operation).

For example, we could give string guidance (non-normative) that no-store should be respected by other caches.

[annevk]

All of these caches are in front of the networking stack and in theory might not even have all response headers if converted to a more optimal representation.

If you consider JavaScript modules, they are de-duped based on their request URL in a module map. If the first response for such a URL had no-store, we still wouldn't be making any further requests. The same goes for images, style sheets, and some other resources as I understand it and for some of these changing that would result in compatibility issues (or presumably functional errors in case of module maps).

For back-forward in particular it might be worth reading whatwg/html#5879. There's a worry that an explicit opt-out could end up cargo-culted and make the feature unusable.

[mnot]

@annevk that makes sense, I agree the current wording is too strong. How about changing

In particular, when an application caches data and does not make this
apparent to or easily controllable by the user, it is strongly encouraged to
honour basic control mechanisms like Cache-Control: no-store, as they
indicate the resource's intent regarding caching.

to:

In particular, when an application caches data and does not make this
apparent to or easily controllable by the user, it is strongly encouraged to
define its operation with respect to HTTP cache directives, so as
not to surprise authors who expect caching semantics
to be honoured. For example, while it might be reasonable to define an
application cache "above" HTTP that allows a response containing
Cache-Control: no-store to be reused for requests that are directly related
to the request that fetched it (such as those created during the same page
load), it would likely be surprising and confusing to users and authors if it
were allowed to be reused for requests unrelated in any way to the one from
which it was obtained.

[annevk]

I think that's good. Some of the caches I mentioned do cross page loads (e.g., images and style sheets). However, I think the statement about those is correct and we should be better about explaining how they fit in and make sense (and perhaps adjust if they don't).

[yadij]

It seems to me that cross-page loads are exactly the type of thing that a sender of no-store is trying to avoid. It is the type of flag sent on highly sensitive or volatile data. Images, stylesheets, etc which have cross-page relevance should not be using it.