是否可以捕获CORS错误？

看到：

• http://www.w3.org/TR/cors/#handling-a-response-to-a-cross-origin-request

…以及XHR Level 2中有关CORS的注释：

• http://www.w3.org/TR/XMLHttpRequest2/

该信息被有意过滤。

几个月后进行编辑：此处的后续评论要求“为什么”；第一个链接的锚点缺少几个字符，这使得我很难看清我指的是文档的哪一部分。

这是安全的事情-尝试避免在HTTP标头中公开可能敏感的信息。关于CORS的W3C链接说：

用户代理必须过滤掉所有响应标头，但那些响应标头不是简单的响应标头，或者其字段名是Access-Control-Expose-
Headers标头（如果有）之一值的ASCII区分大小写的匹配项，在将响应标头公开给CORS API规范中定义的API之前。

该段落包括“简单响应头”的链接，其中列出了缓存控制，内容语言，内容类型，过期，最后修改时间和语用。这样那些就通过了。“ Access-Control-
Expose-Headers标头”部分使远程服务器也可以通过在其中列出其他标头来公开其他标头。有关更多信息，请参见W3C文档。

请记住，您有一个来源-假设这是您加载到浏览器中的网页，并运行了一些Javascript-
脚本正在向另一个来源发出请求，通常不允许这样做，因为恶意软件会做一些令人讨厌的事情，道路。因此，运行脚本并代表其执行HTTP请求的浏览器将充当网守。

浏览器会查看来自该“其他来源”服务器的响应，如果它似乎未参与CORS，则-所需的标头丢失或格式错误-
那么我们处于不信任的位置。我们无法确定本地运行的脚本是否善意运行，因为它似乎正在尝试联系不希望通过这种方式联系的服务器。浏览器当然不应该通过仅将其整个响应传递给脚本而不进行过滤来“泄漏”该远程服务器的任何敏感信息-
这基本上是 允许 某种形式的跨域请求。会出现信息泄露漏洞。

这可能会使调试变得困难，但是这是安全性与可用性之间的折衷，因为在这种情况下，由于“用户”是开发人员，因此安全性具有重要的优先权。