HTTP仕様は2014年に変更され、削除に本文を含めることができます。 connection.rbのデリゲーターメソッドを解決して、削除メソッドを使用し、それを無効にしないボディを許可する計画はありますか?
あなたのレビューのためにPRがまもなくアップされます。
こんにちは@ Carlbc18 、
上記の変更へのリンクを提供していただけますか?
これはHTTP2.0仕様にのみ当てはまると思うので、この機能を慎重に検討する必要があるかもしれません。
https://tools.ietf.org/html/rfc7231#section -4.3.5
参考:これと同じテキストブロックは、GET && HEADリクエストにも適用されます。
具体的には、仕様のこの部分:
DELETE要求メッセージ内のペイロードには定義されたセマンティクスがありません。
DELETEリクエストでペイロード本体を送信すると、既存のペイロードが発生する可能性があります
リクエストを拒否する実装。
動作するテストでコードを変更しました(必要かどうかはわかりません)。 このプロジェクトのPRを作成するにはどうすればよいですか?
これはHTTP2.0仕様にのみ当てはまると思うので、この機能を慎重に検討する必要があるかもしれません。
これは実際にはHTTP1.1の一部です
PRを作りたいなら絶対に検討したいと思います。
他のリポジトリと同じように行うことができます。 faraday
をフォークし、フォークに変更を適用してから、マスターブランチにPRを作成します。
@iMacTiaに感謝します。 我慢します。 バージョンを変更することについてのあなたの見解は、最終的にこれでメジャーバージョン番号を持っていますか? この変更は多くの人にとって壊滅的なものになる可能性があります。 semverパターンに従い、この時点でバージョンfaradayを1.0.0にしたいと思います。 あなたの考えを聞かせてください。
私たちは間違いなくsemverに固執しようとしており、いくつかの重大な変更を加えてv1.0をスケジュールしています。
この変更により下位互換性が失われる場合は、バージョン1.0でのみリリースされます(現在、リリース日は固定されていません)。
ただし、私の理解では、GET、HEAD、およびDELETE要求にオプションで本文を追加できるようになっているはずなので、下位互換性があるべきではありませんか? 私は何かが足りないのですか?
@iMacTia iは
これは私のhttps://github.com/lostisland/faraday/pull/695#issuecomment-305145499のフォローアップです。
まず、これをどのように機能させるかを決定する必要があります。
変更に下位互換性があると仮定すると、以下は引き続き機能します。
conn = Faraday.new(...)
conn.get('/path', {page: 1, per: 10})
# performs "GET /path?page=1&per=10"
私のコメントで述べられているオプション1は、この動作を構成可能にすることです。
conn = Faraday.new(..., standard: :http1_1)
conn.get('/path', {page: 1, per: 10})
# performs "GET /path" with body "page=1&per=10" (assuming www_form_url_encoded request)
オプション2は、代わりに、より強力なものを意味します。
conn = Faraday.new(...) # note no special config here
conn.get('/path', {page: 1, per: 10}, body: {some_key: 'some_value')
# performs "GET /path?page=1&per=10" with body "some_key=some_value"
ただし、問題があります。ruby1.9はキーワードパラメータをサポートしていないため、オプション2はruby> = 2でのみ機能する可能性があります😞
これがruby1.9で機能しないことに関しては、大丈夫だと思います。 Ruby1.9は何年も前のものです。 最小のルビーバージョンについては、バージョンバンプを少なくとも2.0にすることをお勧めします。これは、ファラデーのv1.0リリースと一致します。 また、オプション2は、パラメーターやオプションの本体を渡すオプションがあるため、私の意見ではhttp1.1仕様にさらに厳密に従います。
ruby1.9で動作するhttp仕様機能との下位互換性を維持しようとすると問題が発生するように感じます。 この機能はファラデーのV1に適していると思います。 この変更をサポートするために必要な変数が多すぎるように感じます(ruby v、paramspassing)。 多分私は考えすぎています...
これがruby1.9で機能しないことに関しては、大丈夫だと思います。 Ruby1.9は何年も前のものです。 最小のルビーバージョンについては、バージョンバンプを少なくとも2.0にすることをお勧めします。これは、ファラデーのv1.0リリースと一致します。 また、オプション2は、パラメーターやオプションの本体を渡すオプションがあるため、私の意見ではhttp1.1仕様にさらに厳密に従います。
私は上記のすべてに完全に同意します。 これは、v1.0を待つ必要があることを意味しますが、これは確かに最善の行動です。
したがって、v1.0の下位互換性のあるAPIを定義するには、次のことを試みることができます。
conn = Faraday.new(...) # note no special config here
conn.get(path, url_params, body: {...})
# second parameter is URL PARAMS, optionally accept a named parameter for request body
# works the same for head and delete
conn = Faraday.new(...) # note no special config here
conn.post(path, body, url_params: {...})
# second parameter is REQUEST BODY, optionally accept a named parameter for url_params
# works the same for put and patch
このようにして、考えられるすべての組み合わせをカバーし、ポスト/プット/パッチリクエストも拡張していると思います!
間違いなく同意します。 PRを辞退して、新しいPRを開きますか? 作業できるV1ブランチカットはありますか?
それは完全に異なるので、それを閉じて最初から始めてください。 そのために残念!
マージする前にV1ブランチを作成するので、マスターから始めて、PRをリダイレクトします:)
こんにちは@ Carlbc18は、ブランチ1.0
が利用可能になったことをお知らせしたいと思います😃。
ありがとうありがとう! 😀
まだこれを待っている人のために、私の場合はうまくいくように見える次の回避策を見つけました:
conn = Faraday.new
body = {
some_key: 'some value'
}
conn.run_request(:delete, url, body, headers)
これが、削除するまで誰かがデフォルトで体を無効にするのに役立つことを願っています
それで、これがいつ利用可能になるかについての更新はありますか?
私はまだPRを見ていませんが、v1での作業はゆっくりと進んでいます。
私はこれに自分で取り組むことができるかもしれませんが、現時点では見積もりを出すことはできません。
リクエストがどのように機能するかについての更新されたAPIは、上記の私のコメントで説明されて
完全な下位互換性のあるソリューションの場合、PRをマスターから分岐させることができ、別の0.xリリースを作成できます。
変更によって下位互換性が失われる場合は、 1.0
ブランチから分岐することをお勧めし
https://github.com/lostisland/faraday/pull/855は、これをサポートするためのドラフトPRです。
この機能を拒否します。 ファラデーのブロックフォームを使用して、本文でリクエストを行うことができます。
conn.delete(url) do |req|
req.body = { some_key: 'some value' }
end
このアイデアでは、ボディを1つのライナーで単純に削除できますが、実装により、私が望むよりも複雑で驚くべき動作が追加されます。 このブロックフォームは、ファラデーですでにうまく機能しています。 メソッドに引数を追加するよりも、クラスのプロパティを変更する方が好きです。
conn.delete('/foo/1') do |req|
req.headers["X-Men"] = "marvel"
req.params[:confirm] = 1
req.body = { some_key: 'some value' }
end
最も参考になるコメント
まだこれを待っている人のために、私の場合はうまくいくように見える次の回避策を見つけました:
これが、削除するまで誰かがデフォルトで体を無効にするのに役立つことを願っています