請求時發送OPTIONS請求

最近在用uni-app開發項目時，發現一個以前沒注意到的點，當我發送POST請求的時候，在NetWork能夠看到在發送正式的POST請求時，會先發送一個OPTIONS請求，OPTIONS請求後纔會發送真正的POST請求

這實際上是瀏覽器對複雜跨域請求的一種處理方式,在真正發送請求以前,會先進行一次OPTIONS預請求,以肯定服務器響應是否正確,是否能接受真正的請求,若是在options請求以後獲取到的響應是拒絕性質的,例如500等http狀態,那麼它就會中止第二次的真正請求的訪問。

其實最終是由於瀏覽器對簡單跨域請求和複雜跨域請求的處理區別。

XMLHttpRequest會遵照同源策略(same-origin policy). 也即腳本只能訪問相同協議/相同主機名/相同端口的資源, 若是要突破這個限制, 那就是所謂的跨域, 此時須要遵照跨域資源共享標準CORS(Cross-Origin Resource Sharing)機制。

瀏覽器將CORS請求分爲兩類：簡單請求（simple request）和非簡單請求（not-simple-request）。

簡單請求瀏覽器請求不會觸發預檢請求，而非簡單請求會觸發預檢請求。這兩種方式怎麼區分？

同時知足下列如下條件，就屬於簡單請求，不然屬於非簡單請求（參考HTTP訪問控制（CORS））

1.請求方式只能是：GET、POST、HEAD

2.HTTP請求頭限制這幾種字段（不得人爲設置該集合以外的其餘首部字段）：

Accept、Accept-Language、Content-Language、Content-Type（須要注意額外的限制）、DPR、Downlink、Save-Data、Viewport-Width、Width

3.Content-type只能取：application/x-www-form-urlencoded、multipart/form-data、text/plain

4.請求中的任意XMLHttpRequestUpload 對象均沒有註冊任何事件監聽器；XMLHttpRequestUpload 對象可使用 XMLHttpRequest.upload 屬性訪問。

5.請求中沒有使用 ReadableStream 對象。

非簡單請求 會在正式通訊以前，增長一次HTTP請求，稱之爲預檢請求。瀏覽器會先發起OPTIONS方法到服務器，以獲知服務器是否容許該實際請求。

由此可知，若要咱們的請求知足簡單請求就能夠避免發起OPTIONS請求了。

可是

一、咱們系統請求中除了GET/POST還有PUT,DELETE，不能知足

2，咱們系統有作業務模塊權限，請求頭裏須要帶有用戶驗證信息，第二點也不知足

3，咱們的Content-Type絕大多數是application/json，仍是不知足

而後只能寄但願於減小發起OPTIONS請求的次數，也就是說仍是會用，但不是每次都用，查到的方法以下：

後端在請求的返回頭部添加：

Access-Control-Max-Age：（number）  。數值表明preflight request  （預檢請求）的返回結果（即 Access-Control-Allow-Methods 和Access-Control-Allow-Headers 提供的信息） 能夠被緩存多久，單位是秒。

例如：將預檢請求的結果緩存10分鐘：

Access-Control-Max-Age: 600 

不一樣瀏覽器有不一樣的上限。在Firefox中，上限是24h（即86400秒），而在Chromium 中則是10min（即600秒）。Chromium 同時規定了一個默認值 5 秒。
若是值爲 -1，則表示禁用緩存，每一次請求都須要提供預檢請求，即用OPTIONS請求進行檢測。

Access-Control-Max-Age方法對徹底同樣的url的緩存設置生效，多一個參數也視爲不一樣url。也就是說，若是設置了10分鐘的緩存，在10分鐘內，全部請求第一次會產生options請求，第二次以及第二次之後就只發送真正的請求了。

轉載自：https://blog.csdn.net/xiaoxiong_jiaxin/article/details/88060663