是否有可能捕获 CORS 错误？

这个问题与跨来源资源共享(CORS，http://www.w3.org/TR/cors/)有关。

如果在发出 CORS 请求时出现错误，Chrome (以及 AFAIK 其他浏览器)会将错误记录到错误控制台。示例消息可能如下所示:

XMLHttpRequest 无法加载 http://domain2.example。访问控制-允许-起源不允许起源 http://domain1.example。

我想知道是否有一种方法可以通过编程获得这个错误消息？我试过在 try/catch 中包装我的 xhr.send()调用，我还试过添加一个 onerror()事件处理程序。两者都没有接收到错误消息。

32783 次浏览
小开
最佳答案

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.


提交答案