New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 21 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

XHR CORS on 302 Redirect sets Origin to "null" in request

Reported by te...@cloudflare.com, Oct 10 2012

Issue description

Chrome Version       : 24.0.1284.2 dev
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 6: OK
  Firefox 15.x: OK
       IE 8: OK

What steps will reproduce the problem?
0. Be on one domain (host: http://example.test)
1. Initiate a XHR CORS request to a resource. (host: http://test1.example.org)
2. The resource issues a 302 redirect to another resource on another domain (host: http://test2.example.org)

What is the expected result?
The second request (to test2.example.org) would have set the Origin to "example.test" in the request

What happens instead?
During the second request the Origin is set to "null"

X-Post:
    WebKit: https://bugs.webkit.org/show_bug.cgi?id=98838
    Safari: rdar://problem/12466595 (http://openradar.appspot.com/radar?id=2135401)
 
Cc: abarth@chromium.org
Labels: -Area-Undefined Area-WebKit

Comment 2 by abarth@chromium.org, Oct 10 2012

Thanks for the report.  I believe you're right that this is a bug in our CORS implementation.  Have you tested both synchronous and asynchronous XMLHttpRequests?  We tend to be better at asynchronous requests, especially when there are redirects.
Yes, we're using an asynchronous XMLHTTPRequest. No, I have not tried synchronous.
In case it's not obvious:

   1) I typo'd in the original bug report (this fails in Safari 6)

   2) I'm the same person as #3 (hooray for multiple Google accounts)

Comment 5 by strobe@google.com, Nov 2 2012

This behavior is actually in the spec [1]. See section 7.1.7 step 6.

Unfortunately the convention of transmitting the string "null" makes it seem like it could be a bug; I thought so myself until I tracked this down :)

We could probably do a better job of explaining this in the inspector.

[1] http://www.w3.org/TR/cors/#generic-cross-origin-request-algorithms
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink

Comment 8 by yoz@chromium.org, Jun 17 2013

Cc: creis@chromium.org thestig@chromium.org jlklein@chromium.org
 Issue 249956  has been merged into this issue.
I added the CORS redirect handling to WebKit a while back. It was only implemented for asynchronous requests.

I've been reviewing the standard and I think the code conforms to it. Here are the relevant sections:

http://www.w3.org/TR/cors/#redirect-steps
http://www.w3.org/TR/cors/#resource-sharing-check

In the above reproduction steps, the first request's URL is cross-origin, and its origin is the page URL. The response is a 302 redirect with the appropriate access-control-allow-origin="test1.example.org" header so the redirect is allowed to proceed. As part of the redirect steps, the new request origin is set to "null" and it's URL is set to the value of the Location header.

The second request generates a response. The only way this second response can pass the resource sharing check is if it contains this header:

access-control-allow-origin="*"

Furthermore, the original XHR must not have "allow-credentials" set to true.

If no header is present, or if specific origins are specified, the response is rejected. The code seems consistent with the standard here.

Comment 10 by i.bra...@gmail.com, Aug 22 2013

By the spec it should only set to Origin to `null` if the original origin is **not** same origin with new origin.

In the example above:
example.test [REQUESTS] test1.example.org [REDIRECTS] test2.example.org
Spec says to set Origin to null on the request for test2.example.org

But Chromium is setting to null even to exact same domain
New example:
example.test [REQUESTS] test1.other.org [REDIRECTS] test1.other.org
In this example the second request should keep the origin header, but chrome does not.

Even on the first example I don't really agree with the spec, as the TLD is the same for both hosts. It's very useful, for instance, to redirect to a particular farm.

May be the bug can be re-written or open a new one for redirecting to the same target domain?


Labels: -Cr-Blink Cr-Blink-fetch
Status: WontFix
> But Chromium is setting to null even to exact same domain
> New example:
> example.test [REQUESTS] test1.other.org [REDIRECTS] test1.other.org
> In this example the second request should keep the origin header, but chrome does not.

I tested and it works.

It looks someone fixed the issue.

Labels: -Cr-Blink-fetch Cr-Blink-FetchAPI
> Even on the first example I don't really agree with the spec, as the TLD is the same for both hosts. It's very useful, for instance, to redirect to a particular farm.

I agree.  I don't think it make sense by setting a "null" as the "Origin". 

In my case specifically,  I need to redirect a url like "video.test.org/some_video?frame=123"  to  "image.test.org/some_video_123".  The request to "image.test.org/some_video_123" was blocked by chrome according to the CORS rule. And it was definitely not what I want.

Comment 14 by tkent@chromium.org, Nov 27 2015

Labels: -Cr-Blink-FetchAPI Cr-Blink-Network-FetchAPI

Comment 15 Deleted

Sign in to add a comment