跨域请求中预检请求options之坑

一、前言

因为跨域请求，浏览器可能（后面讲）会发送一次options请求，如果处理不好，跨域还是会gg的。

之前很少涉及跨域，涉及也是简单请求（下面阮老师文章中区别热简单请求和复杂请求），所以基本不会很少关注options。后面就遇到坑了，下面讲讲注意点。

二、说明

直接讲CORS，这是一种解决跨域的处理方案，支持各种请求的跨域（jsonp只支持get请求）。

它允许浏览器器向跨源服务器器，发出XMLHttpRequest 或 fetch请求，从⽽而解决了了AJAX只能同源使⽤用的限制'。

阮一峰《跨域资源共享 CORS 详解》

三、注意点

1、复杂请求（条件看上文）会发送一次预检请求options。比如我在fetch设置了：

headers: {

 'X-TOKEN': ‘自己设定’，

}

2、服务端要对预检查请求做出回应，后面才能继续发送真正的请求拿到数据。

OPTIONS /api HTTP/1.1

Origin: http:XXX.com

Access-Control-Request-Method: GET POST PUT

Access-Control-Request-Headers: X-Token

Host: XXX.com

Connection: keep-alive

3、干掉options

如果不做特殊处理，对于非简单请求每次都会发送一次预检请求。可以在服务端添加：

Access-Control-Max-Age: 1728000

该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。

4、关于cookie

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

秒客网

跨域请求中预检请求options之坑

相关文章