AJAX blocking and cross-domain name resolution

Source: Internet
Author: User
Tags subdomain subdomain name

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,

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

<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>



Then we will write our Home Page:

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 = "http://sub0.test.com/SubDomainProxy.html" style = "display: none ;"
Id = "iframeProxy"> </iframe>
</Body>
</Html>



When the threeRequests method is executed, resources under two different domain names, http://www.test.com and http://sub0.test.com, are requested at the same time. Obviously, the last request is no longer blocked by the first two requests.



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.

Original article:
Author: Zhao Yi http://www.cnblogs.com/JeffreyZhao/archive/2007/02/02/Break_the_Browsers_Restrictions_6.html

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.