Зохиогч: Сэр Тим Бернерс-Ли, URI, URL, HTTP, HTML болон World Wide Web-ийг зохион бүтээгч, 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

Энд паб/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 дизайн

2 жил, 20 жил, 200 жил ашиглах боломжтой URI-г хуваарилах нь вэбмастерын үүрэг юм. Үүнд бодол санаа, зохион байгуулалт, шийдэмгий байдал хэрэгтэй.

Хэрэв ямар нэгэн мэдээлэл өөрчлөгдсөн тохиолдолд URI нь өөрчлөгддөг. Тэдгээрийг хэрхэн зохион бүтээх нь маш чухал юм. (Юу, URI дизайн? Би URI дизайн хийх шаардлагатай юу? Тийм ээ, та энэ талаар бодох хэрэгтэй). Дизайн гэдэг нь үндсэндээ URI дахь аливаа мэдээллийг орхих гэсэн үг юм.

Баримт бичгийг үүсгэсэн огноо - URI-г олгосон огноо нь хэзээ ч өөрчлөгдөхгүй зүйл юм. Энэ нь шинэ системийг ашигладаг асуулгыг хуучин системийг ашигладаг асуулгаас салгахад маш хэрэгтэй. Энэ бол URI-аас эхлэхэд тохиромжтой газар юм. Хэрэв баримт бичиг нь ирээдүйд хамааралтай байсан ч огноотой бол энэ нь сайн эхлэл юм.

Цорын ганц үл хамаарах зүйл бол зориудаар "хамгийн сүүлийн" хувилбар, жишээлбэл, бүхэл бүтэн байгууллага эсвэл түүний ихэнх хэсэг нь хуудас юм.

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

Энэ бол Money сэтгүүлийн хамгийн сүүлийн үеийн Money Daily булан юм. Энэ 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 дарга нарын хурлын тэмдэглэлийн тайлан.

Сэдвүүд ба сэдвийн дагуу ангилах

Энэ аюулаас зайлсхийхэд хамгийн хэцүү зүйлүүдийн нэг учраас би энэ аюулын талаар илүү дэлгэрэнгүй ярих болно. Ихэвчлэн та өөрийн баримт бичгүүдийг хийж буй ажлаар нь ангилах үед сэдвүүд нь URI-д дуусдаг. Гэхдээ энэ задаргаа цаг хугацааны явцад өөрчлөгдөх болно. Бүс нутгийн нэр өөрчлөгдөнө. W3C дээр бид MarkUP-г Markup болгож, дараа нь HTML болгож тухайн хэсгийн бодит агуулгыг тусгахыг хүссэн. Үүнээс гадна, ихэвчлэн хавтгай нэрийн орон зай байдаг. 100 жилийн дараа та юу ч дахин ашиглахыг хүсэхгүй гэдэгтээ итгэлтэй байна уу? Богинохон амьдралдаа бид "Түүх" болон "Загварын хуудас"-ыг дахин ашиглахыг аль хэдийн хүсч байсан.

Энэ бол вэб сайтыг зохион байгуулах сонирхолтой арга бөгөөд вэбийг бүхэлд нь оролцуулан аливаа зүйлийг зохион байгуулах үнэхээр сэтгэл татам арга юм. Энэ бол дунд хугацааны сайн шийдэл боловч урт хугацаанд ноцтой дутагдалтай.

Үүний нэг хэсэг нь утгын гүн ухаанд оршдог. Хэлний нэр томьёо бүр нь бөөгнөрөх боломжит зорилт бөгөөд хүн бүр энэ нь юу гэсэн үг болохыг өөр өөр ойлголттой байж болно. Байгууллага хоорондын харилцаа нь мод гэхээсээ илүү вэб шиг байдаг тул вэбтэй санал нийлдэг хүмүүс хүртэл модны өөр дүрслэлийг сонгож болно. Эдгээр нь ерөнхий шийдэл болох шаталсан ангиллын аюулын талаархи миний (ихэвчлэн давтагддаг) ерөнхий ажиглалтууд юм.

Үнэн хэрэгтээ, та URI-д сэдвийн нэрийг ашиглахдаа ямар нэгэн ангилалд хамрагдах үүрэг хүлээдэг. Магадгүй ирээдүйд та өөр сонголтыг илүүд үзэх болно. Дараа нь URI нь зөрчилд өртөмтгий болно.

Сэдвийн талбарыг URI-ийн нэг хэсэг болгон ашиглах болсон шалтгаан нь URI зайны дэд хэсгүүдийн хариуцлагыг ихэвчлэн хуваарилдаг бөгөөд дараа нь тухайн дэд орон зайг хариуцах байгууллагын байгууллагын нэр - хэлтэс, бүлэг эсвэл юу ч байх шаардлагатай. Энэ нь байгууллагын бүтэцтэй холбоотой URI код юм. Зөвхөн дараагийн (зүүн) URI-г огноогоор хамгаалсан тохиолдолд л аюулгүй байдаг: 1998/зураг нь таны серверт "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-г өөрчлөх шаардлагагүй байсан.

Ичгүүрийн зөвлөл - Өгүүллэг 2: Microsoft Netmeeting

Интернэтийн хамаарал улам бүр нэмэгдэж байгаатай холбогдуулан үйлдвэрлэгчийн вэбсайтын холбоосыг программд суулгаж болно гэсэн ухаалаг санаа гарч ирэв. Үүнийг маш их ашиглаж, урвуулан ашигласан боловч та URL-г өөрчлөх боломжгүй. Дөнгөж сая би Microsoft Netmeeting 2/ямар нэг зүйл клиентийн холбоосыг Вэб/Үнэгүй зүйлс цэсний Microsoft-ын Тусламж/Microsoft-оос оролдоод 404 алдаа хүлээн авсан - серверээс ямар ч хариу олдсонгүй. Магадгүй аль хэдийн зассан байх...

© 1998 Тим Б.Л

Түүхэн тэмдэглэл: 20-р зууны сүүлчээр үүнийг бичихэд "сайн" гэдэг нь ялангуяа залуучуудын дунд загварлаг байдал, чанар, зохистой байдлыг илэрхийлдэг. Яаран, URI замыг ихэвчлэн ашиг тустай, удаан эдэлгээтэй гэхээсээ илүү "сэрүүн" байдлаар сонгосон. Энэ нийтлэл нь сэрүүн гэсэн эрэл хайгуулын цаана байгаа энергийг дахин чиглүүлэх оролдлого юм.

Эх сурвалж: www.habr.com