http - 对 CORS 请求的 304 Not Modified 响应是否应该包含 CORS header ？

Question

假设一个客户端发出了一个跨域请求来读取一个对象，该对象通过了，并且客户端缓存了结果。现在，客户端发出一个新的读取对象的请求，而之前的结果仍然缓存在浏览器中。
客户端发出此请求:

GET /pony.png HTTP/1.1

Host: server.com
Origin: field.com
If-None-Match: "etag-abcd"

现在，假设“etag-abcd”对该对象有效。服务器回复

HTTP/1.1 304 Not Modified

Etag: "etag-abcd"
Date: Tue, ...
Expires: Wed, ...

如果这是一个有效的跨域请求，服务器是否有义务提供适当的 Access-Control-Allow-Origin和其他标题？或者，客户端是否有义务尊重与原始缓存结果一起出现的 CORS header ？
The Fetch standard非常复杂，但它包含诸如“因为 CORS 检查不适用于状态为 304 或 407 的响应......”之类的短语，这让我怀疑在 304 响应中不需要新的 CORS header 。
另一方面，我对§ 4.6的阅读，第 10.4 步，建议 304 响应中的 header 优先，甚至替换原始 GET 响应 header 中的任何缓存结果。

Answer 1

是的，HTTP-network-or-cache fetch 确实处理 304 响应，但它最终返回更新的存储响应，在 HTTP fetch 中执行 CORS 检查。因此，对于典型的 304，不需要 CORS header ，因为它们已经存在于存储的响应中。
有一些边缘情况:

即使客户端不执行验证请求，服务器也可能返回 304 响应。在这种情况下，它将必须具有 CORS header ，因为将对 304 响应执行 CORS 检查(而不是使用 304 响应更新的存储响应)。

304 响应可以更新 CORS header 。 (我不确定我们对这种情况有足够的测试覆盖率。)