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

**tl;dr:** see the title.

**Long and trivial version:**

The CORS protocol can work independently from the response representation. I.e. attaching/omitting the `Access-Control-Allow-Origin` header can instruct UAs whether or not to allow the script to see the response without making any change on the other headers and status-line.

So, to define the CORS algorith, technically, we don't have to define any dedicated HTTP status code for representing rejection due to a bad Origin value. Actually, the current spec doesn't say anything (neither requirement nor recommendation) about a status code to include in a response representing cross-origin access rejection.

Does this design imply that the server should:
- serve the contents anyway
- but decide whether or not to include `Allow-Control-Allow-Origin` to instruct the UA how to handle the response in CORS enabled case
- and then delegate the final decision to the UA. It's possible that the UA doesn't use the `Allow-Control-Allow-Origin` in case the request was issued in the `no-CORS` mode.
  - this (the server sees Origin header but the UA is in `no-CORS` mode) happens since XHR and Fetch works with omit-Origin-header-flag unset.

Regardless the answer is yes or no, in practice, developers want to reject unexpected cross origin requests at minimum cost. We basically want to keep the connection alive, so disconnect is not the best idea. Then, we generate a response w/o `Allow-Control-Allow-Origin`, body. I.e. the response no longer represent any valid response from the application layer. What status code should we put in the response? Maybe 403 is appropriate. But I wonder if there any discussion about this topic has happened in past.

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