Հեղինակ՝ Sir Tim Berners-Lee, URI-ների, URL-ների, HTTP-ի, HTML-ի և Համաշխարհային ցանցի գյուտարար և W3C-ի ներկայիս ղեկավար: Հոդվածը գրված է 1998 թ

Ո՞ր URI-ն է համարվում «թույն»:
Մեկը, որը չի փոխվում:
Ինչպե՞ս են փոխվում URI-ները:
URI-ները չեն փոխվում. մարդիկ փոխում են դրանք:

Տեսականորեն պատճառ չկա, որ մարդիկ փոխեն URI-ները (կամ դադարեցնեն օժանդակ փաստաթղթերը), սակայն գործնականում դրանք միլիոնավոր են:

Տեսականորեն, տիրույթի անվանական տարածքի անվանական սեփականատերը իրականում տիրապետում է տիրույթի անունների տարածքին և, հետևաբար, դրա ներսում գտնվող բոլոր URI-ներին: Բացի անվճարունակությունից, ոչինչ չի խանգարում տիրույթի անվան տիրոջը պահպանել անունը։ Եվ տեսականորեն, ձեր տիրույթի անվան տակ գտնվող URI տարածքն ամբողջությամբ ձեր վերահսկողության տակ է, այնպես որ կարող եք այն կայուն դարձնել, որքան ցանկանում եք: Փաստաթուղթը համացանցից անհետանալու միակ լավ պատճառն այն է, որ տիրույթի անունը պատկանող ընկերությունը դուրս է եկել բիզնեսից կամ այլևս չի կարող իրեն թույլ տալ աշխատել սերվերը: Այդ դեպքում ինչո՞ւ են աշխարհում այդքան շատ բացակայող օղակներ: Դրանցից մի քանիսը պարզապես նախախնամության բացակայություն է: Ահա մի քանի պատճառ, որ դուք կարող եք լսել.

Մենք պարզապես վերակազմավորեցինք կայքը՝ այն ավելի լավը դարձնելու համար:

Իսկապե՞ս կարծում եք, որ հին URI-ներն այլևս չեն կարող աշխատել: Եթե ​​այո, ապա դուք շատ վատ եք ընտրել դրանք։ Մտածեք նորերը պահել հաջորդ վերանախագծման համար:

Մենք այնքան շատ իրեր ունենք, որ չենք կարող հետևել, թե ինչն է հնացած, ինչն է գաղտնի և ինչն է դեռևս տեղին, ուստի լավագույնը մտածեցինք պարզապես անջատել այդ ամենը:

Ես կարող եմ միայն կարեկցել. 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-ին կամ արխիվը պահպանող որևէ այլ կազմակերպությանը:

Ես չէի կարծում, որ URL-ները պետք է մշտական ​​լինեն. կային URN-ներ:

Սա, հավանաբար, URN-ի բանավեճի ամենավատ կողմնակի ազդեցություններից մեկն է: Ոմանք կարծում են, որ ավելի մշտական ​​անվանատարածքի ուսումնասիրության պատճառով նրանք կարող են անփույթ լինել կախովի հղումների նկատմամբ, քանի որ «URN-ները կշտկեն այդ ամենը»: Եթե ​​դուք այս մարդկանցից եք, ապա թույլ տվեք հիասթափեցնել ձեզ։

URN սխեմաների մեծ մասը, որոնք ես տեսել եմ, նման են հեղինակության նույնացուցիչի, որին հաջորդում է կամ ամսաթիվը և ձեր ընտրած տողը, կամ պարզապես ձեր ընտրած տողը: Սա շատ նման է HTTP URI-ին: Այլ կերպ ասած, եթե կարծում եք, որ ձեր կազմակերպությունը կկարողանա ստեղծել երկարատև URN-ներ, ապա ապացուցեք դա հիմա՝ օգտագործելով դրանք ձեր HTTP URI-ների համար: Բուն HTTP-ում ոչինչ չկա, որը ձեր URI-ն անկայուն է դարձնում: Միայն ձեր կազմակերպությունը: Ստեղծեք տվյալների բազա, որը քարտեզագրում է փաստաթղթի URN-ը ընթացիկ ֆայլի անվան հետ և թույլ տվեք, որ վեբ սերվերն այն օգտագործի ֆայլերը իրականում առբերելու համար:

