[fetch] should navigation requests really be same-origin or no-cors? (#101)

Step 2.2 of [HTTP Fetch][] currently has the following note:

> The underlying assumption here is that all client requests use mode "same-origin", which is currently not explicitly stated for navigation requests. 

This is necessary for the step 2.2 checks to properly block opaque responses from being used to intercept a navigation.

It seems, however, forcing navigations to same-origin has other consequences.  Mainly, it would seem to prevent navigations from following cross origin redirects as they currently do on the web:

* When a 30x is encountered step 5 of [HTTP Fetch][] recursively calls [Main Fetch][] using the new location.
* Step 8 of [Main Fetch][] checks to see if the current URL is same origin, and if its not it explicitly returns NetworkError for same-origin RequestMode.

I ran into this while trying to make our navigations same-origin.  We have a test that does `respondWith(fetch(evt.request))` for a navigation request to a cross-origin 308.  This fails when RequestMode is same-origin due the issue above.  When navigations are RequestMode no-cors, then this works.

Note, currently both chrome and firefox implement navigations as no-cors and block opaque interception using a secondary check.

[HTTP Fetch]: https://fetch.spec.whatwg.org/#http-fetch
[Main Fetch]: https://fetch.spec.whatwg.org/#main-fetch

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