HTTP पोस्ट अनुरोध में पैरामीटर कैसे भेजे जाते हैं?




post parameters (6)

एक HTTP GET अनुरोध में, पैरामीटर क्वेरी स्ट्रिंग के रूप में भेजे जाते हैं:

http://example.com/page?parameter=value&also=another

HTTP पोस्ट अनुरोध में, पैरामीटर यूआरआई के साथ नहीं भेजे जाते हैं।

मूल्य कहां हैं? अनुरोध हेडर में? अनुरोध निकाय में? वो कैसा दिखता है?


संक्षिप्त उत्तर: POST अनुरोधों में, अनुरोध के "बॉडी" में मूल्य भेजे जाते हैं। वेब-फॉर्म के साथ उन्हें मीडिया प्रकार के application/x-www-form-urlencoded या multipart/form-data साथ भेजा जाता है। वेब-अनुरोधों को संभालने के लिए डिज़ाइन की गई प्रोग्रामिंग भाषाएं या ढांचे आमतौर पर ऐसे अनुरोधों के साथ "द राइट थिंग ™" करते हैं और आपको आसानी से डीकोड किए गए मानों (जैसे $_REQUEST या PHP में $_POST , या cgi.FieldStorage() , flask.request.form में flask.request.form )।

अब चलो थोड़ा सा खोदना, जो अंतर को समझने में मदद कर सकता है;)

GET और POST अनुरोधों के बीच अंतर काफी हद तक अर्थपूर्ण है। वे अलग-अलग "इस्तेमाल" भी होते हैं, जो कि मूल्यों को पारित करने में अंतर बताते हैं।

प्राप्त करें ( प्रासंगिक आरएफसी अनुभाग )

GET अनुरोध निष्पादित करते समय, आप सर्वर को एक या संस्थाओं के समूह से पूछते हैं। क्लाइंट को परिणाम फ़िल्टर करने की अनुमति देने के लिए, यह यूआरएल की तथाकथित "क्वेरी स्ट्रिंग" का उपयोग कर सकता है। क्वेरी स्ट्रिंग के बाद हिस्सा है ? । यह यूआरआई वाक्यविन्यास का हिस्सा है।

इसलिए, आपके आवेदन कोड (जिस भाग को अनुरोध प्राप्त होता है) के दृष्टिकोण से, आपको इन मानों तक पहुंच प्राप्त करने के लिए यूआरआई क्वेरी भाग का निरीक्षण करना होगा।

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

पोस्ट ( प्रासंगिक आरएफसी अनुभाग )

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

POST थोड़ा और जटिल है (और रास्ता अधिक लचीला):

POST अनुरोध प्राप्त करते समय, आपको हमेशा "पेलोड", या HTTP शर्तों में: एक संदेश निकाय की अपेक्षा करनी चाहिए। संदेश शरीर स्वयं में बेकार है, क्योंकि कोई मानक नहीं है (जहां तक ​​मैं कह सकता हूं। शायद आवेदन / ऑक्टेट-स्ट्रीम?) प्रारूप। शरीर प्रारूप को Content-Type शीर्षलेख द्वारा परिभाषित किया गया है। method="POST" साथ एक HTML FORM तत्व का उपयोग करते समय, यह आमतौर पर application/x-www-form-urlencoded । यदि आप फ़ाइल अपलोड का उपयोग करते हैं तो एक और बहुत आम प्रकार multipart/form-data । लेकिन यह कुछ भी हो सकता है , text/plain , application/json या यहां तक ​​कि कस्टम application/octet-stream

किसी भी मामले में, यदि एक Content-Type अनुरोध के साथ एक POST अनुरोध किया जाता है जिसे एप्लिकेशन द्वारा नियंत्रित नहीं किया जा सकता है, तो उसे 415 स्थिति-कोड वापस करना चाहिए।

