最近最專案改造，對所有的ajax請求統一做了一點處理，發現原來很正經的ajax請求突然不正常了，每個ajax之前都多了乙個相應的method為options的請求。雖然之前知道ajax的請求中method有這個，但是一直沒怎麼去了解過，這次覆盤做個小的學習總計吧~
首先還是看一下官方或者比較官方的定義：
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請求是用於請求伺服器對於某些介面等資源的支援情況的，包括各種請求方法、頭部的支援情況，僅作查詢使用。來個栗子，
access-control-allow-headers: x-requested-with通過curl來傳送乙個http請求，在響應頭中可以發現伺服器上這個介面對請求方法以及一些header的使用允許情況，也就是上面說的獲取伺服器對於某些資源的選項、支援情況。
而除了這些，options和其他http請求還有什麼不同麼？答案是有的
這個概念聽著有點耳生，嗯是我自己這麼說的。。。我們可以把瀏覽器自主發起的行為稱之為「瀏覽器級行為」。之所以說options是一種瀏覽器級行為，是因為在某些情況下，普通的get或者post請求回首先自動發起一次options請求，當options請求成功返回後，真正的ajax請求才會再次發起。
再來看下這個「某些情況下」都是什麼情況？
當滿足條件12或者13的時候，簡單的ajax請求就會出現options請求，有沒有感覺到一點同源策略的意思，個人理解這個就是瀏覽器底層對於同源策略的乙個具體實現。首先得到伺服器端的確認，才能繼續下一步的操作，這也是為什麼options請求也被叫做「預檢」請求的原因吧。
這個基本思路就是server端在接收到請求的時候，先去判斷下是不是options請求，判斷下**，沒問題的時候返回個200之類的成功就可以了。不過由於沒做個具體的demo之類的，這個就不細說了。
關於options請求的一點理解
最近最專案改造，對所有的ajax請求統一做了一點處理，發現原來很正經的ajax請求突然不正常了，每個ajax之前都多了乙個相應的method為options的請求。雖然之前知道ajax的請求中method有這個，但是一直沒怎麼去了解過，這次覆盤做個小的學習總計吧 首先還是看一下官方或者比較官方的定義...
爬蟲 關於 HTTP 的 OPTIONS 請求
用於獲取目的資源所支援的通訊選項。客戶端可以對特定的 url 使用 options 方法，也可以對整站 通過將 url 設定為 使用該方法 簡單來說，就是可以用 options 請求去嗅探某個請求在對應的伺服器中都支援哪種請求方法 前端一般不會主動發起這個請求，但是通過f12 debug頁面，一般可...
關於iBatis selectKey的一點筆記
技術前提 我們使用ibatis作為持久層方案 技術場景 假設我們有兩張表，一張主表main,一張子表sub,並且主表的主鍵是由資料庫維護的自增長的主鍵，子表中有乙個字段引用這個主鍵，那麼當我們插入主表資料後，就需要馬上返回這個自增長的主鍵。解決方案 可以在insert時通過ibatis的select...