Blocked Ajax requests
Let's confirm the blocking of the request first. We use the following code:
Three consecutive requests launched
function Simplerequest ()
{
var request = new XMLHttpRequest ();
Request.open ("POST", "script.ashx");
Request.send (NULL);
}
function threerequests ()
{
Simplerequest ();
Simplerequest ();
Simplerequest ();
}
When the threerequests is executed, 3 consecutive requests for the same domain name are issued, or the blocking effect is viewed through a statistical chart, as shown in figure:
Each request takes 1.5 seconds to be spent. It is clear that the third request must wait until the end of the first request to execute, so that a total of more than 3 seconds is required for execution to complete. This is the situation that we want to change.
Traditional cross-domain asynchronous request solution
The only guarantee of Ajax security seems to be the restrictions on cross domain name (cross-domain) AJAX requests. An AJAX request to another domain name is prohibited unless you open a Web page on your local hard disk, or if you open the restrictions on the transfer of data across domain names in IE. And for the Cross-domain judgment is very strict, different subdomains, or the same domain name of different ports, will be recognized as different domain names, we can not make an AJAX request to their resources.
On the surface there seems to be no way to break this limit, but fortunately we have a savior, that is iframe!
Although IFrame does not appear in the standard, but because it is useful, Firefox also "had to" support it (similar to innerHTML). There are already some asynchronous requests made across the Internet, but they are not doing well. Their simple work is as follows: Place a specific paging file under another domain name as proxy, and the main page sends the information that is requested asynchronously via query string into the proxy page in the IFRAME, The proxy page puts the result in its own location hash after the AJAX request is executed, and the main page will poll the hash value of the src of the IFRAME, and if it finds a change, get the information needed through the hash value.
The implementation of this method is more complex and has limited function. In IE and Firefox, the length of the URL can support about 2000 characters. It may have been enough for ordinary needs, but it would be far from enough if a lot of data were to be delivered. Compared with the solution we are going to propose in a moment, perhaps its only advantage is the ability to make asynchronous requests across arbitrary domain names, and our solution can only break the limits of subdomains.
So now let's look at what we're doing!
Gracefully break the limits of subdomains
The key to breaking through the subdomain limit is the IFRAME.
IFrame is a good thing, we can cross the subdomain to access the page objects in the iframe, such as window and DOM structure, including invoking JavaScript (through Window objects)-- We set the document.domain of the internal and external pages to be the same. Then in different subdomains of the page to launch a different request, the results through JavaScript to pass. The only thing that is needed is simply a static page as a proxy.
We are now ready to start writing a prototype, albeit simple, but it can explain the problem.
First, we'll write a static page, as a proxy placed in the IFRAME, as follows:
Subdomainproxy.html
<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>
<body>
</body>
And then we'll write our homepage:
Http://www.test.com/Default.html
<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>
<body>
<input type= "button" value= "Request" onclick= "threerequests ()"/>
<iframe src= "http://sub0.test.com/SubDomainProxy.html" style= "Display:none;"
Id= "Iframeproxy" ></iframe>
</body>
When the Threerequests method is executed, the http://www.test.com and http://sub0.test.com resources under two different domain names will be requested at the same time. Obviously, the last request has not been blocked by the top two requests as shown:
A satisfying result!
Although only to break through the subdomain, but this is enough, isn't it? Why do we want to be able to communicate between arbitrary domain names asynchronously? Not to mention how elegant our solution is! In the next article, we will implement a complete crosssubdomainrequestexecutor for the asp.net ajax client, which automatically determines whether a request to cross a subdomain is being made and how the AJAX request is chosen. In this way, the client's asynchronous communication layer is completely transparent to the developer. Is there anything more delightful than this? :)
Attention matters
Perhaps the following points are worth mentioning:
I also made some attempts after this idea, and finally found that creating the XMLHttpRequest object, calling the open method and the Send method must be performed in a page in the IFRAME to successfully send AJAX requests in IE and Firefox.
In the example above, the path we request to the subdomain is http://sub0.test.com/Script.ashx. Please note that the full sub domain name can not be omitted, otherwise there will be insufficient permissions under Firefox error, when calling the Open method will throw an exception-it seems that Firefox as a parent page domain name resources.
Windows Live Contacts Gadget uses a technology called Channel to solve the problem of passing data across arbitrary domain names, and I admire the creativity of Microsoft technicians. Channel technology is a good solution to solve the problem of cross domain asynchronous request, and if it is encapsulated as a component, then it will be quite elegant to use (it seems that Microsoft is ready to do so). But it's not the same problem that we need to solve right now, and if I get the chance, I'll explain channel technology in detail--but not now, because I don't think I fully understand the technology itself.
Original:
Author: Zhao http://www.cnblogs.com/JeffreyZhao/archive/2007/02/02/Break_the_Browsers_Restrictions_6.html -->
