Re: [whatwg/fetch] CORS: more information for server developers (#1330)

@sideshowbarker commented on this pull request.



> -<a for=/>headers</a>. The server is encouraged to use the 403 <a for=/>status</a> in such HTTP
-responses.
+<p>Server developers have a lot of freedom in how they handle responses and these tactics can differ
+between the response to the <a>CORS-preflight request</a> and the <a>CORS request</a> that follows
+it:
+
+<ul>
+ <li><p>They can provide a static response. This can be helpful when working with caching
+ intermediaries. The client will perform validation of the response before exposing it, though side
+ channels such as timing might inadvertently leak information.
+
+ <li><p>They can provide a dynamic response, tuned to the exact request headers. This can be helpful
+ when the response body is to be tailored to a specific origin.
+
+ <li><p>They can decide not to partake in the <a>CORS protocol</a> by not including the relevant
+ response headers. In such cases using the 403 status is encouraged. Not including the normal

```suggestion
 response headers. Not including the normal
```

Based on my experiences on Stack Overflow — having read every day, for several years now, every single question and answer posted each day in the Stack `[cors]` tag (and often having discussions in comments there with developers, and actually answering 300+ `[cors]` questions on Stack Overflow), I want to strongly suggest that the spec stop encouraging server developers to send 403 responses in the case where they’re opting out from participating in the CORS protocol for a specific origin.

The reason I say that is, in my experience with trying to help developers troubleshoot CORS issues and identify what’s causing them, a 403 error from the server often just muddies the waters and in practice makes its more difficult for developers to troubleshoot errors and identify where the real cause is.

Part of the problem is, because the server code for a particular API endpoint or route may be configured to respond with a 403 error for reasons other than a CORS origin mismatch or something CORS-related — and because in fact in practice, a 403 error is more likely to be caused by something other than a CORS-related cause — a 403 for the CORS case just adds additional difficulty for developers, in trying to distinguish 403 errors that are caused by non-CORS-related code from 403 errors that are caused by CORS code.

The good news for developers is that in practice, CORS libraries for _most_ runtimes/server systems _don’t_ send 403 errors for anything CORS-related — instead they just don’t return the Access-Control-Allow-Origin header.

Unfortunately, though, there are a few widely-used CORS libraries that do send 403 errors for the “opting out of CORS” case. And what I can say I have observed time and again with developers using those libraries is that the 403 error just adds an additional unnecessary complication for developers who are trying to troubleshoot problems.

Because of all that, I can say that what I believe makes things easier for developers is for CORS libraries to not send a 403 error for the “opting out of CORS” case but instead to just send a 200 OK without the Access-Control-Allow-Origin header.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1330#pullrequestreview-778027481