{"id":89253,"date":"2020-07-21T01:42:24","date_gmt":"2020-07-20T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya"},"modified":"2020-07-21T01:42:24","modified_gmt":"2020-07-20T23:42:24","slug":"krutye-uri-ne-izmenyayutsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya","title":{"rendered":"Seje URI'er \u00e6ndres ikke","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Forfatter \u2014 Sir Tim Berners-Lee, opfinder af URI, URL, HTTP, HTML og World Wide Web, nuv\u00e6rende leder af W3C. Artiklen blev skrevet i 1998. <\/p>\n

Hvilken URI kan betragtes som \"cool\"?
\nEn, der ikke \u00e6ndres.
\nHvordan \u00e6ndres URIs?
\nURIs \u00e6ndres ikke: det er mennesker, der \u00e6ndrer dem.<\/i> <\/p>\n

Teoretisk set har folk ingen grund til at \u00e6ndre URIs (eller stoppe med at underst\u00f8tte dokumenter), men i praksis er der millioner.<\/p>\n

Teoretisk set ejer den nominelle ejer af dom\u00e6neomr\u00e5det faktisk dom\u00e6neomr\u00e5det og dermed alle URIs i det. Udover insolvens er der intet, der forhindrer dom\u00e6neejeren i at beholde dette navn. Og teoretisk set er URI-rummet under dit dom\u00e6nenavn helt under din kontrol, s\u00e5 du kan g\u00f8re det s\u00e5 stabilt, som du \u00f8nsker. I h\u00f8j grad er den eneste gyldige grund til, at et dokument forsvinder fra internettet, at virksomheden, der ejer dom\u00e6nenavnet, er g\u00e5et ud af drift eller ikke l\u00e6ngere kan betale for serverdriften. S\u00e5 hvorfor er der s\u00e5 mange d\u00f8de links i verden? Dels er det bare et sp\u00f8rgsm\u00e5l om mangel p\u00e5 forudseenhed. Her er nogle grunde, man kan h\u00f8re:
\n<\/a><\/noindex><\/p>\n

Vi har bare reorganiseret hjemmesiden for at g\u00f8re den bedre.<\/h4>\n

\nTror du virkelig, at gamle URIs ikke l\u00e6ngere kan fungere? Hvis ja, s\u00e5 har du valgt dem meget d\u00e5rligt. T\u00e6nk p\u00e5, hvordan de nye kan bevares efter n\u00e6ste redesign.<\/p>\n

Vi har s\u00e5 meget materiale, at vi ikke kan holde styr p\u00e5, hvad der er for\u00e6ldet, hvad der er fortroligt, og hvad der stadig er relevant, og dermed mente vi, at det var bedre bare at slukke for det hele.<\/h4>\n

\nJeg kan kun sympatisere. W3C har oplevet en periode, hvor vi m\u00e5tte grundigt gennemg\u00e5 arkivmateriale for fortrolighed, f\u00f8r vi gjorde det offentligt tilg\u00e6ngeligt. Beslutningen b\u00f8r t\u00e6nkes igennem p\u00e5 forh\u00e5nd \u2014 s\u00f8rg for, at du registrerer en acceptabel l\u00e6serkreds, oprettelsesdato og ideelt set udl\u00f8bsdato for hvert dokument. Behold disse metadata.<\/p>\n

N\u00e5, vi har opdaget, at vi skal flytte filer\u2026<\/h4>\n

\nDet er en af de mest ynkelige undskyldninger. Mange ved ikke, at webservere giver dig mulighed for at styre forbindelsen mellem en objekts URI og dets faktiske placering i filsystemet. Forestil dig det URI-omr\u00e5de som et abstrakt rum, perfekt organiseret. S\u00e5 lav en mapping til enhver virkelighed, som du rent faktisk bruger til at implementere det. Derefter informerer du webserveren om dette. Du kan endda skrive en del af din server for at g\u00f8re alt korrekt.<\/p>\n

John underst\u00f8tter ikke denne fil l\u00e6ngere, det g\u00f8r Jane nu.<\/p>\n

Var Johns navn i URI'en? Nej, filen l\u00e5 bare i hans mappe? N\u00e5 ja.<\/p>\n

Tidligere brugte vi CGI-scripts til dette, men nu bruger vi et bin\u00e6rt program.<\/h4>\n

\nDer er en sk\u00f8r id\u00e9 om, at sider lavet med scripts skal placeres i \"cgibin\" eller \"cgi\"-omr\u00e5det. Dette afsl\u00f8rer, hvordan du k\u00f8rer din webserver. \u00c6ndrer du mekanismen (selv n\u00e5r du bevarer indholdet), og ups \u2014 alle dine URI'er \u00e6ndrer sig.<\/p>\n

Lad os tage National Science Foundation (NSF) som et eksempel:<\/p>\n

NSF's online dokumenter<\/p>\n

http:\/\/www.nsf.gov\/cgi-bin\/pubsys\/browser\/odbrowse.pl<\/pre>\n
\nDen f\u00f8rste side til at begynde at gennemse dokumenter vil tydeligvis ikke forblive s\u00e5dan om nogle \u00e5r. cgi-bin<\/code>, oldbrowse<\/code> og pl<\/code>\u00a0\u2014 alt dette giver fragmenter af information om, hvordan-vi-g\u00f8r-det-nu. Hvis du dog bruger en side til at s\u00f8ge efter et dokument, f\u00e5r du f\u00f8rst et lige s\u00e5 d\u00e5rligt resultat:<\/p>\n
Rapport fra arbejdsgruppen om kryptografi og kodeteori<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\nfor indeks-siden til dokumentet, selvom selve html-dokumentet ser meget bedre ud:<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nHer giver overskriften pubs\/1998 enhver fremtidig arkivservice en god n\u00f8gle til at forst\u00e5, hvad den gamle klassifikationsordning for dokumenter fra 1998 handler om. Selvom dokumentnumrene i 2098 muligvis ser anderledes ud, kan jeg forestille mig, at denne URI stadig vil v\u00e6re gyldig, og at den ikke vil genere NSF eller nogen anden organisation, der vil opretholde arkivet.<\/p>\n
Jeg troede ikke, at URL'er skulle v\u00e6re permanente - der har jo v\u00e6ret URN.<\/h4>\n
\nDette er sandsynligvis en af de v\u00e6rste bivirkninger ved diskussionen om URN. Nogle mener, at p\u00e5 grund af forskningen om et mere permanent navnerum kan de negligere h\u00e6ngende links, fordi \"URN vil l\u00f8se alt dette\". Hvis du er en af disse mennesker, s\u00e5 lad mig skuffe dig.<\/p>\n
De fleste URN-ordninger, jeg har set, ligner en autoritetsidentifikator efterfulgt af enten en dato og en streng, du v\u00e6lger, eller blot en streng, du v\u00e6lger. Det minder meget om en HTTP-URI. Med andre ord, hvis du mener, at din organisation vil v\u00e6re i stand til at oprette langtidsholdbare URN'er, s\u00e5 bevis det nu ved at bruge dem til dine HTTP-URI'er. I selve HTTP er der intet, der g\u00f8r din URI ustabil. Kun din organisation. Opret en database, der matcher dokumentets URN med det aktuelle filnavn, og lad webserveren bruge den til faktisk at hente filer.<\/p>\n
Hvis du er kommet til dette punkt, s\u00e5 hvis du ikke har tid, penge og forbindelser til at udvikle noget software, kan du komme med denne undskyldning:<\/p>\n
Vi ville gerne, men vi har bare ikke de n\u00f8dvendige v\u00e6rkt\u00f8jer.<\/h4>\n
\nOg det kan man have medf\u00f8lelse med. Jeg er helt enig. Hvad du skal g\u00f8re, er at f\u00e5 webserveren til \u00f8jeblikkeligt at h\u00e5ndtere den permanente URI og returnere filen, uanset hvor den i \u00f8jeblikket er gemt i dit nuv\u00e6rende sk\u00f8re filsystem. Du vil gerne gemme alle URI'er i en fil som en tjek, og konstant holde databasen opdateret. Du vil gerne bevare relationerne mellem forskellige versioner og overs\u00e6ttelser af det samme dokument, samt opbevare en uafh\u00e6ngig checksum for at sikre beskyttelse mod filskader ved en tilf\u00e6ldig fejl. Og webservere kommer simpelthen ikke med disse funktioner. N\u00e5r du vil oprette et nyt dokument, beder din editor dig om at angive en URI.<\/p>\n
Du har brug for muligheden for at \u00e6ndre ejerskab, adgang til dokumentet, sikkerhedsniveauer for arkivniveau og andre i URI-rummet uden at \u00e6ndre URI'en.<\/p>\n
Det er alt for skidt. Men vi vil rette op p\u00e5 det. I W3C bruger vi funktionaliteten fra Jigedit (Jigsaw-serveren til redigering), som sporer versioner, og vi eksperimenterer med scripts til at oprette dokumenter. Hvis du udvikler v\u00e6rkt\u00f8jer, servere og klienter, s\u00e5 v\u00e6r opm\u00e6rksom p\u00e5 dette problem!<\/p>\n
Denne undskyldning g\u00e6lder ogs\u00e5 for mange W3C-sider, inklusive denne: s\u00e5 g\u00f8r det, jeg siger, og ikke det, jeg g\u00f8r.<\/p>\n
Hvorfor skulle jeg bekymre mig om det?<\/h1>\n
\nN\u00e5r du \u00e6ndrer URI p\u00e5 din server, kan du aldrig helt sige, hvem der har links til den gamle URI. Det kan v\u00e6re links fra almindelige web-sider. Bogm\u00e6rker til din side. URI'en kan v\u00e6re ridset ind p\u00e5 kanten af et brev til en ven.<\/p>\n
N\u00e5r nogen klikker p\u00e5 et link og det er brudt, mister de typisk tilliden til ejer af serveren. De bliver ogs\u00e5 skuffede \u2014 b\u00e5de f\u00f8lelsesm\u00e6ssigt og reelt, da de ikke kan n\u00e5 deres m\u00e5l.<\/p>\n
Mange mennesker klager konstant over d\u00f8de links, og jeg h\u00e5ber, at skaden er \u00e5benlys. Jeg h\u00e5ber, at den omd\u00f8mme skade, der rammer serverens vedligeholder, hvor dokumentet er forsvundet, ogs\u00e5 er indlysende.<\/p>\n
Hvad skal jeg g\u00f8re? Design URI<\/h1>\n
\nDet er webmasterens pligt at skabe URI'er, der kan bruges om 2 \u00e5r, om 20 \u00e5r, om 200 \u00e5r. Det kr\u00e6ver omtanke, organisering og fokus.<\/p>\n
URI'er \u00e6ndres, n\u00e5r der sker \u00e6ndringer i deres information. Det er meget vigtigt, hvordan du designer dem. (Hvad, designe URI? Skal jeg designe URI? Ja, du skal t\u00e6nke over det). Design handler prim\u00e6rt om at udelade enhver information i URI.<\/p>\n
En dokumentoprettelsesdato \u2014 datoen for udstedelse af URI \u2014 er noget, der aldrig vil \u00e6ndre sig. Det er meget nyttigt til at adskille anmodninger, der bruger det nye system, fra dem der bruger det gamle system. Det er en god start for URI. Hvis dokumentet har en dato angivet, selvom dokumentet vil v\u00e6re relevant i fremtiden, er det en god begyndelse.<\/p>\n
Den eneste undtagelse er en side, der bevidst er den \"sidste\" version, for eksempel for hele organisationen eller en stor del af den.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nDette er den sidste kolonne i Money Daily i tidsskriftet Money. Den prim\u00e6re grund til, at der ikke er brug for en dato i denne URI, er, at der ikke er nogen grund til at bevare en URI, der vil overleve tidsskriftet. Konceptet Money Daily vil forsvinde, n\u00e5r Money forsvinder. Hvis du \u00f8nsker at henvise til indholdet, skal du henvise til det separat i arkiverne:<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(Ser godt ud. Antager, at \"money\" vil betyde det samme gennem hele pathfinder.coms eksistens. Der er en duplication af \"98\" og en un\u00f8dvendig \".html\", men ellers ser det ud som en st\u00e6rk URI.<\/p>\n
Hvad der skal udelades<\/h4>\n
\nAlt! Udover dokumentets oprettelsesdato, hvis du placerer nogen information i URI, inviterer du p\u00e5 en eller anden m\u00e5de til problemer.<\/p>\n