Re: CORS performance

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/
>