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

@mnot thanks for pointing that out. That doc seems to clarify in more details which headers to update.

So I'm trying to understand how to best phrase this in Fetch, also in the light of [4.3.3](https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#rfc.section.4.3.3).

My first question: is it possible for a server to respond with a 304, but with a totally different strong validator? Even if possible, should the cache actually do something in such a case? That is actually the case I was thinking about initially, and my hunch was that the cache in such a case(received a 304, but cannot find any matching stored response) should make a new request that is not a validation request(See the current wording in the PR). 

However, looking more closely at 4.3.3, it seems that the server in such a case would instead respond with a full response, and the cache could then use it(and MAY replace the stored once). 

And that seems already covered by Fetch, via step 7.5 of https://fetch.spec.whatwg.org/#http-network-or-cache-fetch.

So perhaps receiving a 304, but being unable to match it with a stored response for update, is an edge case and perhaps a bug on the server(which should really send a full response back if it is unable to send a 304 matching the validator found in the validation request), and not something we should address in fetch?

-- 
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#issuecomment-649324760