HTTP पोस्ट

Question

का उपयोग करते समय यूआरएल में पैराम पास करना क्या POST विधि का उपयोग करते समय यूआरएल (प्रश्न चिह्न के बाद) के माध्यम से वेब पेज पर पैरामीटर पास करने की अनुमति है? मुझे पता है कि यह काम करता है (ज्यादातर समय, वैसे भी) क्योंकि मेरी कंपनी का वेबपैप अक्सर ऐसा करता है, लेकिन मुझे नहीं पता कि यह वास्तव में मानक में समर्थित है या यदि मैं इस व्यवहार पर भरोसा कर सकता हूं। मैं एक एसओएपी अनुरोध हैंडलर को लागू करने पर विचार कर रहा हूं जो प्रश्न चिह्न के बाद पैरामीटर का उपयोग करता है यह इंगित करने के लिए कि यह एक एसओएपी अनुरोध है और सामान्य HTTP अनुरोध नहीं है। इसका कारण यह है कि वेबएप एक आईआईएस एक्सटेंशन है, इसलिए सब कुछ एक ही यूआरएल (उदा: example.com/myisapi.dll?command) के माध्यम से पहुंचा जा सकता है, इसलिए एसओएपी अनुरोध संसाधित होने के लिए, मुझे यह निर्दिष्ट करना होगा कि " आदेश "पैरामीटर। एसओएपी के लिए एक सामान्य आदेश होगा, प्रत्येक एसओएपी कार्रवाई के लिए एक विशिष्ट कमांड नहीं - उनको एसओएपी अनुरोध में ही निर्दिष्ट किया जाएगा।

असल में, मैं वेबपैप को HTTP अनुरोध को संभालने के द्वारा अपाचे एक्सिस 2/सी लाइब्रेरी को अपने वेबपैप में एकीकृत करने की कोशिश कर रहा हूं और फिर एसओएपी अनुरोध होने पर इनकमिंग एसओएपी एक्सएमएल को एक्सिस 2 में पास करने के लिए पास कर रहा हूं। सहजता से, मुझे कोई कारण नहीं दिख रहा है कि यह क्यों काम नहीं करेगा, क्योंकि जिस यूआरएल को आप पोस्ट कर रहे हैं वह सिर्फ एक मनमाना यूआरएल है, जहां तक ​​सभी विभिन्न घटकों का संबंध है ... यह वह सर्वर है जो विशेष अर्थ देता है प्रश्न चिह्न के बाद भागों।

किसी भी मदद/अंतर्दृष्टि के लिए धन्यवाद जो आप प्रदान कर सकते हैं।

Answer 1

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

एक http POST जो http GET से अलग है वेबसर्वर को एक अलग लॉजिकल कॉल है, लेकिन यह अभी भी एक यूआरआई को परिभाषित करता है जिसे पोस्ट को संसाधित करना चाहिए।एक अच्छा वेबसर्वर (अपाचे एक होने वाला) फिर से यूआरआई को जो भी मॉड्यूल या ऐपसर्वर के भीतर चल रहा है, उसके लिए उपलब्ध कराएगा, इसके बाद पोस्ट हेडर में भेजे गए चर उपलब्ध कराएंगे।

उस बिंदु पर जहां आपका आवेदन पोस्ट के दौरान अपाचे से नियंत्रण लेता है, आपको जीईटी और पोस्ट वैरिएबल दोनों तक पहुंच प्राप्त करनी चाहिए और आप जो भी नियंत्रण तर्क चाहते हैं, उसे करने में सक्षम होना चाहिए, जिसमें HTML के बजाय SOAP प्रोटोकॉल का उत्तर देना शामिल है।

Answer 2

यदि आप पूछ रहे हैं कि एक ही HTTP अनुरोध में जीईटी और पोस्ट दोनों के माध्यम से पैरामीटर भेजना संभव है, तो उत्तर "हाँ" है। यह मानक कार्यक्षमता है जिसका उपयोग विश्वसनीय रूप से AFAIK किया जा सकता है।

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

तो आपके मामले में, आप असली एसओएपी अनुरोध रखने के लिए POST का उपयोग कर सकते हैं लेकिन यह जांच कर सकते हैं कि यह GET में पारित पैरामीटर (या यूआरएल के माध्यम से दूसरे शब्दों में) के आधार पर एसओएपी अनुरोध है या नहीं।

Answer 3

मैंने ब्रिटेन में 3 (मोबाइल नेटवर्क ऑपरेटर) के साथ एक वेब एप्लिकेशन तैनात किया। यह मूल रूप से POST पैरामीटर का उपयोग करता था, लेकिन 3 गेटवे ने उन्हें छीन लिया (और एक्स-हेडर भी!)। तो सावधान रहें ...

Answer 4

स्वीकार्य? निश्चित रूप से, यह करने योग्य है, लेकिन मैं इस बात की ओर झुका रहा हूं कि दोहरी तरीकों का सुझाव देना आवश्यक नहीं है, या समर्थित होना चाहिए। RFC2616 HTTP/1.1 को परिभाषित करता है, और मैं तर्क दूंगा कि प्रति अनुरोध केवल एक विधि सुझाता है। (आदि पोस्ट/मिलता है, ...)

$ telnet localhost 80 
POST /page.html?id=5 HTTP/1.1 
host: localhost 

के रूप में आप देख सकते हैं, आप केवल एक विधि का उपयोग कर सकते हैं,: अगर आप ग्राहक की ओर से अपने ठेठ HTTP लेन-देन के बारे में सोचते हैं, तो आप के रूप में अच्छी सीमा देख सकते हैं हालांकि विभिन्न भाषाओं के संचालन की प्रकृति के कारण, वे क्वेरी स्ट्रिंग चुन सकते हैं, और इसे जीईटी वैरिएबल को असाइन कर सकते हैं। आखिरकार, यह एक POST अनुरोध है, और एक प्राप्त नहीं है।

इसलिए मूल रूप से, हाँ यह कार्यक्षमता मौजूद है, क्या इसका इरादा है? मैं कहूंगा नहीं।

Answer 5

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

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

विशिष्ट वेब ढांचे में "अनुरोध चर" की धारणा हो सकती है - चाहे वे एक खोज भाग और अनुरोध निकाय दोनों से इन चरों को आकर्षित करेंगे, आपको उत्पाद प्रलेखन में पता लगाना होगा।