Chrome 73中阻止了CORB OPTIONS请求

Question

最近Chrome发布了一个更新版本，当我调用API时（直到今天为止还没有看到），Google会发出有关阻止CORB请求的警告。

跨源读取阻止（CORB）已阻止MIME类型为text / plain的跨源响应[domain]。有关详细信息，请参见https://www.chromestatus.com/feature/5629709824032768。

我已确定对API的请求成功，并且触发控制台警告的是预检OPTIONS请求。

调用API的应用程序不会明确地进行OPTIONS请求，而是我已经了解到在进行跨域请求时浏览器强制执行此操作并由浏览器自动完成。

我可以确认OPTIONS请求响应未定义MIME类型。但是，我有些困惑，因为我理解OPTIONS响应仅为头文件，并且不包含正文。我不明白为什么这样的请求需要定义MIME类型。

此外，控制台警告显示请求被阻止；但是各种POST和GET请求都成功了。因此看起来OPTIONS请求实际上没有被阻止？

这是一个三部分的问题：

1. 为什么OPTIONS请求需要定义mime-type，当没有响应体时？
2. 如果plain/text不合适，那么OPTIONS请求的mime-type应该是什么？我是否可以假定application/json是正确的？
3. 如何配置我的Apache2服务器以包括所有预检OPTIONS请求的mime-type？

- Crayons

---

OPTIONS预检请求成功了。如果失败了，浏览器会在那里停止，永远不会尝试您的POST请求。您看到POST请求的事实表明预检成功了。OPTIONS请求不需要定义mime类型。问题中没有任何CORS问题的迹象。相反，您有一个CORB问题。问题中引用的错误消息表明您的代码正在获取text/plain响应，但是代码正在尝试在某些上下文中使用该响应，而浏览器不希望使用text/plain。 - sideshowbarker

如果您更新问题并添加一小段前端代码片段以显示您如何发出请求和如何使用响应，则可以在此处获得更好的帮助。例如，您可能会遇到CORB错误，因为您的代码尝试将text/plain响应解析为JSON。 - sideshowbarker

正如我所指出的，OPTIONS请求成功了，因为POST请求也成功了。你也是正确的，我也没有认为OPTIONS请求需要一个mime类型，但Chrome似乎认为它需要？你也是正确的，我没有CORS问题，我的问题不是关于CORS的，因此我没有提到它。正如你在示例POST响应中看到的，我返回了适当的mime类型--Chrome中的警告与OPTIONS请求有关，而这个请求并没有mime类型（因为我认为它不需要）。我开始相信这是Chrome的一个bug。 - Crayons

Answer 1

我已经解决了这些 CORB 警告的问题。

这个问题部分与我使用的 content-type-options: nosniff 头有关。我设置了这个头以防止浏览器尝试自行嗅探 content-type，从而删除 mime-type 技巧，特别是与用户上传的文件相关的攻击向量。

另一部分与返回的 content-type 有关，即 application/json;charset=utf-8。根据 Google 的文档，它指出：

返回的响应头包含“X-Content-Type-Options: nosniff”和不正确的“Content-Type”响应头的响应可能被阻止。

基于此，我着手检查IANA 网站上关于可接受媒体类型的信息。令我惊讶的是，对于 application/json 类型，实际上从未在任何 RFC 中定义过 charset 参数，并进一步注明：

此注册未定义 "charset" 参数。向其添加一个确实对符合规范的收件人没有任何影响。

基于此，我从内容类型application/json中删除了字符集，并确认在Chrome中停止了CORB警告。

总之，根据最近的Chrome发布，谷歌已选择开始更严格地处理mime-type。

最后，作为一个旁注，我们所有应用程序请求仍然成功的原因是因为在Chrome中似乎并没有强制执行跨域读取阻止（CORB）：

在大多数情况下，被阻止的响应不应影响网页的行为，并且可以安全地忽略CORB错误消息。

- Crayons

---

这里出现了完全相同的错误。你在OPTIONS请求的响应头中是否包含Content-Type: application/json？我从响应中删除了字符集，但仍然收到了那些警告（我的API不为OPTIONS请求提供Content-Type头）。 - gouy_e

在我的测试中，使用application/json;charset=utf-8与使用application/json作为内容类型对CORB警告消息没有任何影响。我唯一能够消除警告的方法是停止为OPTIONS请求返回content-type-options: nosniff头。 - JanneK

我制作了一个小测试工具，可以在这里找到：https://foobar.kytomaki.com/corb-test/。它向一个PHP脚本发送POST请求。默认情况下，该脚本仅为POST请求返回“nosniff”标头，您不应看到任何警告。通过选中第一个复选框，该标头也将用于OPTIONS请求，并且您应该会看到CORB警告出现。第二个复选框控制是否将字符集附加到内容类型的末尾，对我来说似乎没有任何区别。 - JanneK

Answer 2

我也遇到了同样的问题。

我的问题是由于API在预检请求中回复了200 OK，但没有设置Content-Length头部，导致返回的响应为空。

因此，要么将预检响应状态更改为204 No Content，要么只需设置Content-Length: 0头部即可解决该问题。

- André Mota