Chrome 73中禁止了CORB OPTIONS请求

Question

看来，在最近的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请求实际上并未被阻止？

这是一个三部分的问题：

Answer 1

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

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

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

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

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

没有为该注册定义“字符集”参数。确实添加一个对符合条件的收件人没有任何影响。

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

总之，对于最近的Chrome版本，似乎Google选择了比过去更严格地对待mime类型。

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

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