ليکڪ: سر ٽم برنرز-لي، URIs، URLs، HTTP، HTML ۽ ورلڊ وائڊ ويب جو موجد، ۽ W3C جو موجوده سربراهه. 1998ع ۾ لکيل مضمون

ڪهڙو URI سمجهي وڃي ٿو "ٿڌي"؟
جيڪو تبديل نٿو ٿئي.
URIs ڪيئن تبديل ڪيا ويا آهن؟
URIs تبديل نه ڪندا آھن: ماڻھو انھن کي تبديل ڪندا آھن.

نظريي ۾، ماڻهن لاءِ ڪو به سبب ناهي ته اهي URIs کي تبديل ڪن (يا دستاويزن کي سپورٽ ڪرڻ بند ڪن)، پر عملي طور تي انهن مان لکين ماڻهو آهن.

نظريي ۾، ڊومين جي نالي جي جڳهه جو نامزد مالڪ اصل ۾ ڊومين جي نالي جي جڳهه جو مالڪ آهي ۽ تنهن ڪري ان جي اندر اندر سڀئي URIs. ناداريءَ کان سواءِ، ڪا به شيءِ ڊومين جي نالي جي مالڪ کي نالو رکڻ کان روڪي ٿي. ۽ نظريي ۾، توهان جي ڊومين جي نالي هيٺ URI اسپيس مڪمل طور تي توهان جي ڪنٽرول هيٺ آهي، تنهنڪري توهان ان کي مستحڪم بڻائي سگهو ٿا جيئن توهان چاهيو. انٽرنيٽ تان هڪ دستاويز غائب ٿيڻ جو تمام گهڻو سٺو سبب اهو آهي ته اها ڪمپني جيڪا ڊومين جي نالي جي مالڪ آهي ڪاروبار کان ٻاهر ٿي چڪي آهي يا هاڻي سرور کي هلائڻ جي متحمل نه ٿي سگهي. ته پوءِ دنيا ۾ ايترا غائب لنڪ ڇو آهن؟ انهن مان ڪجهه صرف اڳڪٿي جي کوٽ آهي. هتي ڪجهه سبب آهن جيڪي توهان ٻڌي سگهو ٿا:

اسان صرف ان کي بهتر بڻائڻ لاءِ سائيٽ کي ٻيهر منظم ڪيو.

ڇا توهان واقعي سوچيو ٿا پراڻا URIs هاڻي ڪم نٿا ڪري سگهن؟ جيڪڏهن ائين آهي، ته پوء توهان انهن کي تمام خراب چونڊيو. نون کي رکڻ تي غور ڪريو ايندڙ نئين ڊيزائن لاءِ.

اسان وٽ تمام گھڻو سامان آھي جو اسان ان جي ٽريڪ نٿا رکي سگھون ته ڇا پراڻو آھي، ڇا ڳجھو آھي، ۽ ڇا اڃا لاڳاپيل آھي، تنھنڪري اسان اھو بھتر سمجھيو آھي ته ان کي بند ڪري ڇڏيون.

مان صرف همدردي ڪري سگهان ٿو. W3C هڪ دور مان گذريو جتي اسان کي احتياط سان آرڪائيو مواد ذريعي رازداري لاءِ انهن کي عام ڪرڻ کان اڳ ڇڪڻو پوندو هو. فيصلو اڳ ۾ ئي سوچڻ گهرجي - پڪ ڪريو ته هر دستاويز سان توهان قابل قبول پڙهندڙن، تخليق جي تاريخ ۽ مثالي طور تي ختم ٿيڻ جي تاريخ کي رڪارڊ ڪيو. هي ميٽا ڊيٽا محفوظ ڪريو.

خير، اسان دريافت ڪيو ته اسان کي فائلن کي منتقل ڪرڻ جي ضرورت آهي ...

اهو سڀ کان وڌيڪ ڏکوئيندڙ عذر مان هڪ آهي. گھڻا ماڻھو نه ٿا ڄاڻن ته ويب سرورز توھان کي اجازت ڏين ٿا ھڪڙي اعتراض جي URI ۽ فائل سسٽم ۾ ان جي حقيقي جڳھ جي وچ ۾ تعلق کي ڪنٽرول ڪن. سوچيو URI اسپيس کي خلاصي جاءِ طور، مڪمل طور تي منظم. پوءِ جيڪا به حقيقت توهان ان کي محسوس ڪرڻ لاءِ استعمال ڪندا آهيو ان جو نقشو ٺاهيو. پوء هن ويب سرور کي رپورٽ ڪريو. توھان ان کي درست ڪرڻ لاءِ پنھنجو سرور جو ٽڪرو پڻ لکي سگھو ٿا.

