google-chrome - 在 Chrome 73 中阻止的 CORB 选项请求

Question

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

Cross-Origin Read Blocking (CORB) blocked cross-origin response [domain] with MIME type text/plain. See https://www.chromestatus.com/feature/5629709824032768 for more details.

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

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

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



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



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

当没有正文响应时，为什么 OPTIONS 请求需要定义 MIME 类型？

如果纯文本/文本不合适，OPTIONS 请求的 MIME 类型应该是什么？我会假设 application/json 是正确的吗？

如何配置我的 Apache2 服务器以包含所有飞行前 OPTIONS 请求的 MIME 类型？

Answer 1

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

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

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

A response served with a "X-Content-Type-Options: nosniff" response header and an incorrect "Content-Type" response header, may be blocked.

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

No "charset" parameter is defined for this registration. Adding one really has no effect on compliant recipients.

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

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

最后，作为旁注，我们所有应用程序请求仍然成功的原因是因为它出现了跨域读取阻塞 isnt actually enforced在 Chrome 中:

In most cases, the blocked response should not affect the web page's behavior and the CORB error message can be safely ignored.