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

@annevk 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

I guess I don't really see how any of this is a problem for frontend devs. They either get a response or not and there's not a whole lot for them to configure other than whether to include credentials.

And as you note they can't even observe the 403 (except through developer tooling) as it gets turned into a network error.

#172 has some context on this. If you decide to not handle a particular request it definitely seems more helpful to send a 403 than a 200, especially since the latter might give the impression it's okay to always send the whole response, as long as you exclude the headers. That's not necessarily okay as the server might perform work that's specific to the user and thereby reveal information to the requesting party.

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