Re: [whatwg/fetch] CORS-safelisted request-headers and Client Hints (#1006)

From my experience there are two simple cases in which you might care about preflights.  In the first, you are happy that they exist, because you are unsure that you have properly hardened your service against all potential accidents.  Those services are why CORS exists, but I always recommend against anything that relies on this (weak) protection.

In the second, you build the service with a strong authorization model that doesn't rely on ambient authority.  Having to build code to answer OPTIONS requests is annoying, in addition to the additional round trip that you end up paying.  I've found that there is a tendency to also want to limit positive responses to only those responses that work and those header fields that they know are good. That leads to a variation on this issue, where the CORS policy tends to block new stuff, and you have to negotiate an exclusion.  That's down to what your internal processes look like, but it can take time; I mean, it's not negotiating a change to this spec, but it isn't free either, especially when listing all the header fields starts to take more and more bytes.

-- 
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/issues/1006#issuecomment-599324320