The topic outline

There are N types of cross-domain, and this article focuses on Ajax request cross-domain (Ajax cross-domain is only part of the browser’s “same origin policy”, cookies cross-domain iframe cross-domain,LocalStorage cross-domain, etc.). The content is roughly as follows:

  • What is Ajax cross domain
    • The principle of
    • Presentation (sorted out some problems and solutions)
  • How can AJAX cross domains be solved
    • The json approach
    • CROS way
    • Proxy request mode
  • How do YOU analyze Ajax across domains
    • Analysis of HTTP packet capture
    • Some examples are

What is Ajax cross domain

How Ajax works across domains

Ajax request cross-domain error problem, the main reason is because the browser “same origin policy”, you can refer to the browser same origin policy and its avoidance method (Ruan Yifeng)

Principle of CROS request

CORS is a W3C standard, which stands for “Cross-origin Resource Sharing”. It allows browsers to issue XMLHttpRequest requests across source servers, overcoming the limitation that AJAX can only be used in the same source.

Almost all browsers currently implement the CORS standard. In fact, almost all browser Ajax requests are based on CORS, although front-end developers may not care about them (so CROS solutions are mostly about how to implement them in the background).

For CROS, it is highly recommended to read cross-domain Resource Sharing CORS (Ruan Yifeng)

In addition, here is an implementation schematic (simplified version):

[image upload failed…(image-2339DC-1513575271343)]

How can I determine whether it is a simple request?

Browsers classify CORS requests into two categories: Simple request and not-so-simple Request. As long as the following two conditions are met, it is a simple request.

  • The request method is one of three: HEAD,GET, and POST
  • HTTP headers do not exceed the following fields:
    • Accept
    • Accept-Language
    • Content-Language
    • Last-Event-ID
    • Application/X-www-form-urlencoded, multipart/form-data, text/plain

Any request that does not meet both conditions is a non-simple request.

Cross-domain representation of Ajax

To be honest, I remember putting together an article as a solution and then finding out that there are still a lot of people who still can’t. But only time-consuming and exhausting debugging. However, even if I do the analysis, I will only judge whether it is cross-domain based on the corresponding performance, so this point is important.

Ajax requests are cross-domain requests, and they are not resolved. (Note that ajax requests are cross-domain requests. Please do not say why HTTP requests are ok, but Ajax requests are cross-domain requests.)

Note: For the specific backend cross-domain configuration, see the outline location.

The first phenomenon:No 'Access-Control-Allow-Origin' header is present on the requested resourceAnd,The response had HTTP status code 404

[image upload failed…(image-874C1E-1513575271343)]

The reasons for this are as follows:

  • This Ajax request is a “non-simple request”, so a pre-check request (OPTIONS) will be sent before the request.
  • The background interface on the server does not allow OPTIONS requests. As a result, the interface address cannot be found

Solution: The back end allows options requests

The second phenomenon:No 'Access-Control-Allow-Origin' header is present on the requested resourceAnd,The response had HTTP status code 405

[image upload failed…(image-4d244C-1513575271343)]

This phenomenon is different from the first one. In this case, the background method allows OPTIONS requests, but some configuration files (such as security configuration) prevent OPTIONS requests

Solution: Disable the corresponding security configuration on the backend

The third phenomenon:No 'Access-Control-Allow-Origin' header is present on the requested resourceAnd,status 200

[image upload failed…(image-5b86c7-1513575271343)]

This phenomenon is different from the first and second cases. In this case, the backend server allows OPTIONS requests and the interface also allows OPTIONS requests, but the header mismatch occurs

For example, the Origin header check does not match, for example, some header support is missing (such as the common X-requesd-with header), then the server will return the response to the front end, and when the front end detects this, it will trigger xhr.onerror, causing the front end console to report an error

Solution: Add corresponding header support to the backend

The fourth phenomenon:heade contains multiple values '*,*'

[image failed to upload…(image-50eddb-1513575271343)] [image-680606-1513575271343] The HTTP header of the background response has two access-Control-allow-origin :*

To be honest, the main reason for this problem is that the cross-domain configuration person does not understand the principle, leading to repeated configuration, such as:

  • This is common in the.net background (usually the origin is configured once in web.config and then added to the code again manually (e.g. the code is manually set to return *))
  • Common in.net backend (set Origin:* in both IIS and the project’s Webconfig)

Solution (one-to-one correspondence):

  • It is recommended to remove the manually added * from the code and use only the project configuration
  • You are advised to delete the configuration * under IIS and use only the project configuration

How can AJAX cross domains be solved

Common ajax cross-domain solutions are JSONP or CROS solutions, such as the following :(note that JSONP is almost not used anymore, so JSONP can be learned)

JSONP approach to solve cross-domain problems

Jsonp is an ancient solution to cross-domain problems (not recommended in practice), so here’s a brief introduction (in real projects, jSONP is usually used to make Ajax requests using JQ and other jSONP wrapped libraries)

Realize the principle of

JSONP can be used to solve cross-domain solutions mainly because