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

Another point I want make about having a statement like *“In such cases using the 403 status is encouraged”* in the spec itself is that some server/library developers reading that are going to treat it as a _de facto_ part of the protocol and so feel the need to implement it because they see it a being part of the spec — while other server/library developers (most of them, in practice), are going to just never even notice that statement, or else just ignore it.

And so in this case what’s that’s resulted in fragmentation: Most servers/libraries don’t send 403 errors for this case, while some few others do.

And the result of that for the frontend developers is that, for any given API endpoint they’re making a request to, if they receive a 403 error, they can’t reliably know whether that 403 might have the “opting out of CORS” semantic or not. The only way they might have a chance of knowing that is if they also have some knowledge about that what CORS library might be used in server environment of the the particular API endpoint they’re sending the request to.

So I think having that statement in the spec is essentially adding an optional feature to the protocol. And it seems like in general, having an optional feature in the protocol is not a super-great idea, for the reasons detailed above.

If we think responding with a 403 for the “opting out of CORS” case is the best thing to do, then I think we should have made it a normative requirement of the protocol. But if we didn’t think it was important or essential enough to make it part of the protocol, then I think we should not be saying anything about it all.

The bottom line for me is, I have seen no evidence to indicate that statement of encouragement in the spec is helping solve any problems on scale for anybody in practice — while I have however seen evidence that it has caused confusion on scale for frontend developers trying to troubleshoot CORS issues.

-- 
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_r727822506