为什么浏览器不遵守使用XMLHttpRequest来和CORS重定向？(Why browser do

我写的RESTful使用API的一些服务的Web应用程序。该API可在HTTPS：//api.example和应用在HTTPS：//app.example 。采用CORS简单的GET请求正在努力在Chrome和Firefox就好了。一些方法通过POST接收数据，并与新的URI在Location头返回303码。

预检OPTIONS请求是罚款：

Request Method:OPTIONS
Status Code:200 OK

请求头

Accept:*/*
Accept-Charset:UTF-8,*;q=0.5
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,ru;q=0.6
Access-Control-Request-Headers:origin, authorization, content-type
Access-Control-Request-Method:POST
Connection:keep-alive
DNT:1
Host:api.example
Origin:https://app.example
Referer:https://app.example/app/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.32 (KHTML, like Gecko) Chrome/27.0.1425.0 Safari/537.32 SUSE/27.0.1425.0

响应头

Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Authorization, Content-Type
Access-Control-Allow-Methods:GET,POST,PUT,DELETE,HEAD,OPTIONS
Access-Control-Allow-Origin:https://app.example
Access-Control-Expose-Headers:*
Access-Control-Max-Age:3628800
Connection:keep-alive
Content-Length:0
Date:Sun, 05 May 2013 15:22:50 GMT
Server:nginx/1.2.5

然后实际的请求接收303之后仅仅停留：

Request URL:https://api.example
Request Method:POST
Status Code:HTTP/1.1 303 See Other

响应头：

Server:nginx/1.2.5
Location:https://api.example/some_url
Date:Sun, 05 May 2013 15:27:49 GMT
Content-Type:application/json
Content-Length:0
Connection:keep-alive
Access-Control-Max-Age:3628800
Access-Control-Expose-Headers:*
Access-Control-Allow-Origin:https://app.example
Access-Control-Allow-Methods:GET,POST,PUT,DELETE,HEAD,OPTIONS
Access-Control-Allow-Headers:Authorization, Content-Type
Access-Control-Allow-Credentials:true

通过RFC用户代理应该遵循重定向，但Chrome和FF似乎并不如预期的行为。它是一个浏览器的错误或我做错了什么？

更新：如果我开始-禁用网络安全铬一切工作正常。

Answer 1:

我一直在摔跤这个。看来，3xx的重定向的预检CORS请求都被禁止规范。

http://www.w3.org/TR/cors/

从规格：

（步骤1和2的详细过程预检。而我们就来一步...）

... 3。这是实际的请求。应用提出要求的步骤和观察之下，而发出请求的请求规则 。
如果响应具有301，302，303，307，或308的HTTP状态代码应用缓存和网络错误的步骤。

然后，如果我们滚动下来到http://www.w3.org/TR/cors/#cache-and-network-error-steps ：

每当施加的网络错误的步骤 ，终止调用这个组步骤和设置跨来源请求状态到网络错误的算法。
注：这对用户证书的设置没有影响。 即，如果块饼干标志未设置，饼干将由响应来设定。
每当应用缓存和网络错误的步骤 ，请按照下列步骤操作：
在预检结果缓存，其中原点字段值是源来源和url域值的情况下，敏感的匹配删除的条目是用于请求URL的情况下，敏感的匹配。
应用充当如果调用缓存和网络错误步骤的算法调用网络错误的步骤，而不是网络错误的步骤。

（从DOC重点获得。）

3XX重定向，但是，允许简单的CORS请求。

Answer 2:

如果这里的铬错误是由铬询问服务给你的代码可能出现的错误：

如果同源请求导致重定向到一个不同的产地，
不执行对重定向响应访问控制检查
本身，因为这导致重定向请求是
同源。
如果同源请求导致重定向到一个不同的产地，
使用原请求的URL为原点的新的请求不使用独特的安全原点。
跟踪客户端（即XMLHttpRequest的）是否实际请求
凭据首先发送。当同源的请求重定向到一个不同的起源，原始请求将发送的cookie是否要求或没有，因为它是同源。如果服务器授予“访问控制允许来源= *”新的跨域请求不应发送的cookie，除非他们的要求，以便在响应中的访问控制检查将成功。

文章来源: Why browser do not follow redirects using XMLHTTPRequest and CORS?