लेखक: सर टिम बर्नर्स-ली, URIs, URLs, HTTP, HTML आणि वर्ल्ड वाइड वेबचे शोधक आणि W3C चे वर्तमान प्रमुख. 1998 मध्ये लिहिलेला लेख

कोणता URI "कूल" मानला जातो?
जो बदलत नाही.
URI कसे बदलतात?
URI बदलत नाहीत: लोक ते बदलतात.

सैद्धांतिकदृष्ट्या, लोकांनी यूआरआय बदलण्याचे (किंवा सहाय्यक कागदपत्रे थांबवण्याचे) कोणतेही कारण नाही, परंतु व्यवहारात ते लाखो आहेत.

सिद्धांततः, डोमेन नेमस्पेसचा नाममात्र मालक प्रत्यक्षात डोमेन नेमस्पेसचा मालक असतो आणि म्हणून त्यामधील सर्व URI. दिवाळखोरी व्यतिरिक्त, डोमेन नावाच्या मालकाला नाव ठेवण्यापासून काहीही प्रतिबंधित करत नाही. आणि सिद्धांतानुसार, तुमच्या डोमेन नावाखालील URI जागा पूर्णपणे तुमच्या नियंत्रणात आहे, त्यामुळे तुम्ही ते तुमच्या इच्छेनुसार स्थिर करू शकता. इंटरनेटवरून दस्तऐवज गायब होण्याचे एकच चांगले कारण म्हणजे डोमेन नावाची मालकी असलेली कंपनी व्यवसायाच्या बाहेर गेली आहे किंवा सर्व्हर चालू ठेवू शकत नाही. मग जगात इतक्या मिसिंग लिंक्स का आहेत? यातील काही केवळ पूर्वविचाराचा अभाव आहे. तुम्ही ऐकू शकता अशी काही कारणे येथे आहेत:

आम्ही ती अधिक चांगली करण्यासाठी साइटची पुनर्रचना केली आहे.

तुम्हाला खरोखर वाटते की जुने URI आता काम करू शकत नाहीत? तसे असल्यास, आपण त्यांना खूप खराब निवडले आहे. पुढील रीडिझाइनसाठी नवीन ठेवण्याचा विचार करा.

आमच्याकडे इतकी सामग्री आहे की आम्ही काय कालबाह्य आहे, काय गोपनीय आहे आणि काय अद्याप संबंधित आहे याचा मागोवा ठेवू शकत नाही, म्हणून आम्हाला ते सर्व बंद करणे चांगले वाटले.

मी फक्त सहानुभूती दाखवू शकतो. W3C अशा कालखंडातून गेला जेव्हा आम्हाला गोपनीयतेसाठी संग्रहित सामग्री सार्वजनिक करण्यापूर्वी काळजीपूर्वक चाळायची होती. निर्णयाचा अगोदरच विचार करणे आवश्यक आहे - आपण प्रत्येक दस्तऐवजासह स्वीकार्य वाचकवर्ग, निर्मितीची तारीख आणि आदर्शपणे कालबाह्यता तारीख ओळखता याची खात्री करा. हा मेटाडेटा जतन करा.

बरं, आम्हाला आढळलं की आम्हाला फाइल्स हलवायची आहेत...

हे सर्वात दयनीय कारणांपैकी एक आहे. बर्‍याच लोकांना हे माहित नाही की वेब सर्व्हर तुम्हाला ऑब्जेक्टचा URI आणि फाइल सिस्टममधील त्याचे वास्तविक स्थान यांच्यातील संबंध नियंत्रित करण्याची परवानगी देतात. यूआरआय स्पेसचा एक अमूर्त जागा म्हणून विचार करा, उत्तम प्रकारे आयोजित करा. मग आपण प्रत्यक्षात ते साकार करण्यासाठी वापरत असलेल्या कोणत्याही वास्तविकतेचे मॅपिंग करा. त्यानंतर वेब सर्व्हरला याची तक्रार करा. ते योग्य करण्यासाठी तुम्ही तुमचा स्वतःचा सर्व्हर स्निपेट देखील लिहू शकता.

जॉन यापुढे ही फाईल सांभाळत नाही, जेन आता करते.

यूआरआयमध्ये जॉनचे नाव होते का? नाही, फाइल फक्त त्याच्या निर्देशिकेत होती का? बरं, ठीक आहे.

