ajax - ¿Se puede hacer que XDomainRequest funcione con SSL?

internet-explorer-8 internet-explorer-9

Question

Tengo un código que utiliza el objeto XDomainRequest de Microsoft en IE8. El código se ve así:

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();  

Cuando el esquema en "url" es "http: //" el comando funciona bien. Sin embargo, cuando el esquema es "https: //" IE8 me da un error de JavaScript de "Acceso denegado". Ambos esquemas funcionan bien en FF 3.6.3, donde estoy, por supuesto, usando XmlHttpRequest. Con ambos navegadores estoy cumpliendo con el control de acceso W3C. "http: //" funciona de origen cruzado para ambos navegadores. Entonces el problema es con IE8, XDomainRequest y SSL.

El certificado SSL no es el problema. Si escribo https: // <host > / en la barra de direcciones de IE8, donde <host > es el mismo que en la "url" anterior, la página se carga bien.

Así que tenemos lo siguiente:
- presionar https: // <host > / directamente desde el navegador funciona bien;
- pulsando https: // <host > / api / adquiera? <query string > a través de XDomainRequest no está permitido.

Se puede hacer? ¿Estoy dejando algo fuera?

Answer 1

Al parecer, la respuesta está aquí: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

El punto 7 en esta página dice: "Las solicitudes deben dirigirse al mismo esquema que la página de alojamiento".

Aquí está algo del texto de apoyo para el punto 7:

"Definitivamente, fue nuestra intención evitar que las páginas HTTPS realicen XDomainRequests para recursos basados ​​en HTTP, ya que ese escenario presenta una amenaza de seguridad de contenido mixto que muchos desarrolladores y la mayoría de los usuarios no comprenden.

Sin embargo, esta restricción es demasiado amplia, ya que evita que las páginas HTTP emitan XDomainRequests dirigidas a páginas HTTPS. Si bien es cierto que la propia página HTTP puede estar comprometida, no hay ninguna razón por la que deba prohibirse que reciba recursos públicos de forma segura ".

Parece que en este momento la respuesta a mi pregunta original es: SÍ, si la página de alojamiento puede usar el esquema "https: //"; NO, si no puede.