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类型？
2. 如果不适合使用纯文本/纯文本，那么对于OPTIONS请求，MIME类型应该是什么？我会认为 application / json 是正确的吗？
3. 如何配置 Apache2 服务器，使其对所有飞行前OPTIONS请求都包含mime类型？

Answer 1

我已经深入了解了这些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参数，并进一步说明：

  

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

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

最后，看来，根据最近的Chrome版本，Google选择了比过去更严格地对待mime类型。

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

  

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

Answer 2

有同样的问题。

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

因此，将飞行前响应状态更改为204 No Content或通过简单地设置Content-Length: 0标头即可解决此问题。