javascript 是否可以捕获 CORS 错误？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4844643/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it possible to trap CORS errors?
提问by monsur
This question is related to Cross-Origin Resource Sharing (CORS, http://www.w3.org/TR/cors/).
这个问题与跨域资源共享（CORS，http://www.w3.org/TR/cors/）有关。
If there is an error when making a CORS request, Chrome (and AFAIK other browsers as well) logs an error to the error console. An example message may look like this:
如果在发出 CORS 请求时出现错误，Chrome（以及 AFAIK 其他浏览器）会将错误记录到错误控制台。示例消息可能如下所示：
XMLHttpRequest cannot load
http://domain2.example. Originhttp://domain1.exampleis not allowed by Access-Control-Allow-Origin.
XMLHttpRequest 无法加载
http://domain2.example。原产地http://domain1.example不被访问控制允许来源允许的。
I'm wondering if there's a way to programmatically get this error message? I've tried wrapping my xhr.send()call in try/catch, I've also tried adding an onerror()event handler. Neither of which receives the error message.
我想知道是否有办法以编程方式获取此错误消息？我试过xhr.send()在 try/catch 中包装我的调用，我也试过添加一个onerror()事件处理程序。两者都没有收到错误消息。
采纳答案by Andrew Hodgkinson
See:
看：
...as well as notes in XHR Level 2 about CORS:
...以及 XHR 级别 2 中关于 CORS 的注释：
The information is intentionally filtered.
信息被有意过滤。
Edit many months later: A followup comment here asked for "why"; the anchor in the first link was missing a few characters which made it hard to see what part of the document I was referring to.
几个月后编辑：此处的后续评论询问“为什么”；第一个链接中的锚点缺少几个字符，这使得很难看出我指的是文档的哪一部分。
It's a security thing - an attempt to avoid exposing information in HTTP headers which might be sensitive. The W3C link about CORS says:
这是一个安全问题 - 试图避免在可能敏感的 HTTP 标头中公开信息。W3C 关于 CORS 的链接说：
User agents must filter out all response headers other than those that are a simple response header or of which the field name is an ASCII case-insensitive match for one of the values of the Access-Control-Expose-Headers headers (if any), before exposing response headers to APIs defined in CORS API specifications.
用户代理必须过滤掉所有响应头，除了那些是简单响应头或字段名称是 Access-Control-Expose-Headers 头（如果有）的值之一的 ASCII 不区分大小写匹配的响应头，在将响应头暴露给 CORS API 规范中定义的 API 之前。
That passage includes links for "simple response header", which lists Cache-Control, Content-Language, Content-Type, Expires, Last-Modified and Pragma. So those get passed. The "Access-Control-Expose-Headers headers" part lets the remote server expose other headers too by listing them in there. See the W3C documentation for more information.
该段落包括“简单响应头”的链接，其中列出了缓存控制、内容语言、内容类型、过期时间、上次修改和编译指示。所以这些都通过了。“Access-Control-Expose-Headers headers”部分允许远程服务器通过在其中列出其他标头来公开其他标头。有关更多信息，请参阅 W3C 文档。
Remember you have one origin - let's say that's the web page you've loaded in your browser, running some bit of JavaScript - and the script is making a request to another origin, which isn't ordinarily allowed because malware can do nasty things that way. So, the browser, running the script and performing the HTTP requests on its behalf, acts as gatekeeper.
记住你有一个来源——假设这是你在浏览器中加载的网页，运行了一些 JavaScript——并且脚本正在向另一个来源发出请求，这通常是不允许的，因为恶意软件可以做一些令人讨厌的事情大大地。因此，运行脚本并代表其执行 HTTP 请求的浏览器充当看门人。
The browser looks at the response from that "other origin" server and, if it doesn't seem to be "taking part" in CORS - the required headers are missing or malformed - then we're in a position of no trust. We can't be sure that the script running locally is acting in good faith, since it seems to be trying to contact servers that aren't expecting to be contacted in this way. The browser certainly shouldn't "leak" any sensitive information from that remote server by just passing its entire response to the script without filtering - that would basically be allowinga cross-origin request, of sorts. An information disclosure vulnerability would arise.
浏览器查看来自“其他源”服务器的响应，如果它似乎没有“参与”CORS - 所需的标头丢失或格式错误 - 那么我们就处于不信任的位置。我们不能确定在本地运行的脚本是善意的，因为它似乎试图联系不希望以这种方式联系的服务器。浏览器当然不应该通过将其整个响应传递给脚本而不进行过滤来“泄漏”来自该远程服务器的任何敏感信息 - 这基本上会允许各种跨域请求。会出现信息泄露漏洞。
This can make debugging difficult, but it's a security vs usability tradeoff where, since the "user" is a developer in this context, security is given significant priority.
这会使调试变得困难，但这是安全性与可用性的权衡，因为在这种情况下“用户”是开发人员，因此安全性被赋予了重要的优先级。
