php接口報錯解決分析記錄
問題表現(xiàn)
服務器上部署了兩套相同代碼的項目A和B,分別以不同的域名訪問,提交代碼時同步更新。以POST
方式請求某個特定接口時,A能夠正常響應,B卻無論如果都是報錯The GET method is not supported for this route. Supported methods: POST.
奇怪的是,本地開發(fā)是正常的,無法復現(xiàn)此bug, 線上服務器里A項目亦是正常訪問,B項目代碼與A完全相同,僅配置文件.env
與域名授權(quán)文件不同。
搜索解決方法,嘗試
php artisan route:clear php artisan route:cache
問題依舊,通過php artisan route:list
打印出項目的所有路由,發(fā)現(xiàn)B項目的路由是正確的,推測問題可能與項目無關(guān);
打開B項目的Debug
設(shè)置,顯示該報錯的追蹤路徑,發(fā)現(xiàn)框架對該請求的Method
判斷為GET
, 而該路由所定義方法為POST
,所以直接拋出錯誤The GET method is not supported for this route. Supported methods: POST.
問題查到這里陷入了死胡同,我無法理解為什么以POST
發(fā)起的請求,流程達到框架中處理時, 請求的Method
會變成GET
;
糾結(jié)一天沒有結(jié)果。第二天判斷可能是nginx
到框架過程中出的問題,嘗試調(diào)取Nginx
的Access日志來判斷問題原因,終于發(fā)現(xiàn)
127.0.0.1 - - [02/Mar/2022:11:29:48 +0800] "POST /api_path/action_name HTTP/1.1" 301 162 "-" "PostmanRuntime/7.29.0"
127.0.0.1 - - [02/Mar/2022:11:29:49 +0800] "GET /api_path/action_name HTTP/1.1" 405 26147 "http://host_domain/api_path/action_name" "PostmanRuntime/7.29.0"
在Nginx
這里,POST
請求被301重定向成GET
,以GET
去請求POST
的路由當然會報錯;
而這個301則是寶塔環(huán)境自帶的“強制HTTPS”的設(shè)置導致,開啟該設(shè)置之后,nginx
的配置文件會增加以下代碼
#HTTP_TO_HTTPS_START if ($server_port !~ 443){ rewrite ^(/.*)$ https://$host$1 permanent; }
至此,關(guān)閉該“強制HTTS"的設(shè)置,問題解決。
后記:一般情況下301重定向強制HTTPS用于網(wǎng)站首頁為主,網(wǎng)站首頁一般情況下都是GET
請求,自然也就不會存在POST
變成GET
的困擾。
關(guān)于301的POST
轉(zhuǎn)GET
問題,可以參考
以上就是php接口報錯解決分析記錄的詳細內(nèi)容,更多關(guān)于php接口報錯解決的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
PHP Header用于頁面跳轉(zhuǎn)時的幾個注意事項
大家都知道header函數(shù)中Location類型的標頭是一種特殊的header調(diào)用,常用來實現(xiàn)頁面跳轉(zhuǎn),在新手剛學習的時候有些注意事項要注意,下面通過本文來詳細看看吧。2016-10-10PHP使用PDO創(chuàng)建MySQL數(shù)據(jù)庫、表及插入多條數(shù)據(jù)操作示例
這篇文章主要介紹了PHP使用PDO創(chuàng)建MySQL數(shù)據(jù)庫、表及插入多條數(shù)據(jù)操作,結(jié)合實例形式總結(jié)分析了php基于pdo的mysql數(shù)據(jù)庫創(chuàng)建、數(shù)據(jù)表創(chuàng)建以及多條數(shù)據(jù)插入操作相關(guān)實現(xiàn)技巧,需要的朋友可以參考下2019-05-05redis查看連接數(shù)及php模擬并發(fā)創(chuàng)建redis連接的方法
下面小編就為大家?guī)硪黄猺edis查看連接數(shù)及php模擬并發(fā)創(chuàng)建redis連接的方法。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2016-12-12