لیکوال: سر ټیم برنرز لی، د URIs، URLs، HTTP، HTML او د نړۍ پراخه ویب اختراع کونکی، او د W3C اوسنی مشر. مقاله په 1998 کې لیکل شوې

کوم URI "ښایسته" ګڼل کیږي؟
یو چې نه بدلیږي.
URIs څنګه بدل شوي؟
URIs نه بدلیږي: خلک دوی بدلوي.

په تیوري کې، د خلکو لپاره هیڅ دلیل شتون نلري چې URIs بدل کړي (یا د مالتړ اسنادو مخه ونیسي)، مګر په عمل کې په میلیونونو کې شتون لري.

په تیوري کې، د ډومین نوم ځای نومول شوی مالک په حقیقت کې د ډومین نوم ځای لري او له همدې امله د هغې دننه ټول URIs. د بې ځایه کیدو سربیره ، هیڅ شی د ډومین نوم مالک د نوم ساتلو مخه نه نیسي. او په تیوري کې، ستاسو د ډومین نوم لاندې د URI ځای په بشپړه توګه ستاسو تر کنټرول لاندې دی، نو تاسو کولی شئ دا د خپل خوښې په توګه باثباته کړئ. د انټرنیټ څخه د یو سند د ورکیدو یوازینی ښه دلیل دا دی چې هغه شرکت چې د ډومین نوم ملکیت لري له سوداګرۍ څخه وتلی یا نور نشي کولی د سرور چلولو توان ولري. بیا ولې په نړۍ کې دومره ورک شوي لینکونه شتون لري؟ د دې څخه ځینې یوازې د وړاندوینې نشتوالی دی. دلته ځینې دلیلونه دي چې تاسو یې اوریدلی شئ:

موږ یوازې سایټ بیا تنظیم کړی ترڅو دا ښه کړي.

ایا تاسو واقعیا فکر کوئ چې زاړه URIs نور کار نشي کولی؟ که داسې وي، نو تاسو دوی خورا خراب انتخاب کړل. د راتلونکي بیا ډیزاین لپاره نوي ساتلو ته پام وکړئ.

موږ دومره ډیر توکي لرو چې موږ نشو کولی د هغه څه تعقیب وساتو چې څه زاړه دي، څه محرم دي، او څه چې لاهم اړوند دي، نو موږ غوره فکر وکړ چې دا ټول بند کړو.

زه یوازې خواخوږی کولی شم. W3C د یوې دورې څخه تیریږي چیرې چې موږ باید د عامه کولو دمخه د محرمیت لپاره د آرشیف موادو له لارې په احتیاط سره وخورئ. پریکړه باید مخکې له مخکې فکر وشي - ډاډ ترلاسه کړئ چې د هر سند سره تاسو د منلو وړ لوستونکي ثبت کړئ، د جوړولو نیټه او په مثالي توګه، د ختمیدو نیټه. دا میټاډاټا خوندي کړئ.

ښه، موږ وموندله چې موږ اړتیا لرو فایلونه حرکت وکړو ...

دا یو له خورا بې رحمه عذرونو څخه دی. ډیری خلک نه پوهیږي چې ویب سرورونه تاسو ته اجازه درکوي د یو اعتراض URI او د فایل سیسټم کې د هغې اصلي موقعیت ترمنځ اړیکه کنټرول کړئ. د 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 یا کوم بل سازمان سره به مداخله ونه کړي چې آرشیف وساتي.

ما فکر نه کاوه چې 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" او نورو اصطلاحاتو لپاره وګورئ چې چیغې وهي "وګورئ کوم سافټویر چې موږ یې کاروو." ایا څوک غواړي خپل ټول ژوند د پرل 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 په توګه راجع شئ وروسته له دې چې تاسو د محصول لین بدل کړئ او د صابون جوړولو مخه ونیسئ (د هغه چا څخه بخښنه وغواړئ چې دا مهال د صابون.com لري).

پایلې

د 2، 20، 200، یا حتی 2000 کلونو لپاره د URI ساتل په ښکاره ډول دومره اسانه ندي لکه څنګه چې ښکاري. په هرصورت، په ټول انټرنیټ کې، ویب ماسټران پریکړې کوي چې دا کار په راتلونکي کې د ځان لپاره واقعیا ستونزمن کوي. ډیری وختونه دا ځکه چې دوی وسیلې کاروي چې دنده یې یوازې په اوس وخت کې غوره سایټ وړاندې کول دي - او هیچا دا ارزونه نه ده کړې چې لینکونو ته به څه پیښ شي کله چې هرڅه بدل شي. په هرصورت، دلته ټکی دا دی چې ډیری، ډیری شیان بدلیدلی شي، او ستاسو URIs کولی شي او ورته پاتې شي. دا یوازې ممکنه ده کله چې تاسو فکر کوئ چې څنګه یې جوړ کړئ.

