AJAX、CORS、Chrome 和 HTTP 错误代码 (401,403,404,500) 的推荐解决方案

Question

背景

（如果你熟悉 CORS，可以跳到最后的问题）

CORS [1] 是一种允许浏览器允许访问来自不同域的资源的解决方案。例如。使用 AJAX 的 REST 数据后端。

在 Internet 上很好地观察到，当此类资源需要时，Chrome（和 Webkit 朋友）不会处理 HTTP 身份验证提示。例如。 [2] （这是为了防止浏览器显示身份验证登录对话框，例如，当图像标签加载失败并出现 401 并需要凭据时，Web-Mail 登录页面。用户可能会被骗输入他们的 webmail 凭据）

Chrome 在这种情况下的行为是放弃响应，几乎默默地取消请求。

实际上，Chrome 只会在出现 200 时才会让响应正常通过；任何其他状态码都被吞下，AJAX 调用被中止。

如果使用 jQuery 执行 Ajax 请求，并且远程站点以 HTTP 401 状态代码响应，则请求被取消并且 ajax 完成并出现错误，但缺少 401 代码。就好像连接死了或等效的低层问题。

我见过的唯一一个特别提到 CORS 警告的网站是 [1]

当出现错误时，浏览器不会很好地报告问题所在。 例如，Firefox 报告所有错误的状态为 0 和空的 statusText。 浏览器还会向控制台日志报告错误消息， 但无法从 JavaScript 访问此消息。 在处理 onerror 时，您会知道发生了错误，但其他的不多。

您可以通过使用 chrome 启动标志来禁用此安全性 - 只是为了测试后端是否“正常”运行，并且一个理智没有因丢失正确的状态代码而受到过度影响。见[2]

问题

如果后端和前端客户端代码应该使用 401 作为其身份验证过程的一部分怎么办？ - 任何失败都只是被分解为一个“错误”输出。

例如：发出身份验证请求时 - 例如2-legged OAuth 令牌请求 - 针对 RESTful 后端 - 使用正确的状态代码 - 客户端不知道是否：

• 401 用户未通过身份验证。
• ---连接失败。
• 400 有一个错误的请求。
• 500 服务器有问题。
• 207成功后没有内容。

我们的后端相当以 REST 方式编写，遵循当时被认为具有成本效益的尽可能多的最佳实践；其中之一是依赖正确的 HTTP 状态代码。 我们使用的 Java REST 客户端运行良好。

现在我已经开始创建一个 Javascript 客户端，用于嵌入网页 - 特别是使用 CORS，我们在 Chrome 等中遇到了问题。（注意 Firefox 似乎很好，我们通常不会目前关心IE。）

问题

人们为解决这些问题做了哪些工作？
有什么办法可以让 CORS 更适合受信任的后端？

链接

1. CORS 教程：http://www.html5rocks.com/en/tutorials/cors/
2. Chrome 不允许 401 触发的资源身份验证提示：http://code.google.com/p/chromium/issues/detail?id=81251
3. --禁用 Chrome 的网络安全性：Disable same origin policy in Chrome

Answer 1

刚刚遇到这个问题。为 401 响应设置 HTTP 标头对我有用。如果没有一些定制，我正在使用的库无法正确执行此操作。例如：

  self.headers["Access-Control-Max-Age"] = '1728000'
  self.headers["Access-Control-Allow-Origin"] = "http://localhost:3001"
  self.headers["Access-Control-Allow-Methods"] = "ANY"
  self.headers["Access-Control-Allow-Credentials"] = 'true'

Answer 2

我今天花了几个小时寻找这个问题的答案，同时在 Chrome 上开发一个网络应用程序。 Some others 已经对这种情况进行了相当详细的分析。

有两个潜在问题：

1. 可能是 Chrome 正在执行预检并得到一个非 200 或非 CORS 响应作为响应

   • Specs about Preflights (When they Occur)

2. 由于某种原因，我的非 200（错误）状态代码没有附加标题。 正如我在this post 中发现的那样，第二个原因就是问题所在。本质上，NGINX 默认只在成功响应上添加标头。为了通过 CORS 获得我的错误响应，改变就足够了

add_header 'Access-Control-Allow-Origin' '*';

到

add_header 'Access-Control-Allow-Origin' '*' always;

如文章所述，您可能还需要将always 添加到'Access-Control-Allow-Credentials' 和'Access-Control-Allow-Headers'。这样做之后，所有错误代码也都通过了，没有 CORS 问题。 您用于 API 服务的程序可能也是如此。希望这可以帮助并节省一些时间！

Answer 3

现在经过大量的摆弄，我已经设法让它工作了。 脸红

似乎有非常多的巫术构成了确保 CORS 可以在每个浏览器中工作的确切场景，但是已经追溯了许多问题，例如：

• Nginx 默认只在其反向代理中使用 HTTP/1.0
• Tomcat 会默默地忽略具有相同密钥的重复 init-param 声明，但 jetty 将它们组合在一起（因此 CORS 过滤器在服务器中关闭，但在 dev-laptop 中打开），并且 nginx 覆盖了一些标头。

偶然发现似乎完全不行，我最终编写了一个 CORS 4xx->200 包装器作为 jquery 插件，试图解决这个问题。调试该插件导致我最终修复。