The JSON returned by the script request is actually a script injection. Although it solves the cross-origin problem, it is not omnipotent.
1. HTTP status codes cannot be accepted
2. POST cannot be used for submission (GET by default)
3. HTTP headers cannot be sent or accepted.
4. synchronous call cannot be set (asynchronous by default)
...
The most serious problem is that error handling cannot be provided. If the requested code is executed normally, the correct result will be obtained. If the request fails, such as 404,500, nothing may happen. Based on the previous article, this article focuses on JSONP error handling.
It may be because some browsers can still provide some error processing. For example, IE9/10/Firefox/Safari/Chrome all support the onerror event of the script. If the request fails, you can perform the necessary callback processing on the onerror. However, IE6/7/8/Opera does not support onerror. This is a headache and it is not easy to create a perfect Sjax.
As long as the onerror of IE6/7/8/Opera is solved, the whole process is OK. The idea is reverse thinking: if the request is successful, the callback is successful. Otherwise, the callback is failed. Don't talk about onerror because it has no onerror at all. Therefore, we can only talk about onload. It is like the following inference:
You are right"
Because I cannot know that you are "wrong ". But I know that you are "right" and can only infer whether you are correct or not.
The implementation details are as follows:
1. IE9/Firefox/Safari/Chrome successfully calls back the onload event, and the error callback uses the onerror event.
2. for successful callback of Opera, the onload event is also used (it does not support onreadystatechange at all). Because it does not support onerror, latency processing is used here. That is, wait and successful callback success. After success, the flag done is set to true. Failure will not be executed; otherwise, it will be executed. The delay value here is very skillful. It took 2 seconds before and it was okay for the company to test. However, when I went home to use a 3G wireless network, I found that even if the referenced js file exists, failure was executed first and success was executed because of the slow network speed. So it is reasonable to take 5 seconds here. Although this method indirectly implements failure, it is not thorough.
3. When the onreadystatechange event is successfully called back in IE6/7/8, the error callback is hardly implemented. It is disgusting that even if the requested resource file does not exist (404 ). Its readyState also goes through the "loaded" state. In this way, you cannot distinguish whether the request succeeds or fails. Finally, we used the forward and back-end coordination mechanism to solve the final problem. Call callback (true) whether the request succeeds or fails ). At this time, the logic of the difference between success and failure has been put into callback. If no jsonp is returned in the background, failure is called; otherwise, success is called.
Interface:
Sjax. load (url, {data // request parameter (key-Value Pair string or js object) success // callback function failure // callback function scope for request failure // context timestamp for callback function execution // timestamp for timestamp });
Example:
<!DOCTYPE HTML>
In the preceding html, click "Get Name" to call the clk function. Because the requested resource jsonp66.js does not exist at all. "Error" is displayed in various browsers. Of course, Opera may be delayed. Okay, this series is over.
Click to try
Related:
Http://stackoverflow.com/questions/3483919/script-onload-onerror-with-iefor-lazy-loading-problems