Easier way to attach `ETag` to `If-None-Match` after #3562

[SukkaW]

This would solve...

3562 introduces HTTP Caching (RFC9110) to undici, which also implements HTTP 304 with If-Modified-Since. But it seems that ETag is missing.

cc @flakey5

The implementation should look like...

IMHO #3562 should not be delayed anymore, this could be implemented after #3562 is merged.

The undici could check the stored ETag header from the cache store and use that to negotiate with the If-None-Match in future requests. If the server returns HTTP 304, undici would then return the cached (transparent) HTTP 200 response to the client (the same behavior of fetch as in browsers).

Additional context

3562

https://github.com/JakeChampion/fetch/issues/241

ETag is described in RFC9110 here: https://httpwg.org/specs/rfc9110.html#field.etag If-None-Match is described in RFC9110 here: https://httpwg.org/specs/rfc9110.html#field.if-none-match HTTP 304 is described in RFC9110 here: https://httpwg.org/specs/rfc9110.html#status.304 The handling of HTTP 304 is described in RFC9110 here: https://httpwg.org/specs/rfc9111.html#freshening.responses

[SukkaW]

I have a question. In the fetch spec, 304 (along with some other status codes like 101 and 204) are null body status (https://fetch.spec.whatwg.org/#concept-status).

undici could return a "transparent" cached Response object with 200 OKs when the server returns 304 (which is also what browsers do), which consists as I mentioned.

But in the context of Node.js, some people might also want to know whether the response is from cached or not.

[mcollina]

We haven't really assessed if/how this would integrate with fetch.