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

Re: CORS performance

From: Brian Smith <brian@briansmith.org>
Date: Thu, 19 Feb 2015 05:50:34 -0800
Message-ID: <CAFewVt47zknktkfUG1aERAKuiiTVQFgubima3wguiEjoSL9U0Q@mail.gmail.com>
To: Dale Harvey <dale@arandomurl.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>, Monsur Hossain <monsur@gmail.com>, Jonas Sicking <jonas@sicking.cc>
Dale Harvey <dale@arandomurl.com> wrote:
>> I believe none of these require preflight unless a mistake is being
>> made (probably setting Content-Type on GET requests).
> http://www.w3.org/TR/cors/#preflight-result-cache-0
> If the cache is against the url, and we are sending requests to different
> urls, wont requests to different urls always trigger a preflight?

In general, if your GET requests don't set custom headers, preflight
isn't necessary, because CORS has an optimization for GET (and POST)
that avoids preflight, for exactly the cases like yours..

>> Also, regardless, you can use the CouchDB bulk document API to fetch
>> all these documents in one request, instead of 70,000 requests.
> CouchDB has no bulk document fetch api

Sorry. I was reading
and assumed it had been implemented already. But I see that maybe you
are trying to do something slightly different anyway with PouchDB.
Regardless, no preflight should be necessary for this and so Anne's
proposal won't help with it.

>> I agree that things can be improved here. I think the solution may be
>> better developer tools. In particular, devtools should tell you
>> exactly why a request triggered preflight.
> Whats wrong with 'This origin is part of the public internet and doesnt need
> any complications or restrictions due to CORS' ie Anne proposal?

I didn't say anything was wrong with Anne's proposal. What I said is
that it would help to have somebody present a concrete example of
where it would be useful.

Received on Thursday, 19 February 2015 13:51:04 UTC

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