AJAX javascript的跨域访问执行

在网站加载评论等信息时，遇到了不同域名间JavaScript无法交互的问题。当尝试加载评论时，页面一直显示加载状态，无法正确显示内容。当更换访问时，却能正常显示。一直未引起注意的是，浏览器提示的错误信息中隐藏了问题的关键。

深入研究后，发现这其实是一个关于跨域请求阻塞的问题。为了验证请求的阻塞情况，我们连续发起了三个请求。每个请求需要大约1.5秒的时间，而第三个请求必须等待前两个请求完成后才能执行，导致总时间超过3秒。我们需要解决的就是这种情况。

传统的跨域异步请求解决方案存在限制。AJAX跨域请求的安全性限制似乎是一个无法逾越的障碍。除非在本地硬盘上打开网页或在IE中打开跨域数据传输的限制，否则向其他域名发起AJAX请求会被禁止。即使是同一域名的不同子域名或不同端口，也被视为不同的域名，无法向其资源发起AJAX请求。

表面上看起来，似乎没有办法打破这个限制。幸运的是，iframe成为了我们的救星。虽然iframe不在标准中，但由于其实用性，得到了浏览器的广泛支持。网上已经出现了一些跨域异步请求的做法，它们虽然做法简单，但存在一些缺陷。这些做法的基本原理是：在另一个域名下放置一个特定的页面作为Proxy，主页面将异步请求的信息通过查询字符串传递给iframe中的Proxy页面。Proxy页面完成AJAX请求后，将结果放在自己的URL的hash中。主页面则轮询iframe的src的hash值，一旦发现变化，就通过hash值获取所需的信息。

这个方法的实现相对复杂，且功能受限。在IE和Firefox中，URL长度大约只能支持2000个字符左右。对于普通需求可能已足够，但如果需要传递大量数据，这显然不够用。与我们即将提出的解决方案相比，它的优势可能仅在于能够跨任意域名进行异步请求，而我们的解决方案只能突破子域名的限制。

让我们先构建一个静态页面，作为嵌入iframe中的代理。这个页面名为SubDomainProxy.html，其代码设计如下：

```html

document.domain = "test.";

function sendRequest(method, url) {

var request = new XMLHttpRequest();

request.open(method, url);

request.send(null);

}

```

紧接着，我们编写主页面

```html

```

当执行threeRequests方法时，将会向不同域名发出请求。请注意，一个请求不会受到其他请求的阻塞，特别是跨域名的请求。这是一个令人欣喜的结果！虽然此方案仅限于子域名间的通信，但在实际应用中，这已足够灵活和高效。我们为何强求在所有域名间都能进行异步通信呢？更何况我们的解决方案是如此优雅。在下一篇文章中，我们将为ASP.NET AJAX客户端实现一个完整的CrossSubDomainRequestExecutor。它会智能判断是否需要发出跨子域名的请求，并选择合适的AJAX请求方式。这样，客户端的异步通讯层对开发人员来说将完全透明。还有什么比这更令人愉悦的事情吗？在AJAX跨域请求时，有几个重要的注意事项值得我们关注。关于创建XMLHttpRequest对象并调用其open和send方法，这些操作必须在iframe中的页面执行，以确保在IE和FireFox等浏览器中成功发送请求。这是一种在实际操作中需要注意的实际操作细节。

让我们以一个例子来说明这个问题。在此例中，我们向子域名发出请求，路径为

由于浏览器的安全策略，不同域（如phinest和lab.phinest）、不同协议（如

对于主域、协议、端口相同的Ajax跨域问题，虽然很早就有通过设置document.domain来解决的提议，但在实际操作中一直未能看到具体的成功应用案例。其原理在于利用隐藏的iframe引入跨越另一子域的页面作为代理，通过JavaScript控制iframe引入的另一子域的XMLHTTPRequest来进行数据获取。而对于不同主域、不同协议、不同端口下的Ajax访问需求，则需要通过后台的代理来实现。这是一种复杂的解决方案，需要我们深入理解浏览器的安全策略和AJAX的工作原理。正是这些复杂性和挑战，促使我们不断和创新，以找到最佳的解决方案。在这里，我尝试使用Cambrian框架的render方法（例如：cambrian.render('body')），希望它能为我们提供更流畅、更直观的用户体验和数据交互方式。