[Jquery mobile] cross-origin Data Retrieval

When the getjson method of jquery mobile JS is used, the following error occurs: parsererror.

The following code is written:

 

VaR Params = jquery. param ({"name": "value", "name2": "value2",}, jquery. ajaxsettings. traditional); $. ajax ({type: "Post", URL: "myurl? Jsoncallback =? ", Data: Params, timeout: 30000, // Timeout: 30 seconds contenttype:" application/JSON; charset = UTF-8 ", datatype:" JSON ", success: function (jqxhr, textstatus) {alert ("success") ;}, error: function (jqxhr, status, responsetext) {alert ("error-" + ": "+ status +"-"+ jqxhr. status + "-" + jqxhr. readystate + "-" + jqxhr. responsetext + "-" + responsetext);}, complete: function (jqxhr, textstatus) {alert ("complete-" + textstatus + "-" + jqxhr. responsetext );}});

The same error is reported;

Cause and solution of parsererror:

1) charset = utf8: FF: No problem. The result is an error in IE. It is okay to change utf8 to UTF-8,

2)Data: "{}". If the data is empty, you must pass "{}". Otherwise, the returned data is in XML format. The system prompts parsererror.

Currently, these two possibilities are found.

However, my program still reports parsererror.

XMLHttpRequest. readystate: the status code is 4.

XMLHttpRequest. State: 200.

 

Later I found this article:

How to solve jquery cross-origin access problems

Cross-origin access on the browser side has always been a problem. Most R & D personnel have a good attitude towards JS, and the scars are lost. Therefore, it hurts from time to time when the problem occurs. I remember using IFRAME and script domain declaration a long time ago. Yahoo JS util solves the problem of second-level domain name cross-origin access. when the time passes through and is pulled back to the JS battlefield, the cross-domain problem becomes painful again. fortunately, with the help of jquery, cross-domain problems seem less difficult. this time, I also took this opportunity to give a thorough understanding of cross-origin issues. Based on the actual development project, I checked the relevant information and solved the cross-origin issue .. it is necessary to write down the memo.
Cross-origin security restrictions refer to the browser. the server does not have cross-origin security restrictions. Therefore, the local server completes "cross-origin access" in a way similar to httpclient, then, use Ajax on the browser side to obtain the URL corresponding to "cross-origin access" on the local server side. to indirectly complete cross-origin access. however, it is clear that the development volume is large, but the restrictions are also the least. Many widgets Open Platform servers (such as Sohu blog Open Platform) are actually implemented. not in the scope of this discussion. we recommend that you use jquery $. ajax () supports cross-origin in get mode, which is implemented in jsonp mode.
Real case:
Copy the Code as follows:
VaR qsdata = {'searchword': $ ("# searchword "). ATTR ("value"), 'currentuserid': $ ("# currentuserid "). ATTR ("value"), 'conditionbean. pagesize ': $ ("# pagesize "). ATTR ("value ")};
$. Ajax ({
Async: false,
URL: http: // cross-domain DNS/document! Searchjsonresult. Action,
Type: "Get ",
Datatype: 'jsonp ',
Jsonp: 'jsoncallback ',
Data: qsdata,
Timeout: 5000,
Beforesend: function (){
// Jsonp method. This method is not triggered because datatype is no longer an Ajax event if it is specified as jsonp.
},
Success: function (JSON) {// call back function pre-defined by jquery on the client. After obtaining JSON data on the Cross-origin server, the callback function is dynamically executed.
If (JSON. actionerrors. length! = 0 ){
Alert (JSON. actionerrors );
}
Gendynamiccontent (qsdata, type, JSON );
},
Complete: function (XMLHttpRequest, textstatus ){
$. Unblockui ({fadeout: 10 });
},
Error: function (xhr ){
// Jsonp method. This method is not triggered because datatype is no longer an Ajax event if it is specified as jsonp.
// Handle request errors
Alert ("request error (Check related network conditions .)");
}
});

Note: $. getjson ("http: // cross-domain DNS/document! Searchjsonresult. Action? Name1 = "+ value1 +" & jsoncallback =? ",
Function (JSON ){
If (JSON. attribute name = value ){
// Execute the code
}
});
This method is actually an advanced encapsulation of the $. Ajax ({...}) API in the previous example. Some underlying parameters of $. Ajax APIs are encapsulated and invisible.
In this way, jquery is assembled into the following url get request
Http: // cross-domain DNS/document! Searchjsonresult. Action? & Jsoncallback = jsonp1231627957501 & _ = 1236828192549 & searchword = % E7 % 94% A8 % E4 % be % 8B login tuserid = 5351 & conditionbean. pagesize = 15
On the response side (http: // cross-domain DNS/document! Searchjsonresult. Action ),
Use jsoncallback = request. getparameter ("jsoncallback") to obtain the JS function name: jsonp1231627957501 to be called back by jquery.
Then the response content is a script tags: "jsonp1231627957501 (" + JSON array generated by Request Parameters + ")";
Jquery dynamically loads and calls this JS tag through the callback method: jsonp1231627957501 (JSON array );
This achieves the purpose of cross-Origin data exchange.
The most basic principle of jsonp is: dynamically Add a consistent one (QQ space is a large number of cross-Origin data exchange using this method ). jsonp is a script injection action, so it also has certain security risks.
Note that jquey does not support cross-origin post.
Why?
Although the use of post + dynamic IFRAME can achieve the purpose of post cross-origin (there is a JS cool who just put jquery1.2.5 in this way), this is an extreme method, not recommended.
It can also be said that the cross-origin of the get method is legal, and the POST method is considered illegal from the security point of view ..
The demand for cross-origin access on the client side also attracted W3C's attention. It is said that the HTML5 websocket standard supports cross-Origin data exchange and should also be an optional cross-Origin data exchange solution in the future.
Detailed source reference: http://www.jb51.net/article/21213.htm

At present, let's classify my program errors as server-side processing.

For further study...