[fetch] redirecting from same-origin to cross-origin CORS with userpass should fail (#112)

Currently the redirect section of [HTTP Fetch](https://fetch.spec.whatwg.org/#http-fetch) step 5 says:

> If the CORS flag is set and either locationURL's username is not the empty string or locationURL's password is non-null, return a network error.

As far as I can tell, the only way for the CORS flag to be set is if we've previously already redirected through a CORS origin.  If the CORS location with userpass was reached from a same-origin URL redirecting, then the CORS flag is not set.

This is counter to how the existing gecko CORS infrastructure works.  It blocks userpass when redirecting to a CORS enabled server regardless of the originating origin doing the redirect.  Gecko code is here:

  https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCORSListenerProxy.cpp?case=true&from=nsCORSListenerProxy.cpp#957

Which is correct?  It seems the gecko version is safer, but maybe its too conservative?

It seems whatever we decide here should also be applied to:

> If the CORS flag is set and locationURL's origin is not request's current url's origin, set request's origin to an opaque identifier. 

In both cases it seems perhaps we should be checking if the RequestMode is 'cors' instead of checking the CORS flag.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/112