Ask questions

There is always a cross-domain problem when developing projects that are separated from the front and back ends.

As you know, in the past, you could use proxies, JSONP, etc., but in the face of modern browsers, we have a better option, CORS.

By setting the access-control-allow-Origin response header on the server side, we can enable the specified source to Access the cross-domain interface as if it were the same Origin interface.

When using CORS, the token checking mechanism is adopted in the background, and the token must be put in the Request Header in the foreground to send a Request, so the custom Header information needs to be transmitted. At this time, you will find a problem when you are careful. Sometimes two requests are sent to the background at once. The first request returns no data, and the second request returns the correct data. There is an “OPTIONS” request like this:

Needless to say, this is not a bug in your code, nor is it a repeat call to the Request function, because obviously the Request Method is different.

If you have ever been confused by this question, confused, don’t know why. Then I will give you the answer to this question!

For CORS cross-domain, there are two different request types.

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

Simple cross-domain request

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

  • HEAD
  • GET
  • POST

2. HTTP header information should not exceed the following fields:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type: Limited to three values, application/ X-www-form-urlencoded, Multipart /form-data, text/plain

Partial response headers for simple cross-domain requests are as follows:

  • Access-control-allow-origin (mandatory) – The request cannot be omitted. Otherwise, the request is treated as a failure. This controls the visibility of the data. You can fill in an “*” if you want the data to be visible to anyone.

  • Access-control-allow-credentials (Optional) – This item indicates whether the request contains cookies. It has only one optional value: true (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, that is, true when withCredentials is true; When withCredentials is false, this item is omitted. Otherwise, the request fails.

  • Access-control-exposure-headers (optional) – This item determines the additional information available to the getResponseHeader() method in the XmlHttpRequest2 object. Normally, 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 it in and separate it with commas.

Complex cross-domain request

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

A complex request sends more than one communication request. The first one that is sent is a “precheck” request. In this case, the server needs to return a “pre-response” as a response. The precheck request is actually a permission request to the server. 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 the domain, and also contains two CORS specific content:

  • Access-Control-Request-Method– Indicates the type of the actual request. It can be a simple request, such as GET and POST, or PUT and DELETE.
  • Access-Control-Request-Headers– This is a comma-separated list of headers used for complex requests.

Obviously, this “precheck” request is actually sending a permission request for the actual subsequent request, and the server should reply to both of these items in the pre-response return so that the browser can determine whether the request can be completed successfully. Once the pre-response has arrived, and all the requested permissions have been satisfied, a real request is made, carrying real data.

The solution

Now that the problem is clear, we can reduce unnecessary precheck requests by setting access-control-max-age in the background to Control how long (in s) the browser does not need to send precheck requests at the time of request.

More detailed questions about CORS can be found in MDN