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.

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.


Reply via email to