Re: [whatwg/fetch] redirects and etag/if-none-match (Issue #1770)

> Okay so if HTTP-network-or-cache fetch step 8.25.1 gives us a non-200 response we should not be pretending we can revalidate.

That's my understanding, at least. (I suppose it's also plausible that the `storedResponse` variable not having any body contents could cause it to be considered null.)

> I guess the Chromium code says it makes sense for 206 as well, but isn't a 304 always translated to a 200?

What does 304 translating to a 200 mean? From what I can tell, a 304 response causes the client to completely ignore the response body.

So 304 behavior in practice seems inconsistent among browsers. See https://cr.kungfoo.net/mrpickles/http_cache/res_304_with_200_first.php for a quick demo of 304 and ETag behavior.

- On Chrome and Safari, the client will send `If-None-Match` headers on subsequent requests if the original response had a 200 and an ETag.
- On Firefox, the client never seems to be send `If-None-Match` headers. I'm not sure if this is some browser setting, but it was the case for both normal and private windows.
- On Chrome, making a request to a page that always 304's is effectively a no-op.
- On Safari and Firefox, making a request to a page that always 304's will render the (empty) page.

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

Message ID: <whatwg/fetch/issues/1770/2310575722@github.com>