3 ms·
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
by gkop 12y ago
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).
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.
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.
[0] http://www.w3.org/TR/cors/#simple-cross-origin-request-0 http://www.w3.org/TR/cors/#simple-cross-origin-request-0
- jlemoine 12y agoI am the author of the post. You're right, I should have mentioned the OPTIONS related problems. The first problem we have got with OPTIONS request is that the cache is only working for the full URL (including URL parameters). So you should prefer a POST API endpoint with parameters in the body instead of a GET API endpoint with parameters in the URL. We have tested a lot caching of OPTIONS requests and we did not found any issue on recent browsers, they respect the cache is you specify the header Access-Control-Max-Age (they do not respect the Cache-Control header)
- gkop 12y agoThanks, you're right that the latest Chrome and Firefox are caching my OPTIONS.