XHR CORS on 302 Redirect sets Origin to "null" in request
Reported by te...@cloudflare.com, Oct 10 2012
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)
Oct 10 2012,
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.
Oct 10 2012,
Yes, we're using an asynchronous XMLHTTPRequest. No, I have not tried synchronous.
Oct 10 2012,
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)
Nov 2 2012,
This behavior is actually in the spec . 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.  http://www.w3.org/TR/cors/#generic-cross-origin-request-algorithms
Mar 10 2013,
Apr 5 2013,
Jun 17 2013,
Issue 249956 has been merged into this issue.
Jul 1 2013,
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.
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?
Jul 1 2015,
> 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.
Aug 5 2015,
Nov 24 2015,
> 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.
Nov 27 2015,
Sign in to add a comment