W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CORS performance

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 19 Feb 2015 12:30:46 +0100
Message-ID: <CADnb78j_t0_+6ahy2FsDYQQP3bKXouEMncoHSauFk-Cw6QpQzw@mail.gmail.com>
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.

Received on Thursday, 19 February 2015 11:31:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC