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

JakeChampion/fetch#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