Եթե ​​դուք հասել եք այս կետին, եթե ժամանակ, գումար և կապեր չունեք որոշ ծրագրեր մշակելու համար, ապա կարող եք պատճառաբանել հետևյալը.

Մենք ուզում էինք, բայց մենք պարզապես չունենք համապատասխան գործիքներ:

Բայց դուք կարող եք համակրել սրան: Լիովին համաձայն եմ։ Այն, ինչ դուք պետք է անեք, ստիպեք վեբ սերվերին ակնթարթորեն վերլուծել մշտական ​​URI-ն և վերադարձնել ֆայլը, որտեղ էլ որ այն պահված է ձեր ընթացիկ խելագար ֆայլային համակարգում: Դուք ցանկանում եք պահել բոլոր URI-ները ֆայլում որպես ստուգում և մշտապես թարմացնել տվյալների բազան: Դուք ցանկանում եք պահպանել կապը նույն փաստաթղթի տարբեր տարբերակների և թարգմանությունների միջև, ինչպես նաև պահպանել անկախ ստուգիչ գումարի գրառում՝ համոզվելու համար, որ ֆայլը չի ​​վնասվել պատահական սխալի հետևանքով: Իսկ վեբ սերվերները պարզապես դուրս չեն գալիս այս հնարավորություններով: Երբ ցանկանում եք ստեղծել նոր փաստաթուղթ, ձեր խմբագիրը ձեզ խնդրում է նշել URI:

Դուք պետք է կարողանաք փոխել սեփականության իրավունքը, փաստաթղթերի հասանելիությունը, արխիվի մակարդակի անվտանգությունը և այլն URI տարածքում՝ առանց URI-ն փոխելու:

Ամեն ինչ շատ վատ է: Բայց մենք կշտկենք իրավիճակը։ W3C-ում մենք օգտագործում ենք Jigedit (Jigsaw խմբագրման սերվեր) գործառույթը, որը հետևում է տարբերակներին, և մենք փորձարկում ենք փաստաթղթերի ստեղծման սկրիպտներ: Եթե ​​դուք մշակում եք գործիքներ, սերվերներ և հաճախորդներ, ուշադրություն դարձրեք այս խնդրին:

Այս արդարացումը վերաբերում է նաև W3C-ի շատ էջերին, ներառյալ այս մեկը. այնպես որ արեք այնպես, ինչպես ես եմ ասում, ոչ թե ինչպես ես անում:

Ինչու՞ պետք է հոգ տանեմ:

Երբ փոխում եք URI-ն ձեր սերվերի վրա, դուք երբեք չեք կարող ամբողջությամբ ասել, թե ով կունենա հղումներ դեպի հին URI: Սրանք կարող են լինել սովորական վեբ էջերի հղումներ: Էջանշեք ձեր էջը: URI-ն կարող էր գրված լինել ընկերոջը ուղղված նամակի լուսանցքում:

Երբ ինչ-որ մեկը հետևում է հղմանը և այն խափանում է, նրանք սովորաբար կորցնում են վստահությունը սերվերի սեփականատիրոջ նկատմամբ: Նա նաև հիասթափված է և՛ էմոցիոնալ, և՛ ֆիզիկապես՝ չկարողանալով հասնել իր նպատակին։

Շատ մարդիկ անընդհատ դժգոհում են կոտրված հղումներից, և հուսով եմ, որ վնասն ակնհայտ է: Հուսով եմ, որ այն սերվերի սպասարկողին, որտեղ փաստաթուղթն անհետացել է, նույնպես ակնհայտ է հեղինակության վնասը։

Այսպիսով, ինչ պետք է անեմ: URI դիզայն

Վեբ վարպետի պարտականությունն է հատկացնել URI-ներ, որոնք կարող են օգտագործվել 2 տարում, 20 տարում, 200 տարում: Սա պահանջում է մտածվածություն, կազմակերպվածություն և վճռականություն:

