IE9 does not work when using CORS

[tsegall]

We have run into a set of issues when testing IE9.

According to the discussion below the front end needs to be https in order to
interact with the userapp, since there is a known limitation in IE9..

When we get past that issue (by using https on the front end) we run into another
issue in userapp.client.js where you are calling xhr.setRequestHeader which
does not exist on the XDomainObject. If you comment that out (which looks valid to do) then you run into another issue where you get 'Unable to load '
https://app.userapp.io/v1/user.login'

It appears that the client library does not currently support either IE9 or IE8? These two versions account for approximately 30% of all browsers.

Thanks in advance, Tim.

See the following, I have included the relevant section #7
http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx
#7

7. Requests must be targeted to the same scheme as the hosting page

This restriction means that if your AJAX page is at http://example.com,
then your target URL must also begin with HTTP. Similarly, if your AJAX
page is at https://example.com, then your target URL must also begin with
HTTPS.

It was definitely our intent to prevent HTTPS pages from making
XDomainRequests for HTTP-based resources, as that scenario presents a Mixed
Content Security Threat
http://blogs.msdn.com/ieinternals/archive/2009/06/22/HTTPS-Mixed-Content-in-IE8.aspx

which many developers and most users do not understand.

However, this restriction is overly broad, because it prevents HTTP pages
from issuing XDomainRequests targeted to HTTPS pages. While it’s true that
the HTTP page itself may have been compromised, there’s no reason that it
should be forbidden from receiving public resources securely.

Worst of all, the Same Scheme restriction means that web developers testing
their pages locally using the file:// scheme will find that all of the
XDomainRequests are blocked because file:// doesn’t match either http:// or
https://, which are the only valid target schemes (point #1). To workaround
this issue, web developers must host their pages on a local web server
(e.g. IIS, the Visual Studio hosting server, etc).

[timothyej]

Thank for submitting this, we're looking into it at the moment.

[colby-swandale]

Tim have you guys done anything about this problem? I am having this same compatibility problem as well, i worked around the HTTP to HTTPs problem but when the library tries to set headers in IE8 it starts to flip out. I have spend a few hours trying to see if a workaround was possible and stumbled across a few possibilities such as https://github.com/jpillora/xdomain but this requires part from the userapp guys to get working.