Use same-origin as the default request mode

[Nisgrak]

If the mode has been set to no-cors the headers won't be sended.

I create a example stackblitz

1. Open this in other window https://beeceptor.com/console/test-ky (this logs the requests in the stackblitz example)
2. Open https://stackblitz.com/edit/js-zatpf9?file=index.js
3. Go to first openend window (beeceptor)
4. Check the headers of the two request, with-cors have x-api-key header and whitout-cors doesn't

Normal mode

No-cors mode

[sholladay]

Thank you for the great reproduction steps. This is not exactly a Ky issue but it's worth exploring.

I say that because I can reproduce the same behavior with just plain fetch, without Ky.

https://stackblitz.com/edit/js-mcdq89?file=index.js

Looking at section 2.2.5 of the fetch standard, I can see why.

https://fetch.spec.whatwg.org/#concept-request-mode

"no-cors"
Restricts requests to using CORS-safelisted methods and CORS-safelisted request-headers. Upon success, fetch will return an opaque filtered response.

So, this is working as intended because the default mode for fetch is 'no-cors' and that option restricts requests to using CORS-safelisted request headers, and x-api-key is not among them.

The only relevant thing that we could perhaps do in Ky would be to use a different default mode.

Interestingly, the fetch standard specifically calls out 'no-cors' as an unsafe mode, so it's definitely worth considering other options.

Even though the default request mode is "no-cors", standards are highly discouraged from using it for new features. It is rather unsafe.

So, should we continue using the same default as fetch or should we diverge here? Personally, I'd be happy for us to use 'same-origin', which causes an explicit error to be thrown for cross origin requests instead of this magical behavior.