Requests: ファイルなしでマルチパート投稿を生成する

これは以前に議論されました。 これは、 @ kennethreitzが望んでいるかどうかわからないAPIへの重要な変更を表しています。

個人的には、APIの辞書（タプルのリストなど）からマルチパートデータを生成する関数を公開して、ユーザーがそれを使用し、生成されたデータをリクエストに渡すことができるようにすることをお勧めします。 表面上、ファイルを使用していない場合、メモリに大きなヒットはないはずですが、それでも、メモリに1つの巨大な文字列があり、2つ目は実際にはそれらを殺さず、それは私たちのせいではなく、彼らのせいです。

おそらく、 @ kennethreitzは2番目の解決策をより受け入れやすいでしょう。 それがリクエストの設計哲学にも適合しておらず、APIの残りの部分を考えると非常に奇妙だと思いますが、知っている人は_肩をすくめる_。

実際、現在のAPIはファイル以外のマルチパートデータの送信をサポートしておらず、これは悪いことです。 問題＃935およびshazow / urllib3 / issues / 120を参照してください

何かが足りないかもしれませんが、変更は私にはかなりマイナーなようです。 リポジトリをフォークし、バージョンの変更を提案しました： https ：
（これを行うためのより良い方法がある場合は、私に知らせてください？私はgithubにかなり慣れていません）。

いくつかのユニットテストが必要で、api.pyのdocstringを変更する必要があるかもしれませんが、このようなものは合理的ですか？

変更の問題は、実装が複雑なことではなく、APIの相違であるということです。 私はこの進行中の議論で一種の垣根を越えています：マルチパートフォームデータをアップロードするための良い方法があるとおそらく便利だと思いますが、現在のfiles APIは非常に良いものだと思います。 multipartをRequest APIに追加するのが道だとは思いません。

正直なところ、私は個人的にはコンテンツタイプヘッダーを介してそれを制御したいと思いますが、それはおそらく現在よりも100倍エラーが発生しやすく、新しいユーザーを混乱させるでしょう。 私もこれについては危機に瀕していますが、それでもこれを行わないという側に誤りがあります。

どうして？ この機能リクエストを受け入れると、誰かがjsonパラメーターを持っていないことについて不平を言う可能性が高くなります。 そして、他の人が追加してほしいパラメータをさらに思いつくことができると確信しています。 現在のように、APIは本来あるべきことを正確に実行し、問題はほとんどまたはまったくありません。 これを見る1つの方法はKISSです。 これにより、リクエストが作成され、レスポンスを簡単かつ自然に使用できる優れたオブジェクトが返されます。 それは宣伝されていることを行い、残りはあなたが行います。 マルチパートエンコーディングをアドバタイズし、文書化された設計を通じてそれを行います。 ぎこちなく見えるかもしれませんが、文書化されており、機能します。

_（...）誰かがjsonパラメータを持っていないことについて不平を言うでしょう_

jsonはmultipartメディアタイプ（ httpbisドラフト21 ）ではなくmultipart applicationメディアタイプ（ rfc4627 ）のサブタイプであるため、このような不満の根拠はありません。

_ぎこちなく見えるかもしれません（...）_

それは厄介ですが、そうではないはずです。

以前のコメントを読んだ後、私の立場を繰り返したいと思います。 multipart/form-dataは現在使用されている最も一般的なマルチパートMIMEタイプであり（引用が必要です:)）、それをサポートしないことは重大な省略です。

@ piotr-dobrogost：私が上で言ったことにもかかわらず、あなたがたった今行った議論は少しでも説得力があるとは思いません。

リクエストはMIMEタイプをサポートせず、ユースケースをサポートします。 この観点から、上記の両方のコメントは奇妙に見えます。 たとえば、JSONパラメータがないことについての不満は、JSON形式のデータのアップロードが非常に一般的であるためです。おそらく、ファイル以外のマルチパートデータをアップロードするよりもリクエストのユーザーの間でより一般的です。 ' multipartの特殊なケースのサブタイプのみ'であるため、提供しないと主張するのは奇妙なことのように思えます。

とにかく、問題の核心はこれです：APIはこのライブラリの要点です。 この機能を実装するための_美しい_方法を思い付くことができない場合、それは起こりません。

そのような不満の根拠はありません[原文のまま]

@ piotr-dobrogostあなたは私よりも開発者の将来にもっと希望を持っています。 それを超えると、要求されたパラメーターは不正確です。 form_dataよりもmultipart form_dataように呼び出す必要があります。 お気づきのように、（間接的ではありますが） multipartはさまざまなメディアタイプを参照する可能性があります。

それは厄介ですが、そうではないはずです。

すべてのものがエレガントであるとは限りません（Pythonでも）。

そしてそれをサポートしていません

しかし、それはサポートされています。 しかし、さておき、我々が持っていることをdataについてapplication/x-www-form-urlencoded 、 files （またはfiles+data ）のためにmultipart/form-data我々はまだ別のパラメータが必要なのか、なぜ、私たちがそれを持っているとき、たったmultipart/form-dataで？