पूर्वी आम्ही यासाठी CGI स्क्रिप्ट वापरत होतो, परंतु आता आम्ही बायनरी प्रोग्राम वापरतो.

स्क्रिप्टद्वारे तयार केलेली पृष्ठे "cgibin" किंवा "cgi" क्षेत्रात स्थित असावीत अशी एक विलक्षण कल्पना आहे. हे तुम्ही तुमचा वेब सर्व्हर कसा चालवता याचे यांत्रिकी उघड करते. तुम्ही यंत्रणा बदलता (सामग्री जतन करतानाही), आणि अरेरे - तुमचे सर्व URI बदलतात.

उदाहरणार्थ नॅशनल सायन्स फाउंडेशन (NSF) घ्या:

NSF ऑनलाइन दस्तऐवज

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

येथे pubs/1998 शीर्षलेख भविष्यातील कोणत्याही अभिलेखीय सेवेला एक चांगला संकेत देईल की जुनी 1998 दस्तऐवज वर्गीकरण योजना प्रभावी आहे. जरी 2098 मध्ये दस्तऐवज क्रमांक भिन्न दिसत असले तरी, मी कल्पना करतो की हा URI अद्याप वैध असेल आणि NSF किंवा संग्रहण राखणाऱ्या इतर कोणत्याही संस्थेमध्ये हस्तक्षेप करणार नाही.

मला असे वाटले नाही की URLs कायम असणे आवश्यक आहे - तेथे URN होते.

हे कदाचित URN वादाच्या सर्वात वाईट दुष्परिणामांपैकी एक आहे. काही लोकांना वाटते की अधिक कायमस्वरूपी नेमस्पेसच्या संशोधनामुळे, ते लटकत असलेल्या दुव्यांबद्दल निष्काळजी असू शकतात कारण "URN हे सर्व निराकरण करतील." जर तुम्ही या लोकांपैकी एक असाल तर मी तुम्हाला निराश करू दे.

मी पाहिलेल्या बर्‍याच URN स्कीम्स ऑथॉरिटी आयडेंटिफायर सारख्या दिसतात ज्यानंतर एकतर तारीख आणि तुम्ही निवडलेली स्ट्रिंग किंवा तुम्ही निवडलेली स्ट्रिंग. हे HTTP URI सारखेच आहे. दुसऱ्या शब्दांत, तुमची संस्था दीर्घायुषी URN तयार करण्यास सक्षम असेल असे तुम्हाला वाटत असल्यास, ते तुमच्या HTTP URI साठी वापरून आता सिद्ध करा. एचटीटीपीमध्ये असे काहीही नाही ज्यामुळे तुमचा URI अस्थिर होतो. फक्त तुमची संस्था. एक डेटाबेस तयार करा जो दस्तऐवज URN ला सध्याच्या फाईलच्या नावावर मॅप करेल आणि वेब सर्व्हरला फायली पुनर्प्राप्त करण्यासाठी त्याचा वापर करू द्या.

जर तुम्ही या टप्प्यावर पोहोचला असाल, जर तुमच्याकडे काही सॉफ्टवेअर विकसित करण्यासाठी वेळ, पैसा आणि कनेक्शन नसेल, तर तुम्ही खालील निमित्त सांगू शकता:

आम्हाला हवे होते, परंतु आमच्याकडे योग्य साधने नाहीत.

परंतु आपण याबद्दल सहानुभूती बाळगू शकता. मी पूर्णपणे सहमत आहे. तुम्हाला काय करावे लागेल ते म्हणजे वेब सर्व्हरला सक्तीने पर्सिस्टंट यूआरआयचे त्वरित विश्लेषण करणे आणि फाइल तुमच्या सध्याच्या क्रेझी फाइल सिस्टीमवर जिथे जिथे संग्रहित आहे तिथे परत करणे. तुम्‍हाला सर्व यूआरआय फाइलमध्‍ये चेक म्‍हणून साठवायचे आहेत आणि डेटाबेस नेहमी अद्ययावत ठेवायचा आहे. तुम्हाला एकाच दस्तऐवजाच्या वेगवेगळ्या आवृत्त्या आणि अनुवाद यांच्यातील संबंध जपायचा आहे आणि फाईल अपघाती त्रुटीमुळे दूषित होणार नाही याची खात्री करण्यासाठी स्वतंत्र चेकसम रेकॉर्ड देखील ठेवायचा आहे. आणि वेब सर्व्हर या वैशिष्ट्यांसह बॉक्समधून बाहेर पडत नाहीत. जेव्हा तुम्हाला नवीन दस्तऐवज तयार करायचा असेल, तेव्हा तुमचे संपादक तुम्हाला URI नमूद करण्यास सांगतात.

