Redirect on preflighted CORS requests generally impossible #204

nschloe · 2016-01-22T16:25:14Z

With the given state of the standard, it is impossible to design APIs that use redirection on authenticated resources and allow access by clients implementing the standard.

The reason for this is that redirects on preflight CORS requests are generally forbidden. An older version of the standard says

7.1.5 Cross-Origin Request with Preflight
If the response has an HTTP status code that is not in the 2xx range
Apply the network error steps.

I cannot find this passage in the latest revision, but it's perhaps been rephrased. (Am I right?)

This restriction seems too strict as it disallows valid (RESTful) use patterns.

Opinions?

annevk · 2016-01-22T18:00:20Z

I think you are correct, that check seems to have gone missing somehow. I wonder why nobody caught that thus far. Will need to investigate when I have some more time.

I guess as-is the specification actually supports your use case.

nschloe · 2016-01-22T18:06:20Z

I guess as-is the specification actually supports your use case.

It'd be great if we could further substantiate this. I'd then go ahead and file feature requests in Chrome and Firefox which both seem to go by the old error-on-non-2?? rule right now.

jdm · 2016-01-22T18:48:35Z

I read through the CORS-preflight-fetch steps, and it doesn't appear to actually follow redirects. It gets a single HTTP response back from the HTTP-network-or-cache step, but there's no processing that occurs as far as I can tell.

nschloe · 2016-01-22T18:50:30Z

@jdm The preflight doesn't follow redirects alright. This is about the actual GET request that follows the preflight.

nschloe · 2016-01-26T22:44:15Z

The respective section in the latest revision says:

Otherwise, request's redirect mode is "follow", run these substeps:

If request's mode is "cors", request's origin is not same origin with locationURL's origin, and locationURL includes credentials, return a network error.

If the CORS flag is set and locationURL includes credentials, return a network error.

[...]

If "locationURL includes credentials" describes URLs of the type http(s)://username:password@example.com, this should be fine.

annevk · 2016-02-15T13:38:31Z

I'm not sure what you mean by your last comment @nschloe.

As for the original report, as far as I can tell the standard already support CORS requests that require a preflight to follow redirects. Basically each request in the chain will be preceded by a CORS-preflight request to the same URL that expects a 2xx response. Then the actual CORS request will be made and for that the response code does not matter (i.e., 307 is okay), as long as it passes the CORS check.

So I guess what remains is someone filing bugs on browsers and hoping they implement these better semantics.

nschloe · 2016-02-15T15:28:46Z

@annevk Indeed.

So I guess what remains is someone filing bugs

Platform tests for this are needed as well, the respective bug report is here.

annevk · 2016-02-15T15:38:46Z

I think we can close this then and leave this up to browsers.

@hillbrad, @mikewest, @wseltzer this "change" makes https://www.w3.org/TR/cors/ even more obsolete than it already is. Can someone rescind it?

annevk · 2016-03-04T11:12:17Z

@hillbrad, @mikewest, @wseltzer, ping.

hillbrad · 2016-03-09T05:10:48Z

So, waaaay back on August 27th, I requested that the CORS REC be updated to
indicate that work since 2013 has continued in Fetch. @wseltzer, whatever
happened to that?

On Fri, Mar 4, 2016 at 3:12 AM Anne van Kesteren notifications@github.com
wrote:

@hillbrad https://github.com/hillbrad, @mikewest
https://github.com/mikewest, @wseltzer https://github.com/wseltzer,
ping.

—
Reply to this email directly or view it on GitHub
#204 (comment).

wseltzer · 2016-03-12T08:47:05Z

@hillbrad, @annevk looking into it, thanks.

annevk · 2016-03-25T09:32:34Z

@wseltzer any updates?

annevk · 2016-05-04T09:43:07Z

Going to close this since the actual issue is fixed. W3C not clearly communicating the state of their documents is not really something that needs to be tracked here.

annevk · 2016-05-04T09:44:34Z

