Cross-Domain Ajax

This is the case, or the personal portal. One function is RSS subscription. Each subscription is displayed on the page as a module. If a user subscribes to a large number of RSS feeds, all the RSS modules will start loading when the page is opened. At this time, it may take more than a dozen seconds or longer to load. In this case, if you need to perform other Ajax operations, such as saving page settings, a long wait is inevitable. Who makes the browser have only two connections for the same domain name? But this is not a good user experience. What should we do?

The first approach may be easier to think of. We can write our own code to maintain a priority queue and add a "Priority" information to each request, so that we can take the lead in issuing important requests. In this way, the user's waiting problem can be solved to a certain extent. Unfortunately, this method still cannot break through the limitations of two connections. So the second approach is to try to break through the limitations of the two connections. If you can send Ajax requests to other domain names, can you avoid blocking important requests by a large number of requests?

From the very beginning, we can solve this problem 1.1 points.

 

Blocked Ajax requests

Let's verify the request blocking first. The following code is used:

Initiate three consecutive requests

function simpleRequest()

{

    var request = new XMLHttpRequest();

    request.open("POST", "Script.ashx");

    request.send(null);

}function threeRequests()

{

    simpleRequest();

    simpleRequest();

    simpleRequest();

}

 

When threerequests is executed, three requests with the same domain name will be sent consecutively, or the blocking effect will be viewed through statistical charts (11 ):

Figure 11: The last request is blocked by the first two requests

 

It takes 1.5 seconds for each request. Obviously, the third request can only be executed after the first request is completed. Therefore, it takes more than three seconds to complete the execution. What we want to change is this situation.

 

Traditional cross-domain asynchronous request Solution

The only guarantee of Ajax security seems to be the restriction on Cross-Domain Ajax requests. Unless you open a webpage on the local hard disk or enable cross-domain data transmission in IE, Ajax requests to other domain names will be banned. In addition, the cross-domain judgment is very strict. Different sub-domain names, or different ports of the same domain name, will be regarded as different domain names. We cannot send Ajax requests to their resources.

On the surface, it seems that there is no way to break this restriction. Fortunately, we have a savior, that is, IFRAME!

IFRAME does not appear in the standard, but because it is actually useful, Firefox also "has to" support it (similar to innerhtml ). There are already some cross-domain name asynchronous requests on the Internet, but they are not doing well. Their simple working principle is as follows: place a specific page file under another domain name as a proxy, and the home page transmits the asynchronous request information to the proxy page in IFRAME through the query string, the proxy page places the results in the hash of its own location after the Ajax request is executed, and the homepage Round-Robin the SRC hash value of IFRAME. Once it is found that it has changed, hash is used to obtain the required information.

The implementation of this method is complex and has limited functions. In IE and Firefox, the URL length can be about 2000 characters. It may be enough for a common requirement. Unfortunately, if you want to transmit a large amount of data, this is far from enough. Compared with the solution we will propose later, its only advantage may be that it can make asynchronous requests across any domain name, and our solution can only break through the limitations of subdomain names.

Now let's take a look at our practices!

 

Break through the limitations of sub-domain names elegantly

The key to breaking through the subdomain name limit is IFRAME.

IFRAME is a good thing. We can access the page objects in IFRAME through subdomain names, such as the window and Dom structures, including calling Javascript (through the window object) -- we will upload the document of the internal and external pages. set domain to the same. Then, initiate different requests on the pages of different subdomains and pass the results through JavaScript. The only thing you need is a simple static page as a proxy.

Now let's start writing a prototype. Although it is simple, it can explain the problem.

First, write a static page as the proxy placed in 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>

 

Then we will write our Home Page:

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, resources under different domain names are requested at http://www.test.com/and http://sub0.test.com. Obviously, the last request is no longer blocked by the first two requests (12 ):

Figure 12: requests for different domain names are not blocked

Satisfactory results!

Although it can only break through subdomain names, it is enough, isn't it? Why do we need to force asynchronous communication between any domain names? What's more, how elegant our solutions are! In the next article, we will implement a complete crosssubdomainrequestexecutor for the ASP. NET Ajax client. It will automatically determine whether a cross-subdomain name request is being sent and select the Ajax request method. In this way, the asynchronous communication layer of the client is completely transparent to developers. Is there anything more pleasant in the world? :)

 

Notes

It may be worth mentioning the following:

• I tried this idea and found that the XMLHTTPRequest object was created, you must call both the open and send methods on the IFRAME page to successfully send Ajax requests in IE and Firefox.
• In the preceding example, The Request Path to the subdomain name is http://sub0.test.com/script.ashx. Please note that the complete subdomain name cannot be omitted; otherwise, an error with insufficient permissions will occur in Firefox, when the open method is called, an exception is thrown -- it seems that Firefox treats it as a resource of the parent page domain name.
• Windows Live Contacts Gadget uses a channel technology to solve the problem of transferring data across any domain name. I admire the creativity of Microsoft technicians. Channel Technology is an excellent solution to cross-domain asynchronous request problems, and if it is encapsulated into components, so it will be quite elegant to use (it seems that Microsoft is ready to do so ). However, it is different from what we need to solve now. If we have the opportunity, I will explain the channel technology in detail-but not now, I don't think I fully understand this technology.