Learn AJAX from the past (3) and learn ajax from the past (3)

Learn AJAX from the past (3) and learn ajax from the past (3)

Learning AJAX actually has a very important application, that is, to execute ASP on several other sites and return results.

I found two problems in real use. I have always worked on DELPHI, but I don't have much access to ASP.

First question:

The VBS variable is passed to JS... Learning to find it is very simple...

Let's take a look at my general implementation methods:

<% Dim sSrv1LinksSrv1Link = "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;} // create an object if (window. XMLHttpRequest) {// code for IE7 +, Firefox, Chrome, Opera, Safarixmlhttp = new XMLHttpRequest ();} else {// code for IE6, IE5xmlhttp = new ActiveXObject ("Microsoft. XMLHTTP ");} // process the ONREADYSTATECHANGE event. Here, only the successful xmlhttp is reported by the server. onreadystatechange = function () {if (xmlhttp. readyState = 4 & xmlhttp. status = 200) {document. getElementById ("txtHint "). innerHTML = xmlhttp. responseText ;}} xmlhttp. open ("GET", str, true); xmlhttp. send () ;}</script>

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

<script type="text/javascript">var jsSvr='<%=sSrv1Link%>'; synSvrData(jsSvr)</script> 

See? This is the key:

var jsSvr='<%=sSrv1Link%>'; 

Why does js use VBS variables like this? Because the encrypted strings are all generated by VBS.

Local test OK, now switch the access file to another server...

SSrv1Link = "http://www.XXX2.org/test1.asp? U = testuser& M = 111 & E = 222"
Cross-origin !!!

Now the problem is... No response is returned after the code is executed. If no response is returned, the XXX2 server does not respond!

The problem is found in the file test1.asp !!! Yes! You are not mistaken!

Cross-origin requests, as the name implies, are resources in one site to access resources on another site with different domain names.

Excerpt from the following two ends:

With the rise of Web2.0 and SNS, Web applications require more and more cross-origin access requests. However, cross-origin requests in scripts are subject to security restrictions, web developers urgently need to provide a safer and more convenient cross-origin Request Method to integrate (Mashup) their own Web applications. One advantage of this is that requests can be distributed to different servers, reducing the pressure on a single server to increase the response speed; another advantage is that different business logic can be distributed to different servers to reduce load.

Fortunately, the cross-origin request standards have been introduced, and mainstream browsers have also achieved this standard. In the W3C Working Group, the Web Applications Working Group (Web application Working Group) released a Cross-Origin Resource Sharing (Cross-Origin Resource Sharing, the standard address: Unknown) Recommendation specification to solve the problem of Cross-Origin requests. This specification provides a safer cross-Origin data exchange method. You can access the website address provided above. It is worth noting that this specification can only be applied to API containers like XMLHttprequest. IE8, Firefox 3.5 and later versions, Chrome browser, Safari 4, and so on have implemented the Cross-Origin Resource Sharing specification and can already make Cross-Origin requests. Cross-Origin Resource Sharing works by adding an HTTP header to determine which resources allow Web browsers to access the information under the domain name. However, for request methods that cause side effects of user data due to HTTP requests (especially for HTTP methods except GET and some MIME-type POST ), this specification requires the browser to "pre-determine" the request, by sending an http options request header to ask the server about the supported methods, after obtaining the server's consent, 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 Cookie and HTTP Authentication data) along with the request.

After reading so much, we actually implement one sentence: adding an HTTP header!

First, let's take a look at the original test1.asp used for testing.

<%sUser=request.QueryString("U") response.write("XXX.org: " & sUser)%> 

Add cross-origin access as follows:

<%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" by the way, that's the sentence, cross-Origin is complete, you test again, is it OK?

Articles you may be interested in:

• Implementation principle of ajax cross-origin communication using iframe (illustration)
• Perfect solution to AJAX cross-origin problems
• Jquery ajax cross-origin solution (json)
• Implementation of jquery's ajax and getJson cross-origin acquisition of json data
• Ajax cross-origin request
• How to implement cross-origin requests using jquery + ajax
• Configure the server to implement AJAX cross-origin requests
• Solve the Problem of cookie loss in ajax cross-origin requests
• Three methods for implementing cross-origin access using Ajax