Fetch: Redirect on preflighted CORS requests generally impossible

[nschloe]

(From the mailing list.)

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]

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]

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]

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]

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

[nschloe]

The respective section in the latest revision says:

• Otherwise, request's redirect mode is "follow", run these substeps:
  
  
  
  1. 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.
  
  
  2. If the CORS flag is set and locationURL includes credentials, return a network error.
  
  
  3. [...]
  
  

If "locationURL includes credentials" describes URLs of the type http(s)://username:[email protected], this should be fine.

[annevk]

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]

@annevk Indeed.

So I guess what remains is someone filing bugs

• Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=918767
• Chrome: https://code.google.com/p/chromium/issues/detail?id=580796

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

[annevk]

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]

@hillbrad, @mikewest, @wseltzer, ping.

[hillbrad]

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 [email protected]
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
https://github.com/whatwg/fetch/issues/204#issuecomment-192236620.

[wseltzer]

@hillbrad, @annevk looking into it, thanks.

[annevk]

@wseltzer any updates?

[annevk]

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]

(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]

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 https://github.com/whatwg/fetch/issues/198#issuecomment-236925202.

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]

Any update ? why is this closed ?

[annevk]

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

[kopax]

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]

You should file an issue with the user agent.

[MattHartz]

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]

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.

[annevk]

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

• @ferjm implemented this in Servo and updated tests: https://github.com/w3c/web-platform-tests/pull/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.)