关于options请求的一点理解
关于options请求的一点理解
一、总结
一句话总结：
options请求是用于请求服务器对于某些接口等资源的支持情况的，包括各种请求方法、头部的支持情况，仅作查询使用。HTTP 的 OPTIONS 方法 用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。 --MDN WEB DOCS
->>> 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
二、关于options请求的一点理解
转自或参考：关于options请求的一点理解
https://www.cnblogs.com/heioray/p/9392533.html
什么是options请求？为什么会有options请求？
首先还是看一下官方或者比较官方的定义：
HTTP 的 OPTIONS 方法 用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。 --MDN WEB DOCS
同时options请求具备以下特性：
| 选项 | 是否允许 | 备注 |
|---|---|---|
| Request has body | No | 没有请求体 |
| Successful response has body | No | 成功的响应有响应体 |
| Safe | Yes | 安全 |
| Idempotent | Yes | 密等性，不变性，同一个接口请求多少次都一样 |
| Cacheable | No | 不能缓存 |
| Allowed in HTML forms | No | 不能在表单里使用 |
简言之，options请求是用于请求服务器对于某些接口等资源的支持情况的，包括各种请求方法、头部的支持情况，仅作查询使用。来个栗子，
->>> 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通过curl来发送一个http请求，在响应头中可以发现服务器上这个接口对请求方法以及一些header的使用允许情况，也就是上面说的获取服务器对于某些资源的选项、支持情况。
而除了这些，options和其他http请求还有什么不同么？答案是有的
浏览器级行为
这个概念听着有点耳生，嗯是我自己这么说的。。。我们可以把浏览器自主发起的行为称之为“浏览器级行为”。之所以说options是一种浏览器级行为，是因为在某些情况下，普通的get或者post请求回首先自动发起一次options请求，当options请求成功返回后，真正的ajax请求才会再次发起。
再来看下这个“某些情况下”都是什么情况？
1、跨域请求，非跨域请求不会出现options请求
2、自定义请求头
3、请求头中的content-type是application/x-www-form-urlencoded，multipart/form-data，text/plain之外的格式
当满足条件12或者13的时候，简单的ajax请求就会出现options请求，有没有感觉到一点同源策略的意思，个人理解这个就是浏览器底层对于同源策略的一个具体实现。首先得到服务器端的确认，才能继续下一步的操作，这也是为什么options请求也被叫做“预检”请求的原因吧。
出现之后怎么处理？服务端怎么响应这个？
这个基本思路就是server端在接收到请求的时候，先去判断下是不是options请求，判断下来源，没问题的时候返回个200之类的成功就可以了。不过由于没做个具体的demo之类的，这个就不细说了。
