On Feb 19, 2015 3:33 AM, "Anne van Kesteren" <ann...@annevk.nl> wrote: > > On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey <d...@arandomurl.com> wrote: > > With Couch / PouchDB we are working with an existing REST API wherein every > > request is to a different url (which is unlikely to change), the performance > > impact is significant since most of the time is used up by latency, the CORS > > preflight request essentially double the time it takes to do anything > > Yeah, also, it should not be up to us how people design their HTTP > APIs. Limiting HTTP in that way because it is hard to make CORS scale > seems bad. > >
+1. Forcing developers to change their APIs would be bad form at this stage. Not to mention just plain silly. Optimizing with an OPTIONS * preflight is a good option but won't be as broadly available to developers as a response header. Perhaps another approach would be to allow a resource to declare a CORS policy only for subordinate resources, rather than the entire origin. For instance, an OPTIONS sent to http://example.org/api/ can return CORS headers that cover every URL prefixed with http://example.org/api/. That would logically extend all the way up to OPTIONS * in order to set a policy that covers the entire origin. - James > I think we've been too conservative when introducing CORS. It's > effectively protecting content behind a firewall, but we added all > these additional opt in mechanism beyond protecting content behind a > firewall due to unease about the potential risks. Figuring out to what > extent that actually serves a purpose would be good. > > If declaring this policy through a header is not acceptable, we could > attempt a double preflight fetch for the very first CORS fetch against > an origin (that requires a preflight). Try OPTIONS * before OPTIONS > /actual-request. If that handshake succeeds (details TBD) no more > preflights necessary for the entire origin. > > > -- > https://annevankesteren.nl/ >