(Note that it's not technically fixed, ever since Fetch was written this has been possible. I simply forgot to add the restriction that the original version had, which we no longer want to have.)

annevk · 2016-08-04T08:44:40Z

Okay, so what I missed was that Fetch does copy this restriction after all, by setting redirect mode to "error".

@youennf pointed this out in #198 (comment).

So I'm going to reopen this and then I'm going to change Fetch to not do that since we have since determined that it is secure. And with the upcoming origin-wide CORS preflights it will be relatively cheap to have redirects that require a preflight.

kopax · 2016-10-07T10:10:02Z

Any update ? why is this closed ?

annevk · 2016-10-07T10:26:52Z

Because it is fixed in the standard per the referenced commit.

kopax · 2016-10-07T10:27:53Z

I have this error

(index):1 XMLHttpRequest cannot load http://localhost:8080/login?username=dka&password=dka. The request was redirected to 'http://localhost:8080/', which is disallowed for cross-origin requests that require preflight.

when trying to authenticate in my spring application. Is there anyway to pybass the issue ? I need to have custom header for the X-XSRF-TOKEN.

annevk · 2016-10-07T10:44:45Z

You should file an issue with the user agent.

MattHartz · 2016-12-06T08:11:50Z

Hi,

I'm receiving a 307 on my preflight request and I'm not sure how to catch that promise and redirect to it's "location". Any ideas on this?

Thanks!

annevk · 2017-01-18T14:06:25Z

I noticed this is still a mess. In particular the Gecko bug is closed but not fixed. There are also existing CORS tests on WPT that contradict the standardized behavior. And I'm not sure if there's a WebKit or Edge bug filed. Reopening until that is all resolved.

Allow for redirects after a CORS-preflight ~Continue the work done in #14811 and #15547~. And applies the Fetch [spec change](whatwg/fetch@0d9a4db) about [allowing redirects after CORS preflights](whatwg/fetch#204). - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix ~#14787 and~ #14519 - [X] There are tests for these changes. Several WPTs go from FAIL to SUCCESS. The new expected FAILs for the cors/redirect-preflight.htm tests are caused by the spec change done [here](whatwg/fetch@0d9a4db), as suggested in the associated [issue](#14519 (comment)).  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/15889)

annevk · 2017-03-13T12:00:37Z

I'm going to close this issue. Current status:

@ferjm implemented this in Servo and updated tests: Allow for redirects after a CORS-preflight web-platform-tests/wpt#5107
https://bugs.chromium.org/p/chromium/issues/detail?id=580796 remains the Chrome bug
https://bugs.webkit.org/show_bug.cgi?id=159056 was the WebKit I filed that got fixed a while back
https://bugzilla.mozilla.org/show_bug.cgi?id=1346749 is the new Gecko bug I filed because the one previously identified by @nschloe was testing something else
Edge also seems to support this already.

(I also ended up filing https://bugs.webkit.org/show_bug.cgi?id=169550 and https://bugzilla.mozilla.org/show_bug.cgi?id=1346747 based on the new failure tests.)

…m ferjm:issue-14519-cors-preflight); r=avadacatavra ~Continue the work done in #14811 and #15547~. And applies the Fetch [spec change](whatwg/fetch@0d9a4db) about [allowing redirects after CORS preflights](whatwg/fetch#204). - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix ~#14787 and~ #14519 - [X] There are tests for these changes. Several WPTs go from FAIL to SUCCESS. The new expected FAILs for the cors/redirect-preflight.htm tests are caused by the spec change done [here](whatwg/fetch@0d9a4db), as suggested in the associated [issue](servo/servo#14519 (comment)). Source-Repo: https://github.com/servo/servo Source-Revision: c90d3d2f06c03d153b2be3ffa9a941cbfe8508cc --HG-- extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear extra : subtree_revision : 8a0dde32f10f530604eec26929466f886c6cd610

…m ferjm:issue-14519-cors-preflight); r=avadacatavra ~Continue the work done in #14811 and #15547~. And applies the Fetch [spec change](whatwg/fetch@0d9a4db) about [allowing redirects after CORS preflights](whatwg/fetch#204). - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix ~#14787 and~ #14519 - [X] There are tests for these changes. Several WPTs go from FAIL to SUCCESS. The new expected FAILs for the cors/redirect-preflight.htm tests are caused by the spec change done [here](whatwg/fetch@0d9a4db), as suggested in the associated [issue](servo/servo#14519 (comment)). Source-Repo: https://github.com/servo/servo Source-Revision: c90d3d2f06c03d153b2be3ffa9a941cbfe8508cc

