Refreshing of stale response assumed to always be successful

Step 7.4 of https://fetch.spec.whatwg.org/#http-network-or-cache-fetch says to:

• If the revalidatingFlag is set and forwardResponse’s status is 304, then:
  • Update storedResponse’s header list using forwardResponse’s header list, as per the "Freshening Stored Responses upon Validation" chapter of HTTP Caching
  • Set response to storedResponse.

However, Freshening Stored Responses upon Validation is subject to successfully selecting a stored response based on strong/weak/no validators found in the headers of the 304 response.

Some cases contain a MUST NOT directive preventing the cache from using the 304 to update any stored responses, for example:

If none of the stored
responses contain the same strong validator, then the cache MUST
NOT use the new response to update any stored responses.

There are a few potential issues that can be identified:

1. Fetch assumes that the 304 forwardResponse will update the previously set storedResponse, while in fact the cache might have to select a different stored resource for update, based on the validators found in the 304 response.
2. Step 4.2 always does a Set response to storedResponse. , while in fact the cache might not have been able to refresh storedResponse, or any other cached resource.
3. If the cache fails to refresh any stored response based on the 304, it seems that fetch should do a "normal" network fetch of the resource, and such hook is not found in the algorithm. Instead step 7.5 says to Set response to forwardResponse. (if response is null), so if an implementation were to not update response as part of Step 4, due to a failure to select a resource for update, it would seem that the 304 would then be set to be the response.

It would seem that a solution could be:

a. making Step 7.4 conditional upon selecting a resource for update based on the the 304 response, and setting storedResponse to the optional result from that operation,
b. and if unsuccesful, the algorithm should make a new network request that is not a validation request, and set forwardResponse to the result of this new HTTP-network fetch.

Please let me know what you think.