URL केस-संवेदी क्यों हैं?

54

मेरा प्रश्न: जब URL पहले डिज़ाइन किए गए थे, तो केस-सेंसिटिविटी को एक फीचर क्यों बनाया गया? मैं यह पूछता हूं क्योंकि यह मुझे लगता है (यानी, एक छंटनी) कि मामले-असंवेदनशीलता को अनावश्यक त्रुटियों को रोकने और पाठ के पहले से ही जटिल स्ट्रिंग को सरल बनाने के लिए प्राथमिकता दी जाएगी।

साथ ही, केस-संवेदी URL होने का एक वास्तविक उद्देश्य / लाभ है (जैसा कि उन अधिकांश URL का विरोध किया गया है जो एक ही पृष्ठ पर इंगित होते हैं, चाहे कोई भी कैपिटलाइज़ेशन क्यों न हो)?

उदाहरण के लिए विकिपीडिया, एक ऐसी वेबसाइट है जो अक्षर मामले के लिए संवेदनशील है (पहले चरित्र को छोड़कर):

https://en.wikipedia.org/wiki/St एक ck_Exchange DOA है।

url case-sensitive

— केली
स्रोत

11

आप स्पष्ट रूप से आईआईएस Windows पर नहीं चला

— जॉन कोंडे

53

मुझे लगता है कि itscrap.com, expertsexchange, और whorepresents.com यह पसंद करेंगे कि अधिक लोग केस-संवेदी नामों का उपयोग करें। अधिक जानकारी के लिए, boredpanda.com/worst-domain-names देखें ।

— एरिक टावर्स

22

URL तब डिज़ाइन किया गया था जब यूनिक्स सिस्टम पर दिए गए डायनासोर पृथ्वी पर घूमते थे, और यूनिक्स संवेदनशील है।

— थोरबजोरन रेव एंडरसन

11

विकिपीडिया विषय शीर्षक के लिए सही पूंजीकरण का उपयोग करने की कोशिश करता है और आम अंतर के लिए पुनर्निर्देश का उपयोग करता है। जैसे। html, htmऔर Htmlसभी पर पुनर्निर्देशित HTML। लेकिन महत्वपूर्ण रूप से, विषय के भारी होने के कारण, एक से अधिक पृष्ठ होना संभव है, जहां URL केवल केस से भिन्न होता है। उदाहरण के लिए: लेटेक्स और लेटेक्स

— MrWhite

7

@ edc65 लेकिन कोबी कहा गया है कि भागों यूआरएल (विशेष रूप से की पथ ) कर रहे हैं केस-संवेदी - हां, तो उस URL को केस-संवेदी नहीं है (एक पूरे के रूप)?

— 22

8

URL संवेदनशील क्यों नहीं होगा?

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

कई, कई अलग-अलग वेब सर्वर हैं जो जारी किए गए हैं। Microsoft ने IIS को विंडोज सर्वर ऑपरेटिंग सिस्टम (और अन्य, विंडोज एक्सपी प्रोफेशनल सहित) के साथ जारी किया है। यूनिक्स के पास नग्नेक्स और अपाचे जैसे हैवीवेट हैं, जो कि ओपनबीएसडी के आंतरिक httpd, या थेटपेड, या लाइटटैप जैसे छोटे प्रसाद का उल्लेख नहीं करते हैं। इसके अतिरिक्त, कई नेटवर्क-सक्षम डिवाइस वेब सर्वरों में बनाए गए हैं जिनका उपयोग डिवाइस को कॉन्फ़िगर करने के लिए किया जा सकता है, जिसमें नेटवर्क के लिए विशिष्ट उद्देश्यों के साथ डिवाइस शामिल हैं, जैसे राउटर (कई वाई-फाई एक्सेस प्वाइंट और डीएसएल मोडेम सहित) और प्रिंटर जैसे अन्य डिवाइस। यूपीएस (बैटरी समर्थित निर्बाध बिजली आपूर्ति इकाइयां) जिनमें नेटवर्क कनेक्टिविटी हो सकती है।

तो प्रश्न, "URL केस-संवेदी क्यों हैं?", पूछ रहा है, "वेब सर्वर URL को संवेदनशील होने के कारण क्यों मानते हैं?" और वास्तविक उत्तर यह है: वे सभी ऐसा नहीं करते हैं। कम से कम एक वेब सर्वर, जो काफी लोकप्रिय है, आमतौर पर संवेदनशील नहीं है। (वेब सर्वर IIS है।)

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

अब, उस पृष्ठभूमि के साथ, यहाँ कुछ विशिष्ट प्रश्नों के उत्तर दिए गए हैं:

जब URL पहली बार डिज़ाइन किए गए थे, तो केस-सेंसिटिविटी को एक फीचर क्यों बनाया गया?

क्यों नहीं? यदि सभी मानक वेब सर्वर केस-असंवेदनशील थे, तो यह इंगित करेगा कि वेब सर्वर मानक द्वारा निर्दिष्ट नियमों के एक सेट का पालन कर रहे थे। बस कोई नियम नहीं था जो कहता है कि मामले को नजरअंदाज करने की जरूरत है। कोई नियम नहीं होने का कारण यह है कि ऐसा नियम होने का कोई कारण नहीं था। अनावश्यक नियम बनाने की जहमत क्यों उठाते हैं?