अधिकांश प्रोग्रामिंग भाषाएं (और / या वेब-फ्रेमवर्क) संदेश निकाय को सबसे सामान्य प्रकारों से / एन्कोड करने का तरीका प्रदान करती हैं (जैसे application/x-www-form-urlencoded , multipart/form-data या application/json ) । तो यह आसान है। कस्टम प्रकारों को संभावित रूप से थोड़ा अधिक काम की आवश्यकता होती है।

एक मानक HTML फॉर्म एन्कोडेड दस्तावेज़ का उपयोग उदाहरण के रूप में, अनुप्रयोग को निम्न चरणों का पालन करना चाहिए:

  1. Content-Type फ़ील्ड पढ़ें
  2. यदि मान समर्थित मीडिया-प्रकारों में से एक नहीं है, तो 415 स्थिति कोड के साथ प्रतिक्रिया दें
  3. अन्यथा, संदेश निकाय से मूल्यों को डीकोड करें।

फिर, अन्य लोकप्रिय भाषाओं के लिए PHP, या वेब-फ्रेमवर्क जैसी भाषाएं शायद आपके लिए इसे संभालेंगी। इसका अपवाद 415 त्रुटि है। कोई ढांचा भविष्यवाणी नहीं कर सकता कि कौन सा सामग्री-प्रकार आपके एप्लिकेशन का समर्थन करने और / या समर्थन करने के लिए चुनता है। यह आप पर निर्भर करता है।

पुट ( प्रासंगिक आरएफसी अनुभाग )

एक PUT अनुरोध एक POST अनुरोध के रूप में ठीक उसी तरह से संभाला जाता है। बड़ा अंतर यह है कि एक POST अनुरोध सर्वर को यह तय करने देता है कि कैसे (और यदि बिल्कुल) एक नया संसाधन बनाते हैं। ऐतिहासिक रूप से (अब अप्रचलित आरएफसी 2616 से यह यूआरआई के "अधीनस्थ" (बच्चे) के रूप में एक नया संसाधन बनाना था जहां अनुरोध भेजा गया था)।

इसके विपरीत एक PUT अनुरोध को उस यूआरआई में और वास्तव में उस सामग्री के साथ संसाधन को "जमा" करना होता है। न आधिक न कम। विचार यह है कि ग्राहक "पटिंग" से पहले पूरा संसाधन तैयार करने के लिए ज़िम्मेदार है। सर्वर को इसे दिए गए यूआरएल पर स्वीकार करना चाहिए।

नतीजतन, एक मौजूदा अनुरोध को प्रतिस्थापित करने के लिए आमतौर पर एक POST अनुरोध का उपयोग नहीं किया जाता है। एक PUT अनुरोध दोनों बना और प्रतिस्थापित कर सकते हैं।

पक्षीय लेख

" पथ पैरामीटर " भी हैं जिनका उपयोग दूरस्थ डेटा को अतिरिक्त डेटा भेजने के लिए किया जा सकता है, लेकिन वे बहुत असामान्य हैं, कि मैं यहां बहुत अधिक जानकारी नहीं दूंगा। लेकिन, संदर्भ के लिए, यहां आरएफसी का एक अंश है:

पदानुक्रमित पथों में डॉट-सेगमेंट के अलावा, एक पथ खंड जेनेरिक वाक्यविन्यास द्वारा अपारदर्शी माना जाता है। यूआरआई उत्पादक अनुप्रयोग प्रायः एक सेगमेंट में अनुमत आरक्षित पात्रों का उपयोग योजना-विशिष्ट या अव्यवस्था-हैंडलर-विशिष्ट उप-संयोजकों को सीमित करने के लिए करते हैं। उदाहरण के लिए, अर्धविराम (";") और बराबर ("=") आरक्षित वर्ण अक्सर उस सेगमेंट पर लागू पैरामीटर और पैरामीटर मानों को सीमित करने के लिए उपयोग किए जाते हैं। अल्पविराम (",") आरक्षित चरित्र अक्सर इसी तरह के उद्देश्यों के लिए उपयोग किया जाता है। उदाहरण के लिए, एक यूआरआई निर्माता "नाम" के संस्करण 1.1 के संदर्भ को इंगित करने के लिए "नाम; v = 1.1" जैसे सेगमेंट का उपयोग कर सकता है, जबकि दूसरा इसे इंगित करने के लिए "नाम, 1.1" जैसे सेगमेंट का उपयोग कर सकता है। पैरामीटर प्रकार योजना-विशिष्ट अर्थशास्त्र द्वारा परिभाषित किया जा सकता है, लेकिन ज्यादातर मामलों में पैरामीटर का सिंटैक्स यूआरआई डीरफ्रेंसिंग एल्गोरिदम के कार्यान्वयन के लिए विशिष्ट है।


