W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: CORS performance

From: James M Snell <jasnell@gmail.com>
Date: Thu, 19 Feb 2015 06:02:50 -0800
Message-ID: <CABP7RbeQTc=6pd=ieaT6ybOQg-xGRLpGpS9D2oL9-=mAD-FwQw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Brian Smith <brian@briansmith.org>, Dale Harvey <dale@arandomurl.com>, Monsur Hossain <monsur@gmail.com>, Jonas Sicking <jonas@sicking.cc>, WebApps WG <public-webapps@w3.org>, WebAppSec WG <public-webappsec@w3.org>
On Feb 19, 2015 3:33 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>
> 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.
>
>

+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/
>
Received on Thursday, 19 February 2015 14:03:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC