Re: CORS performance

> What is it about PouchDB and CouchDB that causes them to require
> preflight for all of these requests in the first place? What is
> difficult about changing them to not require preflight for all of
> these requests?

The REST api pretty much by design means a unique url per request, in this
case a lot of the requests look like

  GET origin/_change?since=0
  GET origin/_change?since=the last id

Its unlikely to change since its 10 years old across standardized across
several different products that works well in most cases aside for just
being kinda slow when you try to use it over CORS.

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

This is very much what I expected when I first used CORS, similiar to the
flash cross-domain.xml file, I would just like to mark an origin I control
as being accessible from any host, as the only things CORS protects is data
behind a firewall I think it should be a simple mechanism to say "this
domain is not behind a firewall, have at it"


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

> 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
>
> I understand that currently the cost of this API is 2*N and you want
> to reduce the 2 to 1 instead of reducing the N, even though N is
> usually much larger than 2.
>
> What is it about PouchDB and CouchDB that causes them to require
> preflight for all of these requests in the first place? What is
> difficult about changing them to not require preflight for all of
> these requests?
>
> Cheers,
> Brian
>