跨域請求中預檢請求options之坑

1、前言

由於跨域請求，瀏覽器可能（後面講）會發送一次options請求，若是處理很差，跨域仍是會gg的。

以前不多涉及跨域，涉及也是簡單請求（下面阮老師文章中區別熱簡單請求和複雜請求），因此基本不會不多關注options。後面就遇到坑了，下面講講注意點。

2、說明

直接講CORS，這是一種解決跨域的處理方案，支持各類請求的跨域（jsonp只支持get請求）。

它容許瀏覽器器向跨源服務器器，發出XMLHttpRequest 或 fetch請求，從⽽而解決了了AJAX只能同源使⽤用的限制'。

阮一峯《跨域資源共享 CORS 詳解》

3、注意點

一、複雜請求（條件看上文）會發送一次預檢請求options。好比我在fetch設置了：

headers: {
 'X-TOKEN': ‘本身設定’，
}　

二、服務端要對預檢查請求作出迴應，後面才能繼續發送真正的請求拿到數據。

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

三、幹掉options

若是不作特殊處理，對於非簡單請求每次都會發送一次預檢請求。能夠在服務端添加：

Access-Control-Max-Age: 1728000

該字段可選，用來指定本次預檢請求的有效期，單位爲秒。上面結果中，有效期是20天（1728000秒），即容許緩存該條迴應1728000秒（即20天），在此期間，不用發出另外一條預檢請求。

四、關於cookie

須要注意的是，若是要發送Cookie，Access-Control-Allow-Origin就不能設爲星號，必須指定明確的、與請求網頁一致的域名。同時，Cookie依然遵循同源政策，只有用服務器域名設置的Cookie纔會上傳，其餘域名的Cookie並不會上傳，且（跨源）原網頁代碼中的document.cookie也沒法讀取服務器域名下的Cookie。