तुम्ही URI न बदलता URI जागेत मालकी, दस्तऐवज प्रवेश, संग्रहण पातळी सुरक्षा इ. बदलण्यात सक्षम असणे आवश्यक आहे.

हे सर्व खूप वाईट आहे. पण आम्ही परिस्थिती दुरुस्त करू. W3C वर, आम्ही आवृत्त्यांचा मागोवा घेणारी Jigedit (जिगसॉ एडिटिंग सर्व्हर) कार्यक्षमता वापरतो आणि आम्ही दस्तऐवज निर्मिती स्क्रिप्टसह प्रयोग करतो. आपण साधने, सर्व्हर आणि क्लायंट विकसित केल्यास, या समस्येकडे लक्ष द्या!

हे निमित्त अनेक W3C पृष्ठांवर देखील लागू होते, यासह: म्हणून मी सांगतो तसे करा, मी करतो तसे नाही.

मी का काळजी करावी?

जेव्हा तुम्ही तुमच्या सर्व्हरवर URI बदलता, तेव्हा तुम्ही कधीही पूर्णपणे सांगू शकत नाही की जुन्या URI ची लिंक कोणाकडे असेल. हे नियमित वेब पृष्ठांचे दुवे असू शकतात. तुमचे पृष्ठ बुकमार्क करा. मित्राला लिहिलेल्या पत्राच्या मार्जिनमध्ये URI स्क्रॉल केले गेले असावे.

जेव्हा कोणी लिंक फॉलो करते आणि ती तुटलेली असते, तेव्हा त्यांचा सहसा सर्व्हर मालकावरील विश्वास कमी होतो. त्याचं ध्येय साध्य न केल्यामुळे तो निराश होतो — भावनिक आणि वास्तववादी दोन्हीही.

बरेच लोक नेहमी तुटलेल्या दुव्यांबद्दल तक्रार करतात आणि मला आशा आहे की नुकसान स्पष्ट आहे. मला आशा आहे की जेथे दस्तऐवज गायब झाला आहे त्या सर्व्हरच्या देखभाल करणार्‍याचे प्रतिष्ठेचे नुकसान देखील स्पष्ट आहे.

मग मी काय करू? URI डिझाइन

2 वर्षात, 20 वर्षात, 200 वर्षात वापरता येणारे URI वाटप करणे ही वेबमास्टरची जबाबदारी आहे. यासाठी विचारशीलता, संघटन आणि दृढनिश्चय आवश्यक आहे.

URI मध्ये कोणतीही माहिती बदलल्यास ते बदलतात. तुम्ही त्यांची रचना कशी करता हे खूप महत्वाचे आहे. (काय, यूआरआय डिझाइन? मला यूआरआय डिझाइन करण्याची आवश्यकता आहे का? होय, तुम्ही त्याबद्दल विचार केला पाहिजे). मुळात डिझाइन म्हणजे URI मधील कोणतीही माहिती सोडून देणे.

दस्तऐवज तयार केल्याची तारीख - URI जारी केल्याची तारीख - अशी गोष्ट आहे जी कधीही बदलणार नाही. नवीन प्रणाली वापरणार्‍या क्वेरी जुन्या सिस्टम वापरणार्‍यांपासून वेगळे करण्यासाठी हे खूप उपयुक्त आहे. URI सह प्रारंभ करण्यासाठी हे एक चांगले ठिकाण आहे. दस्तऐवज दिनांकित असल्यास, भविष्यात दस्तऐवज संबंधित असेल, तर ही एक चांगली सुरुवात आहे.

अपवाद फक्त एक पृष्ठ आहे जे हेतुपुरस्सर "नवीनतम" आवृत्ती आहे, उदाहरणार्थ संपूर्ण संस्थेसाठी किंवा त्याच्या मोठ्या भागासाठी.

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

