Live to learn the old Ajax cross-domain (iii) _ajax related

Learning Ajax In fact has a very important application, is to perform several other sites of ASP, return the results.

Really use up, found 2 problems, always do Delphi, contact ASP Not many of me, indeed a lot of problems.

First question:

VBS variable passed to JS ... By learning to find very simple ...

First look at my general implementation methods:

<%
Dim ssrv1link
Ssrv1link = "http://www. Xxx.org/test1.asp? u=testuser&m=111&e=222 "
%>
<script type=" text/javascript ">
function synsvrdata (str)
{
var xmlhttp;
if (str.length==0)
{
document.getElementById ("Txthint"). innerhtml= "";
return;
}
Creates an object
if (window). XMLHttpRequest)
{//code for ie7+, Firefox, Chrome, Opera, Safari
xmlhttp=new XMLHttpRequest ();
}
else
{//code for IE6, IE5
xmlhttp=new activexobject ("Microsoft.XMLHTTP");
}
Handling onReadyStateChange Event, we only have the corresponding server feedback successfully
xmlhttp.onreadystatechange=function ()
{
if ( xmlhttp.readystate==4 && xmlhttp.status==200)
{
document.getElementById ("Txthint"). innerhtml= Xmlhttp.responsetext
}
}
Xmlhttp.open ("Get", str,true);
Xmlhttp.send ();
}

The above code means to use AJAX to access an ASP, and return the result.

<script type= "Text/javascript" >
var jssvr= ' <%=sSrv1Link%> '; 
Synsvrdata (JSSVR)

Did you see that? This is the key:

JS uses the VBS variable, why do you do this? Because the cryptographic strings are all generated by VBS.

Local test OK, now change the Access file to another server ...

Ssrv1link = "http://www.XXX2.org/test1.asp?U=TESTUSER&M=111&E=222"
That means cross-domain!!!.

This time the problem comes ... Code execution after no return, later found not not to return, is the XXX2 server does not respond!

The problem was found on the test1.asp file!!! Right! You're not wrong!

Cross-domain requests, as the name suggests, are resources in one site to access resources on another different domain name site.

Excerpt from the following two ends:

With the rise of Web2.0 and SNS, Web applications need more and more cross-domain access, but there is a security limit to cross-domain requests in scripts, and Web developers desperately need to provide a more secure and convenient way to merge (Mashup) their WEB applications with Cross-domain requests. One of the benefits of this is that you can allocate requests to different servers, reduce the pressure on individual servers to increase responsiveness, and another benefit is that you can distribute different business logic to different servers to reduce the load.

Thankfully, the criteria for Cross-domain requests have been introduced, as has been achieved by mainstream browsers. The Web Applications Working Group (Web application Workgroup) in the Working Group of the consortium publishes a Cross-origin Resource sharing (cross-domain resource sharing, the canonical address: http://www.w3.org/ tr/access-control/and http://dev.w3.org/2006/waf/access-control/) recommend specifications to address Cross-domain request issues. This specification provides a more secure method of Cross-domain data exchange. The description of the specification can access the website address provided above. It should be noted that this specification can only be applied to API containers such as XMLHttpRequest. IE8, Firefox 3.5 and its later versions, Chrome browser, Safari 4, and so on have implemented the Cross-origin Resource sharing specification, which is already ready for Cross-domain requests. Cross-origin Resource sharing works by adding an HTTP header to determine which resources allow a Web browser to access information under that domain name. However, for those requests that HTTP requests cause side effects on the user's data (especially for HTTP methods other than GET, some MIME-type POST), the specification requires the browser to "test" the request by sending an HTTP option request header asking the server what Some support methods, with the consent of the server, and then use the actual HTTP request method to send the actual request. The server can also notify the client whether to send authentication information, such as cookies and HTTP authentication data, along with the request.

Read so much, in fact, to achieve a sentence: is to add HTTP headers!

Let's take a look at the original test1.asp we used for the test.

<%
suser=request. QueryString ("U") 
Response.Write ("xxx.org:" & suser)

Add Cross-domain access below:

<%
Response. AddHeader "Access-control-allow-origin", "http://www.XXX2.org"
suser=request. QueryString ("U") 
Response.Write ("xxx2.org:" & suser)

Response. AddHeader "Access-control-allow-origin", "http://www.XXX2.org" right, so a word, across the domain completed, you test again, is not OK?