Re: CORS performance

> If the cache is against the url, and we are sending requests to different
urls, wont
> requests to different urls always trigger a preflight?

I just realised my mistake, GETS without custom headers should need to
trigger preflight requests, sorry

On 19 February 2015 at 13:31, Dale Harvey <dale@arandomurl.com> wrote:

> Will take a look at the content-type on GET requests, thanks
>
> > 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?
>
> > 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, it has all_docs but that isnt
> appropriate for this case, there is a talk about introducing it
> https://issues.apache.org/jira/browse/COUCHDB-2310, however its going to
> take a while (I would personally rather we replace it with a streaming api)
>
> > 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?
>
>
> On 19 February 2015 at 13:21, Brian Smith <brian@briansmith.org> wrote:
>
>> On Thu, Feb 19, 2015 at 4:49 AM, Dale Harvey <dale@arandomurl.com> wrote:
>> >> 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?
>>
>> To be clear, my comment was about POST requests to the bulk document
>> API, not about other requests.
>>
>> I ran your demo and observed the network traffic using Wireshark.
>> Indeed, OPTIONS requests are being sent for every GET. But, that is
>> because you are setting the Content-Type header field on your GET
>> requests. Since GET requests don't have a request body, you shouldn't
>> set the Content-Type header field on them. And, if you do, then
>> browsers will treat it as a custom header field. That is what forces
>> the preflight for those requests.
>>
>> Compare the network traffic for these two scripts:
>>
>>   <script>
>>     xhr=new XMLHttpRequest();
>>     xhr.open("GET",
>> "
>> http://skimdb.iriscouch.com/registry/_changes?timeout=25000&style=all_docs&since=209&limit=100&_nonce=xhGtdb3XqOaYCWh4
>> ",
>> true);
>>     xhr.setRequestHeader("Accept","application/json");
>>     xhr.setRequestHeader("Content-Type","application/json");
>>     xhr.send();
>>   </script>
>>
>>   <script>
>>     xhr=new XMLHttpRequest();
>>     xhr.open("GET",
>> "
>> http://skimdb.iriscouch.com/registry/_changes?timeout=25000&style=all_docs&since=209&limit=100&_nonce=xhGtdb3XqOaYCWh4
>> ",
>> true);
>>     xhr.setRequestHeader("Accept","application/json");
>>     xhr.send();
>>   </script>
>>
>> They are the same, except the second one doesn't set the Content-Type
>> header, and thus it doesn't cause the preflight to be sent.
>>
>> > if so then none of the
>> > caching will apply, CouchDB requires sending the appropriate
>> content-type
>>
>> CouchDB may require sending "Accept: application/json", but that isn't
>> considered a custom header field, so it doesn't trigger preflight.
>>
>> > 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)
>>
>> I believe none of these require preflight unless a mistake is being
>> made (probably setting Content-Type on GET requests).
>>
>> Also, regardless, you can use the CouchDB bulk document API to fetch
>> all these documents in one request, instead of 70,000 requests.
>>
>> > 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.
>>
>> 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.
>>
>> Cheers,
>> Brian
>>
>
>