Purge mechanisms

Related to https://github.com/WICG/webpackage/issues/324

While talking to @bratell-at-opera about signed exchanges, he raised concerns about invalid content continuing to circulate after its publisher realized it is invalid.

Thinking about that problem, it's very similar to the one for which CDNs offer purge mechanisms:

• Articles may include typos, embarrassing mistakes or even false information that can expose the publisher from a legal perspective. Once that is discovered, publishers are likely to want to take down that content immediately.
• E-commerce sites may include pricing mistakes, which they typically want to correct ASAP, as that content can cause them to lose money.
• Court order compliance may also be a reason a content's publisher may want it to no longer be considered valid.

Talking to @jyasskin, the validityUrl can be used in order to verify that the content is still valid from the publisher's perspective. Although it was meant for intermediaries, we can use the same value for browser-side validation, to make sure the browser doesn't display invalid content.

The browser would fetch the validity information when navigating to an SXG page. (assuming the browser is online)
If the SXG content is invalid, the browser would force its reload. Assuming that caches validate content regularly, very few users would actually witness those reloads, in the already rare case that content needed to be purged.

This won't solve purge for offline access, but that's similar to any offline content (e.g. in a PWA or a native app)

Thoughts?

Start with the related webpackage issue 324 and the discussion in this issue about signed exchanges and validityUrl. The proposal concerns browser-side validation and forced reloads for invalid SXG content; done would require an agreed design for purge behavior, including the stated limitation for offline access.