When all cross-domain js submits a post request, if the server is set to allow cross-domain access
Will send two requests by default, the first is a pre-check request to check whether cross-domain is supported, and the second is the real post submission
The first is an options request, and the second request is what we expected. Why is an options request initiated first:
options request
The official definition of the options request: The OPTIONS method is used to request the resource identified by the Request-URI to obtain the functional options that can be used during the request/response communication process. Through this method, the client can decide what necessary action to take on the resource or understand the performance of the server before making a specific resource request.
In fact, it is: before a formal request occurs, a pre-check request is made first. See if the server returns some information. After the browser gets it, check whether the background allows access.
How to generate an options request:
The reasons for generating an options request include the following:
1: A complex request was generated. Complex requests correspond to simple requests. The definition of a simple request is:
The request method is GET, HEAD or POST, and when the request method is POST, the Content-Type must be one of application/x-www-form-urlencoded, multipart/form-data or text/plain.
There are no custom HTTP headers in the request.
The so-called custom header, in actual projects, we often encounter the need to add some token or other user information to the header for verification of user information.
2: A cross domain has occurred.
What is the function of the options request?
Officially, the request method with custom information in the header is called a cross-domain request with preflighted. Before actually calling the interface, an options request will be sent first to check whether the server supports real requests for cross-domain requests. The real request is in the options request, and the Access-Control-Request-Headers and Access-Control-Request-Method are sent to the background through the request-header, and the browser will add an Origin request address by itself. After receiving the pre-check request, the server adds access-control-allow-headers (request headers that allow cross-domain requests) and access-control-allow-methods (allows cross-domain requests) to the response-header according to the resource permission configuration. The request method of the request), access-control-allow-origin (domains that allow cross-domain requests). In addition, the server can also use Access-Control-Max-Age to set that there is no need to make a pre-check request for a certain period of time, and it can directly use the negotiation result of the previous pre-check request. The browser then decides whether to make a real cross-domain request based on the information returned by the server. This process is also transparent to users.
In addition, in the HTTP response header, if the browser request carries identity information, but the response header does not return Access-Control-Allow-Credentials: true, the browser will ignore the response.
Summary: As long as it is a cross-domain request with a custom header, it will send an OPTIONS request before sending the real request. The browser decides whether to continue sending real requests for cross-domain resource access based on the results returned by the OPTIONS request. So complex requests will definitely request the server twice.
How to avoid the options request
In fact, through the above analysis, we can come up with the following solutions:
1: Use a proxy to avoid cross-domain.
2: Change complex cross-domain requests to simple cross-domain requests.
3: Do not use the header header with custom configuration.