ავტორი: სერ ტიმ ბერნერს-ლი, 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 editing server) ფუნქციას, რომელიც თვალს ადევნებს ვერსიებს და ჩვენ ექსპერიმენტებს ვაკეთებთ დოკუმენტების გენერირების სკრიპტებზე. თუ თქვენ ავითარებთ ინსტრუმენტებს, სერვერებს და კლიენტებს, ყურადღება მიაქციეთ ამ საკითხს!

ეს საბაბი ასევე ეხება ბევრ 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-ში თარიღის საჭიროება არ არის, არის ის, რომ არ არსებობს URI-ის შენახვის მიზეზი, რომელიც გადარჩება ჟურნალს. Money Daily-ის კონცეფცია გაქრება, როდესაც ფული გაქრება. თუ გსურთ კონტენტის ბმული, არქივში ცალკე უნდა დააკავშიროთ იგი:

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

(კარგად გამოიყურება. ვარაუდობენ, რომ "ფული" იგივეს ნიშნავს pathfinder.com-ის მთელი ცხოვრების განმავლობაში. არის დუბლიკატი "98" და არასაჭირო ".html", მაგრამ სხვა შემთხვევაში ძლიერ URI-ს ჰგავს.

რა უნდა დატოვო

ყველა! გარდა შექმნის თარიღისა, URI-ში ნებისმიერი ინფორმაციის განთავსება ამა თუ იმ გზით ითხოვს პრობლემებს.

• ავტორის სახელი. ავტორი შეიძლება შეიცვალოს ახალი ვერსიების ხელმისაწვდომობის გამო. ადამიანები ტოვებენ ორგანიზაციებს და რაღაცებს სხვებს გადასცემენ.
• Thing. Ძალიან რთულია. თავიდან ყოველთვის კარგად გამოიყურება, მაგრამ საოცრად სწრაფად იცვლება. ამაზე დაწვრილებით ქვემოთ ვისაუბრებ.
• სტატუსი. დირექტორიები, როგორიცაა "ძველი", "დრაფტი" და ასე შემდეგ, რომ აღარაფერი ვთქვათ "უახლესი" და "მაგარი", გამოჩნდება ყველა ფაილურ სისტემაში. დოკუმენტები ცვლის სტატუსს - წინააღმდეგ შემთხვევაში მონახაზების შექმნას აზრი არ ექნება. დოკუმენტის უახლეს ვერსიას სჭირდება მუდმივი იდენტიფიკატორი, მიუხედავად მისი სტატუსისა. შეინახეთ სტატუსი სახელის გარეშე.
• წვდომა. W3C-ში ჩვენ დავყავით საიტი თანამშრომლებისთვის, წევრებისთვის და საზოგადოებისთვის. ეს კარგად ჟღერს, მაგრამ, რა თქმა უნდა, დოკუმენტები იწყება როგორც თანამშრომლების გუნდის იდეები, განიხილება წევრებთან და შემდეგ ხდება საზოგადოებისთვის ცნობილი. ნამდვილად სირცხვილი იქნება, თუ ყოველ ჯერზე, როცა დოკუმენტი ფართო განხილვისთვის იხსნება, მისი ყველა ძველი ბმული იშლება! ახლა ჩვენ გადავდივართ თარიღის მარტივ კოდზე.
• Ფაილის გაფართოება. ძალიან გავრცელებული ფენომენი. "cgi", თუნდაც ".html" შეიცვლება მომავალში. თქვენ შეიძლება HTML-ს არ იყენებდეთ ამ გვერდისთვის 20 წლის განმავლობაში, მაგრამ დღევანდელი ბმულები მაინც უნდა მუშაობდეს. W3C საიტზე არსებული კანონიკური ბმულები არ იყენებენ გაფართოებას (როგორ კეთდება).
• პროგრამული მექანიზმები. URI-ში მოძებნეთ „cgi“, „exec“ და სხვა ტერმინები, რომლებიც ყვირიან „შეხედეთ რა პროგრამულ უზრუნველყოფას ვიყენებთ“. ვინმეს სურს მთელი ცხოვრება გაატაროს Perl CGI სკრიპტების დაწერაზე? არა? შემდეგ ამოიღეთ .pl გაფართოება. წაიკითხეთ სერვერის სახელმძღვანელო, თუ როგორ უნდა გააკეთოთ ეს.
• დისკის სახელი. Მოდი! მაგრამ მე ვნახე ეს.

ასე რომ, საუკეთესო მაგალითი ჩვენი საიტიდან არის უბრალოდ

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

... მოხსენება W3C თავმჯდომარეების შეხვედრის ოქმის შესახებ.

თემები და კლასიფიკაცია თემის მიხედვით

ამ საშიშროების შესახებ უფრო დეტალურად განვიხილავ, რადგან ის ერთ-ერთია, რომლის თავიდან აცილებაც ყველაზე რთულია. როგორც წესი, თემები მთავრდება URI-ებში, როდესაც თქვენ დაახარისხებთ თქვენს დოკუმენტებს სამუშაოს მიხედვით. მაგრამ ეს ავარია დროთა განმავლობაში შეიცვლება. შეიცვლება ტერიტორიების სახელები. W3C-ზე გვინდოდა შევცვალოთ 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 გზას ხშირად ირჩევდნენ "სიგრილის" და არა სარგებლობის ან გამძლეობისთვის. ეს პოსტი არის ენერგიის გადამისამართების მცდელობა cool-ის ძიების უკან.

წყარო: www.habr.com