エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
CORSを許可したLaravel製APIサーバーでput, patch, deleteが出来なくて泣いてたけど、ようやく解決出来た話 - Qiita
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
CORSを許可したLaravel製APIサーバーでput, patch, deleteが出来なくて泣いてたけど、ようやく解決出来た話 - Qiita
解説 正直CORS周り詳しくないんで、間違っている部分はご指摘頂けるとありがたいです CORSにおけるGET、... 解説 正直CORS周り詳しくないんで、間違っている部分はご指摘頂けるとありがたいです CORSにおけるGET、POSTとそれ以外(PUT, PATCH, DELETE)の違い こちらの プリフライトリクエスト を見て頂ければわかる通り、GET、POST以外のリクエストの場合は指定したメソッドの前にOPTIONSメソッドでリクエストが実行されます。 Laravel側が抱えるOPTIONSメソッドまわりの問題 こちらに書いてあるんですが、英語得意じゃないんでもし間違っていたらすいません 一応私なりの解釈を書いていきます。 まず、Laravel側でCORS対策しようとすると、 こちらのようなミドルウェアを仕込むのが一般的だと思います。 このようなミドルウェアを通るGET, POSTのルーティングは問題なく通信出来るのですが、プリフライトリクエストが必要なPUT、PATCH等の場合、一度 OPTI