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:password@example.com, 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 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]

@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.