What are the options request? Why options request?

A little more understanding about the options requested

The most recent renovation project, to unify all the ajax requests to do a little treatment and found that very serious ajax request suddenly not normal, are more than before each ajax request a corresponding method of options. Although known before the ajax request to have this method, but never how to find out about, this re-set to be a small learning total it ~

What are the options request? Why options request?

Above all, look at the comparison of the official or the official definition:

The HTTP OPTIONS method for the purpose of acquiring resources communication options are supported. The client can use the OPTIONS method for a particular URL, the station may be used for the whole process (by the URL is set to "*"). --MDN WEB DOCS

Meanwhile request options have the following characteristics:

Options	Whether to allow	Remark
Request has body	No	No request body
Successful response has body	No	A successful response responsive body
Safe	Yes	Safety
Idempotent	Yes	Close equivalence, invariance, request the same interface as many times as
Cacheable	No	Can not cache
Allowed in HTML forms	No	Can not be used in the form

In short, options request is a request that the server supports the case for some interface resources, including request method, the head of the support case, only for queries. To a chestnut,

->>> curl -X OPTIONS https://xxxx.com/micro/share/getShareRecord -i

HTTP/1.1 200 OK
Server: nginx/1.13.3
Date: Mon, 30 Jul 2018 12:50:08 GMT
Content-Length: 0
Connection: keep-alive
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
X-Frame-Options: SAMEORIGIN
Access-Control-Allow-Origin: 0
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: X-Requested-With

To send a http request by curl, in response headers can be found on this server request interface methods and the use of some header allows the case, which is above acquisition server option for certain resources to support the case .
In addition to these, options and other http request, what difference? The answer is yes

Browser-level behavior

The concept of listening to a little Ersheng, ah I say so myself. . . We can self-initiated behavior browser called "browser-level behavior" . The reason why options is a browser-level behavior, because in some cases , the ordinary get or post request back to the first automatically initiate a request options, the options when the request is successful return, the real ajax request will be initiated again.

Let's look under "certain circumstances" This is what the situation?

1, cross-domain request, the request will not be non-cross-domain request options
2, the custom request header
3, the header request content-type is application / x-www-form- urlencoded, multipart / form-data, text / plain format other than

When the condition 12 or 13, there will be a simple ajax request request options, there is no meaning to feel a little same-origin policy, personal understanding this is the bottom of the browser for a same-origin policy implementation. First confirmed on the server side, to continue the next operation, which is why options request is also known cause "preflight" requests it.

How to deal with after the appearance? The server how to respond to this?

The basic idea is server-side when the request was received, go to the next judge is not requested options, determine the source of the next, no problem when a 200 returns a success like it. But because they did not make a specific demo and the like, this would not elaborate.

 

 

 

How to solve the Request header field Content-Type appears AXIOS of

Obsessed with learning attention 0 comments 2346 people read 2018-08-08 21:59:50

Problem Description:

Since in the restful head header transfer interface requires two fields:

Content-Type: application/json
Access-Token: 84c6635800b14e0eba4f7ece65e095a1

However, vue.js inside configuration:

When performing transmission appears:

Meaning that when the advance request is not passed, no longer issued a formal request

After repeated testing, we found, header which contains custom fields, the browser will first send a request options, if the request is approved, it continues to send a formal request to the post, but if you do not pass the above error is returned

This can only request that the server configuration options return code is as follows:

 

  // TODO 支持跨域访问
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Credentials", "true");
        response.setHeader("Access-Control-Allow-Methods", "*");
        response.setHeader("Access-Control-Allow-Headers", "Content-Type,Access-Token");
        response.setHeader("Access-Control-Expose-Headers", "*");        if (request.getMethod().equals("OPTIONS")) {
            HttpUtil.setResponse(response, HttpStatus.OK.value(), null);            return;
        }

 

The above needs to be added to allow the head of the code, content-type and access-token, and determines whether the requested options when the method is returned ok (200) to the client, in order to continue to receive the formal post requests.

After successfully made a post modification request.