1 Chance encounter — Options request
I recently wrote a project where all ajax requests in the application were sent twice. Because of the new project, the basic module is a new build, so some strange problems are expected, oh, finally, for the first time in Chrome devTools encountered live options request.
1.1 First Request
The request header and response header are displayed as follows:
(1) Precheck the key fields of the request header:
| Request Header | role |
|---|---|
| Access-Control-Request-Method | Tells the server the HTTP method used for the actual request |
| Access-Control-Request-Headers | This command tells the server the user-defined header field carried in the actual request. The content-Type field in the actual request header field is user-defined |
The server decides whether to accept the actual request that follows based on the information it gets from the precheck request header.
(2) Pre-check the key fields of response header:
| response header | role |
|---|---|
| Access-Control-Allow-Methods | Returned to the server to allow requests, including GET/HEAD/PUT/PATCH/POST/DELETE |
| Access-Control-Allow-Credentials | Allow cross-domain cookie carrying (cross-domain requests must be set to true to carry cookies) |
| Access-Control-Allow-Origin | Allow domain names to be requested across domains. This can be configured on the server side with a trusted whitelist of domain names |
| Access-Control-Request-Headers | The custom header field content-Type carried by the client request |
This OPTIONS request returns the content of the response header, but does not return the content of the response body.
1.2 Second Request
This is the request that would have been sent, as shown in a normal POST request. The content-type application/json is the request Content format agreed with the back end, which is also one of the reasons why options request will be sent later.
2 OPTIONS request
From many sources, we can see that using the OPTIONS method to make a request to the server can detect which HTTP methods the server supports. However, we did not initiate the OPTIONS request this time, so why would the OPTIONS request be initiated automatically?
2.1 OPTIONS Requests are automatically initiated
CORS of MDN mentioned in the article:
The specification requires that HTTP request methods (especially HTTP requests other than GET, or POST requests paired with certain MIME types) that may have adverse effects on server data, The browser must first issue a preflight request using the OPTIONS method to know whether the server will allow the cross-domain request.
So this cross-domain request triggers the browser to automatically issue an OPTIONS request. Let’s see what conditions this cross-domain request triggers.
2.2 Conditions for triggering a Cross-domain Request
| CORS precheck request trigger condition | Whether this request triggers the condition |
|---|---|
| 1. Use the followinganyMethods the HTTP: | |
| PUT/DELETE/CONNECT/OPTIONS/TRACE/PATCH | If no, the request is POST |
| 2. It is set manuallyBeyond the following collectionHeader field: | |
| Accept/Accept-Language/Content-Language/Content-Type/DPR/Downlink/Save-Data/Viewport-Width/Width | If no, other header fields are not set |
| 3. The value of the content-typeDo not belong toOne of the following: | |
| Application/X-www-form-urlencoded, multipart/form-data, text/plain | Is that for the application/json |
CORS precheck request is triggered because the content-type is changed to Application /json.
3 Optimize OPTIONS requests: access-Control-max-age or avoid triggering
It can be seen that once the trigger condition is reached, cross-domain requests will always be sent twice. Can the increased number of requests be optimized? The answer is yes, the results of the OPTIONS precheck request can be cached.
Access-control-max-age The response header represents the return result of the Preflight Request (access-Control-allow-methods) And access-Control-allow-headers) the maximum time, in seconds, that can be cached. (MDN)
If the value is -1, caching is disabled. Each request requires a precheck request, that is, an OPTIONS request.
Try not to trigger the OPTIONS request. It is ok to change the Content-type in the example above. In other scenarios, such as cross-domain and business with custom headers, this is difficult to avoid. With third-party Ajax plug-ins like AXIos or SuperAgent, you can see if the default configuration or secondary encapsulation is normal if CORS precheck requests come in.
4 summarizes
OPTIONS requests are pre-checked requests that can be used to detect HTTP methods allowed by the server. For security reasons, when certain conditions are triggered, the browser automatically sends an OPTIONS request, that is, a CORS precheck request, before a formal request. If the server accepts the request, the browser continues to send a formal request.