turnWhy does one action and two requests occur when CORS is across domains?

Ask questions

There is always a cross-domain problem when developing a front – and back-end separation project.

As we all know, in the past, cross-domain can use proxy, JSONP and other methods, but in front of modern browsers, we have a better choice, CORS.

We can set the access-Control-allow-Origin response header on the server side to Allow the specified source to Access the cross-domain interface as if it were the same source.

When using CORS, the background adopts the token checking mechanism, and the foreground sends the Request must put the token into the Request Header, so the custom Header information needs to be transmitted. At this time, you will surely find a problem when the front-end Ajax requests data. Sometimes two requests are sent to the background at once. The first one returns no data, and the second one returns the correct data. As shown in the following figure, a request for OPTIONS is inexplicably added:

There is no doubt that your code is not buggy or that you are calling the Request twice in the Request function, because obviously the Request Method is not the same.

If you have ever been confused by this question, confused, confused, do not know why. So about this question, I will give you the answer!

For CORS across domains, there are two different request types.

  • Simple cross-domain requests
  • Complex cross-domain request (cross-domain request with precheck).

Simple cross-domain requests

A simple cross-domain request is a request that meets the following two conditions. 1. The HTTP method is one of three methods:

  • HEAD
  • GET
  • POST

2. HTTP headers do not exceed the following fields:

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

A partial response header for a simple cross-domain request looks like this:

  • 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.

  • Access-control-expose-headers (Optional) – This determines the additional information available to the getResponseHeader() method in the XmlHttpRequest2 object. In general, the getResponseHeader() method can only get the following information:

    • Cache-Control
    • Content-Language
    • Content-Type
    • Expires
    • Last-Modified
    • Pragma

    When you need to access additional information, fill in this section and separate it with commas.

Complex cross-domain requests

Any request that does not meet the requirements of a simple cross-domain request is considered a complex request, also known as a cross-domain request with precheck.

A complex request sends more than one request containing communication content. The first one is a **” precheck “request **, in which case the server also needs to return **” prereply “** as a response. The precheck request is actually a permission request to the server, and the actual request is executed only when the precheck request returns successfully.

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 item is the type of the actual request, which can be simple requests such as GET and POST, PUT and DELETE.
  • Access-Control-Request-Headers– The entry is a comma-separated list of headers used in complex requests.

Obviously, this “pre-check” request is actually a permission request for a later actual request, and the server should reply to both of these items in the pre-response to allow the browser to determine whether the request can be successfully completed. Once the pre-response arrives as expected and the requested permissions are satisfied, a real request is made, carrying real data.

The solution

Now that the problem is clear, we can set access-Control-max-age in the background to Control how long (s) the browser does not need to send prechecks on requests, thus reducing unnecessary prechecks.

For more detailed questions about CORS, see MDN