मनी मासिकातील हा नवीनतम मनी डेली कॉलम आहे. या URI मध्ये तारखेची गरज नसण्याचे मुख्य कारण म्हणजे URI संचयित करण्याचे कोणतेही कारण नाही जे लॉगपेक्षा जास्त काळ टिकेल. मनी डेली ही संकल्पना मनी गायब झाली की नाहीशी होईल. जर तुम्हाला सामग्रीशी दुवा साधायचा असेल, तर तुम्ही संग्रहणांमध्ये त्याचा स्वतंत्रपणे दुवा साधावा:

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

(चांगले दिसते. pathfinder.com वर "पैसा" चा अर्थ आयुष्यभर एकच असेल असे गृहीत धरले आहे. डुप्लिकेट "98" आणि एक अनावश्यक ".html" आहे, परंतु अन्यथा मजबूत URI सारखे दिसते.

काय बाजूला ठेवावे

सर्व! निर्मिती तारखेव्यतिरिक्त, URI मध्ये कोणतीही माहिती टाकणे एक ना एक प्रकारे समस्या निर्माण करत आहे.

• लेखकाचे नाव. नवीन आवृत्त्या उपलब्ध झाल्यामुळे लेखकत्व बदलू शकते. लोक संस्था सोडतात आणि गोष्टी इतरांना देतात.
• विषय. ते खूप अवघड आहे. हे नेहमी प्रथम चांगले दिसते, परंतु आश्चर्यकारकपणे त्वरीत बदलते. मी खाली याबद्दल अधिक बोलेन.
• स्थिती. "जुने", "मसुदा" आणि यासारख्या डिरेक्टरी, "नवीनतम" आणि "कूल" असा उल्लेख करू नका, सर्व फाइल सिस्टममध्ये दिसतात. दस्तऐवज स्थिती बदलतात - अन्यथा मसुदे तयार करण्यात काही अर्थ नसतो. दस्तऐवजाच्या नवीनतम आवृत्तीला त्याची स्थिती विचारात न घेता सतत ओळखकर्ता आवश्यक आहे. स्टेटस नावाच्या बाहेर ठेवा.
• प्रवेश. W3C वर, आम्ही साइट कर्मचारी, सदस्य आणि लोकांसाठी विभागांमध्ये विभागली आहे. हे चांगले वाटते, परंतु अर्थातच, दस्तऐवजांची सुरुवात कर्मचार्‍यांकडून संघ कल्पना म्हणून केली जाते, सदस्यांशी चर्चा केली जाते आणि नंतर सार्वजनिक ज्ञान बनते. प्रत्येक वेळी एखादा दस्तऐवज व्यापक चर्चेसाठी उघडला गेल्यास त्यावरील सर्व जुने दुवे तुटले तर ही खरोखरच लाजिरवाणी गोष्ट आहे! आता आपण एका साध्या तारीख कोडकडे जाऊ.
• फाइल विस्तार. एक अतिशय सामान्य घटना. "cgi", अगदी ".html" भविष्यात बदलेल. तुम्ही या पानासाठी 20 वर्षात कदाचित HTML वापरत नसाल, पण आजच्या लिंक्सने अजूनही काम केले पाहिजे. W3C साइटवरील कॅनॉनिकल लिंक्स विस्तार वापरत नाहीत (ते कसे केले जाते).
• सॉफ्टवेअर यंत्रणा. URI मध्ये, "cgi", "exec" आणि इतर संज्ञा शोधा ज्या "आम्ही कोणते सॉफ्टवेअर वापरत आहोत ते पहा." पर्ल सीजीआय स्क्रिप्ट्स लिहिण्यात कोणाला आपले संपूर्ण आयुष्य घालवायचे आहे का? नाही? नंतर .pl एक्स्टेंशन काढून टाका. हे कसे करायचे ते सर्व्हर मॅन्युअल वाचा.
• डिस्कचे नाव. चला! पण मी हे पाहिले आहे.

तर आमच्या साइटवरील सर्वोत्तम उदाहरण सोपे आहे

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

... W3C अध्यक्षांच्या बैठकीच्या इतिवृत्तावर अहवाल.

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

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

वेबसाइट व्यवस्थापित करण्याचा हा एक मोहक मार्ग आहे—आणि संपूर्ण वेबसह काहीही व्यवस्थापित करण्याचा खरोखर मोहक मार्ग आहे. हा एक उत्तम मध्यम-मुदतीचा उपाय आहे परंतु दीर्घकालीन गंभीर कमतरता आहेत.

कारणाचा काही भाग अर्थाच्या तत्त्वज्ञानात आहे. भाषेतील प्रत्येक शब्द क्लस्टरिंगसाठी संभाव्य लक्ष्य आहे आणि प्रत्येक व्यक्तीला त्याचा अर्थ काय आहे याची वेगळी कल्पना असू शकते. संस्थांमधील संबंध झाडापेक्षा जालासारखे असल्याने, जे वेबशी सहमत आहेत ते देखील झाडाचे वेगळे प्रतिनिधित्व निवडू शकतात. सामान्य उपाय म्हणून श्रेणीबद्ध वर्गीकरणाच्या धोक्यांबद्दल ही माझी (अनेकदा पुनरावृत्ती केलेली) सामान्य निरीक्षणे आहेत.

खरं तर, जेव्हा तुम्ही URI मध्ये विषयाचे नाव वापरता, तेव्हा तुम्ही स्वत:ला काही प्रकारच्या वर्गीकरणासाठी बांधील आहात. कदाचित भविष्यात तुम्ही वेगळ्या पर्यायाला प्राधान्य द्याल. URI नंतर उल्लंघनास संवेदनशील असेल.

URI चा भाग म्हणून विषय क्षेत्र वापरण्याचे कारण म्हणजे URI स्पेसच्या उपविभागांची जबाबदारी सहसा सोपवली जाते, आणि नंतर तुम्हाला त्या सबस्पेससाठी जबाबदार असलेल्या ऑर्गनायझेशनल बॉडी - विभाग, गट किंवा जे काही - त्याचे नाव आवश्यक आहे. हे संस्थात्मक संरचनेसाठी बंधनकारक URI आहे. पुढील (डावीकडे) URI एखाद्या तारखेनुसार संरक्षित असेल तरच हे सहसा सुरक्षित असते: 1998/pics तुमच्या सर्व्हरसाठी "आम्ही 1998 मध्ये जे चित्रे म्हणतो त्या ऐवजी "आम्ही 1998 मध्ये चित्रांसह काय म्हणायचे" असा अर्थ असू शकतो.

डोमेन नाव विसरू नका

लक्षात ठेवा की हे केवळ URI मधील मार्गावरच लागू होत नाही, तर सर्व्हरच्या नावालाही लागू होते. तुमच्याकडे वेगवेगळ्या गोष्टींसाठी स्वतंत्र सर्व्हर असल्यास, लक्षात ठेवा की ही विभागणी अनेक, अनेक दुवे नष्ट केल्याशिवाय बदलणे अशक्य आहे. काही क्लासिक "आम्ही आज वापरत असलेल्या सॉफ्टवेअरकडे पहा" या चुका डोमेन नेम "cgi.pathfinder.com", "secure", "lists.w3.org" आहेत. ते सर्व्हर प्रशासन सुलभ करण्यासाठी डिझाइन केलेले आहेत. डोमेन तुमच्या कंपनीतील विभाग, दस्तऐवज स्थिती, प्रवेश पातळी किंवा सुरक्षितता पातळी दर्शवत आहे की नाही याची पर्वा न करता, एकाधिक दस्तऐवज प्रकारांसाठी एकापेक्षा जास्त डोमेन नाव वापरण्यापूर्वी अत्यंत सावधगिरी बाळगा. लक्षात ठेवा तुम्ही रीडायरेक्शन आणि प्रॉक्सी वापरून एकाच दृश्यमान वेब सर्व्हरमध्ये अनेक वेब सर्व्हर लपवू शकता.

अरे, आणि तुमच्या डोमेन नावाचा विचार करा. तुम्ही उत्पादनाच्या ओळी बदलल्यानंतर आणि साबण बनवणे थांबवल्यानंतर तुम्हाला soap.com म्हणून संबोधले जावे असे वाटत नाही (या क्षणी ज्याच्याकडे soap.com आहे त्याला क्षमस्व).

निष्कर्ष

2, 20, 200 किंवा 2000 वर्षांसाठी URI जतन करणे हे दिसते तितके सोपे नाही. तथापि, संपूर्ण इंटरनेटवर, वेबमास्टर असे निर्णय घेत आहेत जे भविष्यात स्वतःसाठी हे कार्य खरोखर कठीण करत आहेत. बहुतेकदा हे असे होते कारण ते अशी साधने वापरतात ज्यांचे कार्य केवळ या क्षणी सर्वोत्तम साइट सादर करणे आहे - आणि जेव्हा सर्वकाही बदलते तेव्हा दुव्यांचे काय होईल याचे कोणीही मूल्यांकन केले नाही. तथापि, येथे मुद्दा असा आहे की बर्‍याच, बर्‍याच गोष्टी बदलू शकतात आणि तुमचे URI समान राहू शकतात आणि राहू शकतात. हे तेव्हाच शक्य आहे जेव्हा तुम्ही ते कसे तयार करता याचा विचार करता.

हे सुद्धा पहाः

• याच विषयावर Jakob Nielsen चे tirade

जोडण्या

फाईल एक्स्टेंशन कसे काढायचे...

...वर्तमान फाइल-आधारित वेब सर्व्हरमधील URI वरून?

आपण Apache वापरत असल्यास, उदाहरणार्थ, आपण सामग्री वाटाघाटी करण्यासाठी कॉन्फिगर करू शकता. फाईल एक्स्टेंशन (उदा. png) फाईलमध्ये सेव्ह करा (उदा. mydog.png), परंतु तुम्ही त्याशिवाय वेब संसाधनाशी दुवा साधू शकता. Apache नंतर त्या नावाच्या आणि कोणत्याही विस्तारासह सर्व फायलींसाठी निर्देशिका तपासते आणि सेटमधून सर्वोत्तम निवडू शकते (उदाहरणार्थ, GIF आणि PNG). आणि वेगवेगळ्या प्रकारच्या फाईल्स वेगवेगळ्या डिरेक्टरीमध्ये ठेवण्याची गरज नाही, खरं तर तुम्ही तसे केल्यास सामग्री जुळणे कार्य करणार नाही.

• सामग्री वाटाघाटी करण्यासाठी तुमचा सर्व्हर सेट करा
• विस्ताराशिवाय नेहमी URI ला लिंक करा

विस्तारांसह दुवे अद्याप कार्य करतील, परंतु आपल्या सर्व्हरला सध्या आणि भविष्यात उपलब्ध सर्वोत्तम स्वरूप निवडण्यापासून प्रतिबंधित करतील.

(खरं तर, 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/ बंद शाळांच्या लांबलचक यादीसह.

कदाचित त्यांनी यादी मिळविण्यासाठी प्रणाली बदलली असेल - परंतु त्यांना URI बदलण्याची आवश्यकता नाही.

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

इंटरनेटवरील वाढत्या अवलंबित्वासह, एक हुशार कल्पना आली की निर्मात्याच्या वेबसाइटवरील दुवे अनुप्रयोगांमध्ये एम्बेड केले जाऊ शकतात. हे खूप वापरले आणि गैरवर्तन केले गेले आहे, परंतु तुम्ही URL बदलू शकत नाही. दुसर्‍याच दिवशी मी वेब/फ्री सामग्री मेनूमधील हेल्प/मायक्रोसॉफ्ट मधील मायक्रोसॉफ्ट नेटमीटिंग 2/समथिंग क्लायंटमधील लिंक वापरून पाहिली आणि मला 404 त्रुटी प्राप्त झाली - सर्व्हरकडून कोणताही प्रतिसाद मिळाला नाही. कदाचित ते आधीच निश्चित केले आहे ...

© 1998 टीम बीएल

ऐतिहासिक टीप: 20 व्या शतकाच्या उत्तरार्धात, जेव्हा हे लिहिले गेले तेव्हा, "कूल" हे मान्यतेचे प्रतीक होते, विशेषत: तरुण लोकांमध्ये, फॅशनेबिलिटी, गुणवत्ता किंवा योग्यता दर्शवते. घाईत, URI मार्ग बहुधा उपयुक्तता किंवा टिकाऊपणाऐवजी "थंडपणा" साठी निवडला गेला. ही पोस्ट कूल शोधण्यामागील ऊर्जा पुनर्निर्देशित करण्याचा प्रयत्न आहे.

स्त्रोत: www.habr.com