快速理解OPTIONS请求
- 简述
- 实际遇到的问题
简述
OPTIONS请求常被用作一种“预检”请求，以检查实际请求（如POST或PUT）是否可以被服务器接受。
为什么要有OPTIONS请求？
比如当一个POST请求比较复杂时，传输一个POST请求比较消耗带宽及性能，若被拦截再返回，这样子十分消耗资源。于是可以采用更加轻量化的OPTIONS请求去预检。当OPTIONS请求出现问题时，将不再执行实际的POST请求，这样可以提升性能，特别是遇到跨域问题的时候。
什么时候去发送OPTIONS请求？
这通常不需要在代码里主动发送OPTIONS请求，浏览器若判断某个请求（如复杂的POST等）比较复杂的时候，会自动发送OPTIONS请求进行预检（由浏览器自动控制其发送）。若预检失败，则不发送实际请求。
具体什么情况去发送OPTIONS，这是由浏览器决定的，没必要深究，网上资料也很多
实际遇到的问题
这就很好理解了，为什么我就发了一个post，会出现2个请求，因为其中一个是OPTIONS请求，另外一个是POST
而一般情况下，我发一个post请求，就只有1个post请求（是因为浏览器判断该请求比较简单）
既然是浏览器自动发送，那为什么还要考虑OPTIONS请求呢？
比如后端springboot工程中，会有拦截器，假如一个未登录用户想要请求接口的时候，那就做一个拦截的操作。确保只有登录后，才能访问除登录以外的接口。
只有登录并保存有Session信息的用户，才能访问相应的接口，那么就意味着前端需要传输cookie给后端验证身份，后端才能获取到对应的session。
然而OPTIONS请求，通常不携带cookie，那样后端也没法获取session，会被自定义的Session拦截器拦截。即使，前后端代码中设置了允许携带cookie。
解决方法
后端拦截器除了对登录接口login放行，还需要对OPTIONS请求放行