Svi URI-ji ostaju nepromenjeni

Avtor — sir Tim Berners-Lee, izumitelj URI, URL, HTTP, HTML in Svetovnega spleta, trenutno glavni W3C. Članek je bil napisan leta 1998.

Kateri URI lahko štejemo za 'kul'?
Tak, ki se ne spreminja.
Kako se URI spreminjajo?
URI se ne spreminjajo: spreminjajo jih ljudje.

V teoriji ljudje nimajo nobenih razlogov za spreminjanje URI (ali prenehanje vzdrževanja dokumentov), toda v praksi jih je milijone.

Teoretično nominalni lastnik domenskega imena resnično obvladuje to ime in s tem vse URI znotraj njega. Razen insolventnosti ni nič, kar bi lastniku domenskega imena preprečilo, da obdrži to ime. In teoretično je prostor URI pod vašim domenskim imenom v celoti pod vašim nadzorom, kar pomeni, da ga lahko naredite tako stabilnega, kot želite. V veliki meri je edini upravičen razlog za izginotje dokumenta z interneta dejstvo, da je podjetje, ki je imelo domensko ime, prenehalo z delovanjem ali si ne more več privoščiti vzdrževanja strežnika. Zakaj torej v svetu obstaja toliko izgubljenih povezav? Deloma je to preprosto pomanjkanje previdnosti. Tukaj je nekaj razlogov, ki jih lahko slišite:

Smo le reorganizirali spletno mesto, da bi ga izboljšali.

Ali res menite, da stari URI ne morejo več delovati? Če je tako, ste jih izbrali zelo slabo. Razmislite, kako se novi obdržijo po naslednjem redesignu.

Imamo toliko materiala, da ne moremo slediti temu, kaj je zastarelo, kaj je zaupno in kaj je še vedno aktualno, zato smo mislili, da je bolje kar vse izklopiti.

Lahko le sočustvujem. W3C je doživel obdobje, ko smo morali skrbno preglejati arhivske materiale glede zaupnosti, preden smo jih dali v javnost. Odločitev mora biti premislena vnaprej — poskrbite, da z vsakim dokumentom zabeležite sprejemljivo skupino bralcev, datum ustvarjanja in, idealno, rok trajanja. Ohranjajte te metapodatke.

No, ugotovili smo, da je treba datoteke premakniti...

To je jedan od najsmešnijih izgovora. Mnogi ne znaju da web serveri omogućavaju upravljanje vezom između URI objekta i stvarne lokacije u datotečnom sistemu. Zamislite URI prostor kao apstraktni prostor, savršeno organizovan. Zatim napravite mapiranje na bilo koju stvarnost koju zapravo koristite za njegovu implementaciju. Nakon toga obavestite web server o tome. Čak možete napisati deo svog servera kako biste sve postavili ispravno.

Džon više ne podržava ovu datoteku, sada to radi Džejn.

Da li je Džonovo ime bilo u URI? Ne, samo je datoteka bila u njegovom direktorijumu? Ah, jasno.

Pre smo za to koristili CGI skript, a sada koristimo binarnu aplikaciju.

Postoji luda ideja da stranice kreirane skriptama treba da budu smeštene u "cgibin" ili "cgi" području. To otkriva način na koji pokrećete svoj web server. Menjate mehanizam (čak i kada zadržavate sadržaj), i ups — svi vaši URI se menjaju.

Uzmimo, na primer, Nacionalnu naučnu fondaciju (NSF):

Online dokumenti NSF

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Prva stranica za pregled dokumenata očigledno neće ostati takva kroz nekoliko godina. cgi-bin, oldbrowse in pl — sve to daje delove informacija o tome kako-mi-to-radimo-sada. Ako koristite stranicu za pretragu dokumenta, dobijate isto tako loš rezultat:

Izveštaj radne grupe za kriptologiju i teoriju kodiranja

http://www.nsf.gov/cgi-bin/getpub?nsf9814

