6

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

跨域读取阻止 (CORB) 阻止了 MIME 类型为 text/plain 的跨域响应 [域]。有关详细信息，请参阅https://www.chromestatus.com/feature/5629709824032768 。

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

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

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

在此处输入图像描述

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

在此处输入图像描述

这是一个三部分的问题：

  1. 当没有正文响应时，为什么 OPTIONS 请求需要定义 MIME 类型？
  2. 如果纯/文本不合适，那么 OPTIONS 请求的 mime 类型应该是什么？我会假设application/json是正确的吗？
  3. 如何配置我的Apache2服务器以包含所有飞行前 OPTIONS 请求的 mime 类型？
4

2 回答 2

5

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

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

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

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

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

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

基于此，我从 content-type: 中删除了字符集，application/json并且可以确认 Chrome 中停止的 CORB 警告。

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

最后，作为旁注，我们所有的应用程序请求仍然成功的原因是因为它似乎在 Chrome 中实际上并未强制执行跨源读取阻止：

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

于 2019-04-12T19:17:51.127 回答
0

有同样的问题。

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

因此，将预检响应状态更改为204 No Content或仅通过设置Content-Length: 0标头即可解决问题。

于 2019-08-16T15:54:09.273 回答