मैं यह पूछता हूं क्योंकि यह मुझे लगता है (यानी, एक छंटनी) कि मामले-असंवेदनशीलता को अनावश्यक त्रुटियों को रोकने और पाठ के पहले से ही जटिल स्ट्रिंग को सरल बनाने के लिए प्राथमिकता दी जाएगी।

मशीनों को संसाधित करने के लिए URL डिज़ाइन किए गए थे। हालांकि एक व्यक्ति एक पूर्ण URL को एक पता बार में टाइप कर सकता है, जो कि इच्छित डिज़ाइन का एक प्रमुख हिस्सा नहीं था। इरादा डिजाइन यह है कि लोग हाइपरलिंक्स ("पर क्लिक करें") का पालन करेंगे। अगर औसत व्यक्ति ऐसा कर रहे हैं, तो वे वास्तव में परवाह नहीं करते हैं कि अदृश्य URL सरल है या जटिल है।

साथ ही, केस-संवेदी URL होने का एक वास्तविक उद्देश्य / लाभ है (जैसा कि उन अधिकांश URL का विरोध किया गया है जो एक ही पृष्ठ पर इंगित होते हैं, चाहे कोई भी कैपिटलाइज़ेशन क्यों न हो)?

विलियम हे के उत्तर के पांचवें क्रमांक में एक तकनीकी लाभ का उल्लेख किया गया है: वेब ब्राउज़र के लिए वेब सर्वर के लिए थोड़ी सी जानकारी भेजने के लिए URL एक प्रभावी तरीका हो सकता है, और कम प्रतिबंध होने पर अधिक जानकारी शामिल की जा सकती है, इसलिए केस सेंसिटिविटी प्रतिबंध से यह जानकारी कम हो जाएगी कि कितनी जानकारी शामिल की जा सकती है।

हालांकि, कई मामलों में, संवेदनशीलता के मामले में एक सुपर सम्मोहक लाभ नहीं है, जो इस तथ्य से साबित होता है कि आईआईएस आमतौर पर इसके साथ परेशान नहीं करता है।

सारांश में, सबसे सम्मोहक कारण उन लोगों के लिए बस सादगी की संभावना है, जिन्होंने वेब सर्वर सॉफ़्टवेयर डिज़ाइन किया है, विशेषकर यूनिक्स जैसे केस-सेंसिटिव प्लेटफ़ॉर्म पर। (HTTP कुछ ऐसा नहीं था जिसने यूनिक्स के मूल डिज़ाइन को प्रभावित किया, क्योंकि यूनिक्स HTTP से काफी पुराना है।)

— TOOGAM
स्रोत

"विभिन्न वेब ब्राउज़रों के बीच अलग-अलग व्यवहार का एक महत्वपूर्ण कारण शायद सादगी के मामले में उबलता है।" - मुझे लगता है कि यहां "वेब ब्राउजर" के बजाय "वेब सर्वर" का अर्थ है, और अन्य स्थानों पर?

— MrWhite

2

अपडेट किया गया। "ब्राउज़र" के हर मामले की समीक्षा की और कई प्रतिस्थापन किए। इसे इंगित करने के लिए धन्यवाद, ताकि कुछ गुणवत्ता में सुधार किया जा सके।

— TOOGAM

1

मुझे अपने प्रश्न के कई उत्कृष्ट उत्तर मिले हैं , ऐतिहासिक से तकनीकी तक। मैं अनाज के खिलाफ जाने और निचली श्रेणी के उत्तर को स्वीकार करने में संकोच कर रहा हूं, लेकिन @ TOOGAM का जवाब मेरे लिए सबसे अधिक उपयोगी था। यह उत्तर पूरी तरह से और व्यापक है, फिर भी यह एक सीधी, संवादी शैली में अवधारणा की व्याख्या करता है जिसे मैं समझ सकता हूं। और मुझे लगता है कि यह उत्तर अधिक गहराई से व्याख्या के लिए एक अच्छा परिचय है।

— काइल

74

URL केस-संवेदी नहीं हैं, केवल उनके कुछ भाग हैं।
उदाहरण के लिए, URL में कुछ भी संवेदनशील नहीं है https://google.com,

RFC 3986 के संदर्भ में - यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI): जेनेरिक सिंटैक्स

