مصنف: سر ٹم برنرز لی، URIs، URLs، HTTP، HTML اور ورلڈ وائڈ ویب کے موجد، اور W3C کے موجودہ سربراہ۔ 1998 میں لکھا گیا مضمون

کس URI کو "ٹھنڈا" سمجھا جاتا ہے؟
ایک جو تبدیل نہیں ہوتا۔
URIs کیسے تبدیل ہوتے ہیں؟
URIs تبدیل نہیں ہوتے ہیں: لوگ انہیں تبدیل کرتے ہیں۔

اصولی طور پر، لوگوں کے لیے URIs کو تبدیل کرنے کی کوئی وجہ نہیں ہے (یا معاون دستاویزات کو روک دیں)، لیکن عملی طور پر ان میں سے لاکھوں ہیں۔

نظریہ میں، ڈومین نام کی جگہ کا برائے نام مالک دراصل ڈومین نام کی جگہ کا مالک ہوتا ہے اور اس لیے اس کے اندر موجود تمام URIs۔ دیوالیہ پن کے علاوہ، کوئی بھی چیز ڈومین نام کے مالک کو نام رکھنے سے نہیں روکتی۔ اور نظریہ میں، آپ کے ڈومین نام کے تحت URI کی جگہ مکمل طور پر آپ کے کنٹرول میں ہے، لہذا آپ اسے اپنی مرضی کے مطابق مستحکم بنا سکتے ہیں۔ انٹرنیٹ سے کسی دستاویز کے غائب ہونے کی ایک ہی اچھی وجہ یہ ہے کہ وہ کمپنی جس کے پاس ڈومین نام ہے وہ کاروبار سے باہر ہو چکی ہے یا سرور کو چلانے کی مزید متحمل نہیں ہو سکتی۔ پھر دنیا میں اتنے مسنگ لنکس کیوں ہیں؟ اس میں سے کچھ محض پیشن گوئی کی کمی ہے۔ یہاں کچھ وجوہات ہیں جو آپ سن سکتے ہیں:

ہم نے صرف سائٹ کو بہتر بنانے کے لیے اسے دوبارہ منظم کیا۔

کیا آپ واقعی سوچتے ہیں کہ پرانے URI اب کام نہیں کر سکتے؟ اگر ایسا ہے، تو آپ نے انہیں بہت خراب طریقے سے منتخب کیا۔ اگلے نئے ڈیزائن کے لیے نئے رکھنے پر غور کریں۔

ہمارے پاس اتنی چیزیں ہیں کہ ہم اس پر نظر نہیں رکھ سکتے کہ کیا پرانا ہے، کیا رازدارانہ ہے، اور کیا اب بھی متعلقہ ہے، اس لیے ہم نے ان سب کو بند کر دینا ہی بہتر سمجھا۔

میں صرف ہمدردی ہی کر سکتا ہوں۔ W3C ایک ایسے دور سے گزرا جہاں ہمیں رازداری کے لیے محفوظ شدہ مواد کو عام کرنے سے پہلے احتیاط سے چھاننا پڑا۔ فیصلہ پہلے سے سوچ لیا جانا چاہئے - اس بات کو یقینی بنائیں کہ ہر دستاویز کے ساتھ آپ قابل قبول قارئین، تخلیق کی تاریخ اور مثالی طور پر میعاد ختم ہونے کی تاریخ درج کریں۔ اس میٹا ڈیٹا کو محفوظ کریں۔

ٹھیک ہے، ہم نے دریافت کیا کہ ہمیں فائلوں کو منتقل کرنے کی ضرورت ہے...

یہ سب سے زیادہ قابل رحم عذروں میں سے ایک ہے۔ بہت سے لوگ نہیں جانتے کہ ویب سرورز آپ کو کسی چیز کے URI اور فائل سسٹم میں اس کے اصل مقام کے درمیان تعلق کو کنٹرول کرنے کی اجازت دیتے ہیں۔ 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 یا آرکائیو کو برقرار رکھنے والی کسی دوسری تنظیم کے ساتھ مداخلت نہیں کرے گا۔

