AJAX的阻塞及跨域名解析
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="http://sub0.test.com/SubDomainProxy.html" style="display:none;"
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
<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="http://sub0.test.com/SubDomainProxy.html" style="display:none;"
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