Thanks to nguyen other bosses information, let me have deeper understanding on cross-domain. [r]. Portal (www.ruanyifeng.com/blog/2016/0)…

First, what is cross-domain

Because the browser has the same origin policy, no special processing is performed. We cannot access site B from different sources from Site A

So what is homology?

Concept of homology

The following three conditions must be met for homology

  • The agreement is the same
  • Domain name is the same
  • The same port

In our requested url: www.example.com/dir/page.ht…

  • HTTP corresponds to the protocol
  • www.example.com corresponds to the domain name
  • The default port number is 80

So we visited

  • www.example.com/dir/page2.h… — ok
  • Example.com/dir/other.h… — no (different domain name)
  • V2.www.example.com/dir/other.h… — no (different domain name)
  • www.example.com:81/dir/other.h… — no (different ports)

The same origin policy limits us

  • Cookie, LocalStorage, and IndexDB cannot be read.

  • DOM is not available.

  • AJAX requests cannot be sent.

Because of the same-origin problem, cross-domain requests (most commonly AJAX cross-domain) cannot request data.

So how do we solve cross-domain?

How to resolve cross-domain

There are three common solutions

  • JSONP
  • WebSocket
  • CORS

Let’s start with JSONP

JSONP is an old workaround that works because requests made through the SRC attribute of the

Let’s talk about websockets

As for WebSocket, it was designed to be cross-domain by design, so it won’t be explained here. Just remember.

Highlight CORS

First, CROs can be subdivided into two types of requests, simple request and not-so-simple Request.

A simple request

The request method is one of three:

  • HEAD
  • GET
  • POST

HTTP headers do not exceed the following fields:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-type: Application/X-www-form-urlencoded, multipart/form-data, text/plain

Simple request flow

When the browser realizes that the cross-source AJAX request is simple, it automatically adds an Origin field to the header information. The Origin field indicates the source from which the request came. Based on this value, the server decides whether to approve the request or not.

If the server does not agree to the request

The server will return a normal HTTP response. The browser finds that the response header does not contain access-Control-Allow-Origin and throws an error. Caught by the onError callback function of XMLHttpReauest

Non-simple request

Non-simple requests are requests that have special requirements on the server, such as the request method being PUT or DELETE, or the content-Type field being of Type Application/JSON.

The flow of non-simple requests

If the browser finds that the request is not simple, it will send a pre-check request (OPTIONS) before the formal request is sent. This request asks the server whether the current domain name is on the server’s license list and whether HTTP objects and headers are available. After receiving the response to the request, the browser will issue a formal XMLHttpRequest request.

Once the server passes the “precheck” request, every subsequent normal BROWSER CORS request will have the same Origin header field as a simple request. The server also responds with an Access-Control-Allow-Origin header field.

Response to precheck request

After the server received the precheck request, it checked

  • Origin
  • Access-Control-Request-Method
  • Access-Control-Request-Headers

Field, verify that cross-source requests are allowed, and then respond.