-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Allow for redirects after a CORS-preflight #5107
Allow for redirects after a CORS-preflight #5107
Conversation
Firefox (nightly channel)Testing web-platform-tests at revision c531fe0 All results2 tests ran/cors/preflight-failure.htm
/cors/redirect-preflight.htm
|
Chrome (unstable channel)Testing web-platform-tests at revision c531fe0 All results2 tests ran/cors/preflight-failure.htm
/cors/redirect-preflight.htm
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing we might want to do is to turn these into asynchronous XMLHttpRequest so they don't end up blocking each other. Given the cache busting that should be fine...
cors/redirect-preflight.htm
Outdated
assert_throws(null, function() { client.send(null) }); | ||
|
||
}, | ||
'Redirect ' + code + ' on preflight') | ||
}, 'Redirect ' + code + ' on preflight'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So these tests are not actually checking redirects as much as they are checking that a non-2xx status code on preflights causes failure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
The spec says in steps 6 and 7 of CORS preflight fetch:
(6) If a CORS check for request and response returns success and response’s status is an ok status, run these substeps [...]. (7) Otherwise, return a network error.
There is no explicit mention about 3XX redirection status codes. So maybe this is not the best place for this test? Is this what you are suggesting with your comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was mostly curious. At some point we should probably test other status codes too... I don't really know how much effort you want to put into cleaning up the test suite though. Seems fine to me if you just do it as you come across stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I've been slowly making my way through the web-platform-tests backlog for Fetch and friends, but still lots that can be done.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to help with the clean up :). It should be easy to test failures for all non-2XX status codes on preflights, so I'll do it in this PR, along with the change to async XHR. Thanks for the feedback!
Sure. I'll turn the tests into async XHRs. |
These tests are now available on w3c-test.org |
7bb0bd3
to
292ebb8
Compare
Sigh. I think to fix the build error you need to rebase on latest master and force push. Not sure what else can be it. |
Never mind, the problem is #4540. |
See whatwg/fetch#204 (comment) for bugs I ended up filing and overall status of this feature. |
This PR tries to address the changes on the Fetch spec introduced to allow redirects after CORS-preflitghts.
I took the opportunity to do some code clean up as well.