Chrome 73 中阻止的 CORB OPTIONS 请求答案

【问题标题】：CORB OPTIONS Requests Blocked in Chrome 73Chrome 73 中阻止的 CORB OPTIONS 请求
【发布时间】：2019-09-01 08:03:46
【问题描述】：

似乎在最近的 Chrome 版本中（或者至少最近在调用我的 API 时 --- 直到今天才看到它），Google 正在发出有关 CORB 请求被阻止的警告。

跨域读取阻止 (CORB) 阻止了 MIME 类型为 text/plain 的跨域响应 [域]。详情请见https://www.chromestatus.com/feature/5629709824032768。

我已确定对我的 API 的请求是成功的，并且是飞行前 OPTIONS 请求触发了控制台中的警告。

调用 API 的应用程序并没有显式地发出 OPTIONS 请求，而是我了解到这是在发出跨域请求时由浏览器强制执行的，并且由浏览器自动完成。

我可以确认 OPTIONS 请求响应没有定义 mime 类型。但是，我有点困惑，因为我的理解是 OPTIONS 响应只是标题，不包含正文。我不明白为什么这样的请求需要定义 MIME 类型。

此外，控制台警告说请求被阻止；然而，各种 POST 和 GET 请求都成功了。所以看起来 OPTIONS 请求实际上并没有被阻止？

这是一个由三部分组成的问题：

【问题讨论】：

OPTIONS 预检正在成功。如果它失败了，浏览器会停在那里并且永远不会继续尝试你的 POST 请求。您看到 POST 请求的事实表明预检成功。 OPTIONS 请求不需要定义 mime 类型。问题中没有任何迹象表明您有任何 CORS 问题。相反，您遇到了 CORB 问题。问题中引用的错误消息表明您的代码正在获取 text/plain 响应，但代码试图在浏览器不希望使用 text/plain 的某些上下文中使用该响应。
如果您更新问题以添加前端代码的 sn-p 以显示您如何发出请求以及如何使用响应，您可能会在此处获得更好的帮助。例如，您可能会收到 CORB 错误，因为您的代码正试图将该文本/纯文本响应解析为 JSON。
正确，正如我所指出的，OPTIONS 请求成功，因为 POST 请求成功。您也是正确的，因为我也认为 OPTIONS 请求不需要 mime 类型，但 Chrome 似乎认为它需要？您说我没有 CORS 问题也是正确的，我的问题与 CORS 无关，因此我没有提出来。正如您在示例 POST 响应中看到的那样，我正在返回适当的 mime 类型——Chrome 中的警告与 OPTIONS 请求有关，该请求没有 mime 类型（因为我相信它不需要）。我开始相信这是 Chrome 中的一个错误。

【解决方案1】：

遇到同样的问题。

我遇到的问题是由于 API 使用 200 OK 响应预检但没有设置 Content-Length 标头的空响应。

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

【讨论】：

【解决方案2】：

我已经深入了解了这些 CORB 警告。

此问题部分与我使用 content-type-options: nosniff 标头有关。我设置此标头是为了阻止浏览器尝试嗅探内容类型本身，从而消除 mime 类型的欺骗，即使用用户上传的文件作为攻击媒介。

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

使用“X-Content-Type-Options: nosniff”响应标头和不正确的“Content-Type”响应标头提供的响应可能会被阻止。

基于此，我开始仔细检查IANA's site 可接受的媒体类型。令我惊讶的是，我发现在任何 RFC 中实际上都没有为 application/json 类型定义任何 charset 参数，并进一步说明：

没有为此注册定义“charset”参数。添加一个确实对合规收件人没有影响。

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

总之，根据最近的 Chrome 版本，Google 似乎选择开始比过去更严格地处理 mime 类型。

最后，附带说明一下，我们所有的应用程序请求仍然成功的原因是它在 Chrome 中出现了 Cross-Origin Read Blocking isnt actually enforced：

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

【讨论】：

这里的错误完全相同。您是否在 OPTIONS 请求的响应标头中包含 Content-Type: application/json ？我从回复中删除了字符集，但仍然收到这些警告（我的 API 没有为 OPTIONS 请求提供 Content-Type 标头）
在我的测试中，使用 application/json;charset=utf-8 与使用 application/json 作为内容类型对 CORB 警告消息没有任何影响。我能够删除警告的唯一方法是停止返回 OPTIONS 请求的 content-type-options: nosniff 标头。
我在这里提供了一个小型测试工具：foobar.kytomaki.com/corb-test。它向 PHP 脚本发出 POST 请求。默认情况下，脚本仅为 POST 请求返回 nosniff 标头，您不应看到任何警告。通过选中第一个复选框，还会为 OPTIONS 请求返回标头，您应该会看到出现 CORB 警告。第二个复选框控制字符集是否将附加到内容类型的末尾，对我来说似乎没有任何区别。