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

CORS performance

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 17 Feb 2015 19:39:42 +0100
Message-ID: <CADnb78gP6Sm3MBC8N51jfh7RPWUZYRcTKYRcHH2Bt_LhKoWrKQ@mail.gmail.com>
To: WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>
Cc: Monsur Hossain <monsur@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Dale Harvey <dale@arandomurl.com>
Concerns raised by Monsur
https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0260.html
and others before him are still valid.

When you have an HTTP API on another origin you effectively get a huge
performance penalty. Even with caching of preflights, as each fetch is
likely to go to a distinct URL.

With the recent introduction of CSP pinning, I was wondering whether
something like "CORS pinning" would be feasible. A way for a server to
declare that it speaks CORS across an entire origin.

The CORS preflight in effect is a rather complicated way for the
server to announce that it can handle CORS. We made it rather tricky
to avoid footgun scenarios, but I'm wondering whether that is still
the right tradeoff.

Something like:

  CORS: max-age=31415926; allow-origin=*; allow-credentials=true;
allow-headers=*; allow-methods=*; expose-headers=*


-- 
https://annevankesteren.nl/
Received on Tuesday, 17 February 2015 18:40:09 UTC

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