阻塞的AJAX请求
我们先来证实一下请求的阻塞情况吧。我们使用如下的代码：
连续发起三个请求
function simpleRequest()
{
var request = new XMLHttpRequest();
request.open("POST", "Script.ashx");
request.send(null);
}
function threeRequests()
{
simpleRequest();
simpleRequest();
simpleRequest();
}
当执行threeRequests时就会连续发出3个相同域名的请求，还是通过统计图表来查看阻塞的效果，如图：
每个请求需要花费1.5秒的时间。很明显，第三个请求必须等到第一个请求结束之后才能执行，因此总共需要进行3秒多钟才能执行完毕。我们要改变的就是这个状况。
传统的跨域名异步请求解决方案
AJAX安全性的唯一保证，似乎就是对于跨域名（Cross-Domain）AJAX请求的限制。除非打开本地硬盘的网页，或者在IE中将跨域名传输数据的限制打开，否则向其他域名发出AJAX请求都会被禁止。而且对于跨域名的判断非常严格，不同的子域名，或者相同域名的不同端口，都会被认作是不同的域名，我们不能向它们的资源发出AJAX请求。
从表面上看起来似乎没有办法打破这个限制，还好我们有个救星，那就是iframe！
iframe虽然不在标准中出现，但是由于它实在有用，FireFox也“不得不”对它进行了支持（类似的还有innerHTML）。网上已经有一些跨域名发出异步请求的做法，但是它们实在做的不好。它们的简单工作原理如下：在另一个域名下放置一个特定的页面文件作为Proxy，主页面将异步请求的信息通过Query String传递入iframe里的Proxy页面，Proxy页面在AJAX请求执行完毕后将结果放在自己location的hash中，而主页面会对iframe的src的hash值进行轮询，一旦发现它出现了改变，则通过hash值得到需要的信息。
这个方法的实现比较复杂，而且功能有限。在IE和FireFox中，对于URL的长度大约可以支持2000个左右的字符。对于普通的需求它可能已经足够了，可惜如果真要传递大量的数据，这就远远不够了。与我们一会儿要提出的解决方案相比，可能它唯一的优势就是能够跨任意域名进行异步请求，而我们的解决方案只能突破子域名的限制。
那么现在来看看我们的做法！
优雅地突破子域名的限制
我们突破子域名限制的关键还是在于iframe。
iframe是的好东西，我们能够跨过子域名来访问iframe里的页面对象，例如window和DOM结构，包括调用JavaScript（通过window对象）——我们将内外页面的document.domain设为相同就可以了。然后在不同子域名的页面发起不同的请求，把结果通过JavaScript进行传递即可。唯一需要的也仅仅是一个简单的静态页面作为Proxy而已。
我们现在就来开始编写一个原形，虽然简单，但是可以说明问题。
首先，我们先来编写一个静态页面，作为放在iframe里的Proxy，如下：
SubDomainProxy.html
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Untitled Page</title>
<script type="text/javascript" language="javascript">
document.domain = "test.com";
function sendRequest(method, url)
{
var request = new XMLHttpRequest();
request.open(method, url);
request.send(null);
}
</script>
</head>
<body>
</body>
</html>
然后我们再编写我们的主页面：
http://www.test.com/Default.html
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
<script type="text/javascript" language="javascript">
document.domain = "test.com";
function simpleRequest()
{
var request = new XMLHttpRequest();
request.open("POST", "Script.ashx");
request.send(null);
}
function crossSubDomainRequest()
{
var proxy = document.getElementById("iframeProxy").contentWindow;
proxy.sendRequest('POST', 'http://sub0.test.com/Script.ashx');
}
function threeRequests()
{
simpleRequest();
simpleRequest();
crossSubDomainRequest();
}
</script>
</head>
<body>
<input type="button" value="Request" onclick="threeRequests()" />
<iframe src="/UploadFiles/2021-04-02/SubDomainProxy.html"> id="iframeProxy"></iframe>
</body>
</html>
当执行threeRequests方法时，将会同时请求http://www.test.com以及http://sub0.test.com两个不同域名下的资源。很明显，最后一个请求已经不会受到前两个请求的阻塞了 如图：
令人满意的结果！
虽说只能突破子域名，但是这已经足够了，不是吗？我们为什么要强求任意域名之间能够异步通讯呢？更何况我们的解决方案是多么的优雅！在下一篇文章中，我们将会为ASP.NET AJAX客户端实现一个完整的CrossSubDomainRequestExecutor，它会自动判断是否正在发出跨子域名的请求，并选择AJAX请求的方式。这样，客户端的异步通讯层就会对开发人员完全透明。世上还会有比这更令人愉快的事情吗？:)
注意事项
可能以下几点值得一提：
我在出现这个想法之后也作了一些尝试，最后发现创建XMLHttpRequest对象，调用open方法和send方法都必须在iframe中的页面中执行才能够在IE和FireFox中成功发送AJAX请求。
在上面的例子中，我们向子域名请求的的路径是http://sub0.test.com/Script.ashx。请注意，完整的子域名不可以省略，否则在FireFox下就会出现权限不够的错误，在调用open方法时就会抛出异常——似乎FireFox把它当作了父页面域名的资源了。
Windows Live Contacts Gadget使用了一种叫做Channel的技术，用于解决跨任意域名传递数据的问题，我相当佩服微软技术人员的创造力。Channel技术是一种优秀的解决跨域名异步请求问题的解决方案，而且如果将它封装成了组件，那么使用起来也会相当优雅（似乎微软已经准备这么做了）。不过它和我们现在需要解决的问题并不相同，如果有机会的话，我也会详细的解释一下Channel技术——但不是现在，因为我觉得我还没有完全理解这个技术本身。
原文：
作者：赵劼 http://www.cnblogs.com/JeffreyZhao/archive/2007/02/02/Break_the_Browsers_Restrictions_6.html
我们先来证实一下请求的阻塞情况吧。我们使用如下的代码：
连续发起三个请求
function simpleRequest()
{
var request = new XMLHttpRequest();
request.open("POST", "Script.ashx");
request.send(null);
}
function threeRequests()
{
simpleRequest();
simpleRequest();
simpleRequest();
}
当执行threeRequests时就会连续发出3个相同域名的请求，还是通过统计图表来查看阻塞的效果，如图：
每个请求需要花费1.5秒的时间。很明显，第三个请求必须等到第一个请求结束之后才能执行，因此总共需要进行3秒多钟才能执行完毕。我们要改变的就是这个状况。
传统的跨域名异步请求解决方案
AJAX安全性的唯一保证，似乎就是对于跨域名（Cross-Domain）AJAX请求的限制。除非打开本地硬盘的网页，或者在IE中将跨域名传输数据的限制打开，否则向其他域名发出AJAX请求都会被禁止。而且对于跨域名的判断非常严格，不同的子域名，或者相同域名的不同端口，都会被认作是不同的域名，我们不能向它们的资源发出AJAX请求。
从表面上看起来似乎没有办法打破这个限制，还好我们有个救星，那就是iframe！
iframe虽然不在标准中出现，但是由于它实在有用，FireFox也“不得不”对它进行了支持（类似的还有innerHTML）。网上已经有一些跨域名发出异步请求的做法，但是它们实在做的不好。它们的简单工作原理如下：在另一个域名下放置一个特定的页面文件作为Proxy，主页面将异步请求的信息通过Query String传递入iframe里的Proxy页面，Proxy页面在AJAX请求执行完毕后将结果放在自己location的hash中，而主页面会对iframe的src的hash值进行轮询，一旦发现它出现了改变，则通过hash值得到需要的信息。
这个方法的实现比较复杂，而且功能有限。在IE和FireFox中，对于URL的长度大约可以支持2000个左右的字符。对于普通的需求它可能已经足够了，可惜如果真要传递大量的数据，这就远远不够了。与我们一会儿要提出的解决方案相比，可能它唯一的优势就是能够跨任意域名进行异步请求，而我们的解决方案只能突破子域名的限制。
那么现在来看看我们的做法！
优雅地突破子域名的限制
我们突破子域名限制的关键还是在于iframe。
iframe是的好东西，我们能够跨过子域名来访问iframe里的页面对象，例如window和DOM结构，包括调用JavaScript（通过window对象）——我们将内外页面的document.domain设为相同就可以了。然后在不同子域名的页面发起不同的请求，把结果通过JavaScript进行传递即可。唯一需要的也仅仅是一个简单的静态页面作为Proxy而已。
我们现在就来开始编写一个原形，虽然简单，但是可以说明问题。
首先，我们先来编写一个静态页面，作为放在iframe里的Proxy，如下：
SubDomainProxy.html
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Untitled Page</title>
<script type="text/javascript" language="javascript">
document.domain = "test.com";
function sendRequest(method, url)
{
var request = new XMLHttpRequest();
request.open(method, url);
request.send(null);
}
</script>
</head>
<body>
</body>
</html>
然后我们再编写我们的主页面：
http://www.test.com/Default.html
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
<script type="text/javascript" language="javascript">
document.domain = "test.com";
function simpleRequest()
{
var request = new XMLHttpRequest();
request.open("POST", "Script.ashx");
request.send(null);
}
function crossSubDomainRequest()
{
var proxy = document.getElementById("iframeProxy").contentWindow;
proxy.sendRequest('POST', 'http://sub0.test.com/Script.ashx');
}
function threeRequests()
{
simpleRequest();
simpleRequest();
crossSubDomainRequest();
}
</script>
</head>
<body>
<input type="button" value="Request" onclick="threeRequests()" />
<iframe src="/UploadFiles/2021-04-02/SubDomainProxy.html"> id="iframeProxy"></iframe>
</body>
</html>
当执行threeRequests方法时，将会同时请求http://www.test.com以及http://sub0.test.com两个不同域名下的资源。很明显，最后一个请求已经不会受到前两个请求的阻塞了 如图：
令人满意的结果！
虽说只能突破子域名，但是这已经足够了，不是吗？我们为什么要强求任意域名之间能够异步通讯呢？更何况我们的解决方案是多么的优雅！在下一篇文章中，我们将会为ASP.NET AJAX客户端实现一个完整的CrossSubDomainRequestExecutor，它会自动判断是否正在发出跨子域名的请求，并选择AJAX请求的方式。这样，客户端的异步通讯层就会对开发人员完全透明。世上还会有比这更令人愉快的事情吗？:)
注意事项
可能以下几点值得一提：
我在出现这个想法之后也作了一些尝试，最后发现创建XMLHttpRequest对象，调用open方法和send方法都必须在iframe中的页面中执行才能够在IE和FireFox中成功发送AJAX请求。
在上面的例子中，我们向子域名请求的的路径是http://sub0.test.com/Script.ashx。请注意，完整的子域名不可以省略，否则在FireFox下就会出现权限不够的错误，在调用open方法时就会抛出异常——似乎FireFox把它当作了父页面域名的资源了。
Windows Live Contacts Gadget使用了一种叫做Channel的技术，用于解决跨任意域名传递数据的问题，我相当佩服微软技术人员的创造力。Channel技术是一种优秀的解决跨域名异步请求问题的解决方案，而且如果将它封装成了组件，那么使用起来也会相当优雅（似乎微软已经准备这么做了）。不过它和我们现在需要解决的问题并不相同，如果有机会的话，我也会详细的解释一下Channel技术——但不是现在，因为我觉得我还没有完全理解这个技术本身。
原文：
作者：赵劼 http://www.cnblogs.com/JeffreyZhao/archive/2007/02/02/Break_the_Browsers_Restrictions_6.html
广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
暂无评论...
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。
更新日志
2024年11月24日
2024年11月24日
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]