Web browsers typically implement a “same-origin policy” to prevent code from making requests against a different origin to the one from which the code was served. The intention of the same-origin policy is to provide protection from malicious web sites. As a consequence, by default and without relaxing measures, my web application running on localhost during development cannot access endpoints on OCI API Gateway.
There is a solution: Cross-Origin Resource Sharing (CORS) is a cross-origin sharing standard to relax the same-origin policy by allowing code on a web page to consume a REST API served from a different origin. The CORS standard uses additional HTTP request headers and response headers to specify the origins that can be accessed.
My web application runs on localhost, makes HTTP PUT requests to the endpoint on an API Gateway deployment and sends three headers: Content-Type, file-name and X-Client-Secret.
To allow these calls to succeed, I have to configure the appropriate CORS settings on the deployment. These are shown in the screenshot. Note: I have been a bit lazy here by declaring * as an allowed origin – which covers all origins. During development I assume that this is ok and I do not fear malicious abuse.
The errors I received in the browser before configuring these CORS settings were quite clear and helped me figure out which CORS settings were required.
Resources
Oracle Cloud documentation – API Gateway Adding CORS support to API Deployments – https://docs.oracle.com/en-us/iaas/Content/APIGateway/Tasks/apigatewayaddingcorssupport.htm