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

> Of the status codes that are on offer this does seem the most appropriate one.

In all the SO questions and answers I’ve read, I can’t say that I’ve ever seen anybody write frontend code that checks for a 403 as an indication of “opting out of CORS”.

So while in theory, sending a 403 is appropriate, I don’t think we have any evidence that in practice it’s something that developers writing frontend code expect or write any special handling for.

> I suppose we could note that including the necessary CORS headers on this alternative response might aid in debugging.

I agree, though in practice that adds an additional complication for developers — one more thing to worry about. To be clear, the reason it’s more complicated is the fact many widely-used server systems don’t add application-set response headers to 4xx or 5xx errors — most notably maybe, Apache and nginx do not. And so in order make browsers allow frontend code to access those 4xx and 5xx responses, server developers need to do some additional work — such as adding the `always` parameter to the header-setting directives in Apache and nginx — and from what I have observed, many developers in practice are not aware that that their application-set headers won’t be adding to 4xx and 5xx responses, and don’t know how to make them get added.

So given that if a 403 error is sent without the Access-Control-Allow-Origin header, it’s basically useless to frontend JavaScript code trying to consume a response, I really think that’s another reason why it’s not necessary — and not even helpful — to have the spec encouraging server developers to respond with 403 errors for the “opting out of CORS” case.



-- 
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#discussion_r727806040