記一次前端請求後端接口出現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, [
//自定義內容
]);
}