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 04:05:10 -0800
Message-ID: <CAFewVt5UB-iRenee0EOf4nxO8jK9M=xOL+zHu_W9DRc5tVBOHA@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:
> The REST api pretty much by design means a unique url per request

CouchDB has http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API,
which allows you to fetch or edit and create multiple documents at
once, with one HTTP request. CouchDB's documentation says you're
supposed to POST a JSON document for editing, but the example doesn't
set the Content-Type on the request so presumably it is OK to set the
Content-Type to text/plain. This means that you'd have ONE request and
ZERO preflights to edit N documents.

> in this case a lot of the requests look like
>   GET origin/_change?since=0
>   GET origin/_change?since=the last id

A GET like this won't require preflight unless you set custom header
fields on the request. Are you setting custom headers? If so, which
ones and why? I looked at the CouchDB documentation and it doesn't
mention any custom header fields. Thus, it seems to me like none of
the GET requests should require preflight.

Also, if your server is SPDY or HTTP/2, you should be able to
configure it so that when the server receives a request "GET
/whatever/123", it replies with the response for that request AND
pushes the response for the not-even-yet-sent "OPTIONS /whatever/123"
request. In that case, even if you don't use the preflight-less bulk
document API and insist on using PUT, there's zero added latency from
the preflight.

Received on Thursday, 19 February 2015 12:05:39 UTC

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