za indeksnu stranicu dokumenta, iako sam html dokument izgleda mnogo bolje:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Ovde naslov pubs/1998 pruža bilo kom budućem arhivskom servisu dobar ključ za razumevanje starog sistema klasifikacije dokumenata iz 1998. godine. Iako bi u 2098. godini brojevi dokumenata mogli izgledati drugačije, mogu da zamislim da će ovaj URI i dalje biti važeći, i neće naštetiti NSF-u ili bilo kojoj drugoj organizaciji koja će održavati arhiv.

Nisam mislio da URL-ovi treba da budu trajni — postojali su URN.

Verovatno je ovo jedan od najgorih neželjenih efekata rasprave o URN. Neki misle da zbog istraživanja o trajnijem imenskom prostoru mogu nepažljivo pristupiti visećim linkovima, smatrajući da će „URN to sve popraviti“. Ako ste jedan od tih ljudi, dozvolite mi da vas razočaram.

Večina URN shem, ki sem jih videl, izgleda kot identifikator avtoritete, ki mu sledi bodisi datum in niz, ki ga izberete, bodisi preprosto niz, ki ga izberete. To je zelo podobno HTTP URI. Z drugimi besedami, če menite, da bo vaša organizacija sposobna ustvariti dolgotrajne URN, to dokažite zdaj, in sicer z njihovim uporabništvom za svoje HTTP URI. V samem HTTP ni nič, kar bi vaš URI naredilo nestabilnega. To počne le vaša organizacija. Ustvarite bazo podatkov, ki uskladi URN dokumenta z aktualnim imenom datoteke, in omogočite spletnemu strežniku, da jo uporabi za dejansko pridobivanje datotek.

Če ste prišli do te točke in nimate časa, denarja in povezav, da bi razvili programsko opremo, lahko navedete naslednje opravičilo:

Želeli smo, a preprosto nimamo pravih orodij.

Temu pa lahko izrazimo sočutje. Popolnoma se strinjam. Kar morate storiti, je, da omogočite spletnemu strežniku hiter odziv na stalni URI in vrnete datoteko, kjerkoli je ta trenutno shranjena v vaši trenutni zmešani datotečni sistem. Želite shraniti vse URI v datoteko kot preverjanje in nenehno posodabljati bazo podatkov, da bo v skladu s trenutnostjo. Želite obdržati odnose med različnimi različicami in prevodi istega dokumenta ter ohraniti neodvisen zapis kontrolne vsote za zaščito pred poškodbami datotek zaradi naključne napake. In spletni strežniki preprosto ne pridejo iz škatle z takšnimi funkcijami. Ko želite ustvariti nov dokument, vam vaš urejevalnik zahteva, da določite URI.

Potrebujete možnost spreminjanja lastništva, dostopa do dokumenta, nivoja varnosti arhivske ravni in drugega v prostoru URI brez spreminjanja URI.

Vse je preveč slabo. A to bomo popravili. V W3C uporabljamo funkcionalnost Jigedit (strežnik Jigsaw za urejanje), ki sledi verzijam, in eksperimentiramo s skripti za ustvarjanje dokumentov. Če razvijate orodja, strežnike in odjemalce, bodite pozorni na to težavo!

To opravičilo se nanaša tudi na številne strani W3C, vključno s to: torej delajte tisto, kar govorim, ne pa tisto, kar počnem.

Zakaj bi me to moralo skrbeti?

Ko ko spremenite URI na svojem strežniku, nikoli ne morete povsem reči, kdo bo imel povezave na staro URI. To so lahko povezave z običajnih spletnih strani. Zaznamki na vaši strani. URI je lahko bil napisani na robovih pisma prijatelju.

Ko nekdo klikne na povezavo in je ta pokvarjena, običajno izgubi zaupanje v lastnika strežnika. Prav tako je razočaran - tako čustveno kot dejansko, ker ne more doseči svojega cilja.