पहला, विकिपीडिया से , एक URL जैसा दिखता है:

 scheme:[//host[:port]][/]path[?query][#fragment]

(मैंने user:passwordहिस्सा हटा दिया है क्योंकि यह दिलचस्प नहीं है और शायद ही कभी इस्तेमाल किया जाता है)

scheme:

योजनाएँ असंवेदनशील हैं

host:

मेजबान उपसंपादक केस-असंवेदनशील है।

path:

पथ घटक में डेटा शामिल है ...

query:

क्वेरी घटक में गैर-पदानुक्रमित डेटा शामिल है ...

fragment:

अलग-अलग प्रकार के सबसेट, विचार या अन्य संदर्भों को निर्दिष्ट करने के लिए अलग-अलग मीडिया प्रकार, खंड पहचानकर्ता सिंटैक्स के भीतर या संरचनाओं पर अपने स्वयं के प्रतिबंधों को परिभाषित कर सकते हैं

तो, schemeऔर hostमामले असंवेदनशील हैं।
शेष URL केस-संवेदी है।

`path`केस-संवेदी क्यों है ?

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

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

स्थान - स्थान का एक विहित रूप है, और मामला असंवेदनशील है। क्यों? संभवतः इसलिए आप हजारों वेरिएंट खरीदने के बिना एक डोमेन नाम खरीद सकते हैं।
डेटा - डेटा का उपयोग लक्ष्य सर्वर द्वारा किया जाता है, और एप्लिकेशन इसका अर्थ चुन सकता है । डेटा केस को असंवेदनशील बनाने का कोई मतलब नहीं होगा। आवेदन में अधिक विकल्प होने चाहिए, और अटकल में मामले की असंवेदनशीलता को परिभाषित करने से ये विकल्प सीमित हो जाएंगे।
यह HTTPS के लिए भी एक उपयोगी अंतर है: डेटा एन्क्रिप्ट किया गया है , लेकिन होस्ट दिखाई दे रहा है।

क्या यह उपयोगी है?

केस-सेंसिटिविटी के कैशिंग और कैनोनिकल URL की बात करने पर इसके नुकसान होते हैं, लेकिन यह निश्चित रूप से उपयोगी है। कुछ उदाहरण:

बेस 64 , जिसका उपयोग डेटा यूआरआई में किया जाता है ।
साइटें यूआरएल में बेस 64 डेटा को एनकोड कर सकती हैं, उदाहरण के लिए: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AxxBB4nnngggggggfgqqggqqwqqwqqququ&hl=hi
URL शॉर्टकट केस संवेदनशीलता का उपयोग करते हैं: /a5Bसे भिन्न हो सकता है/a5b
जैसा कि आपने उल्लेख किया है, विकिपीडिया "एड्स" को "एड्स" से अलग कर सकता है।

— कोबी
स्रोत

1

"URL केस-संवेदी नहीं हैं।" / "बाकी URL केस-संवेदी है।" - यह एक विरोधाभास प्रतीत होगा?

— MrWhite

8

सही मायने में, योजना यह परिभाषित करती है कि बाकी URL में क्या उम्मीद की जाए। http:और संबंधित योजनाओं का अर्थ है कि URL एक DNS होस्टनाम को संदर्भित करता है। DNS ASCII केस-असंवेदनशील था जो कि URL के आविष्कार से बहुत पहले था। Ietf.org/rfc/rfc883.txt

— O. जोन्स

3

विस्तृत रूप से! मैं एक ऐतिहासिक दृष्टिकोण से जा रहा था। यह मूल रूप से फ़ाइल पथ था जो केवल केस सिस्टम को संवेदनशील होने के लिए आवश्यक था यदि आप फ़ाइल सिस्टम को मार रहे थे। अन्यथा, यह नहीं था। लेकिन आज, हालात बदल गए हैं। उदाहरण के लिए, पैरामीटर और CGI मूल रूप से मौजूद नहीं थे। आपका उत्तर वर्तमान दिन का परिप्रेक्ष्य लेता है। मुझे आपके प्रयासों को पुरस्कृत करना था !! तुम सच में इस पर खोदा! कौन जानता था कि यह जिस तरह से उड़ा देगा - ?? चीयर्स !!

— 20

2

@ w3dk: यह शब्दावली का एक बहुत ही दिलचस्प नहीं है, लेकिन आप "केस-संवेदी" ले सकते हैं, जिसका अर्थ है, "एक चरित्र के मामले को बदलना पूरे को बदल सकता है", या आप इसे लेने का मतलब निकाल सकते हैं, "बदलते हुए"। एक चरित्र का मामला हमेशा पूरा बदल जाता है "। कोबी उत्तरार्ध का दावा करते हुए प्रतीत होता है, वह पसंद करता है कि केस-संवेदी का अर्थ "मामले में कोई भी बदलाव महत्वपूर्ण है" होना चाहिए, जो निश्चित रूप से URL का सच नहीं है। आप पूर्व को पसंद करते हैं। यह केवल मामला है कि वे केस के प्रति कितने संवेदनशील हैं।

— स्टीव जेसोप

2

@ rybo111: यदि कोई उपयोगकर्ता example.com/fOObaR टाइप करता है , तो इसके लिए युक्ति की आवश्यकता है कि www.example.com पर सर्वर दिए गए अनुसार एक पथ "/ fOObaR" प्राप्त करे; यह इस सवाल पर चुप है कि क्या सर्वर को "/ foOBaR" से अलग तरीके से व्यवहार करना चाहिए।

— सुपरकैट

59

सरल। ओएस केस संवेदी है। वेब सर्वर आमतौर पर तब तक परवाह नहीं करते हैं जब तक कि उन्हें किसी बिंदु पर फ़ाइल सिस्टम को हिट नहीं करना पड़ता है। यह वह जगह है जहां लिनक्स और अन्य यूनिक्स-आधारित ऑपरेटिंग सिस्टम फाइल सिस्टम के नियमों को लागू करते हैं जिसमें केस संवेदनशीलता एक प्रमुख हिस्सा है। यही कारण है कि IIS कभी भी संवेदनशील नहीं रहा है; क्योंकि Windows कभी संवेदनशील नहीं था।

[अपडेट करें]

टिप्पणियों में (जब से हटाए गए) कुछ मजबूत तर्क दिए गए हैं कि क्या URL का फाइल सिस्टम के साथ कोई संबंध है जैसा कि मैंने कहा है। ये तर्क गर्म हो गए हैं। यह मानना बहुत ही अदूरदर्शी है कि रिश्ता नहीं है। वहाँ बिल्कुल है! मैं आगे समझाता हूं।

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

जब वेब सर्वर दिखाई देने लगे, तो एप्लिकेशन डेवलपर्स ने OS सेवाओं को बायपास करने का प्रयास नहीं किया। इसके बहुत से कारण थे। एक, यह आवश्यक नहीं था। दो, एप्लिकेशन प्रोग्रामर आमतौर पर ओएस सेवाओं को बायपास करने का तरीका नहीं जानते थे। तीन, अधिकांश OS या तो बेहद स्थिर और मजबूत थे, या बेहद सरल और हल्के वजन वाले और लागत के लायक नहीं थे।

ध्यान रखें कि प्रारंभिक वेब सर्वर या तो डीईसी वैक्स / वीएमएस सर्वर और दिन के यूनिक्स (बर्कले और अल्ट्रिक्स और साथ ही अन्य) जैसे महंगे कंप्यूटरों पर मेन-फ्रेम या मिड-फ्रेम कंप्यूटरों पर चलते थे, उसके बाद जल्द ही पीसी और विंडोज 3.1 जैसे हल्के वजन वाले कंप्यूटर। जब अधिक आधुनिक खोज इंजन दिखाई देने लगे, जैसे कि 1997/8 में Google, विंडोज विंडोज NT में चला गया था और अन्य OS जैसे कि नोवेल और लिनक्स ने भी वेब सर्वर चलाना शुरू कर दिया था। अपाचे प्रमुख वेब सर्वर था हालांकि आईआईएस और ओ 'रेली जैसे अन्य भी थे जो बहुत लोकप्रिय थे। ओएस सेवाओं को दरकिनार करते समय उनमें से कोई भी नहीं। यह संभावना है कि कोई भी वेब सर्वर आज भी नहीं करता है।

प्रारंभिक वेब सर्वर काफी सरल थे। वे आज भी हैं। HTTP अनुरोध के माध्यम से संसाधन के लिए किया गया कोई भी अनुरोध हार्ड ड्राइव पर मौजूद है / जो वेब सर्वर द्वारा OS फाइल सिस्टम के माध्यम से बनाया गया है।

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

वेब सर्वर के मामले में, यह मानते हुए कि पथ / फ़ाइल के लिए URL अनुरोध किया जाता है, वेब सर्वर URL अनुरोध (URI) का पथ / फ़ाइल भाग लेता है और फ़ाइल सिस्टम से अनुरोध करता है और यह या तो संतुष्ट है या एक अपवाद फेंकता है। वेब सर्वर प्रतिक्रिया की प्रक्रिया करता है। यदि, उदाहरण के लिए, अनुरोध किया गया पथ और फ़ाइल प्राधिकरण उप-प्रणाली द्वारा दी गई है और पहुंच है, तो वेब सर्वर उन प्रक्रियाओं को संसाधित करता है जिन्हें मैं / ओ सामान्य रूप से अनुरोध करता हूं। यदि फ़ाइल सिस्टम एक अपवाद फेंकता है, तो वेब सर्वर 404 त्रुटि देता है यदि फ़ाइल नहीं मिली है या 403 निषिद्ध है यदि कारण कोड अनधिकृत है।

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

यह वास्तव में सरल लोग हैं। यह रॉकेट विज्ञान नहीं है। URL और फ़ाइल सिस्टम के पथ / फ़ाइल भाग के बीच एक पूर्ण संबंध है।

— closetnoc
स्रोत

1

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

— विलियम हेय

@WilliamHay इसका बर्नर्स-ली या वेब के डिजाइन से कोई लेना-देना नहीं है। यह ओएस की सीमाओं और आवश्यकताओं के बारे में है। मैं एक सेवानिवृत्त सिस्टम इंटर्न इंजीनियर हूं। मैंने उस समय इन प्रणालियों पर काम किया। मैं आपको बिल्कुल बता रहा हूं कि URL केस संवेदी क्यों हैं। यह अनुमान नहीं है। यह एक राय नहीं है। यह सच है। मेरा उत्तर जानबूझकर सरल था। बेशक फ़ाइल चेक और अन्य प्रक्रियाएं हैं जो किसी भी खुले बयान को जारी करने से पहले की जा सकती हैं। और हाँ (!) वेब सर्वर आंशिक रूप से आज भी असुरक्षित हैं परिणामस्वरूप।

— क्लोजेटनॉक

क्या URL संवेदनशील होने के कारण वेब के डिज़ाइन से कोई लेना-देना नहीं है? वास्तव में? प्राधिकरण से तर्क के बाद तर्क द्वारा तर्क। वह वेब सर्वर URL के पथ घटक को कम या ज्यादा सीधे खुली कॉल में भेज देता है, यह URL के डिजाइन का परिणाम है, इसका कारण नहीं है। सर्वर (या एफ़टीपी के मामले में स्मार्ट क्लाइंट) उपयोगकर्ता से फाइल सिस्टम की संवेदनशीलता को छिपा सकते हैं। कि वे एक डिजाइन निर्णय नहीं है।

— विलियम हे

@WilliamHay आपको घास की हॉपर को धीमा करना होगा और जो मैंने लिखा है उसे फिर से पढ़ना होगा। मैं एक सेवानिवृत्त सिस्टम इंटर्नल इंजीनियर हूं जो ओएस घटकों, प्रोटोकॉल स्टैक्स और एआरपीए-नेट के लिए राउटर कोड लिख रहा हूं, आदि। मैंने अपाचे, ओ रेली और आईआईएस इंटर्नल्स के साथ काम किया। आपके एफ़टीपी तर्क में पानी नहीं है क्योंकि कम से कम प्रमुख एफ़टीपी सर्वर उसी कारण से संवेदनशील बने रहते हैं। किसी भी समय मैंने URL / URI के डिज़ाइन के बारे में कुछ नहीं कहा। बिना किसी समय मैंने कहा कि वेब सर्वर ने प्रसंस्करण के बिना मूल्यों को पारित किया। मैंने कहा था कि ओएस सेवाओं का आमतौर पर उपयोग किया जाता है और फ़ाइल सिस्टम को सफल होने के लिए सटीक मिलान की आवश्यकता होती है।

— क्लिटनेटॉक

@WilliamHay कृपया समझें कि आप और मैं क्रॉस-उद्देश्यों पर विचार कर रहे हैं। मैं अपने जवाब में कह रहा था कि कुछ OSes के लिए, फ़ाइल सिस्टम कॉल डिज़ाइन द्वारा केस संवेदी हैं। सिस्टम कॉल का उपयोग करने वाले अनुप्रयोग, और अधिकांश करते हैं, ओएस नियमों के प्रवर्तन तक सीमित हैं - इस मामले में, केस संवेदनशीलता। इस नियम को दरकिनार करना असंभव नहीं है। वास्तव में यह कुछ मामलों में कुछ तुच्छ हो सकता है, हालांकि व्यावहारिक नहीं। मैं अपने काम में फ़ाइल सिस्टम को नियमित रूप से हार्ड ड्राइव को अनचाहे करने के लिए इस्तेमाल करता था, जो एक कारण या किसी अन्य कारण से kablooie जाता था या डेटाबेस फ़ाइल

— इंटर्नल्स

21

URL एक यूनिफ़ॉर्म रिसोर्स लोकेटर होने का दावा करते हैं और उन संसाधनों को इंगित कर सकते हैं जो वेब से संबंधित हैं। इनमें से कुछ मामले संवेदनशील हैं (उदाहरण के लिए कई ftp सर्वर) और URL को इन संसाधनों का यथोचित सहज रूप से प्रतिनिधित्व करने में सक्षम होना चाहिए।
केस असंवेदनशीलता के लिए मैच (ओएस में या उससे ऊपर) की तलाश में अधिक काम करने की आवश्यकता होती है।
यदि आप URL को केस संवेदी के रूप में परिभाषित करते हैं तो अलग-अलग सर्वर उन्हें केस असंवेदनशील के रूप में लागू कर सकते हैं यदि वे चाहते हैं। उलटा सच नहीं है।
अंतर्राष्ट्रीय संदर्भों में केस असंवेदनशीलता गैर-तुच्छ हो सकती है: https://en.wikipedia.org/wiki/Dotted_and_dotless_I । इसके अलावा RFC1738 ने ASCII रेंज के बाहर के पात्रों के उपयोग की अनुमति दी, बशर्ते कि वे एन्कोडेड थे, लेकिन एक चारसेट निर्दिष्ट नहीं किया। यह अपने आप को वर्ल्ड वाइड वेब कहलाने के लिए काफी महत्वपूर्ण है। असंवेदनशील होने पर URL को परिभाषित करना बग के लिए बहुत गुंजाइश खोलेगा।
यदि आप बहुत सारे डेटा को यूआरआई (जैसे एक डेटा यूआरआई ) में पैक करने की कोशिश कर रहे हैं, तो आप ऊपरी और निचले मामले में अलग-अलग हैं।

— विलियम हय
स्रोत

1

मुझे पूरा यकीन है कि URL ऐतिहासिक रूप से ASCII तक सीमित थे। इसलिए अंतर्राष्ट्रीयकरण एक मूल कारण होने की संभावना नहीं है। यूनिक्स का मामला संवेदनशील होने का इतिहास, ओटीओएच, ने शायद एक बड़ी भूमिका निभाई है।

— derobert

जबकि ASCII के केवल सबसेट का उपयोग URL RFC1738 में अनएन्कोडेड किया जा सकता है, विशेष रूप से बताता है कि ASCII रेंज के बाहर के अक्षर एन्कोड किए जा सकते हैं। एक चारसेट को निर्दिष्ट किए बिना इसका पता करना संभव नहीं है कि कौन सा ओकटेट मामले को छोड़कर एक ही चरित्र का प्रतिनिधित्व करता है। अपडेट किया गया।

— विलियम है

1

# 4 पुन: यह वास्तव में उससे भी बदतर है। डॉटेड और डॉटलेस I अधिक सामान्य सिद्धांत का एक प्रदर्शन है, भले ही सब कुछ यूटीएफ -8 (या कुछ अन्य यूटीएफ) है, आप उस लोकेल को जाने बिना सही ढंग से कैपिटल या कम नहीं कर सकते हैं, जिसमें पाठ होता है। डिफ़ॉल्ट लोकेल में, एक कैपिटल लैटिन लेटर I एक लोअरकेस लेटिन अक्षर i को देता है, जो कि तुर्की में गलत है क्योंकि यह एक डॉट जोड़ता है (कोई "तुर्की कैपिटल डॉटलेस I" कोड बिंदु नहीं है; आप ASCII कोड का उपयोग करने के लिए हैं; बिंदु)। एन्कोडिंग अंतर में फेंको, और यह "वास्तव में कठिन" से "पूरी तरह से अट्रैक्टिव" हो जाता है।

— केविन

5

मैंने ब्लॉग से एक पुरानी नई बात चुरा ली है, क्योंकि यह सवाल है कि "ऐसा क्यों होता है?" जवाबी सवाल के साथ "अगर ऐसा नहीं होता तो दुनिया कैसी होती?"

कहते हैं कि मैंने एक वेब सर्वर को एक फ़ोल्डर से अपने दस्तावेज़ फ़ाइलों की सेवा करने के लिए सेट किया था ताकि मैं कार्यालय से बाहर होने पर उन्हें फोन पर पढ़ सकूं। अब, मेरे दस्तावेज़ फ़ोल्डर में, मैं तीन फ़ाइलें, है todo.txt, ToDo.txtऔर TODO.TXT(मैं जानता हूँ कि, लेकिन यह मेरे लिए भावना जब मैं फ़ाइलों को बनाया)।

इन फ़ाइलों तक पहुँचने के लिए मैं किस URL का उपयोग करना चाहूंगा? मैं उनका उपयोग करते हुए एक सहज तरीके से एक्सेस करना चाहूंगा http://www.example.com/docs/filename।

कहो कि मेरे पास एक स्क्रिप्ट है जो मुझे अपनी पता पुस्तिका में एक संपर्क जोड़ने की अनुमति देती है, जिसे मैं वेब पर भी कर सकता हूं। कैसे इसके मापदंडों को लेना चाहिए? खैर, मैं इसका इस्तेमाल करना चाहूंगा http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly:। लेकिन अगर मेरे पास केस द्वारा नाम निर्दिष्ट करने का कोई तरीका नहीं था, तो मैं यह कैसे करूंगा?

मैं कैट और कैट, टेक्स्ट और पाठ, लेटेक्स और LaTeX के विकी पेजों को कैसे अलग करूंगा? पृष्ठों की उपेक्षा, मुझे लगता है, लेकिन मैं सिर्फ उस चीज को प्राप्त करना पसंद करता हूं जो मैंने मांगी थी।

लेकिन सभी को ऐसा लगता है कि यह गलत प्रश्न का उत्तर दे रहा है, वैसे भी।

जो प्रश्न मुझे लगता है कि आप वास्तव में पूछ रहे थे, "वेब सर्वर 404 आप केवल एक केस अंतर के लिए क्यों करते हैं, जब वे कंप्यूटर होते हैं, जो जीवन को सरल बनाने के लिए डिज़ाइन किए जाते हैं, और वे कम से कम सबसे स्पष्ट केस-विविधताओं को खोजने में पूरी तरह से सक्षम होते हैं URL मैंने टाइप किया जो काम करेगा? "

जिसका उत्तर यह है कि जबकि कुछ साइटों ने ऐसा किया है (और बेहतर है, वे अन्य टाइपोस के लिए भी जांच करते हैं), किसी ने भी ऐसा करने के लिए वेबसर्वर के डिफ़ॉल्ट 404 त्रुटि पृष्ठ को बदलना उचित नहीं समझा ... लेकिन शायद उन्हें करना चाहिए?

— देवि मोर्गन
स्रोत

1

कुछ साइटें किसी भी क्वेरी को सभी लोअरकेस या कुछ संगत में बदलने के लिए किसी प्रकार के तंत्र का उपयोग करती हैं। एक तरह से, यह स्मार्ट है।

— अलमारी

नहीं, उन्हें नहीं करना चाहिए। यह कार्यक्षमता हो सकती है, और अक्सर यह तब जोड़ा जाता है जब यह वांछनीय है (उदाहरण के लिए, अपाचे में मॉड्यूल द्वारा।) इस तरह के परिवर्तन को डिफ़ॉल्ट व्यवहार के रूप में लागू करने के लिए - या इससे भी बदतर, अपरिवर्तनीय व्यवहार - अपेक्षाकृत दुर्लभ से अधिक विघटनकारी होगा ऐसा अवसर जहां किसी को होस्ट नाम से परे URL में मैन्युअल रूप से लिखना पड़ता है। ऐसा क्यों नहीं किया जाता है, के एक अच्छे उदाहरण के लिए, नेटवर्क समाधान जब सार्वजनिक DNS प्रश्नों से गैर-मौजूद डोमेन त्रुटियों को "ठीक" गैर-मौजूद डोमेन त्रुटियों को याद करते हैं।

— SirNickity

@SirNickity कोई भी किसी भी स्तर पर अपरिवर्तनीयता का प्रस्ताव कर रहा था और वेबसर्वर त्रुटि पृष्ठ मेरे द्वारा उपयोग किए जाने वाले प्रत्येक वेबसर्वर पर कॉन्फ़िगर करने योग्य हैं; कोई भी 40 * 30 कोड के साथ प्रतिस्थापित करने का सुझाव नहीं दे रहा था, बल्कि त्रुटि पृष्ठ पर मानव-क्लिक करने योग्य सुझाव लिंक की सूची जोड़ रहा था; डोमेन नाम एक बहुत अलग विषय है और मामला असंवेदनशील होने के कारण, और एक अलग सुरक्षा संदर्भ में; और IIS पहले से ही URI के पथ या फ़ाइल नाम भागों में केस-अंतर को "स्वचालित रूप से" ठीक करता है (अनदेखा करके)।

— डेवी मॉर्गन

1996 से, Apache ने आपको mod_speling के साथ ऐसा करने दिया । यह सिर्फ करने के लिए एक बहुत लोकप्रिय बात नहीं लगती है। यूनिक्स / लिनक्स लोग मामले की संवेदनशीलता को नियम के रूप में देखते हैं, मामले की संवेदनशीलता को अपवाद के रूप में।

— रीस्टोरियरपोस्ट

4

हालांकि उपरोक्त उत्तर सही और अच्छा है। मैं कुछ और बिंदु जोड़ना चाहूंगा।

बेहतर समझने के लिए, यूनिक्स (लिनक्स) बनाम विंडोज सर्वर के बीच बुनियादी अंतर को समझना चाहिए। यूनिक्स केस सेंसिटिव है और विंडोज नॉन केस सेंसिटिव ओएस है।

HTTP प्रोटोकॉल को 1990 के आसपास लागू किया गया या लागू होना शुरू हुआ। HTTP प्रोटोकॉल CERN संस्थानों में काम करने वाले इंजीनियरों द्वारा डिजाइन किया गया था, उन दिनों अधिकांश वैज्ञानिक यूनिक्स मशीनों का उपयोग करते थे, न कि विंडोज का।

अधिकांश वैज्ञानिक यूनिक्स से परिचित थे, इसलिए वे शायद यूनिक्स शैली की फाइल प्रणाली से प्रभावित थे।

विंडोज सर्वर 2000 के बाद जारी किया गया था। विंडोज़ सर्वर के लोकप्रिय होने से पहले ही HTTP प्रोटोकॉल अच्छी तरह से परिपक्व हो गया था और कल्पना पूरी हो गई थी।

यह कारण हो सकता है।

— मणि
स्रोत

2

"विंडोज सर्वर 2000 के बाद जारी किया गया था।" Windows NT 3.1 टीम 1995 में 1993 NT 3.51 में आप से सहमत नहीं है | शायद था जब NT बनने शुरू कर दिया परिपक्व और पर्याप्त व्यवसाय की महत्वपूर्ण सर्वर अनुप्रयोगों का समर्थन करने अच्छी तरह से स्थापित।

— बजे एक CVn

NT 3.51 में विन 3.1 इंटरफ़ेस था। विंडोज ने विंडोज 95 तक वास्तव में बंद नहीं किया और समान इंटरफ़ेस प्राप्त करने के लिए NT 4.0 लिया।

— थोरबजोरन रेव एंडरसन

माइकल Kjörling, सहमत हुए। मुझे इसे संशोधित करने दें।

— मणि

1

@ ThorbjørnRavnAndersen सर्वर बाजार में, NT 3.51 यथोचित सफल रहा। NT लाइन के गंभीर ट्रैक्शन प्राप्त करने से पहले उपभोक्ता / प्रॉसीक्यूमर मार्केट में, विंडोज 2000 (NT 5.0) तक ले गया।

— बजे एक CVn

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

— रीस्टोरियरपोस्ट

4

किसी को कैसे पढ़ना चाहिए "इसे इस तरह से क्यों बनाया गया था?" सवाल? क्या आप निर्णय लेने की प्रक्रिया का ऐतिहासिक-सटीक हिसाब पूछ रहे हैं, या आप पूछ रहे हैं कि "कोई इसे इस तरह से क्यों डिजाइन करेगा?"

ऐतिहासिक रूप से सटीक खाता मिलना बहुत कम संभव है। कभी-कभी जब मानकों की समितियों में निर्णय किए जाते हैं तो बहस का संचालन कैसे किया जाता है, इसका एक दस्तावेजी तरीका है, लेकिन वेब के शुरुआती दिनों में कुछ व्यक्तियों द्वारा जल्दबाजी में निर्णय लिए गए थे - इस मामले में शायद खुद टिमबीएल द्वारा - और तर्क की संभावना नहीं है। नीचे लिखा गया है। लेकिन टिमबीएल ने स्वीकार किया है कि उसने यूआरएल के डिजाइन में गलतियाँ की हैं - देखें http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

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

— माइकल के
स्रोत

अंतिम उपयोगकर्ता यूनिक्स उपयोगकर्ता थे (आवश्यक रूप से प्रोग्रामर, लेकिन उच्च-ऊर्जा भौतिक विज्ञानी और पसंद नहीं), इसलिए वे भी असंवेदनशीलता के मामले के आदी थे।

— रीस्टोरियरपोस्ट

3

इससे कोई लेना-देना नहीं है कि आपने अपना डोमेन कहां खरीदा है, डीएनएस संवेदनशील नहीं है। लेकिन, होस्टिंग के लिए आप जिस सर्वर का उपयोग कर रहे हैं, वह फाइल सिस्टम है।

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

— adnan3344
स्रोत

2

Closetnoc OS के बारे में सही है। कुछ फाइल सिस्टम एक ही नाम को अलग-अलग केसिंग के साथ अलग-अलग फाइलों के रूप में मानते हैं।

साथ ही, केस-संवेदी URL होने का एक वास्तविक उद्देश्य / लाभ है (जैसा कि उन अधिकांश URL का विरोध किया गया है जो एक ही पृष्ठ पर इंगित होते हैं, चाहे कोई भी कैपिटलाइज़ेशन क्यों न हो)?

हाँ। डुप्लिकेट सामग्री मुद्दों से बचने के लिए।

यदि आपके पास उदाहरण के लिए निम्न URL हैं:

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

और वे सभी ठीक उसी सामग्री के साथ एक ही पृष्ठ पर इंगित करते हैं, तो आपके पास डुप्लिकेट सामग्री होगी, और मुझे यकीन है कि यदि आपके पास Google खोज कंसोल (वेबमास्टर टूल) खाता है, तो Google आपको यह संकेत देगा।

यदि मैं सुझाव देता हूं कि यदि आप उस स्थिति में हैं तो सभी लोअर-केस URL का उपयोग करना है, तो कम से कम केस वर्जन में कम से कम एक कैपिटल लेटर वाले URL को रीडायरेक्ट करें। इसलिए ऊपर दिए गए URL की सूची में, सभी URL को पहले URL पर पुनर्निर्देशित करें।

— माइक
स्रोत

"हाँ। डुप्लिकेट सामग्री मुद्दों से बचने के लिए।" - लेकिन इसके विपरीत सच प्रतीत होगा? तथ्य यह है कि URL केस-संवेदी हो सकते हैं (और यह है कि खोज इंजन उनके साथ कैसा व्यवहार करते हैं) आपके द्वारा उल्लेखित डुप्लिकेट सामग्री समस्याओं का कारण बनता है। यदि URL सार्वभौमिक रूप से असंवेदनशील थे, तो अलग-अलग मामले के साथ कोई डुप्लिकेट सामग्री समस्या नहीं होगी। जैसा page-1होगा वैसा ही होगा PAGE-1।

— MrWhite

मुझे लगता है कि खराब सर्वर कॉन्फ़िगरेशन वह है जो डुप्लिकेट सामग्री का कारण बन सकता है जब यह आवरण में आता है। उदाहरण के लिए, RewriteRule ^request-uri$ /targetscript.php [NC].htaccess में संग्रहीत स्टेटमेंट मेल खाएगा http://example.com/request-uriऔर http://example.com/ReQuEsT-Uriक्योंकि यह [NC]इंगित करता है कि उस नियमित अभिव्यक्ति का मूल्यांकन करते समय आवरण मायने नहीं रखता है।

— माइक

1

केस संवेदनशीलता का मूल्य है।

यदि 26 अक्षर हैं, तो उनमें से प्रत्येक में कैपिटल होने की क्षमता है, जो कि 52 वर्ण हैं।

4 पात्रों में 52 * 52 * 52 * 52 संयोजनों की समरूपता है, जिसमें 7311616 संयोजन हैं।

यदि आप वर्णों को कैपिटल नहीं कर सकते हैं, तो संयोजनों की मात्रा 26 * 26 * 26 * 26 = 456976 है

52 पात्रों के लिए 26 की तुलना में 14 गुना अधिक संयोजन हैं। इसलिए डेटा संग्रहीत करने के लिए, उरल्स को छोटा किया जा सकता है और कम डेटा हस्तांतरित वाले नेटवर्क पर अधिक जानकारी पारित की जा सकती है।

यही कारण है कि आप https://www.youtube.com/watch?v=xXxxXxxX जैसे URL का उपयोग करके youtube देखते हैं

— माइकल डी
स्रोत

URL केस-संवेदी क्यों हैं?

pathकेस-संवेदी क्यों है ?

क्या यह उपयोगी है?

`path`केस-संवेदी क्यों है ?