意図した結果を得るために、 dataとfiles組み合わせを使用する必要はありません。 実際のファイルがなくても、 requests.post('http://example.com/', files=[('key1', 'param1'), ('key2', 'param2')])似たことができます。

また、正確に言うと、 form_dataは完全には明らかではない可能性があるため、パラメーターmultipart_form_data使用しないのはなぜですか。しかし、これも不器用です。 それは明示的です、はい、そしてPEP 8は明示的に要求しますが、既存の振る舞いは十分に文書化されています。 @kennethreitzがこの機能リクエストを受け入れることを決定した場合、パラメータが行う必要があるのは、filesパラメータのエイリアスとして機能することだけです。 しかし、その動作がすでにサポートされていることを考えると、それは必要ではないと思います。

@ sigmavirus24と@Lukasaはこれを完全に要約しました。

@ piotr-dobrogostあなたの貢献は高く評価されていますが、あなたの口調は高く評価されていません。 私たちのプロジェクトとその目標に対して確固たる主張をするのはやめてください。

私の見解では、リクエストがすでにマルチパート投稿をサポートしているのに、ファイルを使用せずにユーザーがアクセスできるようになっていないことは非常に苛立たしいことです。 @ sigmavirus24がファイルをそこに貼り付けるという提案は適切ではありません。 私が使用しているWebアプリケーションは、このようなことを試みるとエラーコードを返します。

これは今後もユーザーにとって問題になるのではないかと思いますが、これに対処する努力がなされていないように思われる理由は少し混乱しています。

＃935への私の応答を参照してください

ああ、ありがとう。 楽しみにしています！

@ルカサ

_RequestsはMIMEタイプをサポートせず、ユースケースをサポートします。_

multipart/form-dataデータの送信は一般的な使用例です。

_（...）JSON形式のデータのアップロードは非常に一般的です（...）_

jsonの送信とmultipart/form-data送信を比較することはできません。 jsonの送信は簡単です。 Content-typeを設定し、組み込みモジュールを使用して1行でデータをエンコードします。それだけです。 multipart/form-data送信は、リクエストの本文が特定の構造を持っている必要があるため、より複雑です。 言い換えれば、jsonの送信はHTTPに関する限り透過的ですが、 multipart/form-data送信はそうではありません。 RequestsはHTTPライブラリであるため、このような構造の作成を処理する必要があります。

_この機能を実装するための美しい方法を思い付くことができない場合、それは起こりません。_

現在のfilesパラメータを使用してmultipart/form-dataを送信することは、ファイルとは何の関係もありませんが、決して美しくはありません（醜いです）が、どういうわけかコードベースに入ることができました:)。 醜いものを思い付くのは本当に簡単です:)

@ sigmavirus24

_（...）しかし、既存の動作は十分に文書化されています。_

悪いAPIから良いAPIを作るドキュメントはありません。 APIが優れているほど、ドキュメントは少なくて済みます。

_あなたは（...）_に似た何かをすることができます

そうですが、これは非常に誤解を招き、直感的ではありません。 以前のコメントで、これにfilesパラメータを使用することの何が問題になっているのかを説明しました。

結論：より良いものを考え出すには、現在のAPIがmultipart/form-dataデータの送信に関して悪いことを認める必要があります。

@spacecase

_私の観点からは、リクエストがすでにマルチパート投稿をサポートしていることは非常に苛立たしいことですが、ファイルを使用せずにユーザーがそれにアクセスすることはできません_

同意します。そのため、第935号を作成しました。

この問題は解決されました。

@kennethreitzを許してください、しかし@spacecase私はその例のどこにもファイルを使用しませんでした。 私はfilesパラメーターを使用して、あなたが望むことを正確に実行しました。 open('filename')を見たはずのファイルを使用したとしたら。

@ sigmavirus24 、残念ながらそれは私が望むものではありません。 クライアントがファイルから読み取っているかどうかは問題ではありません。 それがサーバーに伝えられていることです。 あなたの例では、投稿の本文は

Content-Disposition: form-data; name="key1"; filename="key1"
Content-Type: application/octet-stream

param1
--2f8732ee35564115a6c6e0c1032773e8
Content-Disposition: form-data; name="key2"; filename="key2"
Content-Type: application/octet-stream

param2
--2f8732ee35564115a6c6e0c1032773e8--

filename=の使用に注意してください。 これは、ファイルが送信されていることをサーバーに通知しています。 Webアプリでは、この誤った動作で作業するとエラーが発生します。

申し訳ありませんが、それがまさに私が望んでいることであるとあなたが私に言うのにとても傲慢であることは私を怒らせます。 私はアイデアや助けを提供するようになりましたが、この場合もあなたは望んでいないようです。 それは結構ですが、私に話しかけられていると感じさせないでください。

