Re: [fetch] Status code to use in a response indicating rejection of a cross-origin access (#172)

Discussed this with @yutakahirano.

When the ServiceWorker is used, we may serve (by calling `respondWith()`) a no-CORS request for loading a sub-resource with a response fetched using a modified request (e.g. changing URL). The modified request's `omit-Origin-header-flag` is unset. Given this, it seems that a server basically shouldn't alter a response to send based on presence of a Origin header. Applying a stricter rule for requests with the Origin header may unexpectedly apply a stricter rule to SW-controlled pages even though either the SW or the controlled page's script cannot see the contents of the no-CORS response.

Now, you see that the via-SW request is not distinguishable from a request issued by CORS enabled fetching. Both have the Origin header. The mode (no-CORS or CORS) is not visible to the server. So, there's no way to serve them differently. If you're going to accept no-CORS requests based on the above discussion, you also have to accept CORS requests.

This suggests that we shouldn't do anything special at the server basically. As Mark said, the enforcement point is the client and only the client knows the mode (CORS/no-CORS). It seems the best thing to do is just serving any request regardless of the Origin presence but setting `Access-Control-Allow-Origin` appropriately based on the Origin value if any.

----

One can give up serving requests w/o the Origin header correctly, and return simplified body-less 4XX response for bad Origin requests, if they really want. Maybe it helps DDoS protection to some extent.

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