[whatwg/fetch] Refreshing of stale response assumed to always be successful (#950)

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](https://tools.ietf.org/html/rfc7234#section-4.3.4) 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 from updating stored responses, for example:

> If the new response contains a strong validator (see Section 2.1
      of [RFC7232]), then that strong validator identifies the selected
      representation for update.  All of the stored responses with the
      same strong validator are selected.  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 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 4 conditional upon selecting a resource for update based on the the 304 response, and setting `storedResponse` to the option 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 HTTP-network fetch.

Please let me know what you think.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/950