"no-cors" POST and 307/308 redirects #593
Labels
security/privacy
There are security or privacy implications
Comments
annevk
added
needs tests
annevk
added a commit
that referenced
this issue
Aug 31, 2017
Otherwise things go wrong for "no-cors" POST redirects. Fixes #593.
annevk
removed
the
needs tests
annevk
added a commit
that referenced
this issue
May 24, 2018
Otherwise things go wrong for "no-cors" POST redirects. Fixes #593.
annevk
added a commit
that referenced
this issue
May 28, 2018
Before this change "no-cors" POST redirects would not have their Origin header value reset as appropriate for certain cross-origin redirects. This is now accomplished by rather than resetting request's origin (which we only did for "cors" fetches and would have bad side effects if we started doing that for "no-cors"), we set request's tainted origin flag. A new flag that indicates when request's origin is tainted and needs to be serialized as null. Tests: web-platform-tests/wpt#11164. Fixes #593.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We basically want the same behavior as we have with POST for the
Originheader. From the moment you go across origins a flag is set and then if you cross origins again we set the origin to a unique identifier.This isn't a problem for POST and 302 or some such as "no-cors" GET never includes an
Originheader.See also https://bugs.chromium.org/p/chromium/issues/detail?id=760487.
Related Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=446344.
There's also some issues with Safari here. If someone could write web-platform-tests that'd be great.
The text was updated successfully, but these errors were encountered: