前端請求接口瀏覽器發起option預請求而導致405的問題

記一次前端請求後端接口出現405的問題：

---

問題描述：

首先闡述http的405狀態碼，405的直接提示是method not allowed，即前端請求的方法不被後端接受。（如下圖）

當時就納悶了，我後端路由明明寫的post方法，前端也是通過post的方法發起的請求，爲什麼會提示這個method不被允許。

後來仔細一看發現這個請求的request meshod，天啦擼，居然是option！！！

那麼這個option是什麼玩意，爲什麼會產生。

---

產生原因：

Http1.1共定義了9種請求方法，option就是其中的一種

GET	請求指定的頁面信息，並返回實體主體。
HEAD	類似於 GET 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。
PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE	請求服務器刪除指定的頁面。
CONNECT	HTTP/1.1 協議中預留給能夠將連接改爲管道方式的代理服務器。
OPTIONS	允許客戶端查看服務器的性能。
TRACE	回顯服務器收到的請求，主要用於測試或診斷。
PATCH	是對 PUT 方法的補充，用來對已知資源進行局部更新 。

option請求其實是一種瀏覽器自主發起的行爲， 在滿足以下情況的時候，在普通的get或post請求前，瀏覽器會自發的先發起一個option請求，檢查服務端是否支持相關的方法或自定義信息，如果滿足纔會發起下一步的請求；

1、接口請求跨域，否則不會發起option請求；

2、有自定義的請求頭信息或者請求頭中的content-type是application/x-www-form-urlencoded，multipart/form-data，text/plain之外的格式。

---

我當時就是在做接口校驗的時候讓前端在head中添加了一個簽名祕鑰signature的自定義頭信息，然後就出現了405的問題。

解決辦法：

1、在服務端的路由請求部分新增option請求，允許option請求通過。

     我這後端用的php的lumen,路由寫法變化（當然也可修改路由類）：

 //原來寫法
 $app->post('/login','AdminController@login');
 //新增option請求
 $app->addRoute(['OPTIONS','POST'],'/login','AdminController@login');
        

2、對於所有的option請求，可以在cors中間件中對option請求統一返回200即可：

if ($request->getMethod() == "OPTIONS") {
    return response()->json('ok', 200, [
      //自定義內容
    ]);
}