Not sure you made the right choice.
This is how to use CORS without Preflights: <a href="http://homakov.blogspot.com/2014/01/how-to-use-cors-without-preflights.html" rel="nofollow">http://homakov.blogspot.com/2014/01/how-to-use-cors-without-...</a><p>And this is why JSONP is almost always a bad idea (for sensitive data): <a href="http://homakov.blogspot.com/2013/02/are-you-sure-you-use-jsonp-properly.html" rel="nofollow">http://homakov.blogspot.com/2013/02/are-you-sure-you-use-jso...</a>
Yes, you generally need a fallback when using CORS. When I can get away with it, I prefer running a proxy on my origin domain for this fallback, as it allows me to use all the headers I like (rather than JSONP).<p>The article doesn't mention that many modern browsers don't respect MaxAgeSec for caching the OPTIONS requests, at least not for more than a few minutes, which is another knock against CORS due to it causing 2x the number of requests versus JSONP.<p>Also the article doesn't mention that, once you've already moved all your header data into the body, you can make simple requests that don't require preflight OPTIONS requests [0] - which eliminates the problem with the 2x the requests.<p>[0] <a href="http://www.w3.org/TR/cors/#simple-cross-origin-request-0" rel="nofollow">http://www.w3.org/TR/cors/#simple-cross-origin-request-0</a>
At RunOrg, we've encountered this a few times with our CORS-only API.<p>It is against our philosophy to leave users behind only because they are locked in by outdated infrastructure. We still want to support them.<p>It is against our philosophy to bend the purity of our API to accommodate wrinkles in how outdated infrastructure declines to support standards. There will be no JSONP alternative to CORS in RunOrg.<p>The solution we propose each and every time is to mount a proxy to our API on the same domain as the site it is used on. Users on modern infrastructure reach us directly at api.runorg.com, users on CORS-hostile infrastructure reach us through the proxy and still get their data (albeit with decreased performance). It's a fairly simple technical solution that leavers our API clean and supports non-CORS modes of access.
A different position would be to simply let these misconfigured and badly written networking programs fail - and let them fail hard.<p>Yes, it will be painful in the short term and users will notice outages, but in the long run it will result in these issues being fixed. If we continue a policy of reversion to bad workarounds (which is really what JSONP is), we not only add complexity and the potential for obscure exploits to our own software, we ensure that nobody at Cisco et al will ever feel the pressure to fix these bugs.