URI-ները փոխվում են, եթե դրանցում առկա որևէ տեղեկություն փոխվում է: Ինչպես եք դրանք նախագծում, շատ կարևոր է: (Ի՞նչ, URI ձևավորում: Պե՞տք է արդյոք նախագծել URI-ն: Այո, դուք պետք է մտածեք դրա մասին): Դիզայնը հիմնականում նշանակում է URI-ում որևէ տեղեկություն թողնել:

Փաստաթղթի ստեղծման ամսաթիվը՝ URI-ի թողարկման ամսաթիվը, մի բան է, որը երբեք չի փոխվի: Այն շատ օգտակար է նոր համակարգ օգտագործող հարցումները հին համակարգից օգտվողներից բաժանելու համար: Սա լավ տեղ է URI-ով սկսելու համար: Եթե ​​փաստաթուղթը թվագրված է, նույնիսկ եթե փաստաթուղթը կլինի համապատասխան ապագայում, ապա սա լավ սկիզբ է:

Միակ բացառությունն այն էջն է, որը միտումնավոր «վերջին» տարբերակն է, օրինակ՝ ամբողջ կազմակերպության կամ դրա մեծ մասի համար։

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

Սա Money Daily-ի վերջին սյունակն է Money ամսագրում: Այս URI-ում ամսաթվի կարիք չկա: Money Daily-ի հայեցակարգը կվերանա, երբ Money-ն անհետանա: Եթե ​​ցանկանում եք հղում կատարել բովանդակությանը, ապա պետք է արխիվում առանձին հղում կատարեք դրան.

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

