Re: CORS performance proposal

On Fri, Mar 18, 2016 at 6:05 PM, Hewitt, Rory <rhewitt@akamai.com> wrote:
> The original intent of CORS was, I assume, that developers would spend time figuring out exactly which headers the application should allow, and only allow those to be processed by the application. However, that is (again, in my experience) rarely the case - developers simply list all the headers that they can possibly think might be sent by an API and allow them. Or they go the route of mirroring back the AC-Request-Headers value. Partly this may be due to the fact that the team adding the XMLHttpRequest call in the client-side code may not be the same team that wrote the backend API in the first place - it's the former team the defines what headers will be sent, and it's the latter team that defines what value should be returned  in AC-Allow-Headers.

It's been a while, but my recollection is that while designing CORS it
did not always have explicit header/method opt-in. We added that based
on feedback from Mozilla's security team proxied through Jonas
Sicking. They were afraid of certain request headers/methods
triggering the wrong thing. We should have gone maybe more in depth on
that at the time, especially since this keeps coming up. Even though I
work for Mozilla I have never quite figured out all the constraints
and thinking here. Just the general concerns. I would happily make
some changes here, but it's hard to figure out who to talk to.

AC-Expose-Headers was added later, based on feedback from mnot (who I
guess directed you here, say hi), and we did not really consider *
there. We just went with the simplest thing that matched what we
already did for request headers and everyone thought was reasonable.


-- 
https://annevankesteren.nl/

Received on Friday, 18 March 2016 17:21:33 UTC