CORS and Content Server API - Preflight issues

Jeremy Pedro

I have noticed that while using fetch that any CORS triggering request(post, put, delete,...) will fail because the OPTIONS preflight request sent by the browser lacks the OTCSTicket authorization header, as you can't add custom headers to a browser's preflight request. Without the header the OPTIONS response from the content server returns a 401 unauthorized. This is a problem because the actual PUT,POST,DELETE may return a 200 OK even though the OPTIONS is returning a 401 which means it will look like everything succeeded when in reality the browser blocked your PUT, POST, DELETE request and to make things even harder to diagnose, Chrome Dev Tools doesn't show the preflight request. I had to use Postman with the Interceptor on to even see the Options request and the subsequent 401 response.

I am pretty sure the fix for this is to NOT require the OTCSTicket on OPTIONS requests only. As OPTIONS will generally only be sent by the browser for preflight CORS verification. Unless someone has another way around this, it is making my life a living **** because it effectively breaks localhost development.

Jeremy Pedro

OK so while the PUT/POST/DELETE fails it wasn't because of the OTCSTicket not being sent it was the fact that I was sending the data in the wrong content type. The content type that needs to be sent while updating a node is "application/x-www-form-urlencoded" and I was using the FETCH api to send the data across. Unless you specify a content type header, Fetch will try and decide the content type for you. When it sees a FormData object it sends the payload as "multipart/form-data". You can send your own content-type header by passing it into the header options with Fetch. This is good to know because when you create a new document it has to be sent as "multipart/form-data" and not "application/x-www-form-urlencoded". Just a heads up.