लेखक: सर टिम बर्नर्स-ली, यूआरआई, यूआरएल, एचटीटीपी, एचटीएमएल और वर्ल्ड वाइड वेब के आविष्कारक और डब्ल्यू3सी के वर्तमान प्रमुख। 1998 में लिखा गया लेख

कौन सा यूआरआई "कूल" माना जाता है?
जो बदलता नहीं.
यूआरआई कैसे बदलते हैं?
यूआरआई नहीं बदलते: लोग उन्हें बदलते हैं।

सिद्धांत रूप में, लोगों के पास यूआरआई बदलने (या दस्तावेजों का समर्थन करना बंद करने) का कोई कारण नहीं है, लेकिन व्यवहार में ऐसे लाखों लोग हैं।

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

हमने साइट को बेहतर बनाने के लिए इसे पुनर्गठित किया है।

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

हमारे पास इतना सामान है कि हम इस बात पर नज़र नहीं रख सकते कि क्या पुराना है, क्या गोपनीय है और क्या अभी भी प्रासंगिक है, इसलिए हमने सोचा कि इसे बंद कर देना ही बेहतर होगा।

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

खैर, हमें पता चला कि हमें फ़ाइलों को स्थानांतरित करने की आवश्यकता है...

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

जॉन अब इस फ़ाइल का रखरखाव नहीं करता, जेन अब करता है।

क्या यूआरआई में जॉन का नाम था? नहीं, क्या फ़ाइल सिर्फ उसकी निर्देशिका में थी? अच्छी तरह से ठीक है।

पहले हम इसके लिए CGI स्क्रिप्ट का उपयोग करते थे, लेकिन अब हम बाइनरी प्रोग्राम का उपयोग करते हैं।

एक अजीब विचार है कि स्क्रिप्ट द्वारा बनाए गए पेज "cgibin" या "cgi" क्षेत्र में स्थित होने चाहिए। यह आपके वेब सर्वर चलाने की कार्यप्रणाली को उजागर करता है। आप तंत्र बदलते हैं (सामग्री सहेजते समय भी), और उफ़ - आपके सभी यूआरआई बदल जाते हैं।

उदाहरण के लिए राष्ट्रीय विज्ञान फाउंडेशन (एनएसएफ) को लें:

एनएसएफ ऑनलाइन दस्तावेज़

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

दस्तावेज़ देखना शुरू करने वाला पहला पृष्ठ स्पष्ट रूप से कुछ वर्षों में पहले जैसा नहीं रहेगा। cgi-bin, oldbrowse и pl - यह सब कुछ जानकारी देता है कि हम इसे अभी कैसे करते हैं। यदि आप किसी दस्तावेज़ को खोजने के लिए पृष्ठ का उपयोग करते हैं, तो आपको जो पहला परिणाम मिलता है वह उतना ही खराब होता है:

क्रिप्टोलॉजी और कोडिंग सिद्धांत पर कार्य समूह की रिपोर्ट

http://www.nsf.gov/cgi-bin/getpub?nsf9814

दस्तावेज़ अनुक्रमणिका पृष्ठ के लिए, हालाँकि HTML दस्तावेज़ स्वयं बहुत बेहतर दिखता है:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

यहां पब/1998 हेडर किसी भी भविष्य की अभिलेखीय सेवा को एक अच्छा संकेत देगा कि पुरानी 1998 दस्तावेज़ वर्गीकरण योजना प्रभावी है। हालाँकि 2098 में दस्तावेज़ संख्याएँ भिन्न दिख सकती हैं, मुझे लगता है कि यह यूआरआई अभी भी वैध होगा और एनएसएफ या किसी अन्य संगठन के साथ हस्तक्षेप नहीं करेगा जो संग्रह को बनाए रखेगा।

मैंने नहीं सोचा था कि यूआरएल लगातार बने रहने चाहिए - यूआरएन थे।

यह संभवतः यूआरएन बहस के सबसे खराब दुष्प्रभावों में से एक है। कुछ लोग सोचते हैं कि अधिक स्थायी नामस्थान पर शोध के कारण, वे लटकते लिंक के प्रति लापरवाह हो सकते हैं क्योंकि "यूआरएन यह सब ठीक कर देगा।" अगर आप भी इन लोगों में से एक हैं तो मैं आपको निराश कर दूं।

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

यदि आप इस बिंदु पर पहुंच गए हैं, यदि आपके पास कुछ सॉफ़्टवेयर विकसित करने के लिए समय, पैसा और कनेक्शन नहीं है, तो आप निम्नलिखित बहाना बता सकते हैं:

हम चाहते थे, लेकिन हमारे पास सही उपकरण नहीं हैं।

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

