- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 19 Feb 2015 12:30:46 +0100
- To: Dale Harvey <dale@arandomurl.com>
- Cc: Brian Smith <brian@briansmith.org>, WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>, Monsur Hossain <monsur@gmail.com>, Jonas Sicking <jonas@sicking.cc>
On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey <dale@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. 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/
Received on Thursday, 19 February 2015 11:31:09 UTC