CORS Error Response Handling
According to the CORS specification, to indicate an invalid CORS request one simply does not add any CORS specific headers to the response.
There are two situations with regards to CORS Preflight request where this might cause confusion:
- The request is using a HTTP Method that is not supported by the server
- The request contains headers that are not supported by the server
In both of these cases the response status would be 200, but there will be no CORS-specific response headers. Since there are no CORS-specific headers in the response, the browser assumes the request is invalid, and doesn’t make the actual request. For both of these situations the client would see the same error:
XMLHttpRequest cannot load http://corscontroller-danbev.rhcloud.com/aerogear-controller-demo/delorean. Origin http://corsclient-danbev.rhcloud.com is not allowed by Access-Control-Allow-Origin.
In AeroGear Controller we currently log the different cases, for example if a bad request header was included in the request you'd find this in the log:
AG_CONTROLLER000007: CORS Bad Request Headers: Received 'origin, x-header1, x-header2', allowed: '[origin]'
At the moment this is logged at INFO level as you can see but perhaps this would be logged with a different level before being pushed.
We have the option to perhaps include some information about what went wrong to the calling client using a similar message as found above. For example, adding a JSON object to the response body which would be AeroGear specific.
You can find a CORS enabled version of aerogear-controller-demo and a very simple client app which are available on openshift. For the client app you can use developer tool in you browser to inspect the request/response headers and also the error message in the console.