是否有可能捕获CORS错误？ [英] Is it possible to trap CORS errors?
问题描述
这个问题涉及跨源资源共享（CORS， http://www.w3.org/TR/cors / ）。
如果在发出CORS请求时出现错误，Chrome（以及AFAIK其他浏览器）也会在错误控制台中记录错误。一个示例消息可能如下所示：
XMLHttpRequest无法加载
http：//domain2.example。
$不允许原始 http：//domain1.example b $ b
我想知道是否有一种方法以编程方式获取此错误消息？我试过在try / catch中包装我的 xhr.send（）调用，我也试过添加一个 onerror（）事件处理程序。
...以及XHR 2级关于CORS的注释：
信息被有意过滤。
编辑多个月后：这里的后续注释要求为什么;在第一个链接的锚点丢失了几个字符，这使我很难看到我指的是什么文件的部分。
这是一个安全的东西 - 避免在可能敏感的HTTP标头中显示信息。关于CORS的W3C链接说：
用户代理必须过滤出所有响应头，而不是那些简单响应头，在将响应标头暴露给CORS API规范中定义的API之前，字段名是对Access-Control-Expose-Headers标头（如果有）的值之一的ASCII不区分大小写匹配。
该段落包含简单响应头的链接，其中列出了Cache-Control，Content-Language，Content-Type，Expires，Last-Modified和Pragma。所以那些得到通过。 Access-Control-Expose-Headers标头部分允许远程服务器通过在其中列出其他标头来公开其他标头。有关详细信息，请参阅W3C文档。
请记住，您有一个来源 - 假设您在浏览器中加载的网页运行了一些JavaScript - 该脚本向另一个来源发出请求，这是不正常允许的，因为恶意软件可以这样做令人讨厌的事情。因此，运行脚本并代表其执行HTTP请求的浏览器充当关守。
浏览器查看来自其他来源服务器的响应， ，如果它看起来不是参与CORS - 所需的标题丢失或格式不正确 - 那么我们处于不信任的位置。我们不能确定本地运行的脚本是否真诚地行事，因为它似乎试图联系不希望以这种方式联系的服务器。浏览器当然不应该通过将它的整个响应传递给脚本而不过滤来泄漏来自该远程服务器的任何敏感信息，这基本上是允许跨源的请求。会出现信息泄露漏洞。
这可能使调试困难，但它是一个安全vs可用性权衡，因为用户是一个开发人员在这种情况下，安全具有显着的优先权。
This question is related to Cross-Origin Resource Sharing (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:
XMLHttpRequest cannot load
http://domain2.example. Originhttp://domain1.exampleis not allowed by Access-Control-Allow-Origin.
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.
See:
...as well as notes in XHR Level 2 about 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:
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.
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.
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.
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 allowing a cross-origin request, of sorts. An information disclosure vulnerability would arise.
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.
这篇关于是否有可能捕获CORS错误？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
