क्या URL में पैरामीटर और <form method = "get"> के बीच कोई अंतर है?

Question

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

चर्चा के लिए, मान लें कि निम्नलिखित वेब एप्लिकेशन: उपयोगकर्ता एक (संभावित रूप से सैकड़ों) एक्स, वाई निर्देशांक की एक श्रृंखला इनपुट कर सकता है। सर्वर उन्हें एक चार्ट में प्लॉट करता है, जिसे एक छवि के रूप में वापस किया जाता है।

यह idempotent operation का स्पष्ट रूप से एक उदाहरण है, इसलिए HTTP spec के अनुसार, इसे जीईटी ऑपरेशन के रूप में लागू करने की अनुशंसा की जाती है। हालांकि, आप सभी पैरामीटर के साथ एक यूआरएल नहीं बना सकते हैं, क्योंकि यह बहुत लंबा होगा। क्या < फॉर्म विधि = "प्राप्त करें" > उस पैरामीटर को संभाल सकता है?

मैंने यह भी सुना है कि < फॉर्म विधि = "प्राप्त करें" > यूआरएल में पैरामीटर रखने के बराबर है? अब, क्या यह कुछ ब्राउज़रों या पूरे HTTP प्रोटोकॉल के लिए सच है? क्या अनुरोध के लिए अधिकतम लंबाई है?

Answer 1

HTTP spec सीमाएं सेट नहीं करता है, लेकिन ब्राउज़र और सर्वर करते हैं। विशिष्टताओं के लिए here देखें।

यदि विधि किसी फ़ॉर्म के लिए GET को सेट करने के लिए सेट की गई है, तो ब्राउज़र एक लंबा यूआरएल बनाएगा, इसलिए उपरोक्त सीमाएं लागू होती हैं।

Answer 2

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

Answer 3

मैंने यह भी सुना है कि < फॉर्म विधि = "प्राप्त करें" > यूआरएल में पैरामीटर रखने के बराबर है?

यही सच है, यहाँ इसी RFC section

है वहाँ एक अनुरोध करने के लिए अधिकतम लंबाई है?

spec कहता है "HTTP प्रोटोकॉल यूआरआई की लंबाई पर कोई प्राथमिक सीमा नहीं रखता है।"

हालांकि इंटरनेट एक्सप्लोरर 6 की 2,083 वर्णों की सीमा है। अन्य ब्राउज़र अधिक वर्णों की अनुमति देते हैं लेकिन यदि आप उस मार्ग पर जाते हैं तो आपको मूल रूप से यानी

Answer 4

फ़ॉर्म विधि = सभी फॉर्म के इनपुट को URL में डाल दिया जाएगा।

यह सच है कि ब्राउज़र के पास URL के लिए अधिकतम लंबाई है। यह ब्राउज़र से ब्राउज़र में बदलता है, और निश्चित रूप से ब्राउज़र संस्करण से ब्राउज़र संस्करण में बदल जाता है।

यदि आप कर सकते हैं, तो मैं आपको अपने फॉर्म के लिए POST का उपयोग करने की सलाह दूंगा।

HTH

Answer 5

प्राप्त और यूआरएल? नाम = मूल्य & ..., एक ही बात कर रहे हैं के रूप में ब्राउज़र केवल अनुरोध भेजने से पहले एक यूआरएल के लिए एक GET रूप बदल देता है।

यूआरएल की अधिकतम लंबाई ब्राउज़र और सर्वर स्तर पर निर्धारित की जाती है, इसलिए किसी दिए गए ब्राउज़र/सर्वर के लिए, यह दोनों में से छोटा है।

This post यूआरएल

Answer 6

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

यह आपको अनुरोधित छवियों को कैश करने में भी मदद कर सकता है ताकि जब भी उपयोगकर्ता किसी विशेष चार्ट को फिर से देखना चाहता है तो उन्हें पुन: उत्पन्न करने के काम से गुजरना पड़ेगा।

Answer 7

नहीं, कोई सर्वर किसी URL में पैरामीटर डालने और GET विधि के साथ FORM का उपयोग करने के बीच कोई अंतर नहीं देख सकता है। इसलिए, यदि पैरामीटर वाले दिए गए यूआरएल बहुत लंबे होंगे, तो जीईटी विधि के साथ एक फॉर्म का उपयोग करने से मदद नहीं मिलेगी।

पोस्ट या जीईटी मुख्य रूप से उनके अर्थशास्त्र के लिए चुना जाना चाहिए। प्राप्त करें "सुरक्षित" कार्यों के लिए है। यही है, उपयोगकर्ताओं को जीईटी अनुरोध द्वारा किए गए एक ऑपरेशन के लिए उत्तरदायी नहीं ठहराया जाना चाहिए। POST विधि का उपयोग उन परिचालनों के लिए किया जाता है जिनके लिए उपयोगकर्ता को जिम्मेदार ठहराया जाना है।

यह बहुत निराशाजनक है, उदाहरण के लिए, जब कोई खोज सुविधा पोस्ट का उपयोग करती है। उपयोगकर्ता किसी भी महत्वपूर्ण सिस्टम स्थिति को बदलने के लिए एक साधारण क्वेरी की अपेक्षा नहीं करता है — वे "सुरक्षित" ऑपरेशन होने की उम्मीद करते हैं।

दूसरी ओर, कई भेद्यताएं मौजूद हैं क्योंकि असुरक्षित संचालन जीईटी अनुरोधों के साथ-साथ पोस्ट के माध्यम से सुलभ हैं। यह एक्सएसआरएफ जैसी कमजोरियों में योगदान देता है जहां एक हमलावर को वैध साइट पर किसी IMG टैग में दुर्भावनापूर्ण "src" URL प्राप्त करने की आवश्यकता होती है।

आपके उपयोग के मामले में, अजाक्स वास्तव में एक उपयुक्त समाधान हो सकता है। आप चयनित प्रत्येक बिंदु के लिए एक जीईटी अनुरोध कर सकते हैं, उन्हें सर्वर पर एक सत्र में संग्रहीत कर सकते हैं। जब उपयोगकर्ता अंक दर्ज करना समाप्त कर देता है, तो अंतिम GET अनुरोध समाप्त उत्पाद को पुनर्प्राप्त करता है।

Answer 8

HTTP specification को यूआरआई में जीईटी अनुरोध के मानकों को रखने की आवश्यकता नहीं है। जीओटी अनुरोध में संदेश-बॉडी भेजने के लिए कानूनी होगा जैसे POST do का उपयोग कर फ़ॉर्म।

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

यदि आप चार्ट एपीआई डिज़ाइन करने की योजना बना रहे हैं, तो आप Google पर एक नज़र डालना चाहेंगे। वे पहले से ही जनता के लिए एक बहुत अच्छा प्रस्ताव देते हैं। यहां तक ​​कि अगर यह सीखने के लिए केवल यूआरआई पैराम में जितनी अधिक जानकारी पैक करना है, तो यह एक लायक है।