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

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

客户端提出此请求:

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 和其他 header ？或者，客户端是否有义务遵守原始缓存结果附带的 CORS header ？

The Fetch standard相当复杂，但它包含诸如“因为 CORS 检查不适用于状态为 304 或 407 的响应......”之类的短语，这让我怀疑在 304 响应中不需要新的 CORS header 。

另一方面，我对 § 4.6 的阅读步骤 10.4 建议 304 响应中的 header 优先，甚至替换原始 GET 响应 header 中的任何缓存结果。

最佳答案

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

有一些边缘情况:

即使客户端未执行验证请求，服务器也可能返回 304 响应。在这种情况下，它必须具有 CORS header ，因为 CORS 检查将在 304 响应上执行(而不是使用 304 响应更新的存储响应)。
304 响应可以更新 CORS header 。 (我不确定我们是否有足够的测试覆盖率来应对这种情况。)

关于http - 对 CORS 请求的 304 Not Modified 响应是否应该包含 CORS header ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/67730604/