دا هم وګورئ:

په همدې موضوع د جاکوب نیلسن لیکنه

اضافې

د فایل توسیعونو لرې کولو څرنګوالی ...

... د اوسني فایل پر بنسټ ویب سرور کې د URI څخه؟

که تاسو اپاچی کاروئ، د بیلګې په توګه، تاسو کولی شئ دا د منځپانګې د خبرو اترو لپاره تنظیم کړئ. د فایل توسیع (د بیلګې په توګه. png) په فایل کې خوندي کړئ (د بیلګې په توګه mydog.png)، مګر تاسو کولی شئ پرته له دې ویب سرچینې سره اړیکه ونیسئ. اپاچی بیا د دې نوم او هر توسیع سره د ټولو فایلونو لپاره لارښود چیک کوي، او کولی شي د سیټ څخه غوره غوره کړي (د مثال په توګه، GIF او PNG). او اړتیا نشته چې مختلف ډوله فایلونه په مختلف لارښودونو کې واچوئ ، په حقیقت کې د مینځپانګې میچ کول به کار ونکړي که تاسو دا وکړئ.

د منځپانګې د خبرو اترو لپاره خپل سرور تنظیم کړئ
تل د تمدید پرته URIs سره اړیکه ونیسئ

د تمدیدونو سره لینکونه به لاهم کار وکړي ، مګر ستاسو سرور به اوس مهال او راتلونکي کې د غوره فارمیټ غوره کولو مخه ونیسي.

(په حقیقت کی، mydog, mydog.png и mydog.gif - معتبر ویب سرچینې، mydog یو نړیوال منځپانګې ډول سرچینه ده، او mydog.png и mydog.gif - د ځانګړي منځپانګې ډول سرچینې).

البته، که تاسو خپل ویب سرور لیکئ، دا یو ښه نظر دی چې د ډیټابیس څخه کار واخلئ ترڅو دوامداره پیژندونکي د دوی اوسني بڼې ته وتړئ، که څه هم د لامحدود ډیټابیس ودې څخه خبر اوسئ.

د شرم بورډ - لومړۍ کیسه: چینل 1

د 1999 په جریان کې، ما په پاڼه کې د واورې له امله د ښوونځي تړل کیدل تعقیب کړل http://www.whdh.com/stormforce/closings.shtml. د تلویزیون سکرین په ښکته کې د معلوماتو څرګندیدو ته انتظار مه کوئ! ما دا زما د کور پاڼې څخه لینک کړی. د 2000 لومړی لوی واوره طوفان راځي او زه پاڼه ګورم. هلته لیکل شوي دي:

- لکه څنګه چې.
اوس مهال هیڅ شی بند نه دی. مهرباني وکړئ د هوا د خبرتیا په صورت کې بیرته راشئ.

دا دومره قوي طوفان نه شي کیدی. دا مسخره ده چې تاریخ ورک دی. مګر که تاسو د سایټ اصلي پا pageې ته لاړشئ ، نو هلته به یو لوی تڼۍ وي "تړل شوي ښوونځي" ، کوم چې مخ ته ځي http://www.whdh.com/stormforce/ د تړل شویو ښوونځیو اوږد لیست سره.

شاید دوی د لیست ترلاسه کولو لپاره سیسټم بدل کړی - مګر دوی د URI بدلولو ته اړتیا نلري.

د شرم بورډ - کیسه 2: د مایکروسافټ نیټ میټینګ

په انټرنیټ باندې د مخ په زیاتیدونکي انحصار سره، یو هوښیار نظر راغی چې د جوړونکي ویب پاڼې لینکونه په غوښتنلیکونو کې ځای پرځای کیدی شي. دا ډیر کارول شوی او ناوړه ګټه اخیستنه ده، مګر تاسو نشئ کولی URL بدل کړئ. یوازې بله ورځ ما د مایکروسافټ نیټ میټینګ 2/something پیرودونکي څخه لینک هڅه وکړه په ویب / وړیا توکو مینو کې د مایکروسافټ / مایکروسافټ مینو کې او 404 تېروتنه مې ترلاسه کړه - د سرور څخه هیڅ ځواب ونه موندل شو. شاید دا لا دمخه ثابت شوی وي ...

تاریخي یادونه: د شلمې پیړۍ په وروستیو کې، کله چې دا لیکل شوی و، "کول" د تصویب یوه نمونه وه، په ځانګړې توګه د ځوانانو ترمنځ، د فیشن وړتیا، کیفیت، یا مناسبیت په ګوته کوي. په چټکۍ سره، د URI لاره اکثرا د ګټورتیا یا پایښت پر ځای د "سوکالۍ" لپاره غوره شوې وه. دا پوسټ یوه هڅه ده چې د یخ لپاره د لټون تر شا انرژي بیرته راستون کړي.

سرچینه: www.habr.com

ښه URIs نه بدلیږي