مجھے نہیں لگتا تھا کہ یو آر ایل کو مستقل رہنا چاہیے - یو آر این تھے۔

یہ شاید URN بحث کے بدترین ضمنی اثرات میں سے ایک ہے۔ کچھ لوگوں کا خیال ہے کہ زیادہ مستقل نام کی جگہ کی تحقیق کی وجہ سے، وہ لٹکتے روابط کے بارے میں لاپرواہ ہو سکتے ہیں کیونکہ "URNs یہ سب ٹھیک کر دیں گے۔" اگر آپ ان لوگوں میں سے ایک ہیں تو مجھے آپ کو مایوس کرنے دیں۔

زیادہ تر URN اسکیمیں جو میں نے دیکھی ہیں وہ ایک اتھارٹی شناخت کنندہ کی طرح نظر آتی ہیں جس کے بعد یا تو تاریخ اور ایک سٹرنگ جو آپ منتخب کرتے ہیں، یا صرف ایک سٹرنگ جو آپ منتخب کرتے ہیں۔ یہ HTTP URI سے بہت ملتا جلتا ہے۔ دوسرے لفظوں میں، اگر آپ کو لگتا ہے کہ آپ کی تنظیم طویل المدت URNs بنانے کے قابل ہو گی، تو اپنے HTTP URIs کے لیے انہیں استعمال کر کے ابھی ثابت کریں۔ خود HTTP میں کچھ بھی نہیں ہے جو آپ کے URI کو غیر مستحکم بناتا ہے۔ صرف آپ کی تنظیم۔ ایک ڈیٹا بیس بنائیں جو دستاویز URN کو موجودہ فائل کے نام سے نقشہ بناتا ہے، اور ویب سرور کو فائلوں کو اصل میں بازیافت کرنے کے لیے استعمال کرنے دیں۔

اگر آپ اس مقام پر پہنچ چکے ہیں، اگر آپ کے پاس کچھ سافٹ ویئر تیار کرنے کے لیے وقت، پیسہ اور کنکشن نہیں ہے، تو آپ درج ذیل عذر بیان کر سکتے ہیں:

ہم چاہتے تھے، لیکن ہمارے پاس صحیح ٹولز نہیں ہیں۔

لیکن آپ اس سے ہمدردی کر سکتے ہیں۔ میں مکمل اتفاق کرتا ہوں. آپ کو کیا کرنے کی ضرورت ہے ویب سرور کو فوری طور پر مستقل URI کو پارس کرنے اور فائل کو واپس کرنے پر مجبور کرنا ہے جہاں بھی یہ آپ کے موجودہ پاگل فائل سسٹم میں محفوظ ہے۔ آپ تمام URIs کو ایک فائل میں بطور چیک اسٹور کرنا چاہتے ہیں اور ڈیٹا بیس کو ہر وقت اپ ٹو ڈیٹ رکھنا چاہتے ہیں۔ آپ ایک ہی دستاویز کے مختلف ورژن اور ترجمے کے درمیان تعلق کو محفوظ رکھنا چاہتے ہیں، اور یہ یقینی بنانے کے لیے ایک آزاد چیکسم ریکارڈ بھی برقرار رکھنا چاہتے ہیں کہ فائل کسی حادثاتی غلطی سے خراب نہ ہو۔ اور ویب سرور ان خصوصیات کے ساتھ باکس سے باہر نہیں آتے ہیں۔ جب آپ ایک نئی دستاویز بنانا چاہتے ہیں، تو آپ کا ایڈیٹر آپ سے URI بتانے کو کہتا ہے۔

آپ کو URI کو تبدیل کیے بغیر URI اسپیس میں ملکیت، دستاویز تک رسائی، آرکائیو لیول سیکیورٹی وغیرہ کو تبدیل کرنے کے قابل ہونے کی ضرورت ہے۔