جان هاڻي هن فائل کي برقرار نٿو رکي، جين هاڻي ڪندو آهي.

يو آر آئي ۾ جان جو نالو هو؟ نه، فائل صرف هن جي ڊاريڪٽري ۾ هئي؟ چڱو، ٺيڪ آهي.

اڳي اسان ان لاءِ CGI اسڪرپٽ استعمال ڪندا هئاسين، پر هاڻي اسان بائنري پروگرام استعمال ڪندا آهيون.

اتي ھڪڙو چريو خيال آھي ته اسڪرپٽ پاران ٺاھيل صفحا "cgibin" يا "cgi" واري علائقي ۾ واقع ھجن. هي ميخانيات کي ظاهر ڪري ٿو ته توهان پنهنجي ويب سرور کي ڪيئن هلائيندا آهيو. توھان ميکانيزم کي تبديل ڪريو (جيتوڻيڪ مواد کي محفوظ ڪرڻ دوران)، ۽ اوپو - توھان جا سڀئي يو آر آئي تبديل ڪريو.

مثال طور نيشنل سائنس فائونڊيشن (NSF) وٺو:

NSF آن لائن دستاويز

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

دستاويز ڏسڻ شروع ڪرڻ لاءِ پهريون صفحو واضح طور تي ڪجهه سالن ۾ ساڳيو نه رهندو. cgi-bin, oldbrowse и pl - هي سڀ ڪجهه معلومات ڏئي ٿو ته اسان-کي-ڪيئن-اِهو-هاڻي- ڪريون ٿا. جيڪڏهن توهان ڪنهن دستاويز کي ڳولڻ لاءِ صفحو استعمال ڪريو ٿا، ته پهريون نتيجو جيڪو توهان حاصل ڪيو اهو ساڳيو خراب آهي:

Cryptology ۽ ڪوڊنگ ٿيوري تي ڪم ڪندڙ گروپ جي رپورٽ

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

دستاويز جي اشاري واري صفحي لاء، جيتوڻيڪ html دستاويز پاڻ کي بهتر ڏسڻ ۾ اچي ٿو:

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

هتي پبس/1998 هيڊر ڪنهن به مستقبل جي آرڪائيو سروس کي سٺو اشارو ڏيندو ته پراڻي 1998 دستاويزن جي درجه بندي اسڪيم اثر ۾ آهي. جيتوڻيڪ دستاويز نمبر 2098 ۾ مختلف نظر اچن ٿا، مان سمجهان ٿو ته هي URI اڃا به صحيح هوندو ۽ NSF يا ڪنهن ٻئي تنظيم سان مداخلت نه ڪندو جيڪو آرڪائيو کي برقرار رکندو.

مون اهو نه سوچيو ته URLs لڳاتار هجڻ گهرجن - اتي URNs هئا.

اهو شايد URN بحث جي بدترين ضمني اثرات مان هڪ آهي. ڪجهه ماڻهن جو خيال آهي ته تحقيق جي ڪري وڌيڪ مستقل نالن جي جاءِ تي، اهي شايد ڳنڍيندڙ ڳنڍين جي باري ۾ لاپرواهي ڪن ڇو ته "URNs اهو سڀ ڪجهه ٺيڪ ڪري ڇڏيندو." جيڪڏھن توھان انھن ماڻھن مان ھڪڙو آھيو، پوء مون کي توھان کي مايوس ڪرڻ ڏيو.

