關於options請求的一點理解

2021-10-12 08:47:43 字數 1720 閱讀 4465

最近最專案改造,對所有的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...