आप सीधे ब्राउज़र यूआरएल बार पर टाइप नहीं कर सकते हैं।

उदाहरण के लिए आप लाइव HTTP हेडर के साथ इंटरनेट पर POST डेटा कैसे भेज सकते हैं। परिणाम ऐसा कुछ होगा

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

यह कहां कहा गया है

Content-Length: 30
    username=zurfyx&pass=password

पोस्ट मूल्य होंगे।


HTTP POST में फॉर्म मान अनुरोध निकाय में भेजे गए हैं, क्वेरीस्ट्रिंग के समान प्रारूप में।

अधिक जानकारी के लिए, spec देखें।


मान निकाय में निर्दिष्ट होते हैं, प्रारूप में सामग्री प्रकार निर्दिष्ट करता है।

आम तौर पर सामग्री प्रकार application/x-www-form-urlencoded , इसलिए अनुरोध निकाय क्वेरी स्ट्रिंग के समान प्रारूप का उपयोग करता है:

parameter=value&also=another

जब आप फॉर्म में फ़ाइल अपलोड का उपयोग करते हैं, तो आप इसके बजाय multipart/form-data एन्कोडिंग का उपयोग करते हैं, जिसमें एक अलग प्रारूप होता है। यह अधिक जटिल है, लेकिन आपको आमतौर पर इसकी देखभाल करने की आवश्यकता नहीं होती है, इसलिए मैं एक उदाहरण नहीं दिखाऊंगा, लेकिन यह जानना अच्छा होगा कि यह मौजूद है।


कुछ वेब सर्विसेज के लिए आपको अनुरोध डेटा और मेटाडेटा अलग से रखने की आवश्यकता होती है। उदाहरण के लिए एक दूरस्थ फ़ंक्शन उम्मीद कर सकता है कि हस्ताक्षरित मेटाडेटा स्ट्रिंग को यूआरआई में शामिल किया गया है, जबकि डेटा को HTTP-body में पोस्ट किया गया है।

POST अनुरोध अर्थात् इस तरह दिख सकता है:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

यह दृष्टिकोण तर्कसंगत रूप से क्वेरी-स्ट्रिंग और बॉडी-पोस्ट को एक Content-Type का उपयोग करके जोड़ता है जो वेब-सर्वर के लिए "पार्सिंग-निर्देश" है।

कृपया ध्यान दें: HTTP / 1.1 बाईं ओर #32 (स्पेस) और दाईं ओर #10 (लाइन फीड) के साथ लपेटा गया है।


POST अनुरोध में डिफ़ॉल्ट मीडिया प्रकार application/x-www-form-urlencoded । यह एन्कोडिंग कुंजी-मूल्य जोड़े के लिए एक प्रारूप है। चाबियाँ डुप्लिकेट हो सकती हैं। प्रत्येक कुंजी-मूल्य जोड़ी को एक वर्ण से अलग किया जाता है, और प्रत्येक कुंजी को उसके मान से एक = वर्ण से अलग किया जाता है।

उदाहरण के लिए:

Name: John Smith
Grade: 19

एन्कोडेड के रूप में है:

Name=John+Smith&Grade=19

यह HTTP शीर्षलेख के बाद अनुरोध निकाय में रखा गया है।





uri