うーん、私はその行動を間違って覚えていたようです。 申し訳ありません。 あなたを怒らせたり、話しかけられたように感じさせたりすることは、私の意図ではありませんでした。 multipart/form-dataを処理するためのより良い方法が必要になるのは間違いなく十分ですが、今のところ、APIのアイデアがまったくエレガントではないことに同意しません。

@ spacecase ＃935への私の回答をご覧ください。 物事は良くなるでしょう。 あなたのフィードバックは重要であり、大いに感謝しています。 :)

あなたの意見が重要であることを示すジェスチャーとしての@spacecaseは、Content-Typeヘッダーを設定する必要がありますが、それはささいな煩わしさかもしれません。

@ sigmavirus24に感謝します、私はそれを試してみます。 それがトリックをするように見えます。
あなたが私を怒らせるつもりはなかったことに感謝します。 私はそれについて気分が良くなり、あなたやプロジェクトに対して何もしません。

ええ、一部の人にはばかげているように見えるので、インターネットで書いたものを洗練する必要があると思います。 私はそれを理解しておらず、他の人も私に同意していますが、私はそれに取り組んでいます。 私は、意図せずに人々に不快感を与えるものを理解するのに十分な大きさのサンプルサイズが必要だと思います（そうでない方法で何かが機能していることを覚えて自分の尻を作る以外に）。

投稿するファイルといくつかのキー値があります。 では、そのようなmutilpart-formリクエストを送信する正しい方法は何ですか？ あなたが私を助けてくれることを願っています。

Content-Disposition: form-data; name="up"; filename="aa.PNG"
Content-Type: image/png

file data
---------------------------7dee5302248e
Content-Disposition: form-data; name="exp"


-----------------------------7dee5302248e
Content-Disposition: form-data; name="ptext"

text
-----------------------------7dee5302248e
Content-Disposition: form-data; name="board"

DV_Studio
-----------------------------7dee5302248e--

I tried this way but only got a 504 error.
myfile=[('file',open('bb.jpg')),('exp','python'),('ptext',''),('board','DV_Studio')]
r = requests.post(url,files=myfile)

質問のための@deerstalkerは、ご使用くださいStackOverflowのを。 しかし、あなたの質問に答えるために、この問題に対処するためのプロジェクトが進行中ですsigmavirus24 / requests-toolbelt

また、ここで確認できるように、StackOverflowで以前にこの質問に回答したことにも注意してください。

ファイルなしでマルチパート投稿を生成するという同じ問題があります。 現時点では、 requests.post(url, data=data_dict)とrequests.post(url, data=data_dict, files={})どちらを実行しても違いはありません。 ただし、 filesキーワードのデフォルトはNoneであるため、2つの異なる動作をとることができるはずです。 files={}が指定されている場合はmultipart/form-data 、指定されていない場合はapplication/x-www-form-urlencoded 。

私は何か見落としてますか？

@jwoillez私が投稿したスタックオーバーフローリンクをたどりましたか？

私はそう思いますが、あそこのあなたの答えは、1つのファイルでのマルチパートPOSTを扱っています。 元の問題に戻りました：ファイルのないマルチパートPOST。

ファイルオブジェクトは文字列にすることができます。 =）それはあなたが望む情報をあなたに提供するはずです。

しかし、私があなたの提案に従うならば、私はこのようなものになってしまうことはありません：

Content-Disposition: form-data; name="file"; filename="filename.txt"
Content-Type: text/plain

content
--3eeaadbfda0441b8be821bbed2962e4d--

ここで、 contentは、ファイルの代わりに使用するように招待した文字列ですか？

私は本当にこの後だけです：

Content-Disposition: form-data; name="key1"

value1
--3eeaadbfda0441b8be821bbed2962e4d

不要なタプルのフィールドは、デフォルトのままにしておくことができます。

files = {'name': ('', 'content')}

今後、質問はStackOverflowに送信してください。 すべてのメンテナは定期的にそれを追跡しており、これらの質問をするのに適した場所です。

それが私が探していた答えです、ありがとう。 騒音でごめんなさい。

たぶん最後の質問ですが、次の可能性はありますか（指定された空のファイル名、空のコンテンツ）？

Content-Disposition: form-data; name="file"; filename=""
Content-Type: text/plain


--3eeaadbfda0441b8be821bbed2962e4d--

タプルのコンテンツセクションで空の文字列を使用して、空のコンテンツを提供できます。 リテラルの空のファイル名を指定することはできませんが、存在しないファイル名はまったく同じ方法で処理する必要があります。

さまざまな奇妙な理由で、これを行う必要がある場合があります。
APIをこのユースケースに強力に武装させたい人には、このアプローチをお勧めします。

class ForceMultipartDict(dict):
    def __bool__(self):
        return True


FORCE_MULTIPART = ForceMultipartDict()  # An empty dict that boolean-evaluates as `True`.


client.post("/", data={"some": "data"}, files=FORCE_MULTIPART)

または、ツールベルトを使用して、ハッキングに頼らないようにすることもできます。