…m ferjm:issue-14519-cors-preflight); r=avadacatavra ~Continue the work done in #14811 and #15547~. And applies the Fetch [spec change](whatwg/fetch@0d9a4db) about [allowing redirects after CORS preflights](whatwg/fetch#204). - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix ~#14787 and~ #14519 - [X] There are tests for these changes. Several WPTs go from FAIL to SUCCESS. The new expected FAILs for the cors/redirect-preflight.htm tests are caused by the spec change done [here](whatwg/fetch@0d9a4db), as suggested in the associated [issue](servo/servo#14519 (comment)). Source-Repo: https://github.com/servo/servo Source-Revision: c90d3d2f06c03d153b2be3ffa9a941cbfe8508cc UltraBlame original commit: 7458bd403ad69e8c8348c11de0c8a30db7678843

annevk added the addition/proposal New features or enhancements label Jan 22, 2016

annevk mentioned this issue Mar 23, 2016

Allow * for Access-Control-Allow-Headers and Access-Control-Allow-Methods #251

Closed

annevk closed this as completed May 4, 2016

annevk mentioned this issue Jun 23, 2016

Mark Accept-* request headers as simple / safe #326

Closed

annevk reopened this Aug 4, 2016

annevk mentioned this issue Aug 4, 2016

Only append Authorization if none is set #198

Closed

annevk closed this as completed in 0d9a4db Aug 4, 2016

Ms2ger mentioned this issue Dec 9, 2016

Allow for redirects after a CORS-preflight servo/servo#14519

Closed

annevk reopened this Jan 18, 2017

annevk added the needs tests Moving the issue forward requires someone to write tests label Jan 18, 2017

annevk mentioned this issue Feb 22, 2017

Adding redirect count tests in case of cross origin redirections web-platform-tests/wpt#4102

Open

ferjm mentioned this issue Mar 9, 2017

Allow for redirects after a CORS-preflight servo/servo#15889

Merged

4 tasks

annevk closed this as completed Mar 13, 2017

annevk mentioned this issue Mar 13, 2017

Allow for redirects after a CORS-preflight web-platform-tests/wpt#5107

Merged

ZachTRice mentioned this issue Sep 29, 2017

Add Browserstack automated testing nasa-gibs/worldview#454

Closed

whatwg deleted a comment from JefriReynaldi Dec 16, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Redirect on preflighted CORS requests generally impossible #204

Redirect on preflighted CORS requests generally impossible #204

nschloe commented Jan 22, 2016

annevk commented Jan 22, 2016

nschloe commented Jan 22, 2016

jdm commented Jan 22, 2016

nschloe commented Jan 22, 2016

nschloe commented Jan 26, 2016

annevk commented Feb 15, 2016

nschloe commented Feb 15, 2016

annevk commented Feb 15, 2016

annevk commented Mar 4, 2016

hillbrad commented Mar 9, 2016

wseltzer commented Mar 12, 2016

annevk commented Mar 25, 2016

annevk commented May 4, 2016

annevk commented May 4, 2016

annevk commented Aug 4, 2016

kopax commented Oct 7, 2016

annevk commented Oct 7, 2016

kopax commented Oct 7, 2016

annevk commented Oct 7, 2016

MattHartz commented Dec 6, 2016

annevk commented Jan 18, 2017

annevk commented Mar 13, 2017

Redirect on preflighted CORS requests generally impossible #204

Redirect on preflighted CORS requests generally impossible #204

Comments

nschloe commented Jan 22, 2016

annevk commented Jan 22, 2016

nschloe commented Jan 22, 2016

jdm commented Jan 22, 2016

nschloe commented Jan 22, 2016

nschloe commented Jan 26, 2016

annevk commented Feb 15, 2016

nschloe commented Feb 15, 2016

annevk commented Feb 15, 2016

annevk commented Mar 4, 2016

hillbrad commented Mar 9, 2016

wseltzer commented Mar 12, 2016

annevk commented Mar 25, 2016

annevk commented May 4, 2016

annevk commented May 4, 2016

annevk commented Aug 4, 2016

kopax commented Oct 7, 2016

annevk commented Oct 7, 2016

kopax commented Oct 7, 2016

annevk commented Oct 7, 2016

MattHartz commented Dec 6, 2016

annevk commented Jan 18, 2017

annevk commented Mar 13, 2017