Safari fails CORS request after 302 redirect

Question

I have problem with the way Safari handles CORS requests. Consider following scenario:

1. DomainA hosts a page which makes a XHR request to DomainB (origin header is set to DomainA)
2. DomainB returns 302 redirect do DomainC (origin header is set to null, which seems to be OK with RFC)
3. DomainC return 200 response with actual content

This works in Chrome, FF, but it fails on Safari (tested on Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Version/8.0.8 Safari/600.8.9).

When I make the request without xhr.withCredentials turned on, first, Safari makes a OPTIONS preflight request prior actual request to DomainC, which IMHO is not nessesary as all request are simple request, but that I can handle. Problem is Safari fails after preflight request to DomainC saying "Cannot make any request from null". I can bypass this by setting Access-Control-Allow-Origin to * and drop Access-Control-Allow-Credentials header (those are mutually exclusive), which would make this scenario work. However I still think this is not correct behavior.

Now, thing is I need credentials to be passed by (and no, I can not pass it some other way as it depends on some third party servers). So, let's set

xhr.withCredentials

to true and we are back to "Cannot make any request from null" and now even wildcarding Access-Control-Allow-Credentials does not help.

I think all CORS headers are set properly, but please feel free to check me. Test example can be found here: http://a.ihatesafari.com

What is going on here? Is it a bug or am I missing something?

Thanks for answers

Subjacent

It even fails in the simpler case of DomainA making an XHR to DomainA and redirecting to DomainC. – Krahling

Answer 1

I was experiencing this issue as well and found this bug from 2012 that appears to be describing it. Running the test code referenced in the bug in FF / Chrome / Safari yielded failures only in Safari. It appears that the bug has not been patched.

Ultimately to get around this, I modified our HTTP API to add an optional query parameter to trigger a different response that returned a 200 OK with a JSON body containing the url that the client was to follow. Unfortunately if you're a consumer of someone else's HTTP API this won't help much.

Threw

I'm experiencing this problem calling a third party API. Any idea on how I can workaround (or solve) this? – Paleoclimatology

If you have your own web server / API you could perhaps wrap the third party API call with a call you implement on your server that functions in a way that Safari can work with. – Threw