(Լավ տեսք ունի: Ենթադրվում է, որ «փողը» կնշանակի նույն բանը pathfinder.com-ի ողջ կյանքի ընթացքում: Կա կրկնօրինակ «98» և անհարկի «.html», բայց հակառակ դեպքում կարծես ուժեղ URI է:

Ինչը մի կողմ թողնել

Բոլորը! Բացի ստեղծման ամսաթվից, ցանկացած տեղեկատվություն URI-ում տեղադրելը այս կամ այն ​​կերպ խնդիրներ է պահանջում:

• Հեղինակի անունը. Հեղինակությունը կարող է փոխվել, քանի որ նոր տարբերակները հասանելի են դառնում: Մարդիկ հեռանում են կազմակերպություններից և փոխանցում ուրիշներին:
• Առարկան. Շատ դժվար է։ Սկզբում միշտ լավ տեսք ունի, բայց զարմանալիորեն արագ է փոխվում: Այս մասին ավելի մանրամասն կխոսեմ ստորև:
• Կարգավիճակը. Բոլոր ֆայլային համակարգերում հայտնվում են այնպիսի գրացուցակներ, ինչպիսիք են «հին», «սևագիր» և այլն, էլ չեմ ասում «վերջին» և «cool»: Փաստաթղթերը փոխում են կարգավիճակը, հակառակ դեպքում նախագծեր ստեղծելն իմաստ չի ունենա: Փաստաթղթի վերջին տարբերակին անհրաժեշտ է մշտական ​​նույնացուցիչ՝ անկախ դրա կարգավիճակից: Պահպանեք կարգավիճակը անունից:
• Մուտք. W3C-ում մենք կայքը բաժանել ենք բաժինների՝ նախատեսված աշխատակիցների, անդամների և հանրության համար: Սա լավ է հնչում, բայց, իհարկե, փաստաթղթերը սկսվում են որպես անձնակազմի թիմային գաղափարներ, քննարկվում են անդամների հետ և այնուհետև դառնում հանրությանը հայտնի: Իսկապես ամոթ կլինի, եթե ամեն անգամ, երբ փաստաթուղթը բացվում է ավելի լայն քննարկման համար, կոտրվում են դրա բոլոր հին հղումները: Այժմ մենք անցնում ենք պարզ ամսաթվի կոդը:
• Ֆայլի ընդլայնում. Շատ տարածված երեւույթ. «cgi», նույնիսկ «.html»-ը հետագայում կփոխվի։ Դուք կարող եք չօգտագործել HTML այս էջի համար 20 տարի անց, բայց այսօրվա հղումները դեռ պետք է աշխատեն: W3C կայքի կանոնական հղումները չեն օգտագործում ընդլայնում (ինչպես է դա արվում).
• Ծրագրային մեխանիզմներ. URI-ում փնտրեք «cgi», «exec» և այլ տերմիններ, որոնք գոռում են՝ «նայեք, թե ինչ ծրագրակազմ ենք օգտագործում»: Արդյո՞ք որևէ մեկը ցանկանում է իր ամբողջ կյանքը ծախսել Perl CGI սցենարներ գրելով: Ոչ? Այնուհետեւ հեռացրեք .pl ընդլայնումը: Կարդացեք սերվերի ձեռնարկը, թե ինչպես դա անել:
• Սկավառակի անունը. Արի՛ Բայց ես սա տեսել եմ:

Այսպիսով, մեր կայքի լավագույն օրինակը պարզապես

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

... զեկուցել W3C նախագահների հանդիպման արձանագրության մասին:

Թեմաներ և դասակարգում ըստ թեմայի

Ես ավելի մանրամասն կանդրադառնամ այս վտանգի մասին, քանի որ դա այն բաներից է, որից ամենադժվարն է խուսափել։ Սովորաբար, թեմաները հայտնվում են URI-ներում, երբ ձեր փաստաթղթերը դասակարգում եք ըստ նրանց կատարած աշխատանքի: Բայց այս անկումը ժամանակի ընթացքում կփոխվի: Տարածքների անվանումները կփոխվեն. 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 այն բանից հետո, երբ փոխեք արտադրանքի գիծը և դադարեցնեք օճառ պատրաստելը (ներողություն խնդրեք նրան, ով այս պահին պատկանում է soap.com-ին):

Ամփոփում

URI-ի պահպանումը 2, 20, 200 կամ նույնիսկ 2000 տարի ակնհայտորեն այնքան էլ հեշտ չէ, որքան թվում է: Այնուամենայնիվ, ամբողջ համացանցում վեբ վարպետները որոշումներ են կայացնում, որոնք ապագայում իրենց համար իսկապես դժվարացնում են այս խնդիրը: Հաճախ դա պայմանավորված է նրանով, որ նրանք օգտագործում են գործիքներ, որոնց խնդիրն է ներկայացնել լավագույն կայքը միայն այս պահին, և ոչ ոք չի գնահատել, թե ինչ կլինի հղումների հետ, երբ ամեն ինչ փոխվի: Այնուամենայնիվ, խնդիրն այստեղ այն է, որ շատ ու շատ բաներ կարող են փոխվել, և ձեր URI-ները կարող են և պետք է մնան նույնը: Դա հնարավոր է միայն այն ժամանակ, երբ մտածում ես, թե ինչպես ես դրանք ստեղծում:

Տես նաեւ.

• Յակոբ Նիլսենի տիրադը նույն թեմայով

Հավելումներ

Ինչպես հեռացնել ֆայլերի ընդարձակումները...

... ընթացիկ ֆայլի վրա հիմնված վեբ սերվերի 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-ն փոխելու կարիք չունեին:

Board of Shame - Պատմություն 2. Microsoft Netmeeting

Ինտերնետից աճող կախվածության հետ մեկտեղ խելացի միտք ծագեց, որ արտադրողի կայքի հղումները կարող են ներառվել հավելվածներում: Սա շատ է օգտագործվել և չարաշահվել, բայց դուք չեք կարող փոխել URL-ը: Հենց օրերս ես փորձեցի հղումը Microsoft Netmeeting 2/something հաճախորդից Help/Microsoft on the Web/Free stuff մենյուում և ստացա 404 սխալ. սերվերից պատասխան չգտնվեց: Երևի արդեն շտկել են...

© 1998 Թիմ ԲԼ

Պատմական նշում. 20-րդ դարի վերջին, երբ սա գրվեց, «սառը» հավանության նշան էր, հատկապես երիտասարդների շրջանում, ինչը ցույց էր տալիս նորաձևությունը, որակը կամ պատշաճությունը: Շտապելով, URI ուղին հաճախ ընտրվում էր «զովության» համար, քան օգտակարության կամ երկարակեցության համար: Այս գրառումը փորձ է վերահղելու էներգիան, որը հետևում է զով որոնմանը:

Source: www.habr.com