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

> I guess I don't really see how any of this is a problem for frontend devs. They either get a response or not

This about what they see in the devtools Network pane — not just about what gets exposed to the frontend code.

> and there's not a whole lot for them to configure other than whether to include credentials

As far as questions getting posted to SO, sometimes (often) the developer is writing both the server CORS config and some frontend code too.

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

Right — but they can observe the 403 in the devtools Network pane.

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