为什么浏览器不使用XMLHTTPRequest和CORS跟踪重定向? [英] Why browser do not follow redirects using XMLHTTPRequest and CORS?

查看:176
本文介绍了为什么浏览器不使用XMLHTTPRequest和CORS跟踪重定向?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用RESTful API为一些服务编写了一个Web应用程序。该API位于 https://api.example ,应用程序位于 https:/ / /app.example 。使用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重定向似乎被规范禁止。



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



根据规格:



我们来到步骤...)




... 3。这是实际请求。应用提出请求步骤,并在发出请求时观察
请求规则



HTTP状态代码301,302,303,307或308
应用缓存和网络错误步骤


然后,如果我们向下滚动到 http://www.w3.org/TR/cors/#cache-and-network-错误 - 步骤


每当应用网络错误步骤,都会终止算法
调用此组步骤并将跨源请求状态
设置为网络错误。



注意:用户凭据。也就是说如果块
cookie标志未设置,cookie将由响应设置。



每当缓存和网络错误步骤,请按照以下
步骤操作:



删除预检结果缓存中的条目,其中原始字段
值区分大小写匹配源来源和url字段值
是对请求URL的区分大小写的匹配。



应用网络错误步骤,就像调用
缓存和网络错误步骤调用了
的网络错误步骤。


文档。)



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.

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

From the spec:

(Step 1. and 2. detail the preflighting process. And the we come to step...)

...3. This is the actual request. Apply the make a request steps and observe the request rules below while making the request.

If the response has an HTTP status code of 301, 302, 303, 307, or 308 Apply the cache and network error steps.

And then if we scroll on down to http://www.w3.org/TR/cors/#cache-and-network-error-steps:

Whenever the network error steps are applied, terminate the algorithm that invoked this set of steps and set the cross-origin request status to network error.

Note: This has no effect on setting of user credentials. I.e. if the block cookies flag is unset, cookies will be set by the response.

Whenever the cache and network error steps are applied, follow these steps:

Remove the entries in the preflight result cache where origin field value is a case-sensitive match for source origin and url field value is a case-sensitive match for request URL.

Apply the network error steps acting as if the algorithm that invoked the cache and network error steps invoked the network error steps instead.

(Emphasis taken from the doc.)

3xx redirects are, however, permitted for simple CORS requests.

这篇关于为什么浏览器不使用XMLHTTPRequest和CORS跟踪重定向?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