یہ سب بہت برا ہے۔ لیکن ہم حالات کو درست کریں گے۔ W3C میں، ہم Jigedit (Jigsaw ایڈیٹنگ سرور) کی فعالیت کا استعمال کرتے ہیں جو ورژن کو ٹریک کرتی ہے، اور ہم دستاویز کی تخلیق کے اسکرپٹ کے ساتھ تجربہ کرتے ہیں۔ اگر آپ ٹولز، سرورز اور کلائنٹس تیار کرتے ہیں تو اس مسئلے پر توجہ دیں!

یہ عذر بہت سے W3C صفحات پر بھی لاگو ہوتا ہے، جس میں یہ ایک بھی شامل ہے: جیسا کہ میں کہتا ہوں ویسا نہیں، جیسا کہ میں کرتا ہوں۔

میں کیوں فکر کروں؟

جب آپ اپنے سرور پر یو آر آئی کو تبدیل کرتے ہیں، تو آپ کبھی بھی مکمل طور پر یہ نہیں بتا سکتے کہ پرانے یو آر آئی کے لنک کس کے پاس ہوں گے۔ یہ باقاعدہ ویب صفحات کے لنکس ہو سکتے ہیں۔ اپنے صفحہ کو بک مارک کریں۔ ہو سکتا ہے کہ URI کسی دوست کو لکھے گئے خط کے حاشیے میں کھرچ دیا گیا ہو۔

جب کوئی کسی لنک کی پیروی کرتا ہے اور وہ ٹوٹ جاتا ہے، تو وہ عام طور پر سرور کے مالک پر اعتماد کھو دیتے ہیں۔ وہ اپنے مقصد کو حاصل کرنے کے قابل نہ ہونے کی وجہ سے جذباتی اور جسمانی طور پر بھی مایوس ہے۔

بہت سارے لوگ ہر وقت ٹوٹے ہوئے لنکس کے بارے میں شکایت کرتے ہیں، اور مجھے امید ہے کہ نقصان واضح ہے۔ مجھے امید ہے کہ سرور کے مینٹینر کو ہونے والا نقصان جہاں دستاویز غائب ہوا ہے وہ بھی واضح ہے۔

تو مجھے کیا کرنا چاھیے؟ URI ڈیزائن

یہ ویب ماسٹر کی ذمہ داری ہے کہ وہ URIs مختص کرے جو 2 سال میں، 20 سالوں میں، 200 سالوں میں استعمال کیے جاسکتے ہیں۔ اس کے لیے سوچ، تنظیم اور عزم کی ضرورت ہے۔

