对 CORS 请求的 304 Not Modified 响应是不是应该包含 CORS 标头？

Posted 2023-03-04

【中文标题】对 CORS 请求的 304 Not Modified 响应是不是应该包含 CORS 标头？

【英文标题】：Should a 304 Not Modified response to a CORS request contain CORS headers?对 CORS 请求的 304 Not Modified 响应是否应该包含 CORS 标头？

【发布时间】：2021-08-16 05:08:08

【问题描述】：

说一个客户端做了一个跨域请求读取一个对象，通过了，客户端缓存了结果。现在，客户端发出一个新的读取对象的请求，而之前的结果仍然缓存在浏览器中。

客户端发出此请求：

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 标头？

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

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

【参考方案1】：

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

有一些极端情况：

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

【讨论】：

我明白了。因此，304 响应中存在的任何标头都将替换先前 GET 响应中的任何标头，因此 304 可以更改 CORS 响应。但是如果 304 省略了标头，那么应该保留原始的 CORS 标头。那么，如果我理解正确，答案是服务器没有义务在 304 响应中包含 CORS 标头，但如果需要，304 将提供更改标头的机会。谢谢！

来晚了，但你理解正确。

谢谢，这很有帮助！