Mnogo ljudi nenehno pritožuje zaradi pokvarjenih povezav, in upam, da je škoda očitna. Upam, da je prav tako očitna ugledna škoda vzdrževalcem strežnika, kjer je dokument izginil.

Kaj naj torej naredim? Oblikovanje URI.

Obveznost spletnega skrbnika je, da določi URI, ki bodo uporabni čez 2 leti, čez 20 let, čez 200 let. Za to so potrebni premislek, organizacija in usmerjenost.

URI se spreminjajo, če se spremeni kakšna informacija. Zelo pomembno je, kako jih oblikujete. (Kaj, oblikovanje URI? Moram oblikovati URI? Da, o tem morate razmisliti). Oblikovanje predvsem pomeni odsotnost kakršne koli informacije v URI.

Datum ustvarjanja dokumenta - datum dodelitve URI - je nekaj, kar se nikoli ne bo spremenilo. Zelo je koristno za ločevanje poizvedb, ki uporabljajo nov sistem, od tistih, ki uporabljajo star sistem. Od tega je dobro začeti URI. Če je na dokumentu označen kakršen koli datum, tudi če bo dokument relevanten v prihodnosti, je to dobra osnova.

Edina izjema je stran, ki je namerno 'zadnja' različica, na primer za celo organizacijo ali velik njen del.

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

To je zadnja kolumna Money Daily v reviji Money. Glavni razlog, zakaj v tej URI ni potrebnega datuma, je, da ni nobenega razloga za ohranitev URI, ki bo preživel revijo. Koncept Money Daily bo izginil, ko bo Money izginil. Če želite povezati vsebino, se morate povezati z njo ločeno v arhivih:

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

