Http協議什麼時候發生options請求？

其實透過http方式我們最常用的就是：GET，POST; 他們都可以作為前端和後臺的資料交換使用;

• 跨域呼叫，例如：除錯時候很多情況都在跨越方式下除錯
• 自定義頭部
• 請求頭的content-type引數：application/x-www-form-urlencoded，multipart/form-data，text/plain之外的格式

以上三種情況出現就會出現options請求了，說白就是為了伺服器安全，例如：同源策略引發這個規則;

options通常是瀏覽器自動發起的，目的就是去伺服器檢查一下接下來要到用的方法(GET、POST、PUT、detele)在伺服器上是否支援;

對於伺服器該如何處理

檢查以下內容

A：方式
• 來源是否允許
• 自定義的頭部是否包含(這個和你專案有關)

如果你專案認為是安全的，直接返回200狀態碼，就可以;

B：方式
• 來源是否允許
• 自定義的頭部是否包含(這個和你專案有關)
• 檢查content-type 的內容是否是你期望的

如果你專案認為是安全的，直接返回200狀態碼，就可以

如果不允許你可以放回狀態碼400或者其他;

options請求影響服務效能，如何最佳化

本來一個請求就搞定，結果頻繁多了很多options必然造成服務的壓力;

可以做到options請求做快取處理，例如： http:// www.**.com/api/getUser 介面會出現 options請求，我們在options返回是做一次options快取，告知前端以後在此請求這個介面就不要在發options了，伺服器響應時可設定 Access-Control-Max-Age 的時間，預設10分鐘;

進一步理解options

和options有關的關鍵欄位作用

• Access-Control-Request-Method：告知伺服器，接下來請求將使用方法，例如POST
• Access-Control-Request-Headers：告知伺服器，接下來請求將攜帶的自定義請求首部欄位
MDN 中對於OPTIONS的描述

HTTP 的 OPTIONS 方法 用於獲取目的資源所支援的通訊選項。客戶端可以對特定的 URL 使用 OPTIONS 方法，也可以對整站(透過將 URL 設定為“*”)使用該方法。”