Re: CORS performance

> so presumably it is OK to set the Content-Type to text/plain

Thats not ok, but may explain my confusion, is Content-Type considered a
Custom Header that will always trigger a preflight? if so then none of the
caching will apply, CouchDB requires sending the appropriate content-type

I tried setting up a little demo here, it will replicate the npm registry
for 5 seconds - http://paste.pouchdb.com/paste/q8n610/#output

You can see in the network logs various OPTIONS requests for
http://skimdb.iriscouch.com/registry/_changes?timeout=25000&style=all_docs&since=209&limit=100&_nonce=xhGtdb3XqOaYCWh4
http://skimdb.iriscouch.com/registry/_changes?timeout=25000&style=all_docs&since=311&limit=100&_nonce=UIZRQHrUG1Gjbm6S
etc etc

The /_changes requests are only part of the problem, once we receive the
changes information we then have to request information about individual
documents which all have a unique id

  GET /registry/mypackagename

We do one of those per document (70,000 npm docs), all trigger a preflight
(whether or not custom headers are involved)

We can and are doing a lot of thing to try and improve performance / reduce
the number of HTTP requests, but for our particular case its dealing with
10 years of established server protocols, there isnt 'a server', theres at
least 10 server implementations across all platforms by various projects /
companies that all need / try to interoperate, we cant just make ad hoc
changes to the protocol to get around CORS limitations.

Also performance details aside every week somebody has a library or proxy
that sends some custom header or they just missed a step when configuring
CORS, its a constant source of confusion for our users. We try to get
around it by providing helper scripts but Anne's proposal mirroring flashes
cross domain.xml sounds vastly superior to the current implementation from
the developers perspective.

On 19 February 2015 at 12:05, Brian Smith <brian@briansmith.org> wrote:

> 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.
>
> Cheers,
> Brian
>