CORS handshake hides API Exceptions

[adam-patterson]

@bruce-alderson

Excuse the brevity. I want to record this before I leave so I don't forget. This is not well tested or understood yet.

What I'm seeing is a CORS request that results in an exception on the server masks the exception. Instead of seeing the exception I see Access-Control-Allow-Origin does not allow your origin ... or something to that extent: it looks like a CORS problem instead of the exception.

Possibly this is because presto does not include the CORS headers if an exception is raised, but I need to look into that further.

Sounds reasonable. I will look at fixing the general Presto exception pattern to allow for handling of Content-Types properly (note similar issue with JSONP - I think)

[adam-patterson]

Further investigation:

Purposefully throwing the kind of exception we would expect (eg. 404) gives the same result. The exception is 'hidden' by the CORS double call. The first call fails with the following result in the browser console:

XMLHttpRequest cannot load http://app.rubrix.test/v4/reviews/categories.html. Origin http://reports.rubrix.test is not allowed by Access-Control-Allow-Origin. progress.html?defaults:1
Rubrix [error]: Network error <em>0</em> We were unable to load a required resource from the server error 

and network console:

Request URL:http://app.rubrix.test/v4/reviews/categories.html
Request Headers
Accept:text/html, */*; q=0.01
Origin:http://reports.rubrix.test
Referer:http://reports.rubrix.test/explorable/progress.html?defaults
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

With the assumption that the exception was masked because the CORS headers are not properly set when presto handles the exception I tried setting the headers explicitly in the global exception handler. This had no effect at all, so the problem seems to be something else.