اگر ان میں کوئی بھی معلومات تبدیل ہوتی ہیں تو URI بدل جاتے ہیں۔ آپ انہیں کس طرح ڈیزائن کرتے ہیں یہ بہت اہم ہے۔ (کیا، 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 چیئرز میٹنگ کے منٹس پر رپورٹ۔

عنوانات اور عنوان کے لحاظ سے درجہ بندی

میں اس خطرے کے بارے میں مزید تفصیل میں جاؤں گا، کیونکہ یہ ان چیزوں میں سے ایک ہے جس سے بچنا سب سے مشکل ہے۔ عام طور پر، موضوعات URIs میں ختم ہوتے ہیں جب آپ اپنے دستاویزات کو ان کے کام کے لحاظ سے درجہ بندی کرتے ہیں۔ لیکن یہ ٹوٹ پھوٹ وقت کے ساتھ بدلے گی۔ علاقوں کے نام بدلیں گے۔ W3C میں ہم سیکشن کے اصل مواد کو ظاہر کرنے کے لیے MarkUP کو Markup اور پھر HTML میں تبدیل کرنا چاہتے تھے۔ اس کے علاوہ، اکثر فلیٹ نام کی جگہ ہوتی ہے۔ 100 سالوں میں، کیا آپ کو یقین ہے کہ آپ کچھ بھی دوبارہ استعمال نہیں کرنا چاہیں گے؟ اپنی مختصر زندگی میں ہم پہلے ہی مثال کے طور پر "ہسٹری" اور "اسٹائل شیٹس" کو دوبارہ استعمال کرنا چاہتے ہیں۔

یہ ایک ویب سائٹ کو منظم کرنے کا ایک پرکشش طریقہ ہے — اور پوری ویب سمیت کسی بھی چیز کو منظم کرنے کا واقعی پرکشش طریقہ ہے۔ یہ ایک بہترین درمیانی مدتی حل ہے لیکن طویل مدتی میں اس میں سنگین کوتاہیاں ہیں۔

وجہ کا ایک حصہ معنی کے فلسفہ میں مضمر ہے۔ کسی زبان کی ہر اصطلاح کلسٹرنگ کے لیے ممکنہ ہدف ہے، اور ہر شخص کا اس کے معنی کے بارے میں مختلف خیال ہو سکتا ہے۔ چونکہ اداروں کے درمیان تعلقات درخت سے زیادہ جالے کی طرح ہوتے ہیں، یہاں تک کہ جو لوگ ویب سے متفق ہیں وہ درخت کی مختلف نمائندگی کا انتخاب کر سکتے ہیں۔ یہ ایک عمومی حل کے طور پر درجہ بندی کی درجہ بندی کے خطرات کے بارے میں میرے (اکثر دہرائے گئے) عمومی مشاہدات ہیں۔

درحقیقت، جب آپ کسی URI میں موضوع کا نام استعمال کرتے ہیں، تو آپ خود کو کسی قسم کی درجہ بندی کے پابند کر رہے ہوتے ہیں۔ شاید مستقبل میں آپ ایک مختلف آپشن کو ترجیح دیں گے۔ URI پھر خلاف ورزی کا شکار ہو جائے گا۔

URI کے حصے کے طور پر کسی موضوع کے علاقے کو استعمال کرنے کی وجہ یہ ہے کہ URI اسپیس کے ذیلی حصوں کی ذمہ داری عام طور پر سونپی جاتی ہے، اور پھر آپ کو تنظیمی ادارے کے نام کی ضرورت ہوتی ہے - محکمہ، گروپ، یا کوئی بھی - جو اس ذیلی جگہ کے لیے ذمہ دار ہے۔ یہ تنظیمی ڈھانچے کا پابند URI ہے۔ یہ عام طور پر صرف تب ہی محفوظ ہے جب مزید (بائیں) URI کو تاریخ کے ذریعہ محفوظ کیا گیا ہو: 1998/pics کا آپ کے سرور سے مطلب ہو سکتا ہے "1998 میں تصویروں کے ساتھ ہمارا کیا مطلب تھا" کے بجائے "1998 میں ہم نے کیا کیا جسے ہم اب تصویر کہتے ہیں۔"

ڈومین کا نام مت بھولنا

یاد رکھیں کہ یہ نہ صرف URI میں راستے پر لاگو ہوتا ہے، بلکہ سرور کے نام پر بھی لاگو ہوتا ہے۔ اگر آپ کے پاس مختلف چیزوں کے لیے الگ الگ سرور ہیں، تو یاد رکھیں کہ بہت سے، بہت سے لنکس کو تباہ کیے بغیر اس تقسیم کو تبدیل کرنا ناممکن ہوگا۔ کچھ کلاسک "جو سافٹ ویئر ہم آج استعمال کرتے ہیں اسے دیکھیں" غلطیاں ہیں ڈومین نام "cgi.pathfinder.com"، "secure"، "lists.w3.org"۔ وہ سرور انتظامیہ کو آسان بنانے کے لیے بنائے گئے ہیں۔ قطع نظر اس کے کہ کوئی ڈومین آپ کی کمپنی میں کسی تقسیم کی نمائندگی کرتا ہے، دستاویز کی حیثیت، رسائی کی سطح، یا سیکیورٹی کی سطح، متعدد دستاویزات کی اقسام کے لیے ایک سے زیادہ ڈومین نام استعمال کرنے سے پہلے بہت محتاط رہیں۔ یاد رکھیں کہ آپ ری ڈائریکشن اور پراکسینگ کا استعمال کرتے ہوئے ایک ہی مرئی ویب سرور کے اندر متعدد ویب سرورز کو چھپا سکتے ہیں۔

اوہ، اور اپنے ڈومین نام کے بارے میں بھی سوچیں۔ پروڈکٹ لائنز کو تبدیل کرنے اور صابن بنانا بند کرنے کے بعد آپ کو صابن ڈاٹ کام کے طور پر حوالہ دیا جانا نہیں چاہتے ہیں (اس وقت جو بھی soap.com کا مالک ہے اس سے معذرت)۔

حاصل يہ ہوا

URI کو 2، 20، 200، یا یہاں تک کہ 2000 سال تک محفوظ رکھنا ظاہر ہے اتنا آسان نہیں جتنا لگتا ہے۔ تاہم، پورے انٹرنیٹ پر، ویب ماسٹر ایسے فیصلے کر رہے ہیں جو مستقبل میں اس کام کو اپنے لیے واقعی مشکل بنا رہے ہیں۔ اکثر ایسا ہوتا ہے کیونکہ وہ ایسے ٹولز استعمال کرتے ہیں جن کا کام صرف اس وقت بہترین سائٹ پیش کرنا ہے - اور کسی نے اندازہ نہیں لگایا کہ جب سب کچھ بدل جائے گا تو لنکس کا کیا ہوگا۔ تاہم، یہاں بات یہ ہے کہ بہت سی، بہت سی چیزیں بدل سکتی ہیں، اور آپ کے URIs ایک جیسے رہ سکتے ہیں اور رہنا چاہیے۔ یہ تبھی ممکن ہے جب آپ سوچتے ہیں کہ آپ انہیں کیسے بناتے ہیں۔

یہ بھی دیکھیں:

اسی موضوع پر جیکب نیلسن کا ٹائریڈ

اضافہ

فائل ایکسٹینشن کو کیسے ہٹایا جائے...

موجودہ فائل پر مبنی ویب سرور میں URI سے؟

اگر آپ Apache استعمال کرتے ہیں، مثال کے طور پر، آپ اسے مواد پر گفت و شنید کرنے کے لیے ترتیب دے سکتے ہیں۔ فائل ایکسٹینشن (جیسے .png) کو فائل میں محفوظ کریں (جیسے mydog.png)، لیکن آپ اس کے بغیر کسی ویب وسائل سے لنک کر سکتے ہیں۔ اپاچی پھر اس نام اور کسی بھی ایکسٹینشن والی تمام فائلوں کی ڈائرکٹری چیک کرتا ہے، اور سیٹ میں سے بہترین کا انتخاب کرسکتا ہے (مثال کے طور پر، 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: مائیکروسافٹ نیٹ میٹنگ

انٹرنیٹ پر بڑھتے ہوئے انحصار کے ساتھ، ایک ہوشیار خیال آیا کہ مینوفیکچرر کی ویب سائٹ کے لنکس کو ایپلی کیشنز میں سرایت کیا جا سکتا ہے۔ یہ بہت زیادہ استعمال اور زیادتی کی گئی ہے، لیکن آپ URL کو تبدیل نہیں کر سکتے۔ دوسرے ہی دن میں نے مائیکروسافٹ نیٹ میٹنگ 2/کچھ کلائنٹ سے ہیلپ/مائیکروسافٹ آن دی ویب/مفت سامان کے مینو میں ایک لنک آزمایا اور مجھے 404 ایرر موصول ہوا - سرور سے کوئی جواب نہیں ملا۔ شاید وہ پہلے ہی ٹھیک کر چکے ہیں...

تاریخی نوٹ: 20 ویں صدی کے آخر میں، جب یہ لکھا گیا تھا، "ٹھنڈا" منظوری کا خاصہ تھا، خاص طور پر نوجوانوں میں، فیشن، معیار، یا مناسبیت کی نشاندہی کرتا تھا۔ جلدی میں، URI کا راستہ اکثر افادیت یا پائیداری کے بجائے "ٹھنڈک" کے لیے چنا جاتا تھا۔ یہ پوسٹ ٹھنڈے کی تلاش کے پیچھے توانائی کو ری ڈائریکٹ کرنے کی کوشش ہے۔

ماخذ: www.habr.com

ٹھنڈے URIs تبدیل نہیں ہوتے ہیں۔