Preflight request with the OPTIONS are needed

[landonreed]

Issue by zbouziane
Tuesday Mar 07, 2017 at 11:49 GMT
Originally opened as catalogueglobal#2

---

Especially in FeedVersionController::register, FeedSourceController::register, ProjectController::register and UserController::register.

[landonreed]

Comment by landonreed
Thursday Mar 23, 2017 at 21:41 GMT

---

@zbouziane, could you elaborate on what you need additional preflight options for? Would a blanket wildcard for all routes (api/manager/*) work or do you need individual options routes specified with the precise http verbs available for that route?

I assume this is to make the proxy work?

[landonreed]

Comment by zbouziane
Tuesday Mar 28, 2017 at 13:29 GMT

---

I don't think your wildcard could solve this. It has to do with the CORS paradigm. See the following from mozilla

"The Cross-Origin Resource Sharing standard works by adding new HTTP headers that allow servers to describe the set of origins that are permitted to read that information using a web browser. Additionally, for HTTP request methods that can cause side-effects on user data (in particular; for HTTP methods other than GET, or for POST usage with certain MIME types). The specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request header, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method. Servers can also notify clients whether "credentials" (including Cookies and HTTP Authentication data) should be sent with requests."

FYI For me the server and the web app are deployed on two disjoint machines.