CORS Cross-domain requests [Simple versus complex requests]

CORS stands for Cross Origin Resource Sharing,

In plain English, it is known as cross-domain request. As we all know, in the past, cross-domain proxy, JSONP and other methods can be used, but in the face of modern browsers, these will eventually be abandoned, because of CORS.

When CORS first contacted them, they only knew roughly,
By setting the access-Control-allow-Origin response header on the server side, the specified source can Access the cross-domain interface in the same way as the same-origin interfaceRecently, when using CORS, because of the need to transmit custom Header information, I found that the original SPECIFICATION definition of CORS is far more than these.

CORS can be divided into two types:

Simple request 2. Complex request

A simple request looks something like this:

The HTTP method is one of the following

HEAD

GET

POST

HTTP header information does not exceed the following fields

Application/X-www-form-urlencoded multipart/form-data text/plain

Any request that does not meet the above requirements is considered a complex request. A complex request includes not only the request containing the communication content, but also the pre-request.

The sending of a simple request is not much different from regular XHR code, but HTTP headers always require an Origin message. This field contains the protocol name, address, and an optional port. However, this item is actually sent by the browser and is not touched by the developer code.

The partial response header and explanation for a simple request are as follows:

Access-control-allow-origin (required) – Cannot be omitted, otherwise the request is treated as a failure. This controls the visibility of the data. If you want the data to be visible to anyone, you can fill in an “*”. Access-control-allow-credentials (Optional) – This parameter indicates whether cookies are included in the request. There is only one optional value: true (must be lowercase). If cookies are not included, omit this item instead of filling in false. This should be consistent with the withCredentials property in the XmlHttpRequest2 object, which is true when withCredentials is true. When the withCredentials are false, this item is omitted. Otherwise, the request fails. Cache-control Content-language Content-type Expires Last-Modified When you need to access additional information, enter this field and separate it with a comma

It’s not a big deal if you don’t use CORS for simple requests, but the complexity of CORS makes it more useful. Simply put, any request that does not meet the above simple request requirements is a complex request. For example, you need to send HTTP actions such as PUT and DELETE, or send content-Type: application/ JSON.

Complex requests look similar to simple requests on the surface, but the browser actually sends more than one request. The first one is a “pre-request”, and the server needs to return a “pre-response” as a response. A pre-request is actually a permission request to the server. The actual request is executed only when the pre-request is successfully returned.

The pre-request is sent in the form of OPTIONS, which also contains fields and contains two CORS specific items:

Access-control-request-method – This is the type of actual Request, which can be simple requests like GET, POST, PUT, DELETE, and so on. Access-control-request-headers – This item is a comma-separated list of the Headers used by the complex Request.

Obviously, this pre-request is actually a permission request for a later actual request, and in the pre-response returned, the server should reply to both items to let the browser determine whether the request can be successfully completed.

The partial response header and explanation for a complex request are as follows: X

Access-control-allow-origin (required) – As with simple requests, a field must be included. Access-control-allow-methods (required) – This is a comma-separated list of responses to access-Control-request-methods in a pre-request. Although a client may only request one method, the server can still return all allowed methods for the client to cache. Access-control-allow-headers (must be included if the pre-request contains access-Control-request-headers) — This is a response to the pre-request for access-Control-request-headers. As above, it is a comma-separated list that returns all supported headers. If you don’t want to make too much of a decision on this layer, you can actually get Access to access-Control-request-headers from the request header. Set the value to access-Control-allow-headers. Access-control-allow-credentials (Optional) – The same as in simple requests. Access-control-max-age (Optional) – Cache time in seconds. The sending of pre-requests is not a free lunch and should be cached whenever possible.

Once the pre-response arrives as expected and all requested permissions are satisfied, the actual request is sent.

Most modern browsers already support full CORS, but Internet Explorer didn’t fully support CORS until Internet Explorer 11, so for PC sites, it is recommended to use other solutions, if only mobile sites, can be assured.