最近最項目改造，對所有的ajax請求統一做了一點處理，發現原來很正經的ajax請求突然不正常了，每個ajax之前都多了一個相應的method為options的請求。雖然之前知道ajax的請求中method有這個，但是一直沒怎么去了解過，這次復盤做個小的學習總計吧~
什么是options請求？為什么會有options請求？
首先還是看一下官方或者比較官方的定義：
HTTP 的 OPTIONS 方法 用於獲取目的資源所支持的通信選項。客戶端可以對特定的 URL 使用 OPTIONS 方法，也可以對整站（通過將 URL 設置為“*”）使用該方法。 --MDN WEB DOCS
同時options請求具備以下特性：
| 選項 | 是否允許 | 備注 |
|---|---|---|
| Request has body | No | 沒有請求體 |
| Successful response has body | No | 成功的響應有響應體 |
| Safe | Yes | 安全 |
| Idempotent | Yes | 密等性，不變性，同一個接口請求多少次都一樣 |
| Cacheable | No | 不能緩存 |
| Allowed in HTML forms | No | 不能在表單里使用 |
簡言之，options請求是用於請求服務器對於某些接口等資源的支持情況的，包括各種請求方法、頭部的支持情況，僅作查詢使用。來個栗子，
->>> curl -X OPTIONS https://xxxx.com/micro/share/getShareRecord -i
HTTP/1.1 200 OK
Server: nginx/1.13.3
Date: Mon, 30 Jul 2018 12:50:08 GMT
Content-Length: 0
Connection: keep-alive
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
X-Frame-Options: SAMEORIGIN
Access-Control-Allow-Origin: 0
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: X-Requested-With
通過curl來發送一個http請求，在響應頭中可以發現服務器上這個接口對請求方法以及一些header的使用允許情況，也就是上面說的獲取服務器對於某些資源的選項、支持情況。
而除了這些，options和其他http請求還有什么不同么？答案是有的
瀏覽器級行為
這個概念聽着有點耳生，嗯是我自己這么說的。。。我們可以把瀏覽器自主發起的行為稱之為“瀏覽器級行為”。之所以說options是一種瀏覽器級行為，是因為在某些情況下，普通的get或者post請求回首先自動發起一次options請求，當options請求成功返回后，真正的ajax請求才會再次發起。
再來看下這個“某些情況下”都是什么情況？
1、跨域請求，非跨域請求不會出現options請求
2、自定義請求頭
3、請求頭中的content-type是application/x-www-form-urlencoded，multipart/form-data，text/plain之外的格式
當滿足條件12或者13的時候，簡單的ajax請求就會出現options請求，有沒有感覺到一點同源策略的意思，個人理解這個就是瀏覽器底層對於同源策略的一個具體實現。首先得到服務器端的確認，才能繼續下一步的操作，這也是為什么options請求也被叫做“預檢”請求的原因吧。
出現之后怎么處理？服務端怎么響應這個？
這個基本思路就是server端在接收到請求的時候，先去判斷下是不是options請求，判斷下來源，沒問題的時候返回個200之類的成功就可以了。不過由於沒做個具體的demo之類的，這個就不細說了。