Should newer HTTP cache contents override signed exchange's inner content?

[kinu]

Currently the loading spec says the newer HTTP cache contents should override the stashed exchange if the cached one is newer, but discussing this with @sleevi we suspected this may not make a lot sense if the underlying HTTP cache is NOT single-keyed (e.g. is double-keyed / partitioned). So the question here is how much real benefit would this behavior have, and if we should really implement it.

(Context: Chromium currently doesn't implement this behavior, and no plan to do so until this issue is clarified or we see a real, clear benefit)

[jyasskin]

I think it has some value in blocking some downgrade attacks when loading a signed exchange for a top-level origin the user has already visited, even if cross-origin subresources are double-keyed. It'll help less for catching downgrades of common subresources being re-used by a new site.

What did you and @sleevi think it breaks?

[kinu]

I agree that this could still be beneficial for top-level origins. Reg: what it may break: I think @sleevi's stance has been more about we'll need more investigation to see if it'd make the best sense. And from impl pov: doing so simply requires more work, so we want to be very careful on the decisions. (Interested in if @sleevi has renewed thoughts)

[ithinkihaveacat]

Is the suggestion here that clicking on the reload button in the browser UI might not necessarily result in a network request to the origin if SXG content is available locally? This is the opposite of #295, FWIW.

Also, is there any difference between reload mechanisms? (The service worker spec requires force reload to go to network in all cases.)

[jyasskin]

@ithinkihaveacat No, a browser reload should always try to check the origin. This issue is about whether, if you've recently visited the origin, but a distributor offers you an older SXG, whether you use the newer from-origin content or the older SXG.