CORS

When you work whit services on a different domain, the horror and pain from fighting with CORS are unavoidable. Exactly, was unavoidable, before I discover how to prevent browsers to send “silly” preflight OPTIONS request. I was desperately trying everything, middleware, proxying requests, and accepting and dropping  OPTIONS requests on the server side. But when you don’t have control on the server side, the server is some public API for example, the pain was imminent.

Solutions

All these technics are actually working quite fine. Middleware, proxying requests and accepting and dropping  OPTIONS requests on the server, all work. But wasting time on additional requests is usually unacceptable.  Of course, you can disable the CORS and preflight request on a browser, but that is a solution only in the development environment, and as in electron application, or some similar environment.

Eureka!

And finally, yesterday, by reading this article I’ve been enlighted 🙂 the solution is so simple, painfully simple and it is: DON’T SEND any additional HEADERS with the request.  For some silly reasons browsers send a preflight OPTIONS request and usually, for some other silly reasons, that is forbidden, unacceptable,  or against CORS policies on the serv.

Interesting

This is an interesting article with nice explanation off preflight request. Also there you can find a list of headers triggering preflight request.

Article about CORS, on Mozzila developer.