Can XDomainRequest be made to work with SSL?

Question

I have code that uses Microsoft's XDomainRequest object in IE8. The code looks like this:

var url = "http://<host>/api/acquire?<query string>";  
var xdr = new XDomainRequest();  
xdr.onload = function(){  
    $.("#identifier").text(xdr.responseText);  
};  
xdr.open("GET", url);  
xdr.send();  

When the scheme in "url" is "http://" the command works fine. However, when the scheme is "https://" IE8 gives me an "Access denied" JavaScript error. Both schemes work fine in FF 3.6.3, where I am, of course, using XmlHttpRequest. With both browsers I am complying with W3C Access Control. "http://" works cross origin for both browsers. So the problem is with IE8, XDomainRequest, and SSL.

The SSL certificate is not the problem. If I type https://<host>/ into the address bar of IE8, where <host> is the same as in "url" above, the page loads fine.

So we have the following:
- hitting https://<host>/ directly from the browser works fine;
- hitting https://<host>/api/acquire?<query string> via XDomainRequest is not allowed.

Can it be done? Am I leaving something out?

Answer 1

Apparently, the answer is here: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

Point 7 on this page says, "Requests must be targeted to the same scheme as the hosting page."

Here is some of the supporting text for point 7:

"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 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."

It would appear at present that the answer to my original question is: YES, if the hosting page can use the "https://" scheme; NO, if it cannot.