Add CORS initiation to XHR request object

[PrototypeAlex]

Adds CORS to the request for the SVG file, only if the server supports it will this effect the request.

If you're loading this script from outside of your domain, or your svg files live on a different server/domain than where the javascript file originates from then you'll probably run into cross origin request issues. This patch solves that by adding CORS to the xhr request, i.e. adding the ORIGIN header to the GET request.

If CORS isn't supported then an error will occur, but this is OK, because if the browser doesn't support CORS, then it doesn't support SVG, looking at IE specifically, there could be edge cases to this? If there is, and you're reading this, please ping me and I'll write a condition for the browser in question.

[protodave]

Awesome, thanks Alex! I'll give this a spin and also double check it when it's integrated into iconic.js, etc, then I'll get this added.

[protodave]

I finally got around to playing with this and created a cross-origin test case page and IE9 VM setup. Quick update from what I learned so far...

• This change is only required to add CORS support for IE8/9 by using XDomainRequest instead of XMLHttpRequest. In browsers with XMLHttpRequest 2 support the call is the same for CORS & non-CORS, with CORS being triggered automatically when the requested resource is associated with a different origin from where the script is being executed.

• XDomainRequest doesn't send onreadystatechange events, so with this PR IE9 never returns from the xhr.send() and never injects the SVG. I'm thinking we should probably just switch over to using onload and onerror handlers, which should be fine since we only care about xhr.readyState === 4 and that's when onload is triggered.

  There are some additional checks wrapped up in the current onreadystatechange handler though to see if the injector is being run locally without a local webserver (and display a helpful warning) using xhr.status (also not available with XDomainRequest) and we are relying on the xhr.responseXML.documentElement being created for us, except in IE9 where we have to do our own DOM parsing.

So, looks like it will take a bit more wrangling and testing to refactor properly. I'll keep at it. Thanks again Alex!

[adg29]

Hey @protodave, any luck getting this PR in shape for further testing? Thanks for the initial effort in any case!

[protodave]

Hey Alan! Thanks for the nudge... I'll work on setting aside a day soon to get this, and a couple other overdue PRs and updates, over the finish line.

Also, if you have a specific use case let me know so I can test against it. (ex: CDN hosted SVGs for IE9 maybe?)

[longzheng]

Any updates on this?