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

I took a look through the cache tests and spec, and from what I can tell, it doesn't actually seem to conflict with the fetch spec changes. (Note that this isn't any proposal to change any spec, but rather my observations on the existing specs and whether they'd conflict.)

If we look at the cache tests, the logic basically goes as follows:

1. The client sends a request with `Cache-Control` headers set accordingly.
2. The server gives a response with any status code.
3. The client seconds a second request, and the server gives a 304 response.
4. In such a case, the original response should have been cached.

The section of the fetch spec goes over the slightly different logic:
1. The client sends a request (not necessarily with `Cache-Control` headers set accordingly).
2. The server sends an `ETag` value back. The response status code may vary.
3. Depending on the response status code, should the client include an `If-None-Match` header in subsequent requests?

The fetch spec changes discussed in this thread focus more on **when the client chooses to send `If-None-Match` headers**, whereas the caching spec is more about **when the client is obligated to cache results**. So they don't necessarily conflict. For example, the browser may arbitrarily choose whether or not to send `If-None-Match` headers, but if the HTTP response is a 304, it'll still need to use the cached response from a previous request.

So from what I can tell, tweaking behavior around the fetch spec does not have to conflict with the HTTP cache spec, since the behavior we're looking to adjust is around request headers. This is my understanding after looking around at the specs, so please double check my thought process and correct me if I'm mistaken or missing something.

### Miscellaneous/tangential observations

To amend a previous quote:

> And 200 and 206 are the only status codes that imply that there's content to cache.

> > And 200 and 206 are the only status codes that imply that there's **probably interesting** content to cache, **such that the browser might actively want to ask the server to confirm whether it should use the cached results**.

Also, from what I can tell, the "conditional requests" section of the cache tests (https://cache-tests.fyi/#conditional-inm) cover how the cache should response if `If-None-Match` headeres are sent, but it does not specify when the client must send those headers. So that doesn't conflict with the fetch spec discussion in this thread either.

The caching spec does bring up a fair point that all response status codes should be cache-able. So checking status code in step `8.25.2` of [network-or-cache-fetch](https://fetch.spec.whatwg.org/#http-network-or-cache-fetch) might be too broad. It may make sense to modify step `8.25.2.2.2` or around there. (This is just me musing to myself, not an actual change proposal.)



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

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