اڪثر URN اسڪيمون جيڪي مون ڏٺيون آهن اٿارٽي سڃاڻپ ڪندڙ وانگر نظر اينديون آهن يا ته هڪ تاريخ ۽ هڪ اسٽرنگ جنهن کي توهان چونڊيو آهي، يا صرف هڪ تار جيڪو توهان چونڊيو آهي. اهو تمام گهڻو هڪ HTTP URI سان ملندڙ جلندڙ آهي. ٻين لفظن ۾، جيڪڏهن توهان سوچيو ته توهان جو ادارو ڊگھي زندگين URNs ٺاهڻ جي قابل هوندو، پوء ان کي ثابت ڪريو انهن کي استعمال ڪندي پنهنجي HTTP URIs لاءِ. HTTP پاڻ ۾ ڪجھ به ناهي جيڪو توهان جي URI کي غير مستحڪم بڻائي ٿو. صرف توهان جي تنظيم. ھڪڙو ڊيٽابيس ٺاھيو جيڪو نقشو ٺاھيو دستاويز URN کي موجوده فائل جي نالي سان، ۽ ويب سرور کي استعمال ڪرڻ ڏيو اصل ۾ فائلن کي حاصل ڪرڻ لاء.

جيڪڏهن توهان هن نقطي تي پهچي ويا آهيو، جيڪڏهن توهان وٽ ڪجهه سافٽ ويئر ٺاهڻ لاء وقت، پئسا ۽ ڪنيڪشن نه آهي، ته پوء توهان هيٺ ڏنل عذر بيان ڪري سگهو ٿا:

اسان چاهيون ٿا، پر اسان وٽ صرف صحيح اوزار نه آهن.

پر توهان هن سان همدردي ڪري سگهو ٿا. مان مڪمل طور تي متفق آهيان. توهان کي ڇا ڪرڻ جي ضرورت آهي ويب سرور کي فوري طور تي مسلسل URI کي پارس ڪرڻ ۽ فائل کي واپس ڪرڻ لاءِ مجبور ڪيو جتي اهو هن وقت توهان جي موجوده چريو فائل سسٽم تي محفوظ ٿيل آهي. توھان چاھيو ٿا ته سڀئي URIs ھڪڙي فائل ۾ ھڪڙي چيڪ جي طور تي ذخيرو ڪريو ۽ ڊيٽابيس کي ھر وقت اپڊيٽ رکو. توھان چاھيو ٿا ته ساڳي دستاويز جي مختلف ورزن ۽ ترجمن جي وچ ۾ لاڳاپا محفوظ ڪريو، ۽ پڻ ھڪ آزاد چيڪسم رڪارڊ کي برقرار رکڻ چاھيو ٿا ته ان کي يقيني بڻائڻ لاءِ ته فائل حادثاتي غلطي سان خراب نه ٿئي. ۽ ويب سرور صرف انهن خاصيتن سان دٻي مان ٻاهر نٿا اچن. جڏهن توهان هڪ نئون دستاويز ٺاهڻ چاهيو ٿا، توهان جو ايڊيٽر توهان کان پڇي ٿو هڪ URI بيان ڪرڻ لاءِ.

توهان کي URI کي تبديل ڪرڻ کان سواءِ URI اسپيس ۾ ملڪيت، دستاويز جي رسائي، آرڪائيو ليول سيڪيورٽي، وغيره تبديل ڪرڻ جي ضرورت پوندي.

اهو سڀ ڪجهه خراب آهي. پر اسان صورتحال کي درست ڪنداسين. W3C تي، اسان استعمال ڪريون ٿا Jigedit (Jigsaw ايڊيٽنگ سرور) ڪارڪردگي جيڪا ورجن کي ٽريڪ ڪري ٿي، ۽ اسان دستاويز ٺاھڻ واري اسڪرپٽ سان تجربو ڪريون ٿا. جيڪڏهن توهان اوزار، سرور، ۽ ڪلائنٽ ٺاهي، هن مسئلي تي ڌيان ڏيو!

اهو عذر ڪيترن ئي W3C صفحن تي پڻ لاڳو ٿئي ٿو، جنهن ۾ هي هڪ شامل آهي: ائين ڪريو جيئن مان چوان ٿو، نه جيئن مان ڪريان ٿو.

مون کي پرواه ڇو ڪرڻ گهرجي؟

جڏهن توهان پنهنجي سرور تي URI تبديل ڪندا آهيو، توهان ڪڏهن به مڪمل طور تي نه ٿا ٻڌائي سگهو ته ڪنهن وٽ پراڻي URI سان ڪڙيون هونديون. اهي باقاعده ويب صفحن مان لنڪ ٿي سگهن ٿيون. پنھنجي صفحي کي نشانو بڻايو. URI شايد ڪنهن دوست ڏانهن خط جي حاشيا ۾ اسڪرول ڪيو ويو هجي.

