मैं वर्तमान में एक एपीआई प्रोग्रामिंग कर रहा हूं जो पैरामीटर प्राप्त करने के माध्यम से डेटा पास कर लेता है, इसलिए मैं सोच रहा था कि यूआरएल की कुल लंबाई या पैरामीटर मान सर्वोत्तम अभ्यास या प्रोटोकॉल द्वारा सीमित है या नहीं।अनुरोध प्राप्त करने में पैरामीटर कितने समय तक हो सकते हैं?
http://www.boutell.com/newfaq/misc/urllength.html
असल में, 2K सबसे आप एक क्रॉस-ब्राउज़र फैशन में पर भरोसा कर सकते है, लेकिन अगर आप IE 8 और नीचे के लिए समर्थन छोड़, आप 64K पसंद करने के लिए मिल सकता है।
हालांकि मुझे लगता है कि मुझे यह जानने के लिए आपकी आवश्यकता पर सवाल उठाने की ज़रूरत है, कुछ भी कहने पर .. 100 अक्षरों को जीईटी के बजाय POST अनुरोध के माध्यम से सबसे अच्छा संभाला जाएगा।
कोई आधिकारिक सीमा नहीं है, इसलिए यह विभिन्न ब्राउज़रों की दया पर है।
बस विहित संदर्भ ... HTTP 1.1 RFC से जोड़ने के लिए, खंड 3.2.1 में:
HTTP प्रोटोकॉल यूआरआई की लंबाई पर किसी भी एक प्रायोरी सीमा जगह नहीं है। सर्वर सेवा के किसी भी संसाधन के यूआरआई को संभालने में सक्षम होना चाहिए, और अगर वे जीईटी-आधारित फॉर्म प्रदान करते हैं जो ऐसे यूआरआई उत्पन्न कर सकते हैं तो यूआरआई को बिना किसी लंबाई के यूआरआई को संभालने में सक्षम होना चाहिए। एक सर्वर सर्वर को संभाल सकता है (धारा 10.4.15 देखें) की तुलना में एक URI लंबा लंबा 414 (अनुरोध-यूआरआई बहुत लंबा) स्थिति लौटा सकता है (अनुभाग 10.4.15 देखें)।
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
मैं अपने लिंक के हवाले कर रहा हूँ त्वरित उत्तर के लिए "अत्यंत लंबे URL को आम तौर पर एक गलती कर रहे हैं। यूआरएल 2,000 से अधिक पात्रों सबसे लोकप्रिय वेब ब्राउज़र में काम करेंगे नहीं।", धन्यवाद! –
मेरी राय, लेकिन लंबे यूआरएल कोड गंध का संकेत हैं। खुद में कोई समस्या नहीं है, लेकिन अक्सर एक और मौलिक समस्या का एक लक्षण है। – stand
हालांकि, यदि आप रीस्टफुल होने का प्रयास कर रहे हैं, तो POST को निष्पादित नहीं किया जाना चाहिए यदि यह सर्वर पर संसाधन नहीं बदलता है। –