浏览器将HTTP 302重定向到CORS请求 [英] HTTP 302 Redirect to a CORS request is dropped by browsers

查看:1107
本文介绍了浏览器将HTTP 302重定向到CORS请求的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在从站点A加载带有某些JavaScript的HTML页面。

I am loading a HTML page with some javascript from site A.

Javascript向站点B发送HTTP GET请求。此时:

   -浏览器将选项请求发送到站点B

    -站点B响应选项请求

   -浏览器然后将原始HTTP GET请求发送到站点B

   -站点B响应,并将HTTP 302的位置设置为站点C。

Javascript sends a HTTP GET request to site B. At this point:
    - browser sends OPTIONS request to site B
    - Site B responds to OPTIONS request
    - Browser then sends original HTTP GET request to site B
    - Site B responds with HTTP 302 with location set to site C.

这时浏览器停止处理请求。我原本希望它向站点C发送HTTP OPTIONS请求,就像它向站点B发送请求时一样。但是事实并非如此。我在Firefox和Chrome上观察到了相同的行为。

At this point Browser stops processing the request. I was expecting it to send the HTTP OPTIONS request to site C just like it did when it sent request to Site B. But it didn't. I observed the same behaviour on Firefox and Chrome.

我想了解为什么浏览器以这种方式运行。我知道应该进行一些检查或最大重定向,以防止出现循环,但不限于2个重定向请求。

I would like to understand why browsers are behaving in this manner. I understand there should be some checks or max redirects to prevent loops but not limited 2 redirect requests.

为什么标头信息没有发送到Javascript代码,以便应用程序可以执行一些操作。尽管它通过在浏览器控制台中显示具有位置URL的站点C的HTTP 302响应来取笑您,但它只是被浏览器丢弃。

Also why the header information is NOT sent to Javascript code so that application can do something about it. It is simply dropped by browser although it teases you by showing the HTTP 302 Response from site C with Location URL in browser console.

XMLHttpRequest无法加载 https:// siteB / ...请求已重定向到' https :// siteC / ..,对于需要预检的跨域请求是不允许的。

XMLHttpRequest cannot load https://siteB/... The request was redirected to 'https://siteC/..', which is disallowed for cross-origin requests that require preflight.

对设计的任何见解都受到真诚的感谢。

Any insights to the design are sincerely appreciated.

致谢

推荐答案

嗯,我遇到了同样的问题,不幸的是,这种行为是正常的,根据W3C规范

Well, I had the same problem you did, and unfortunately, this behavior is normal, according to W3C spec

此规范描述了浏览器将CORS视为计算机状态的行为,并且如果您跳至第3步(执行实际请求),则它明确指出:

This spec describes the behavior of the browser regarding CORS as a machine state, and if you jump to step 3 (doing the actual request), it clearly states :


这是实际的请求。应用发出请求的步骤,并在发出请求时遵守
的以下请求规则。

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

如果响应的HTTP状态码为301、302、303 ,307或308
应用缓存和网络错误步骤。

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

因此,如果我理解正确,我们将无法希望浏览器在发生CORS的情况下能够自动遵循重定向(据说,由于OPTION授予了对另一资源的访问权限?但是为什么不自动向该资源发送另一个OPTION请求?)。

So if I understand correctly, we can't expect the browser to automatically follow the redirect in case of a CORS (supposedly, as the OPTION has granted access to another resource ? But then why not automatically send another OPTION request to this resource ?).

更糟糕的是,由于上述原因,在自动重定向失败后,响应的HEADERS被浏览器隐藏了,因此我们无权访问Location标题来处理对正确资源的后续调用。因此,在这种情况下,无法获取实际资源。

What's worse, as the HEADERS of the response are hidden by the browser after the automatic redirect failed for the reason above, we don't have access to the Location header to handle the subsequent call to the correct resource ourselves. So there is no way to fetch the actual resource in this case.

我认为这是一个错误,但是我在网上找不到关于此主题的任何好帖子。

I consider this a bug, but I couldn't find any good post on the subject on the web.

一种可能的解决方法是,不进行CORS请求,而是使用一个简单的请求(再次根据规范,例如,一个简单的GET与没有自定义标头),则不会导致发送任何预检请求:在这种情况下,重定向正常(自动由浏览器执行)。

One workaround, if possible for you, is to not do a CORS request but instead use a simple request (according to the spec again, such as a simple GET with no custom headers), that will not cause any preflight requests to be sent : in this case, the redirect works normally (automatically followed by the browser).

否则,您可以看到您是否可以将服务器调整为在CORS类请求的情况下不响应302,而是使用您可以在客户端中标识的自定义HTTP代码进行响应,以将重定向位置包含在响应的内容中,以便您的客户手动遵循它。

Otherwise, you could see if you can tune your server to not respond 302 in case of a CORS-kind of request, but instead respond with a custom HTTP code that you can identify in your client to include the redirect Location in the content of the response to let your client follow it manually.

如果有人对为什么这种行为有任何有效的信息,请输入:-)

If anybody has any valid information about why this behavior is, please give your input :-)

希望有帮助。

这篇关于浏览器将HTTP 302重定向到CORS请求的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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