我有在 IE8 中使用 Microsoft 的 XDomainRequest 对象的代码。代码如下所示:
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();
当“url”中的方案为“http://”时,该命令可以正常工作。然而,当方案是“https://”时,IE8 会给我一个“访问被拒绝”的 JavaScript 错误。这两种方案在 FF 3.6.3 中都可以正常工作,当然,我使用的是 XmlHttpRequest。对于这两种浏览器,我都遵守 W3C 访问控制。 “http://”对于两种浏览器都可以跨源工作。所以问题出在 IE8、XDomainRequest 和 SSL 上。
SSL 证书不是问题。如果我在 IE8 的地址栏中输入 https://>/,其中 >与上面的“url”相同,页面加载正常。
所以我们有以下内容:
- 直接从浏览器点击 https://>/ 效果很好;
- 点击 https://>/api/acquire?>不允许通过 XDomainRequest。
能做到吗?我遗漏了什么吗?
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?
发布评论
评论(1)
显然,答案就在这里: 链接
此页面上的第 7 点表示:“请求必须针对与托管页面相同的方案。”
以下是第 7 点的一些支持文字:
看来,我原来问题的答案是:是,如果托管页面可以使用“https://”方案;否,如果不能。
Apparently, the answer is here: Link
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 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.