问题描述
我使用RESTful API为一些服务编写了一个Web应用程序。该API位于，应用程序位于。使用CORS的简单GET请求在Chrome和Firefox中正常工作。一些方法通过POST接受数据，并返回303代码，并在Location头中加入新的uri。
Preflight OPTIONS请求正常：
请求方法：选项
状态代码：200 OK
$ b b
请求标头
接受：* / *
Accept-Charset：UTF-8，*; q = 0.5
Accept-Encoding：gzip，deflate，sdch
Accept-Language：en-US，en; q = 0.8，ru; q = 0.6
访问控制请求标头：源，授权，内容类型
访问控制请求方法：POST
连接：keep-alive
DNT：1
主机：api.example
：https：//app.example
Referer：https：//app.example/app/
User-Agent：Mozilla / 5.0（X11; Linux x86_64）AppleWebKit / 537.32（KHTML，类似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-控制允许方法：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
日期：Sun，05 May 2013 15:22:50 GMT
服务器：nginx / 1.2.5
然后，实际请求在接收303后立即停止：
请求URL：https：//api.example
请求方法：POST
状态代码：HTTP / 1.1 303查看其他
Resposce标题：
服务器：nginx / 1.2.5
位置：https：//api.example/some_url
日期：Sun，05 May 2013 15:27:49 GMT
Content-Type：application / json
Content-Length：0
连接：keep-alive
访问控制 - 最大年龄：3628800
访问控制 - 公开头：*
Access-Control-Allow-Origin：https：//app.example
Access-Control-Allow-Methods：GET，POST，PUT，DELETE，HEAD，OPTIONS
Access-控制允许标头：授权，内容类型
访问控制允许凭证：true
由RFC用户代理应该跟随重定向，但Chrome和FF似乎不如预期的行为。
更新：如果我使用--disable-web-security启动chrome，那么这是一个浏览器错误工作正常。
我也一直在摔跤。对于预检的CORS请求，3xx重定向似乎被规范禁止。
根据规格：
我们来到步骤...）
然后，如果我们向下滚动到：
文档。）
3xx重定向允许用于简单的CORS请求。
I am writing a web application for some service using RESTful API. The API is available at https://api.example and app at https://app.example. Simple GET requests using CORS are working just fine in Chrome and Firefox. Some method accept data via POST and return 303 code with new uri in Location header.
Preflight OPTIONS request is fine:
Request Method:OPTIONS
Status Code:200 OK
Request Headers
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
Response Headers
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
Then the actual request just stop after receiving 303:
Request URL:https://api.example
Request Method:POST
Status Code:HTTP/1.1 303 See Other
Responce headers:
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
By RFC user agent should follow redirects, but Chrome and FF seems doesn't behave as expected. Is it a browsers' bug or I am doing something wrong?
update: If I start chromium with --disable-web-security everything works fine.
I've been wrestling with this, too. It appears that 3xx redirects for preflighted CORS requests are forbidden by the spec.
From the spec:
(Step 1. and 2. detail the preflighting process. And the we come to step...)
And then if we scroll on down to http://www.w3.org/TR/cors/#cache-and-network-error-steps:
(Emphasis taken from the doc.)
3xx redirects are, however, permitted for simple CORS requests.
这篇关于为什么浏览器不使用XMLHTTPRequest和CORS跟踪重定向？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！