-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redirect on preflighted CORS requests generally impossible #204
Comments
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. |
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. |
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. |
@jdm The preflight doesn't follow redirects alright. This is about the actual |
The respective section in the latest revision says:
If "locationURL includes credentials" describes URLs of the type |
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. |
@annevk Indeed.
Platform tests for this are needed as well, the respective bug report is here. |
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? |
So, waaaay back on August 27th, I requested that the CORS REC be updated to On Fri, Mar 4, 2016 at 3:12 AM Anne van Kesteren [email protected]
|
@wseltzer any updates? |
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. |
(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.) |
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. |
Any update ? why is this closed ? |
Because it is fixed in the standard per the referenced commit. |
I have this error
when trying to authenticate in my spring application. Is there anyway to pybass the issue ? I need to have custom header for the |
You should file an issue with the user agent. |
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! |
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)). <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/15889) <!-- Reviewable:end -->
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)). <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/15889) <!-- Reviewable:end -->
I'm going to close this issue. Current status:
(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
…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
…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
…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
(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
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?
The text was updated successfully, but these errors were encountered: