Requests: बिना फ़ाइल के मल्टीपार्ट पोस्ट जेनरेट करें

इस पर पहले भी चर्चा की जा चुकी है। यह एपीआई में एक महत्वपूर्ण बदलाव का प्रतिनिधित्व करेगा जो मुझे यकीन नहीं है कि @kennethreitz पसंद करेंगे।

व्यक्तिगत रूप से, मैं एपीआई में शब्दकोशों (टुपल्स की सूची, आदि) से मल्टीपार्ट डेटा उत्पन्न करने के लिए एक फ़ंक्शन को उजागर करने के पक्ष में हूं ताकि उपयोगकर्ता इसका उपयोग कर सकें और जेनरेट किए गए डेटा को अनुरोधों पर पास कर सकें। जाहिरा तौर पर, अगर वे फाइलों का उपयोग नहीं कर रहे हैं, तो एक बड़ी मेमोरी हिट नहीं होनी चाहिए, लेकिन फिर भी, उनके पास पहले से ही एक बड़ी मेमोरी है, दूसरा वास्तव में उन्हें नहीं मारेगा और यह उनकी गलती होगी, हमारी नहीं .

शायद @kennethreitz दूसरे समाधान के लिए अधिक

दरअसल, मौजूदा एपीआई फाइलों के अलावा मल्टीपार्ट डेटा भेजने का समर्थन नहीं करता है और यह एक बुरी बात है। अंक #935 और shazow/urllib3/मुद्दों/120 देखें

शायद मुझे कुछ याद आ रहा है, लेकिन बदलाव मुझे मामूली लगते हैं। मैंने रिपॉजिटरी को फोर्क किया और यहां मेरे संस्करण में एक प्रस्तावित परिवर्तन किया है: https://github.com/spacecase/requests/commit/45b0b3ce1e76b241b323570a5fc88ae2089c3c3d
(यदि ऐसा करने का कोई बेहतर तरीका है तो मुझे बताएं? मैं जीथब के लिए नया हूं)।

इसे एक जोड़े की आवश्यकता हो सकती है और api.py में एक डॉकस्ट्रिंग में बदलाव की आवश्यकता होगी, लेकिन क्या ऐसा कुछ उचित है?

परिवर्तन के साथ मुद्दा यह नहीं है कि इसे लागू करना जटिल है, यह है कि यह एपीआई में एक विचलन है। मैं इस चल रही चर्चा में बाड़ पर हूं: मुझे लगता है कि मल्टीपार्ट फॉर्म-डेटा अपलोड करने का एक अच्छा तरीका शायद उपयोगी होगा, लेकिन मुझे यह भी लगता है कि वर्तमान files एपीआई एक बहुत अच्छा है . मुझे लगता है कि multipart को Request API में जोड़ने का तरीका है।

ईमानदारी से, मैं व्यक्तिगत रूप से सामग्री प्रकार शीर्षलेख के माध्यम से इसे नियंत्रित करूंगा लेकिन यह 100x अधिक त्रुटि प्रवण और नए उपयोगकर्ताओं को भ्रमित करने वाला होगा जो हम वर्तमान में करते हैं। मैं इसके बारे में भी बाड़ पर हूं, लेकिन मैं अभी भी ऐसा नहीं करने के पक्ष में हूं।

क्यों? यदि हम इस सुविधा अनुरोध को स्वीकार करते हैं, तो इस बात की अधिक संभावना हो जाती है कि कोई व्यक्ति json पैरामीटर न होने की शिकायत करेगा। और मुझे यकीन है कि अन्य लोग और भी अधिक मापदंडों के साथ आ सकते हैं जिन्हें वे जोड़ना पसंद करेंगे। जैसा कि अभी है, एपीआई ठीक वही करता है जो उसे करना चाहिए और इसमें बहुत कम या कोई क्रूफ्ट नहीं है। इसे देखने का एक तरीका KISS है। यह अनुरोध करता है और एक महान वस्तु देता है जो प्रतिक्रिया का उपयोग करना आसान और स्वाभाविक बनाता है। यह वही करता है जो विज्ञापित है और आप बाकी काम करते हैं। यह मल्टीपार्ट एन्कोडिंग का विज्ञापन करता है और इसे अपने प्रलेखित डिज़ाइन के माध्यम से करता है। यह अजीब लग सकता है लेकिन यह प्रलेखित है और यह काम करता है।

_(...) कोई जेसन पैरामीटर नहीं होने की शिकायत करेगा_

इस तरह की शिकायत का कोई आधार नहीं होगा क्योंकि json application मीडिया टाइप ( rfc4627 ) का एक उपप्रकार है न कि multipart मीडिया टाइप ( httpbis ड्राफ्ट 21 )

_यह अजीब लग सकता है (...)_

यह अजीब है जबकि ऐसा नहीं होना चाहिए।

पिछली टिप्पणियों को पढ़ने के बाद मैं अपनी स्थिति दोहराना चाहूंगा: multipart/form-data वर्तमान में उपयोग किया जाने वाला सबसे आम मल्टीपार्ट MIME प्रकार है (उद्धरण वांछित :)) और इसका समर्थन नहीं करना एक सकल चूक है।

@ पियोट्र-डोब्रोगोस्ट: मैंने ऊपर जो कहा है, उसके बावजूद, मुझे वह तर्क नहीं मिला, जिसे आपने थोड़ा सम्मोहक बनाया था।

अनुरोध MIME प्रकारों का समर्थन नहीं करता है, यह उपयोग के मामलों का समर्थन करता है। यह दृष्टिकोण ऊपर दी गई आपकी दोनों टिप्पणियों को अजीब लगता है। उदाहरण के लिए, JSON पैरामीटर न होने की शिकायत इसलिए होगी क्योंकि JSON-स्वरूपित डेटा अपलोड करना बहुत आम है - गैर-फ़ाइल मल्टीपार्ट डेटा अपलोड करने की तुलना में अनुरोधों के उपयोगकर्ताओं के बीच शायद अधिक आम है। यह तर्क देते हुए कि हम इसे प्रदान नहीं करेंगे क्योंकि 'हम केवल multipart विशेष-केस उपप्रकार' कहने के लिए एक विचित्र बात की तरह लगते हैं।

भले ही, इस मुद्दे का मूल यह है: एपीआई इस पुस्तकालय का संपूर्ण बिंदु है। यदि आप इस कार्यक्षमता को लागू करने के लिए _सुंदर_ तरीके से नहीं आ सकते हैं, तो ऐसा नहीं होगा।

ऐसी शिकायत का कोई आधार नहीं होगा [sic]

@ piotr-dobrogost आपको डेवलपर्स के भविष्य के लिए मुझसे ज्यादा उम्मीद है। इसके अलावा, अनुरोधित पैरामीटर सटीक नहीं है। इसे form_data तुलना में multipart form_data जैसा कुछ और कहने की आवश्यकता होगी। जैसा कि आप नोट करते हैं, (हालांकि परोक्ष रूप से) multipart विभिन्न मीडिया प्रकारों को संदर्भित कर सकता है।

यह अजीब है जबकि ऐसा नहीं होना चाहिए।

सभी चीजें सुरुचिपूर्ण नहीं हो सकतीं (पायथन में भी)।

और इसका समर्थन नहीं कर रहा है

लेकिन यह समर्थित है। लेकिन इसके अलावा, हमारे पास 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 , लेकिन अब वह भी अनाड़ी है। यह स्पष्ट है, हाँ, और पीईपी 8 स्पष्टीकरण के लिए कहता है, लेकिन मौजूदा व्यवहार अच्छी तरह से प्रलेखित है । यदि @kennethreitz इस सुविधा अनुरोध को स्वीकार करने का निर्णय समर्थित है, मुझे नहीं लगता कि यह आवश्यक है।

@sigmavirus24 और @Lukasa ने इसे पूरी तरह से अभिव्यक्त किया है।

@piotr-dobrogost आपके योगदान की सराहना की जाती है, लेकिन आपके स्वर की नहीं। कृपया हमारी परियोजना और उसके लक्ष्यों के खिलाफ दृढ़ दावे करना बंद करें।

मेरे दृष्टिकोण से यह काफी निराशाजनक है कि अनुरोधों में पहले से ही बहु-भाग पदों के लिए समर्थन है, लेकिन उपयोगकर्ता को फ़ाइल का उपयोग किए बिना उस तक पहुंच प्रदान नहीं करता है। @ sigmavirus24 का केवल एक फ़ाइल को वहाँ

मुझे संदेह है कि यह भविष्य में उपयोगकर्ताओं के लिए एक समस्या बनी रहेगी, और मैं थोड़ा भ्रमित हूं कि इसे संबोधित करने का प्रयास क्यों नहीं किया जा रहा है।

#935 . पर मेरी प्रतिक्रिया देखें

धन्यवाद। मैं इसकी आशा करता हूं!

@लुकासा

_अनुरोध MIME प्रकारों का समर्थन नहीं करता, यह उपयोग के मामलों का समर्थन करता है।_

multipart/form-data डेटा भेजना एक सामान्य उपयोग का मामला है।

_(...) JSON-स्वरूपित डेटा अपलोड करना बहुत आम है (...)_

हम multipart/form-data भेजने के साथ json भेजने की तुलना नहीं कर सकते। जेसन भेजना आसान है; आप Content-type सेट करते हैं, अंतर्निहित मॉड्यूल का उपयोग करके डेटा को एक पंक्ति में एन्कोड करते हैं और यही वह है। multipart/form-data भेजना अधिक जटिल है क्योंकि अनुरोध के मुख्य भाग में विशिष्ट संरचना होनी चाहिए। दूसरे शब्दों में, json भेजना उतना ही पारदर्शी है जितना HTTP का संबंध है लेकिन multipart/form-data भेजना नहीं है। चूंकि अनुरोध HTTP पुस्तकालय है, इसलिए इसे ऐसी संरचना बनाने का ख्याल रखना चाहिए।

_यदि आप इस कार्यक्षमता को लागू करने के लिए एक सुंदर तरीके से नहीं आ सकते हैं, तो ऐसा नहीं होगा।_

वर्तमान files परम को भेजने के लिए multipart/form-data जिसका फाइलों से कोई लेना-देना नहीं है, किसी भी तरह से सुंदर नहीं है (यह बदसूरत है), फिर भी यह किसी तरह कोडबेस में आने में कामयाब रहा :)। कुछ कम बदसूरत के साथ आना वास्तव में आसान है :)

@sigmavirus24

_(...) लेकिन मौजूदा व्यवहार अच्छी तरह से प्रलेखित है।_

दस्तावेज की कोई भी राशि खराब एपीआई से अच्छा एपीआई नहीं बनाती है। एपीआई जितना बेहतर होगा, उसे दस्तावेज़ीकरण की उतनी ही कम आवश्यकता होगी।

_आप (...)_ जैसा कुछ कर सकते हैं

ठीक है, लेकिन यह बहुत ही भ्रामक और अनजाने में है। मैंने अपनी पिछली टिप्पणी में वर्णित किया कि इसके लिए files परम का उपयोग करने में क्या गलत है।

निचली पंक्ति: कुछ बेहतर के साथ आने के लिए हमें यह स्वीकार करना होगा कि वर्तमान एपीआई multipart/form-data डेटा भेजने के संबंध में खराब है।

@स्पेसकेस

_मेरे दृष्टिकोण से यह काफी निराशाजनक है कि अनुरोधों में पहले से ही बहु-भाग पदों के लिए समर्थन है, लेकिन उपयोगकर्ता को फ़ाइल का उपयोग किए बिना उस तक पहुंच प्रदान नहीं करता है_

मैं सहमत हूं और इसलिए मैंने #935 अंक बनाया है।

यह मुद्दा बंद है।

मुझे @kennethreitz क्षमा करें लेकिन @spacecase मैंने उस उदाहरण में कहीं भी फ़ाइल का उपयोग नहीं किया। मैंने वही करने के लिए फाइल पैरामीटर का उपयोग किया जो आप चाहते हैं। अगर मैंने एक फाइल का इस्तेमाल किया होता तो आपने 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= के उपयोग पर ध्यान दें। यह सर्वर को बता रहा है कि एक फाइल भेजी जा रही है। वेब ऐप्स में मैं इस गलत व्यवहार के साथ काम करता हूं जिसके परिणामस्वरूप त्रुटि होती है।

मुझे खेद है, लेकिन मुझे यह बताने के लिए इतना अभिमानी होना कि मैं वही चाहता हूं जो मुझे ठेस पहुंचाता है। मैं विचारों और सहायता की पेशकश करने आया था, और ऐसा लगता है कि आप इस मामले में भी नहीं चाहते हैं। यह ठीक है, लेकिन कृपया मुझे यह महसूस न कराएं कि मुझसे बात की गई है।

एचएम, ऐसा लगता है कि मुझे व्यवहार गलत तरीके से याद आया। उसके लिए माफ़ करना। मेरा इरादा आपको ठेस पहुँचाना या आपको नीचा दिखाने का नहीं था। यह निश्चित रूप से मुझे multipart/form-data को संभालने के बेहतर तरीके की आवश्यकता के लिए पर्याप्त है, लेकिन अभी के लिए मैं अभी भी असहमत हूं कि एपीआई के विचार बिल्कुल भी सुरुचिपूर्ण नहीं हैं।

@spacecase कृपया #935 पर मेरी प्रतिक्रिया देखें। चीजें बेहतर होंगी। आपकी प्रतिक्रिया महत्वपूर्ण है और बहुत प्रशंसनीय है। :)

@spacecase एक इशारा के रूप में यह दिखाने के लिए कि आपकी राय मायने रखती है, स्टॉप-गैप उपाय के रूप में sigmavirus24/request-data-schemes देखें। आपको अपना खुद का Content-Type हेडर सेट करना होगा, लेकिन यह एक छोटी सी झुंझलाहट हो सकती है।

धन्यवाद @ sigmavirus24 , मैं इसे
मैं सराहना करता हूं कि आपने मुझे ठेस पहुंचाने का इरादा नहीं किया। मैं इसके बारे में बेहतर महसूस करता हूं और मैं आपके या प्रोजेक्ट के खिलाफ कुछ भी नहीं रखता हूं।

हाँ, ऐसा लगता है कि मैं कुछ लोगों के लिए क्रूर हो गया हूं, इसलिए मुझे लगता है कि मुझे इंटरनेट पर जो कुछ भी लिखा जाता है उसे परिष्कृत करने की आवश्यकता है। मैं इसे नहीं समझता और अन्य लोग मुझसे सहमत हैं, लेकिन मैं इस पर काम कर रहा हूं। मुझे लगता है कि मुझे यह महसूस करने के लिए पर्याप्त नमूना आकार की आवश्यकता है कि मेरे इरादे के बिना लोगों के लिए आक्रामक क्या है (इसके अलावा कुछ काम करने के तरीके को याद करके खुद को गधे बनाने के अलावा)।

मेरे पास पोस्ट करने के लिए एक फ़ाइल और कुछ कुंजी-मान हैं। तो ऐसे म्यूटिलपार्ट-फॉर्म अनुरोध भेजने का सही तरीका क्या है? मुझे आशा है आप मेरी मदद कर सकते हैं।

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)

प्रश्नों के लिए StackOverflow का उपयोग करें। हालांकि आपके प्रश्न का उत्तर देने के लिए, इस समस्या के समाधान के लिए एक परियोजना चल रही है sigmavirus24/requests-toolbelt

यह भी ध्यान दें कि मैंने इस प्रश्न का उत्तर StackOverflow पर पहले दिया है, जैसा कि आप यहाँ देख सकते हैं।

मेरे पास फ़ाइल के बिना मल्टीपार्ट पोस्ट जेनरेट करने का एक ही मुद्दा है। फिलहाल, यदि आप requests.post(url, data=data_dict) या requests.post(url, data=data_dict, files={}) करते हैं तो इससे कोई फर्क नहीं पड़ता। लेकिन, चूंकि files कीवर्ड डिफ़ॉल्ट रूप से None , multipart/form-data जब files={} निर्दिष्ट किया जाता है, और application/x-www-form-urlencoded जब नहीं।

क्या मुझसे कुछ छूटा?

@jwoillez क्या आपने पोस्ट किए गए स्टैक ओवरफ़्लो लिंक का पालन किया था?

मुझे ऐसा लगता है, लेकिन वहां पर आपका जवाब एक फाइल के साथ मल्टीपार्ट पोस्ट से संबंधित है। मैं मूल मुद्दे पर वापस गया: बिना किसी फ़ाइल के पोस्ट को मल्टीपार्ट करें।

फ़ाइल ऑब्जेक्ट को एक स्ट्रिंग होने की अनुमति है। =) इससे आपको वह जानकारी मिलनी चाहिए जो आप चाहते थे।

लेकिन अगर मैं आपके सुझाव का पालन करता हूं, तो क्या मैं इस तरह से कुछ खत्म नहीं करूंगा:

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--

आप टपल के सामग्री अनुभाग में एक खाली स्ट्रिंग का उपयोग करके एक खाली सामग्री प्रदान कर सकते हैं। आप एक शाब्दिक खाली फ़ाइल नाम प्रदान नहीं कर सकते हैं, लेकिन एक गैर-मौजूद फ़ाइल नाम को ठीक उसी तरह से व्यवहार किया जाना चाहिए।

मुझे कभी-कभी विभिन्न विषम कारणों से ऐसा करने की आवश्यकता होती है।
मैं इस उपयोग के मामले में एपीआई को मजबूत करने के इच्छुक किसी भी व्यक्ति के लिए इस दृष्टिकोण का सुझाव दूंगा:

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)

या आप टूलबेल्ट का उपयोग कर सकते हैं और हैक्स का सहारा नहीं ले सकते।