आपको यूआरआई बदले बिना यूआरआई स्थान में स्वामित्व, दस्तावेज़ पहुंच, संग्रह स्तर की सुरक्षा आदि को बदलने में सक्षम होना चाहिए।

यह सब बहुत बुरा है. लेकिन हम स्थिति को सुधार लेंगे. W3C में, हम जिगेडिट (जिगसॉ एडिटिंग सर्वर) कार्यक्षमता का उपयोग करते हैं जो संस्करणों को ट्रैक करती है, और हम दस्तावेज़ निर्माण स्क्रिप्ट के साथ प्रयोग करते हैं। यदि आप टूल, सर्वर और क्लाइंट विकसित करते हैं, तो इस मुद्दे पर ध्यान दें!

यह बहाना कई W3C पृष्ठों पर भी लागू होता है, जिनमें यह भी शामिल है: इसलिए जैसा मैं कहता हूं वैसा करो, जैसा मैं करता हूं वैसा नहीं।

मै क्यूँ ध्यान दूँ?

जब आप अपने सर्वर पर यूआरआई बदलते हैं, तो आप कभी भी पूरी तरह से नहीं बता सकते कि पुराने यूआरआई से किसके लिंक होंगे। ये नियमित वेब पेजों के लिंक हो सकते हैं। अपने पेज को बुकमार्क करें. हो सकता है कि यूआरआई किसी मित्र को लिखे पत्र के हाशिये पर लिखा गया हो।

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

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

तो मुझे क्या करना चाहिए? यूआरआई डिज़ाइन

यह वेबमास्टर की जिम्मेदारी है कि वह यूआरआई आवंटित करे जिसका उपयोग 2 वर्षों में, 20 वर्षों में, 200 वर्षों में किया जा सके। इसके लिए विचारशीलता, संगठन और दृढ़ संकल्प की आवश्यकता है।

यदि उनमें कोई जानकारी बदलती है तो यूआरआई बदल जाते हैं। आप उन्हें कैसे डिज़ाइन करते हैं यह बहुत महत्वपूर्ण है। (क्या, यूआरआई डिज़ाइन? क्या मुझे यूआरआई डिज़ाइन करने की ज़रूरत है? हां, आपको इसके बारे में सोचना चाहिए)। डिज़ाइन का मूल रूप से मतलब यूआरआई में किसी भी जानकारी को छोड़ना है।

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

एकमात्र अपवाद वह पृष्ठ है जो जानबूझकर "नवीनतम" संस्करण है, उदाहरण के लिए संपूर्ण संगठन या उसके बड़े हिस्से के लिए।