(Izgleda dobro. Predpostavlja, da bo 'money' pomenil isto skozi celotno obstoj pathfinder.com. Obstaja podvajanje '98' in nepotreben '.html', toda drugače izgleda kot močan URI.

Kaj pustiti ob strani

Vse! Razen datuma ustvarjanja, kakršna koli informacija v URI, se na nek način obnavlja na težave.

  • Ime avtorja. Avtorstvo se lahko spremeni z novimi različicami. Ljudje zapuščajo organizacije in prepuščajo stvari drugim.
  • Predmet. To je zelo težko. Sprva vedno izgleda dobro, vendar se neverjetno hitro spremeni. O tem bom podrobneje spregovoril spodaj.
  • Status. Katalogi, kot so 'staro', 'osnutek' in tako naprej, ne govorimo o 'zadnjem' in 'kul', se pojavijo v vseh datotečnih sistemih. Dokumenti spremenijo status — drugače ni smiselno ustvarjati osnutkov. Zadnja različica dokumenta potrebuje natančno identifikacijo, ne glede na njen status. Ohranite status ločen od imena.
  • Dostop. V W3C smo razdelili spletno stran na oddelke za zaposlene, člane in javnost. Zveni dobro, vendar dokumenti začnejo kot ideje ekip zaposlenih, se razpravljajo s člani, nato pa postanejo dostopni javnosti. Res je težko, če se ob odprtju dokumenta za širšo razpravo vsi stari povezave na njem pokvarijo! Zdaj prehajamo na preprost datumovni kodo.
  • Razširitev datoteke. Zelo razširjena praksa. "cgi", celo ".html" se bo v prihodnosti spremenila. Morda čez 20 let ne boste več uporabljali HTML za to stran, vendar bi morale danes povezave nanjo še vedno delovati. Kanonične povezave na spletnem mestu W3C ne uporabljajo razširitve (kako to storiti).
  • Programski mehanizmi. V URI iščite 'cgi', 'exec' in druge izraze, ki vpijejo 'poglejte, kakšno programsko opremo uporabljamo'. Ali kdo želi posvetiti celo življenje skriptam Perl CGI? Ne? Potem odstranite razširitev .pl. Preberite priročnik strežnika o tem, kako to storiti.
  • Ime diska. Ja, res! Ampak to sem že videl.

Tako je najboljši primer z naše strani preprosto

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

… poročilo o protokolu srečanja predsednikov W3C.

Teme in razvrstitev po temah

Podrobneje bom govoril o tej nevarnosti, saj je to ena tistih stvari, ki jih je najtežje preprečiti. Običajno teme pridejo v URI, ko razvrščate svoje dokumente glede na opravljeno delo. Vendar se ta razvrstitev sčasoma spremeni. Imena področij se bodo spremenila. V W3C smo želeli spremeniti MarkUP v Markup, nato pa v HTML, da bi odražali dejansko vsebino razdelka. Poleg tega je tukaj pogosto ploski prostor imen. Čez 100 let ste prepričani, da ne boste želeli ničesar znova uporabiti? V našem kratkem življenju smo že želeli ponovno uporabiti „Zgodovino“ in „Slogovne liste“, na primer.

To je mamljiv način organizacije spletnega mesta — in resnično mamljiv način organizacije česarkoli, vključno z vso mrežo. To je odlična srednjeročna rešitev, a ima resne pomanjkljivosti na dolgi rok.

Delno so vzroki zakoreninjeni v filozofiji smisla. Vsak izraz v jeziku je potencialni objekt klastriranja, vsak posameznik pa lahko ima različne predstave o tem, kaj pomeni. Ker so odnosi med subjekti bolj podobni mreži kot drevesu, lahko celo tisti, ki se strinjajo z mrežo, izberejo drugo predstavitev drevesa. To so moje (pogosto ponavljane) splošne pripombe o nevarnostih hierarhične klasifikacije kot splošne rešitve.

Dejansko, ko uporabite ime teme v URI, se zavežete neki klasifikaciji. Morda boste v prihodnosti raje izbrali drugo različico. Takrat bo URI izpostavljen kršitvi.

Razlog za uporabo tematskega področja kot dela URI je, da je odgovornost za podpodročja prostora URI običajno delegirana, tako da potrebujete ime organizacijskega organa — oddelka, skupine ali česarkoli drugega, kar nosi odgovornost za to podprostor. To je vezava URI na organizacijsko strukturo. Običajno je varna le takrat, ko je naprej (levo) URI zaščiten z datumom: 1998/pics lahko vašemu strežniku pomeni „to, kar smo imeli v mislih leta 1998 pod pics“, ne pa „to, kar smo v 1998 storili s tistim, kar zdaj imenujemo pics“.

Ne pozabite na ime domene

Ne pozabite, da to velja ne le za pot v URI, temveč tudi za ime strežnika. Če imate ločene strežnike za različne stvari, upoštevajte, da te delitve ne bo mogoče spremeniti brez uničenja velikega števila povezav. Nekatere klasične napake, kot je „poglejte, katero programsko opremo uporabljamo danes“ — domenska imena "cgi.pathfinder.com", "secure", "lists.w3.org". Ta so bila ustvarjena, da bi olajšala upravljanje strežnikov. Ne glede na to, ali domena predstavlja kakšno podružnico v vaši družbi, status dokumenta, raven dostopa ali raven varnosti, bodite zelo, zelo previdni, preden uporabite več kot eno domensko ime za različne vrste dokumentov. Ne pozabite, da lahko skrijete številne spletne strežnike znotraj enega vidnega spletnega strežnika, tako da uporabite preusmerjanje in posredovanje.

Da, in še razmislite o svojem domenskem imenu. Ne želite, da vas povezujejo kot soap.com potem, ko spremenite svojo produktno linijo in prenehate proizvajati milo (Opravičujem se tistemu, ki trenutno ima soap.com).

Zaključek

Ohranjanje URI god 2, 20, 200 ali celo 2000 let, ni le enostavno, kot se zdi. Kljub temu pa na internetu webmasterji sprejemajo odločitve, ki si v prihodnosti resnično otežijo to nalogo. To pogosto nastane, ker uporabljajo orodja, katerih naloga je predstaviti najboljšo stran samo v tem trenutku — in nihče ni ocenil, kaj se bo zgodilo s povezavami, ko se bo vse spremenilo. Vendar pa je glavna ideja, da se lahko in mora veliko, zelo veliko spremeniti, vaši URI pa morajo ostati enaki. To je mogoče le, če razmislite o tem, kako jih ustvarjate.

Glej tudi:

Razširitve

Kako odstraniti razširitve datotek…

…iz URI v trenutnem spletnem strežniku, ki temelji na datotekah?

Če uporabljate, na primer, Apache, ga lahko konfigurirate, da se uskladi z vsebino. Ohranite razširitev datoteke (npr. .png) v datoteki (npr. mydog.png), vendar lahko na spletne vire pokličete tudi brez njega. Nato Apache preveri imenik, ali vsebuje vse datoteke s tem imenom in katerim koli razširitvijo, ter lahko izbere najboljšo iz nabora (na primer, GIF in PNG). In ni vam treba postavljati različnih vrst datotek v različne imenike, dejansko usklajevanje vsebine ne bo delovalo, če to storite.

  • Nastavite svoj strežnik za usklajevanje vsebine
  • Vedno ustvarjajte povezave na URI brez razširitve

Povezave z razširitvami še vedno delujejo, vendar ne omogočajo vašemu strežniku, da izbere najboljšo trenutno in prihodnje razpoložljive formate.

(V resnici, mojpes, mydog.png in mydog.gif — veljavne spletne povezave, mojpes — to je vir univerzalnega tipa vsebine, medtem ko mydog.png in mydog.gif — so viri specifičnega tipa vsebine).

Seveda, če pišete lasten spletni strežnik, je dobro uporabiti bazo podatkov za povezavo trajnih identifikatorjev z njihovo trenutno obliko, čeprav bodite previdni pred neomejenim povečevanjem podatkovne baze.

Sramotna tabla — Zgodba 1: Channel 7

Med letom 1999 sem spremljal zapiranje šol zaradi snega na strani http://www.whdh.com/stormforce/closings.shtml. Ne morem čakati, da bo informacija prikazana na dnu televizijskega zaslona! Dal sem povezavo na svojo domačo stran. Prihaja prvi veliki snežni vihar leta 2000 in preverjam stran. Na njej piše:

— Status.
Trenutno ni nobenih zaprtij. Prosimo, vračajte se ob vremenskih opozorilih.

Ne more biti tako močan vihar. Zabavno, da datum manjka. Ampak, če odprete glavno stran spletnega mesta, bo tam velika gumb 'Zaprte šole', ki vodi do strani http://www.whdh.com/stormforce/ z dolgim seznamom zaprtih šol.

Mogoče so spremenili sistem pridobivanja seznama — ampak ni jim bilo treba spreminjati URI.

Sramotna tabla — Zgodba 2: Microsoft Netmeeting

Z naraščajočo odvisnostjo od interneta se je pojavila pametna misel, da je možno v aplikacije vključiti povezave do spletnega mesta proizvajalca. To so pogosto uporabljali in močnejše zlorabili, vendar — URL se ne sme spremeniti. Pred nekaj dnevi sem poskusil povezavo iz odjemalca Microsoft Netmeeting 2/something v meniju Pomoč/Microsoft na spletu/Brezplačne stvari in prejel napako 404 — odgovor strežnika ni bil najden. Mogoče so ga že popravili…

©1998 Tim BL

Zgodovinska opomba: ob koncu 20. stoletja, ko je bilo to napisano, je bila beseda 'kul' izraz odobravanja, še posebej med mladimi, kar je označevalo modnost, kakovost ali ustreznost. V naglici so pot URI pogosto izbirali zaradi 'kul' videza, ne pa uporabnosti ali trajnosti. Ta opomba je poskus preusmeritve energije, ki jo prinaša iskanje kul stvari.

Izvor: habr.com

Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki 🔥 Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki | ProHoster