यूआरएल संरचना: अपर केस वी.एस. लोअर केस

Question

मेरे मन जब मैं कुछ वेबसाइटों के माध्यम से जा रहा था में

बस ट्रिगर वे अपर केस और http://www.domain.com/Home/Article

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

Answer 1

डोमेन भाग केस संवेदनशील नहीं है। GoOgLe.CoM काम करता है। आप अपनी पसंद के अनुसार अपरकेस जोड़ सकते हैं, लेकिन आम तौर पर ऐसा करने का कोई कारण नहीं है और जैसा कि नीचे दी गई टिप्पणियों में बताया गया है, आपकी एसईओ रैंकिंग को नुकसान पहुंचा सकता है।

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

क्वेरी स्ट्रिंग भाग सर्वर के रूप में उपलब्ध है। आप आसानी से मिश्रित मामले का उपयोग कर सकते हैं, या केस को छोड़ सकते हैं (toLowerCase(...))। इसका मतलब यह भी है कि बेस 64-एन्कोडेड कुंजियों का उपयोग काम करेगा। आप उपयोगकर्ताओं को सही तरीके से टाइप करने की उम्मीद नहीं कर सकते हैं, हालांकि।

हैश भाग (जिसे "खंड पहचानकर्ता" कहा जाता है) केवल क्लाइंट कोड के लिए उपलब्ध है, सर्वर पर नहीं। जावास्क्रिप्ट उन मामलों के बीच अंतर कर सकता है जैसा इसे पसंद है, और ब्राउज़र भी करता है। url#a आईडी a के साथ तत्व पर स्क्रॉल करेगा, लेकिन url#A नहीं होगा।

Answer 2

मुझे पता है कि आपने तकनीकी कारणों से पूछा है लेकिन यह यूएक्स परिप्रेक्ष्य से इस पर विचार करने योग्य भी है।

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

यदि आपका सर्वर केस संवेदनशील है और आप मिश्रित केस यूआरएल का उपयोग कर रहे हैं तो आप यूआरएल को गलत टाइप करने के लिए उपयोगकर्ता को अधिक गुंजाइश दे रहे हैं। इसके अलावा, कहें कि आपके पास URL www.example.com/ संपर्क है। यदि उपयोगकर्ता इसे अनदेखा करता है और गलत केस का उपयोग करता है तो वे आपकी सामग्री तक कभी नहीं पहुंच सकते हैं, तो ऊपरी और निचले मामले "सी" (विशेष रूप से यदि इसे हाथ लेखन में कॉपी किया गया है) को भ्रमित करना आसान है।

यह सब ध्यान में रखते हुए www.example.com/News/Articles/FreeIceCreamForAll पर विचार करें। कीबोर्ड पर जो बहुत मुश्किल नहीं है लेकिन इसे मोबाइल डिवाइस पर विचार करें, यह इनपुट के लिए बहुत ही मुश्किल होगा।

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

निष्कर्ष निकालना; यूआरएल कम मामला रखें।इस मुद्दे का

Answer 3

के संबंध में सुरक्षा पहलुओं:

वास्तव में अपरकेस और लोअरकेस के मिश्रण का इस्तेमाल करने के लिए एक अच्छा सुरक्षा पर्याप्त कारण मौजूद है।

इसका हमलावरों को भ्रमित करने और अवरुद्ध करने का असर पड़ता है!

मानव वार्तालाप में मनुष्यों को आसानी से अपरकेस और लोअरकेस उपयोग के साथ भ्रमित हो जाता है।

अगर वे अपरकेस और लोअरकेस होते हैं तो मानव स्पष्टता के साथ "पहचानकर्ता या पासवर्ड या यूआरएल" के शब्द को "बोल" नहीं सकते हैं।

यह साइट उप-भागों पर डेटा या पासवर्ड पर सुरक्षा के साथ मदद करता है जो साइट या उनके डेटा के "स्वचालित पहुंच" हिस्से के लॉक-इन या सुरक्षित उप-हिस्से के हिस्से के रूप में प्रदान किए जाते हैं।

यह JSON का उपयोग न करने जैसा है।

जेएसओएन "मानव-पठनीय पाठ" है और इसलिए जेएसओएन सभी हमलावरों (सरकारों सहित, Google .. जो आपके विचारों और डेटा चुरा लेता है) दे रहा है ... लगभग हर चीज को डेटा के बारे में जानने की जरूरत है ... निजी bespoke बहुत तेज़ "बाइनरी प्रोटोकॉल" का उपयोग करके उन्हें भ्रमित करने के लिए और अधिक सुरक्षित है - जो आपके अपने "अज्ञात डेटा संरचनाओं" का उपयोग करते हैं ... लेकिन केवल देखें, क्योंकि वास्तव में स्वयं या अपनी खुद की विकास टीम को भ्रमित करना संभव है।

आपकी सभी सुरक्षा परतों और प्रोटोकॉल को भ्रम से बचने के लिए "अच्छी तरह से प्रबंधित" होना चाहिए।

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

बस "नमक और हैश" सबकुछ - साथ ही कुछ अतिरिक्त अतिरिक्त bespoke सुरक्षा भी जोड़ें - यह सिर्फ कॉमन्सेंस है!

निष्कर्ष: सभी उपर्युक्त उत्तर बहुत स्पष्ट और सही हैं - लेकिन आप संभावित हमलावरों को भ्रमित करने के लिए भी वही ज्ञान का आनंद ले सकते हैं।

Answer 4

मैं इस पर सभी की स्थापना की बुद्धि से असहमत करने के लिए जा रहा हूँ, तो मैं शायद downvoted कर देंगे, लेकिन:

आप अनुप्रेषित सभी मिश्रित मामले आपके ठीक से मामलों यूआरएल को यूआरएल है, यह हल करती है सब समस्याओं का उल्लेख किया। इसलिए ऐसा लगता है कि यह तर्क परंपरा और वरीयता से आ रहा है। यूआरएल का बिंदु एक पृष्ठ के उपयोगकर्ता के अनुकूल प्रतिनिधित्व होना है, और यदि आपका यूआरएल ऊपरी मामले के साथ मित्रवत है, तो इसका उपयोग क्यों न करें? की तुलना करें:

moviesforyoutowatch.com/batman-vii-the-dark-knight-whatevers MoviesForYouToWatch.com/Batman-VII-The-Dark-Knight-Whatevers

मैं मिश्रित केस संस्करण बेहतर लगता है उद्देश्य के लिए। यदि कोई तकनीकी कारण है जिसे कम-मामले की तुलना और पुनर्निर्देशन के साथ हल नहीं किया जा सकता है, तो कृपया इसे साझा करें।