PATCHメソッドの使用を止めるのも回避策としてはありなのだろうけど、結局何がPATCHをブロックしていたのか不明なのがモヤる。こうやってRESTの思想が徐々に骨抜きにされていくのか?
エッジ/BFFを境界として、formのPOSTとAPIのPATCHを切り分ける、とかですかね。しらんけど。それと大分久々に"AJAX"という単語を見た。
GET、POST、DELETE以外は禁止。原点回帰だ
なぜ今回ついでにPUTもNGにする方針にしたのか、そこを詳しく知りたいです。
そんなことがあるのか〜
「「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけました。」ぬあ、PATCH使ったやつ使い始めた所なのに…
くええ…… 辛い…… とはいえ現世利益が優先……
おお…これはつらい感じだ。toBだとやむを得ないのか…ほかに道はなかったのか…？
思想的にはput/pacth使いたいけどそうなの
"その結果、同じくPATCH APIが使われている他の機能も使用できないことがわかりました。 そのため「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけました"
PATCHがブロックされる…誰に…そんな環境あるんだ…えー
“「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけ”
昔なんかDELETEメソッドが通らなくなったことがあり、追っていくとAkamaiの設定で「body付きDELETEをブロックする」ってのがデフォルトONになってて外したら動くようになったのを思い出しました
FirewallとかUTMの設定でPATCHメソッドを許可してないんですかね？
脆弱性レポート「xxxライブラリには脆弱性があり、POST,PUT,PATCH,DELETEを利用していると影響あり。」→POSTだけにして影響を1/4に軽減！みたいな判断があって抗えないみたいな話が世の中のどこかにあるかもしれない。
HTTPメソッドに限って言えば政治で何とかするより実装を合わせてあげるほうが楽だもんなぁ。PUTも許さないのは追加時に今回はどのメソッドを使おうか？という余計な判断が入るのを嫌ってのことかなと邪推。
DELETEもいらん説。／body付きのGETやDELETEはElasticSearchをプロキシする時にハマったような・・？
そんなことあるのか。どういう理由でブロックされたんだろう
なぜpatchがブロックされるのかわからないのがとてもモヤる。
yaml用linter、稀に良く欲しくなるやつだ。
「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」こんな過酷な環境で働いている人もいるのか。おいたわしや🙏
まぁ稀によくあるよなそういう環境。思想として正しくとも、使えなきゃ意味ないので残当
大変そうだな…
全部POSTでいいし、レコードが無い時に404を返すのは馬鹿だろって思ってる。そもそもアプリケーション層に下層のプロトコルを持ち込むのが間違い。RESTは中二病。
正直、DELETEもいらん。GETとPOSTで回る。POSTされた時の一連の処理の中でDELETEしていることがあったりするし。結局コストの関係値は現状、通信量 < 通信回数のケースが多いのでそう感じるのかなと。
「PATCHメソッドがセキュリティソフトの設定などによりブロック」まじか。。とはいえリソース指向で設計しても、自由度高すぎるPATCHより部分リソースのPUTの方が適切と感じることが多いので、まあ禁止してもOKな気はする
ええー？何のためのRFCよ…顧客都合を優先せざるを得ないのは分かるけど、ひどいセキュリティソフトもあったものだな。こんな調子じゃWebDAVなんかも事実上、封印されてしまうんじゃないの？
“結果、同じくPATCH APIが使われている他の機能も使用できないことがわかりました。そのため「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけました。”
新規APIの実装でPATCHメソッドを使用しないようにしました | PR TIMES 開発者ブログ
PATCHメソッドの使用を止めるのも回避策としてはありなのだろうけど、結局何がPATCHをブロックしていたのか不明なのがモヤる。こうやってRESTの思想が徐々に骨抜きにされていくのか?
エッジ/BFFを境界として、formのPOSTとAPIのPATCHを切り分ける、とかですかね。しらんけど。それと大分久々に"AJAX"という単語を見た。
GET、POST、DELETE以外は禁止。原点回帰だ
なぜ今回ついでにPUTもNGにする方針にしたのか、そこを詳しく知りたいです。
そんなことがあるのか〜
「「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけました。」ぬあ、PATCH使ったやつ使い始めた所なのに…
くええ…… 辛い…… とはいえ現世利益が優先……
おお…これはつらい感じだ。toBだとやむを得ないのか…ほかに道はなかったのか…？
思想的にはput/pacth使いたいけどそうなの
"その結果、同じくPATCH APIが使われている他の機能も使用できないことがわかりました。 そのため「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけました"
PATCHがブロックされる…誰に…そんな環境あるんだ…えー
“「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけ”
昔なんかDELETEメソッドが通らなくなったことがあり、追っていくとAkamaiの設定で「body付きDELETEをブロックする」ってのがデフォルトONになってて外したら動くようになったのを思い出しました
FirewallとかUTMの設定でPATCHメソッドを許可してないんですかね？
脆弱性レポート「xxxライブラリには脆弱性があり、POST,PUT,PATCH,DELETEを利用していると影響あり。」→POSTだけにして影響を1/4に軽減！みたいな判断があって抗えないみたいな話が世の中のどこかにあるかもしれない。
HTTPメソッドに限って言えば政治で何とかするより実装を合わせてあげるほうが楽だもんなぁ。PUTも許さないのは追加時に今回はどのメソッドを使おうか？という余計な判断が入るのを嫌ってのことかなと邪推。
DELETEもいらん説。／body付きのGETやDELETEはElasticSearchをプロキシする時にハマったような・・？
そんなことあるのか。どういう理由でブロックされたんだろう
なぜpatchがブロックされるのかわからないのがとてもモヤる。
yaml用linter、稀に良く欲しくなるやつだ。
「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」こんな過酷な環境で働いている人もいるのか。おいたわしや🙏
まぁ稀によくあるよなそういう環境。思想として正しくとも、使えなきゃ意味ないので残当
大変そうだな…
全部POSTでいいし、レコードが無い時に404を返すのは馬鹿だろって思ってる。そもそもアプリケーション層に下層のプロトコルを持ち込むのが間違い。RESTは中二病。
正直、DELETEもいらん。GETとPOSTで回る。POSTされた時の一連の処理の中でDELETEしていることがあったりするし。結局コストの関係値は現状、通信量 < 通信回数のケースが多いのでそう感じるのかなと。
「PATCHメソッドがセキュリティソフトの設定などによりブロック」まじか。。とはいえリソース指向で設計しても、自由度高すぎるPATCHより部分リソースのPUTの方が適切と感じることが多いので、まあ禁止してもOKな気はする
ええー？何のためのRFCよ…顧客都合を優先せざるを得ないのは分かるけど、ひどいセキュリティソフトもあったものだな。こんな調子じゃWebDAVなんかも事実上、封印されてしまうんじゃないの？
“結果、同じくPATCH APIが使われている他の機能も使用できないことがわかりました。そのため「PATCHメソッドがセキュリティソフトの設定などによりブロックされている」ことが原因と結論づけました。”