jquery - Backbone 模型 CORS 获取未发送

Question

我正在尝试使用来自另一个域的 model.fetch() ，但我似乎偶然发现了一堵墙。看来我可以执行跨域请求或设置自定义 header (哪个并不重要)，而不是两者兼而有之。不幸的是，我两者都需要，因为我尝试从中获取的 API 使用基本身份验证。

简而言之:

var Model = Backbone.Model.extend({
    url: function() {
        return a_cross_domain_url;
    },
    initialize: function() {
        this.fetch();
    }
});

Backbone.sync = _.wrap(Backbone.sync, function(sync, method, model, options) {
    if (!options.xhrFields) {
        options.xhrFields = {withCredentials:true};
    }

    options.headers = options.headers || {};

    // credentials is a string that looks like 'Basic d2Vwb3c6McriNzk3YZgvZTNkMTkzOGE4MTk3NjMwMDkzNmMwZGI='
    options.headers['Authorization'] = credentials;

    sync(method, model, options);
});

var m = new Model();

我抽象了很多代码，但我认为这是相关信息。重要的是最终请求如下所示:

据我了解，这就是我所需要的一切。这很有趣，因为 $.ajax.beforeSend 函数确实被触发了，但是根本没有实际 GET 触发的日志(服务器什么也没收到)。似乎在调用之前就被取消了。错误回调确实触发，并打印:

SyntaxError: JSON.parse: unexpected end of data

JSON.parse 可能是因为当错误到达时我期望从服务器发送 JSON，以便将它们显示给我的应用程序上的最终用户，但是，除了该消息之外，我没有得到任何关于发生了什么的线索或者为什么请求被取消。

最后一点，如果我从请求中删除 header (在上面的 js 上)，GET 就会被执行，但会被服务器拒绝，因为没有身份验证。

任何有关正在发生的事情的想法将不胜感激。

Answer 1

所以，这是一段坎坷的旅程，但我最近学到了很多关于 CORS 等的知识，并且认为我不妨回答这个问题，让后代能够意识到。希望这会对那里的人有所帮助。

首先，一些背景知识:

这是一个简单的表单，会发送到另一个域上的服务器，因此有 CORS 位。我使用 Backbone 来处理客户端，Rails 在服务器上，并使用 HAL 来管理周围的数据。 CORS 使用基本身份验证进行处理。收到数据后，服务器会响应 201 - Created、一个空正文和一个我下一步应该去的位置响应 header 。

这带来了很多令人惊叹的时刻，我将与您分享。

基本身份验证

@j03w 说的很对，他提到这可能不是前端的问题，而是后端的问题。事实上，预检请求中缺少 header 导致我的请求失败。事实证明，如果预检失败，即使技术上发生了请求，也不会显示任何请求。通过this nifty gem很快解决了这个问题。 .

但这还没有结束。

空响应？你即将受苦了!

我现在能够与服务器交互，但是当发布表单时，响应是“201 - Created”代码，这是成功代码，但未调用成功回调。取而代之的是错误。为什么？好吧，事实证明我的服务器在响应正文中没有返回任何内容。这才是错的。

起初，我以为这是 Backbone 的错，因为它期待更新的模型作为响应。事实证明，这不是 Backbone 的错。它仍然期待来自服务器的更新模型，但这不是触发错误回调的原因。这实际上是 jQuery 的错。 As of 1.9, an empty string returned for JSON data is considered to be malformed JSON (because it is) 。

但是服务器不想返回模型! (我是一名前端开发人员，但我认为后端人员有充分的理由不这样做)。我该如何解决这个问题？

事实证明，更改状态代码可以解决此问题。使用“204 - 无内容”而不是“201 - 创建”。 jQuery 完美地处理了这个问题，现在调用成功回调。

搬迁问题

这个令人痛苦的、比需要的时间更长的旅程的最后一步是将用户重新定位到服务器在位置响应 header 上发送的 URL。 “易如反掌!” -天真的开发者说。 “我只需要使用 xhr.getResponseHeader('Location') 访问 header !” - 他兴奋地喊道。

但那不起作用。经过一些调试(尝试了简单的 console.log(xhr.getAllResponseHeaders() 之前的所有操作)，我发现它没有返回 Location header 。事实上，它只返回 2 个无用的 header :Cache-Control 和 Content-输入!我不需要这个!我将头转向 Firebug 控制台上 POST 请求的响应，结果就在那里。位置 header 正在被发送，以及 xhr.getAllResponseHeaders() 的大量响应 header 没有回来!为什么，以三角力量的名义，这不起作用？

好吧，事实证明它还需要一些更多的配置。更多服务器配置选项表明，我们需要使用“Access-Control-Expose-Headers”显式告知客户端可以读取哪些 header 。在那里列出“位置”解决了这个问题。

resource '*', { 
  headers: :any,
  expose:  ['Location'],
  methods: [:get, :post, :options]
}

<小时/>

所以你已经得到它了。这是一段漫长而坎坷的旅程，但我希望这能帮助人们在处理所有这些技术时更快地解决问题。