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

时间:2021-10-24 14:58:37

一、前言

因为跨域请求,浏览器可能(后面讲)会发送一次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。