【问题标题】:Why does an OPTIONS request fail when the answer to the follow up request is a 204?当后续请求的答案是 204 时,为什么 OPTIONS 请求会失败?
【发布时间】:2012-10-30 13:06:05
【问题描述】:

我正在构建一个基于 Backbone.js 的应用程序并遇到一个奇怪的问题。

在某个时刻,应用程序请求收集资源,但在 Chrome(和 Safari)中,我收到如下错误:

XMLHttpRequest cannot load http://api.mydomain.net/v1/foos/00000d/bars/000014/boots Origin http://localhost:3501 is not allowed by Access-Control-Allow-Origin.

好的,我想到了 CORS 问题并将其归咎于我的 API。然后通过 CURL 请求这个资源:

curl -i -H'Accept: application/json' -H'X-Auth-Token: pAWp5hrCmXA83GgFzgHC' -XOPTIONS 'http://api.mydomain.net/v1/foos/00000d/bars/000014/boots'
HTTP/1.1 200 OK
Status: 200
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,X-Auth-Token
Content-Length: 0

看起来不错,现在是 GET:

curl -i -H'Accept: application/json' -H'X-Auth-Token: pAWp5hrCmXA83GgFzgHC' -XGET 'http://api.mydomain.net/v1/foos/00000d/bars/000014/boots'
HTTP/1.1 204 No Content
Status: 204
Cache-Control: no-cache
Content-Length: 0
Content-Type: text/plain

如果我请求包含至少一个对象的靴子集合,一切正常。我的服务器的 CORS 标头以 arr 响应,我认为完全没问题。那么为什么浏览器会报跨源资源问题呢?

是不是因为我的 204 条回复的内容类型 text/plain

开发工具中的预检 (OPTIONS) 请求:

中止响应的请求标头:

【问题讨论】:

  • 确保问题确实是由 CORS 引起的,而不是某些服务器端故障。使用 --disable-web-security 标志运行 Chrome 并仔细检查服务器的响应。
  • 不幸的是,OSX 上最新的 Chrome(非开发版)在使用该命令行开关启动时会死机。
  • 检查服务器的错误日志。
  • Serverlog 很好:在 2012-11-10 11:33:04 +0100 开始 GET "/v1/foos/00000d/bars/000014/boots" for 93.219.xxx.yyy 由 V1 处理::BootsController#index as JSON 参数:{"foo_id"=>"00000d", "bar_id"=>"000014"} 渲染文本模板 (0.0ms) 完成 204 No Content in 7ms (Views: 0.4ms)
  • 所以,服务器不是问题的原因。

标签: javascript ajax backbone.js xmlhttprequest cors


【解决方案1】:

您还必须在第二个请求的响应标头中包含 Access-Control-Allow-Origin。这不是客户端问题,而是后端问题。

此行为符合CORS specification,应用于以下解释(section 7.1.5 "Cross-Origin Request with Preflight"):

  1. 预检请求(details 省略)
  2. “将cross-origin request status 设置为预检完成。”
  3. “这是实际请求。(...) 发出请求时请遵守以下请求规则。”
    • 如果响应的 HTTP 状态代码为 301、302、303 或 307 不适用
    • 如果最终用户取消请求 不适用
    • 如果出现网络错误 不适用
    • 否则
      执行resource sharing check。如果返回失败,请应用缓存和网络错误步骤。

您的请求在resource sharing check的第一步已经失败:

  1. 如果响应包含零个或多个 Access-Control-Allow-Origin 标头值,则返回失败并终止此算法。

我提供了一个简单的 NodeJS 示例来说明您的问题。
您当前的后端行为如下:

require('http').createServer(function(request, response) {
    if (request.method == 'OPTIONS') { // Handle preflight
        response.writeHead(200, {
           "Access-Control-Allow-Origin": "*",
           "Access-Control-Allow-Headers": "X-Foo"
        });
    } else {                           // Handle actual requests
        response.writeHead(204, {
          //"Access-Control-Allow-Origin": "*"
        });
    }
    response.end();
}).listen(12345);

现在,提出请求并体验失败

var x = new XMLHttpRequest;
x.open('GET', 'http://localhost:12345');
x.setRequestHeader('X-Foo','header to trigger preflight');
x.send();

回到我提供的代码,并在响应中启用Access-Control-Allow-Origin 标头,然后再次测试。您的请求现在将成功。

【讨论】:

  • 204 根本不包括 CORS 标头...感谢您的所有努力和出色的答案!
猜你喜欢
  • 1970-01-01
  • 2019-03-22
  • 1970-01-01
  • 2017-06-18
  • 1970-01-01
相关资源
最近更新 更多