جڏهن ڪو ماڻهو هڪ لنڪ جي پيروي ڪري ٿو ۽ اهو ڀڄي ويو آهي، اهي عام طور تي سرور جي مالڪ تي اعتماد وڃائي ٿو. هو پنهنجي مقصد حاصل ڪرڻ جي قابل نه هئڻ ڪري جذباتي ۽ جسماني طور پڻ مايوس آهي.

گھڻا ماڻھو شڪايت ڪندا آھن ٽٽل لنڪن بابت ھر وقت، ۽ اميد اٿم ته نقصان پڌرو آھي. مون کي اميد آهي ته سرور جي سنڀاليندڙ کي شهرت جو نقصان جتي دستاويز غائب ٿي ويو آهي پڻ واضح آهي.

پوء مون کي ڇا ڪرڻ گهرجي؟ URI ڊيزائن

اهو ويب ماسٽر جي ذميواري آهي ته URIs مختص ڪرڻ جيڪي 2 سالن ۾، 20 سالن ۾، 200 سالن ۾ استعمال ڪري سگهجن ٿيون. ان لاءِ سوچ، تنظيم ۽ عزم جي ضرورت آهي.

URIs تبديل ڪندا آھن جيڪڏھن انھن ۾ ڪا ڄاڻ تبديل ٿي وڃي. توهان انهن کي ڪيئن ٺاهيو اهو تمام ضروري آهي. (ڇا، 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" ۽ ٻيا اصطلاح جيڪي چيري "ڏسو ته اسان ڪھڙو سافٽ ويئر استعمال ڪري رھيا آھيون." ڇا ڪو ماڻھو پنھنجي سڄي زندگي Perl CGI اسڪرپٽ لکڻ ۾ گذارڻ چاھي ٿو؟ نه؟ پوءِ .pl ايڪسٽينشن کي هٽايو. اهو ڪيئن ڪجي سرور مينوئل پڙهو.
ڊسڪ جو نالو. اچو به! پر مون اهو ڏٺو آهي.

تنهنڪري اسان جي سائيٽ مان بهترين مثال سادو آهي

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

... W3C چيئرز جي اجلاس جي منٽس تي رپورٽ.

عنوانن ۽ موضوع جي لحاظ کان درجه بندي

مان هن خطري بابت وڌيڪ تفصيل ۾ ويندس، ڇاڪاڻ ته اهو انهن شين مان هڪ آهي جنهن کان بچڻ تمام ڏکيو آهي. عام طور تي، موضوع ختم ٿي ويندا آهن URIs ۾ جڏهن توهان پنهنجي دستاويزن کي درجه بندي ڪندا آهيو انهن ڪم جي حساب سان. پر اهو وقفو وقت سان تبديل ٿيندو. علائقن جا نالا تبديل ٿي ويندا. W3C تي اسان مارڪ اپ کي مارڪ اپ ۽ پوءِ HTML ۾ تبديل ڪرڻ چاهيون ٿا سيڪشن جي اصل مواد کي ظاهر ڪرڻ لاءِ. ان کان سواء، اتي اڪثر هڪ فليٽ نالو جاء آهي. 100 سالن ۾، توهان کي پڪ آهي ته توهان ڪجهه به ٻيهر استعمال ڪرڻ نٿا چاهيو؟ اسان جي مختصر زندگي ۾ اسان اڳ ۾ ئي "تاريخ" ۽ "اسٽائل شيٽ" مثال طور ٻيهر استعمال ڪرڻ چاهيندا هئاسين.

اهو هڪ ويب سائيٽ کي منظم ڪرڻ جو هڪ پرجوش طريقو آهي- ۽ ڪنهن به شيءِ کي منظم ڪرڻ جو هڪ واقعي پرجوش طريقو آهي، بشمول پوري ويب. هي هڪ بهترين وچولي مدي وارو حل آهي پر ڊگهي مدي ۾ سنگين خاميون آهن.

دليل جو حصو معني جي فلسفي ۾ آهي. ٻوليءَ ۾ هر اصطلاح ڪلستر ڪرڻ لاءِ هڪ امڪاني حدف آهي، ۽ هر ماڻهوءَ جو مختلف خيال ٿي سگهي ٿو ته ان جو مطلب ڇا آهي. جيئن ته ادارن جي وچ ۾ لاڳاپا هڪ وڻ کان وڌيڪ ويب وانگر آهن، جيتوڻيڪ اهي جيڪي ويب سان متفق آهن اهي وڻ جي مختلف نمائندگي چونڊي سگهن ٿا. ھي آھن منھنجا (اڪثر بار بار) عام مشاھد عام حل جي طور تي درجي بندي جي خطرن بابت.

حقيقت ۾، جڏهن توهان هڪ URI ۾ هڪ موضوع جو نالو استعمال ڪندا آهيو، توهان پنهنجو پاڻ کي ڪنهن قسم جي درجه بندي ڪرڻ لاء ڪم ڪري رهيا آهيو. ٿي سگهي ٿو ته مستقبل ۾ توهان هڪ مختلف اختيار کي ترجيح ڏيندو. URI پوءِ ان جي خلاف ورزي لاءِ حساس هوندو.

URI جي حصي جي طور تي هڪ موضوع واري علائقي کي استعمال ڪرڻ جو سبب اهو آهي ته URI اسپيس جي ذيلي حصن جي ذميواري عام طور تي نمائندي ڪئي ويندي آهي، ۽ پوء توهان کي تنظيمي اداري جي نالي جي ضرورت آهي - ڊپارٽمينٽ، گروپ، يا ٻيو ڪجهه - جيڪو ان سب اسپيس لاء ذميوار آهي. هي هڪ تنظيمي ڍانچي لاءِ پابند URI آهي. اهو عام طور تي صرف محفوظ هوندو آهي جيڪڏهن اڳتي (کاٻي) URI تاريخ جي لحاظ کان محفوظ آهي: 1998/pics شايد توهان جي سرور جي معنيٰ هجي ”ڇا اسان جو مطلب 1998 ۾ تصويرن سان آهي“ بجاءِ ”1998 ۾ اسان ڇا ڪيو جنهن کي اسان هاڻي تصويرون سڏين ٿا“.

ڊومين جو نالو نه وساريو

ياد رهي ته اهو لاڳو ٿئي ٿو نه رڳو URI ۾ رستي تي، پر سرور جي نالي تي پڻ. جيڪڏهن توهان وٽ مختلف شين لاءِ الڳ سرور آهن، ياد رکو ته هي ڊويزن ڪيترن ئي، گهڻن لنڪن کي تباهه ڪرڻ کان سواءِ تبديل ڪرڻ ناممڪن ٿي پوندو. ڪجھ کلاسک "ڏسو سافٽ ويئر اسان اڄ استعمال ڪندا آهيون" غلطيون ڊومين جا نالا آهن "cgi.pathfinder.com"، "محفوظ"، "lists.w3.org". اهي ٺهيل آهن سرور انتظاميه کي آسان ڪرڻ لاء. ان کان سواءِ ته ڇا هڪ ڊومين توهان جي ڪمپني ۾ هڪ ڊويزن جي نمائندگي ڪري ٿو، هڪ دستاويز جي حيثيت، هڪ رسائي جي سطح، يا سيڪيورٽي سطح، تمام گهڻو محتاط رهو، هڪ کان وڌيڪ ڊومين جو نالو استعمال ڪرڻ کان پهريان ڪيترن ئي دستاويز جي قسمن لاءِ. ياد رکو ته توھان لڪائي سگھوٿا گھڻن ويب سرورن کي ھڪڙي ھڪڙي ڏسڻ واري ويب سرور اندر ريڊائريڪشن ۽ پراڪسينگ استعمال ڪندي.

او، ۽ توهان جي ڊومين جي نالي بابت پڻ سوچيو. توھان نٿا چاھيو ته صابڻ.com جو حوالو ڏنو وڃي توھان کان پوءِ توھان پراڊڪٽ جون لائينون تبديل ڪريو ۽ صابن ٺاهڻ بند ڪيو (معاف ڪجو جيڪو ھن وقت soap.com جو مالڪ آھي).

ٿڪل

2، 20، 200، يا ان کان به 2000 سالن لاءِ يو آر آئي کي محفوظ ڪرڻ واضح طور تي ايترو آسان ناهي جيترو لڳي ٿو. بهرحال، انٽرنيٽ تي، ويب ماسٽرز فيصلا ڪري رهيا آهن جيڪي هن ڪم کي مستقبل ۾ پاڻ لاء واقعي ڏکيو بڻائي رهيا آهن. گهڻو ڪري اهو آهي ڇاڪاڻ ته اهي اوزار استعمال ڪندا آهن جن جي نوڪري صرف هن وقت بهترين سائيٽ پيش ڪرڻ آهي - ۽ ڪنهن به اهو اندازو نه ڪيو آهي ته لنڪس ڇا ٿيندو جڏهن هر شيء تبديل ٿيندي. جڏهن ته، هتي نقطو اهو آهي ته ڪيتريون ئي شيون تبديل ٿي سگهن ٿيون، ۽ توهان جي يو آر آئي ٿي سگهي ٿي ۽ ساڳيو رهڻ گهرجي. اهو صرف ممڪن آهي جڏهن توهان سوچيو ته توهان انهن کي ڪيئن ٺاهيو.

پڻ ڏسندا

ساڳئي موضوع تي جيڪب نيلسن جي ٽائريڊ

اضافا

فائل ايڪسٽينشن کي ڪيئن ختم ڪجي...

... موجوده فائل تي ٻڌل ويب سرور ۾ URI کان؟

جيڪڏهن توهان Apache استعمال ڪريو ٿا، مثال طور، توهان ان کي ترتيب ڏئي سگهو ٿا مواد ڳالهين لاءِ. فائل ايڪسٽينشن (مثال طور .png) کي فائل ۾ محفوظ ڪريو (مثال طور. mydog.png)، پر توهان ان جي بغير ڪنهن ويب وسيلن سان ڳنڍي سگهو ٿا. Apache پوءِ ڊاريڪٽري کي چيڪ ڪري ٿو سڀني فائلن لاءِ ان نالي سان ۽ ڪنهن به توسيع سان، ۽ سيٽ مان بهترين چونڊيو (مثال طور، GIF ۽ PNG). ۽ مختلف قسم جي فائلن کي مختلف ڊائريڪٽرن ۾ رکڻ جي ڪا ضرورت ناهي، حقيقت ۾ مواد جي ميلاپ ڪم نه ڪندي جيڪڏهن توهان ائين ڪندا.

مواد جي ڳالهين لاءِ پنهنجو سرور قائم ڪريو
هميشه بغير واڌ جي URIs سان ڳنڍيو

ملندڙ لنڪس اڃا به ڪم ڪندا، پر توهان جي سرور کي موجوده ۽ مستقبل ۾ موجود بهترين فارميٽ چونڊڻ کان روڪيندا.

(حقيقت ۾، 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: Microsoft Netmeeting

انٽرنيٽ تي وڌندڙ انحصار سان، هڪ هوشيار خيال آيو ته ٺاهيندڙن جي ويب سائيٽ جون لنڪس ايپليڪيشنن ۾ شامل ٿي سگهن ٿيون. ھي گھڻو استعمال ڪيو ويو آھي ۽ غلط استعمال ڪيو ويو آھي، پر توھان URL تبديل نٿا ڪري سگھو. بس ٻئي ڏينهن مون Microsoft Netmeeting 2/something ڪلائنٽ مان هڪ لنڪ جي ڪوشش ڪئي مدد/Microsoft on the Web/Free stuff menu ۽ هڪ 404 غلطي ملي - سرور کان ڪوبه جواب نه مليو. ٿي سگهي ٿو اهو اڳ ۾ ئي طئي ٿيل آهي ...

تاريخي نوٽ: 20 صدي جي آخر ۾، جڏهن هي لکيو ويو، "ٿڌي" منظوري جو هڪ نمونو هو، خاص طور تي نوجوانن ۾، فيشن، معيار، يا مناسبيت جي نشاندهي ڪري ٿو. تڪڙ ۾، URI جو رستو اڪثر ڪري ”ٿڌائي“ لاءِ چونڊيو ويندو هو بلڪه افاديت يا استحڪام جي. هي پوسٽ ٿڌي جي ڳولا جي پويان توانائي کي ريڊريٽ ڪرڻ جي ڪوشش آهي.

جو ذريعو: www.habr.com

ٿڌي URIs تبديل نه ڪندا آھن