http://www.pathfinder.com/money/moneydaily/latest/

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

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(अच्छा लग रहा है। मान लिया गया है कि pathfinder.com के पूरे जीवनकाल में "पैसा" का एक ही मतलब होगा। एक डुप्लिकेट "98" और एक अनावश्यक ".html" है, लेकिन अन्यथा एक मजबूत यूआरआई जैसा दिखता है।

क्या छोड़ना है

सभी! निर्माण तिथि के अलावा, यूआरआई में कोई भी जानकारी डालना किसी न किसी तरह से परेशानी खड़ी करना है।

• लेखक का नाम. नए संस्करण उपलब्ध होते ही लेखकत्व बदल सकता है। लोग संगठन छोड़ देते हैं और चीजें दूसरों को सौंप देते हैं।
• विषय. यह बेहद कठिन है। यह शुरुआत में हमेशा अच्छा दिखता है, लेकिन आश्चर्यजनक रूप से तेज़ी से बदल जाता है। मैं नीचे इसके बारे में और अधिक बात करूंगा।
• हैसियत. "पुरानी", "ड्राफ्ट" इत्यादि जैसी निर्देशिकाएँ, "नवीनतम" और "कूल" का उल्लेख न करते हुए, सभी फ़ाइल सिस्टम में दिखाई देती हैं। दस्तावेज़ों की स्थिति बदल जाती है - अन्यथा ड्राफ्ट बनाने का कोई मतलब नहीं होगा। किसी दस्तावेज़ के नवीनतम संस्करण को उसकी स्थिति की परवाह किए बिना एक सतत पहचानकर्ता की आवश्यकता होती है। स्टेटस को नाम से अलग रखें.
• अभिगम. W3C में, हमने साइट को कर्मचारियों, सदस्यों और जनता के लिए अनुभागों में विभाजित किया है। यह अच्छा लगता है, लेकिन निश्चित रूप से, दस्तावेज़ कर्मचारियों के टीम विचारों के रूप में शुरू होते हैं, सदस्यों के साथ चर्चा की जाती है, और फिर सार्वजनिक ज्ञान बन जाते हैं। यह वास्तव में शर्म की बात होगी अगर हर बार जब कोई दस्तावेज़ व्यापक चर्चा के लिए खोला जाता है, तो उसके सभी पुराने लिंक टूट जाते हैं! अब हम एक सरल दिनांक कोड की ओर बढ़ते हैं।
• दस्तावेज़ विस्तारण. एक बहुत ही सामान्य घटना. भविष्य में "सीजीआई", यहां तक ​​कि ".html" भी बदल जाएगा। हो सकता है कि आप 20 वर्षों से इस पृष्ठ के लिए HTML का उपयोग न कर रहे हों, लेकिन आज के इसके लिंक अभी भी काम करने चाहिए। W3C साइट पर कैनोनिकल लिंक एक्सटेंशन का उपयोग नहीं करते (यह कैसे किया है).
• सॉफ्टवेयर तंत्र. यूआरआई में, "सीजीआई", "एक्जीक्यूटिव" और अन्य शब्द देखें जो चिल्लाते हैं "देखो हम किस सॉफ्टवेयर का उपयोग कर रहे हैं।" क्या कोई अपना पूरा जीवन पर्ल सीजीआई स्क्रिप्ट लिखने में बिताना चाहता है? नहीं? फिर .pl एक्सटेंशन हटा दें। यह कैसे करें, इसके लिए सर्वर मैनुअल पढ़ें।
• डिस्क का नाम. चलो भी! लेकिन मैंने ये देखा है.

तो हमारी साइट से सबसे अच्छा उदाहरण सरल है

http://www.w3.org/1998/12/01/chairs

... W3C अध्यक्षों की बैठक के कार्यवृत्त पर रिपोर्ट।

विषयानुसार विषय और वर्गीकरण

मैं इस खतरे के बारे में और अधिक विस्तार से बताऊंगा, क्योंकि यह उन चीजों में से एक है जिससे बचना सबसे कठिन है। आमतौर पर, जब आप अपने दस्तावेज़ों को उनके द्वारा किए जाने वाले कार्य के आधार पर वर्गीकृत करते हैं तो विषय यूआरआई में समाप्त हो जाते हैं। लेकिन यह टूटन समय के साथ बदल जाएगी। इलाकों के नाम बदल जायेंगे. W3C में हम अनुभाग की वास्तविक सामग्री को प्रतिबिंबित करने के लिए मार्कअप को मार्कअप और फिर HTML में बदलना चाहते थे। इसके अलावा, अक्सर एक फ्लैट नेमस्पेस होता है। क्या आप वाकई 100 वर्षों में किसी भी चीज़ का पुन: उपयोग नहीं करना चाहेंगे? उदाहरण के लिए, अपने छोटे से जीवन में हम पहले से ही "इतिहास" और "स्टाइल शीट्स" का पुन: उपयोग करना चाहते थे।

यह किसी वेबसाइट को व्यवस्थित करने का एक आकर्षक तरीका है—और संपूर्ण वेब सहित किसी भी चीज़ को व्यवस्थित करने का वास्तव में आकर्षक तरीका है। यह एक बेहतरीन मध्यम अवधि का समाधान है लेकिन लंबी अवधि में इसमें गंभीर कमियां हैं।

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

वास्तव में, जब आप यूआरआई में किसी विषय के नाम का उपयोग करते हैं, तो आप स्वयं को किसी प्रकार के वर्गीकरण के लिए प्रतिबद्ध कर रहे होते हैं। शायद भविष्य में आप कोई दूसरा विकल्प पसंद करेंगे. तब यूआरआई उल्लंघन के प्रति संवेदनशील होगा।

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

डोमेन नाम मत भूलना

याद रखें कि यह न केवल यूआरआई में पथ पर लागू होता है, बल्कि सर्वर नाम पर भी लागू होता है। यदि आपके पास अलग-अलग चीज़ों के लिए अलग-अलग सर्वर हैं, तो याद रखें कि कई लिंक को नष्ट किए बिना इस विभाजन को बदलना असंभव होगा। कुछ क्लासिक "आज हम जिस सॉफ़्टवेयर का उपयोग करते हैं उसे देखें" गलतियाँ डोमेन नाम "cgi.pathfinder.com", "सुरक्षित", "lists.w3.org" हैं। इन्हें सर्वर प्रशासन को आसान बनाने के लिए डिज़ाइन किया गया है। भले ही कोई डोमेन आपकी कंपनी में एक प्रभाग, दस्तावेज़ स्थिति, पहुंच स्तर या सुरक्षा स्तर का प्रतिनिधित्व करता हो, एकाधिक दस्तावेज़ प्रकारों के लिए एक से अधिक डोमेन नाम का उपयोग करने से पहले बहुत सावधान रहें। याद रखें कि आप पुनर्निर्देशन और प्रॉक्सी का उपयोग करके एक ही दृश्यमान वेब सर्वर के अंदर कई वेब सर्वर छिपा सकते हैं।

ओह, और अपने डोमेन नाम के बारे में भी सोचें। उत्पाद शृंखला बदलने और साबुन बनाना बंद करने के बाद आप नहीं चाहेंगे कि आपको साबुन.कॉम कहा जाए (इस समय जो भी साबुन.कॉम का मालिक है, उसके लिए क्षमा करें)।

निष्कर्ष

किसी यूआरआई को 2, 20, 200 या यहां तक ​​कि 2000 वर्षों तक संरक्षित रखना स्पष्ट रूप से उतना आसान नहीं है जितना लगता है। हालाँकि, पूरे इंटरनेट पर, वेबमास्टर ऐसे निर्णय ले रहे हैं जो भविष्य में उनके लिए इस कार्य को वास्तव में कठिन बना रहे हैं। अक्सर ऐसा इसलिए होता है क्योंकि वे ऐसे टूल का उपयोग करते हैं जिनका काम केवल इस समय सर्वोत्तम साइट प्रस्तुत करना है - और किसी ने भी यह आकलन नहीं किया है कि जब सब कुछ बदल जाएगा तो लिंक का क्या होगा। हालाँकि, यहाँ मुद्दा यह है कि बहुत-सी चीज़ें बदल सकती हैं, और आपका यूआरआई वही रह सकता है और रहना भी चाहिए। यह तभी संभव है जब आप सोचें कि आप उन्हें कैसे बनाते हैं।

यह भी देखें:

• इसी विषय पर जैकब नील्सन का व्यंग्य

की आपूर्ति करता है

फ़ाइल एक्सटेंशन कैसे हटाएं...

...वर्तमान फ़ाइल-आधारित वेब सर्वर में एक यूआरआई से?

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

• सामग्री पर बातचीत करने के लिए अपना सर्वर सेट करें
• हमेशा बिना एक्सटेंशन के यूआरआई से लिंक करें

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

(वास्तव में, mydog, mydog.png и mydog.gif - वैध वेब संसाधन, mydog एक सार्वभौमिक सामग्री प्रकार का संसाधन है, और mydog.png и mydog.gif - एक विशिष्ट सामग्री प्रकार के संसाधन)।

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

शर्म का बोर्ड - कहानी 1: चैनल 7

1999 के दौरान, मैंने पेज पर बर्फबारी के कारण स्कूल बंद होने का पता लगाया http://www.whdh.com/stormforce/closings.shtml. टीवी स्क्रीन के नीचे जानकारी प्रदर्शित होने की प्रतीक्षा न करें! मैंने इसे अपने होम पेज से लिंक किया है। 2000 का पहला बड़ा बर्फ़ीला तूफ़ान आया और मैंने पृष्ठ की जाँच की। वहां लिखा है:,

- के रूप में।
फिलहाल कुछ भी बंद नहीं है. कृपया मौसम संबंधी चेतावनी मिलने पर वापस आएँ।

इतना तेज़ तूफ़ान नहीं हो सकता. यह हास्यास्पद है कि तारीख गायब है। लेकिन यदि आप साइट के मुख्य पृष्ठ पर जाते हैं, तो वहां एक बड़ा बटन "बंद स्कूल" होगा, जो पृष्ठ पर ले जाता है http://www.whdh.com/stormforce/ बंद स्कूलों की है लंबी सूची

हो सकता है कि उन्होंने सूची प्राप्त करने के लिए सिस्टम बदल दिया हो - लेकिन उन्हें यूआरआई बदलने की जरूरत नहीं पड़ी।

शर्म का बोर्ड - कहानी 2: माइक्रोसॉफ्ट नेटमीटिंग

इंटरनेट पर बढ़ती निर्भरता के साथ, एक चतुर विचार आया कि निर्माता की वेबसाइट के लिंक को अनुप्रयोगों में एम्बेड किया जा सकता है। इसका बहुत उपयोग और दुरुपयोग किया गया है, लेकिन आप यूआरएल नहीं बदल सकते। अभी कुछ ही दिन पहले मैंने वेब/फ्री स्टफ मेनू पर हेल्प/माइक्रोसॉफ्ट में माइक्रोसॉफ्ट नेटमीटिंग 2/समथिंग क्लाइंट से एक लिंक का प्रयास किया और 404 त्रुटि प्राप्त हुई - सर्वर से कोई प्रतिक्रिया नहीं मिली। शायद उन्होंने इसे पहले ही ठीक कर लिया है...

© 1998 टिम बीएल

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

स्रोत: www.habr.com