URL

adressen som sier hvor en ting er

Hva det er

En URL, kort for Uniform Resource Locator og i dagligtale kalt nettadresse eller bare lenke, er en tekstlinje som både navngir en ressurs og forteller programvare hvordan den skal hentes: hvilken protokoll som skal snakkes, hvilken maskin som skal spørres, og hva den maskinen skal spørres om. Lim den inn i en nettleser, en terminal eller en konfigurasjonsfil, så kan hver av dem handle ut fra den uten mer hjelp.

Oppbygningen ligger fast gjennom den generiske syntaksen, som er lik uansett skjema:

https://shop.example.com:8443/orders/42?view=full#items

scheme     https
host       shop.example.com
port       8443
path       /orders/42
query      view=full
fragment   items

Skjemaet sier hvordan ressursen nås, her HTTP over TLS. Verten og en valgfri port sier hvor, stien sier hvilken ressurs på den verten, og spørrestrengen bærer parametere, som regel som par av typen name=value satt sammen med &. Fragmentet etter # peker inn i resultatet, på en overskrift eller en posisjon. Det hører til klienten: nettleseren tar det bort før forespørselen sendes, så serveren får aldri vite hvilken del av siden leseren ble sendt til.

Fordi tegn som /, ?, #, & og = har oppgaver i den strukturen, må hvert av dem som opptrer som vanlige data, prosentkodes: skrives som % fulgt av to heksadesimale sifre. Et mellomrom blir %20, et og-tegn %26 og selve prosenttegnet %25. Bokstaver utenfor ASCII reiser på samme måte, som UTF-8-bytene sine, og det er slik danske eller ukrainske ord i en sti kommer fram.

Er en URL det samme som en URI? Nesten. En URI, Uniform Resource Identifier, er enhver streng i den syntaksen som identifiserer noe. En URL er den typen som også sier hvordan det kan finnes, mens urn:isbn:9780000000002 navngir en bok uten å gi noen måte å hente den på. RFC 3986 ber nye spesifikasjoner om å si URI. WHATWG URL Standard, som nettleserne følger, gikk motsatt vei: den valgte URL som det ene ordet og satte seg fore å beskrive hva virkelige implementasjoner gjør, med mål om å erstatte RFC-en. De to er enige om vanlige adresser og skiller lag i kanttilfeller, og det er verdt å huske når en nettleser og et serverbibliotek tolker den samme rare strengen.

Hvorfor det er viktig

En publisert URL er et løfte. Den havner i bokmerker, søkeindekser, e-poster, trykte brosjyrer, chattelogger og andres sider, og ingen av de kopiene oppdaterer seg selv. Endres adressen senere, brytes hver eneste av dem, med mindre den gamle adressen fortsetter å svare med en omdirigering til den nye.

Det gjør den nyttige beslutningen til en tidlig en: hva adressen bygges av. Alt som sannsynligvis endres, er et dårlig fundament, enten det er en sidetittel, et kategoritre, et produktnavn eller en filendelse som avslører rammeverket som brukes i dag. En kort identifikator varer, og det samme gjør en slug som lagres som data og bare endres med vilje. Det gjør også en plan for hva som skjer når en adresse likevel må flyttes: den gamle blir en permanent omdirigering og ikke en 404.

Den andre beslutningen er hva som holdes utenfor. RFC 9110 sier det rett ut: adresser er laget for å deles, ikke for å sikres. De skrives til loggene på servere og proxyer, blir liggende i nettleserhistorikken, kopieres inn i webanalyse og sendes, avhengig av policy, med i Referer-headeren til det siden laster inn etterpå. Øktidentifikatorer, tokens for tilbakestilling, API-nøkler og personopplysninger hører hjemme i headere eller i forespørselskropper.

Lengde er et mindre spørsmål. HTTP-spesifikasjonen anbefaler at programvare godtar adresser på minst 8 000 oktetter, noe som er rundhåndet. En spørrestreng som bærer et helt skjema eller et serialisert filter, har likevel en tendens til å treffe en kortere grense et sted langs kjeden før den kommer så langt.

Slik ser det ut i praksis

Arbeidet med dette nettstedet behandler adresser som data som lever lenger enn teksten på siden. Da 495 resultatsider på tre språk ble generert fra en skrivebeskyttet SQLite-eksport, gjaldt beslutningen med størst konsekvenser adressen. Nettstedet utledet tidligere en sides URL fra de første ordene i den engelske formuleringen, så å rette en setning flyttet siden i det stille og brøt alle lenker til den. Adressen skrives nå som data, én rad per adresse per resultat: den første raden er den gjeldende, og hver senere rad er en utfaset adresse som nettstedet sender ut som en omdirigering. Alle adressene nettstedet noen gang har publisert, svarer fortsatt.

Et notat om lommebøker på mobil viser hva som skjer når én URL reiser inne i en annen. Phantom, Solflare og Backpack åpner en dApp gjennom universelle lenker som bærer måladressen i sin egen sti og opprinnelsen til siden som ber om det, i en parameter som heter ref, begge sendt gjennom encodeURIComponent. Et ukodet ? eller & i målet ødelegger tolkningen, og lommeboken åpner på startskjermen sin i stedet for i nettleserfanen. Et gjettet eget skjema som backpack:// går det verre med: appen kjenner ikke igjen skjemaet, og brukeren havner på installasjonssiden.

Adresser tjener også som identitet. Da 963 blokker med strukturerte data ble byttet ut med én lenket graf, ble identifikatorene for organisasjonen, nettstedet og personen utstedt fra nettstedets origin, og listesider publiserer elementene sine bare med URL. Det valget ble målt: å navngi elementene på porteføljeindeksen ville ha betydd 107 fullstendige formuleringer og en komprimert side som var 52 % større. Kontrollen som vokter grafen, slår fast at hver URL den nevner, faktisk ble bygget.

Hvor det går galt

Feil i URL-er er som regel stille. Adressen ser fortsatt riktig ut; den peker bare et annet sted, eller avslører mer enn meningen var.

Koding skjer null ganger eller to. En returadresse som slippes rett inn i en spørrestreng, som i ?next=/cart?item=4&size=m, deles ved den andre &, og serveren ser size=m som en egen parameter. Å kode en streng som allerede er kodet, gjør %20 om til %2520, og siden får en bokstavelig %20. Kod hver komponent nøyaktig én gang, i det øyeblikket den settes inn i adressen, med funksjonen som er laget for komponenter. I JavaScript er det encodeURIComponent; encodeURI lar ?, & og # være i fred fordi den venter en hel adresse.

En hemmelighet reiser i spørrestrengen. Et token for tilbakestilling av passord eller en API-nøkkel i URL-en kopieres inn i tilgangslogger, nettleserhistorikk og webanalyse, og med en romslig referrer-policy sendes det i Referer til hver tredjepart siden laster noe fra. Legg legitimasjon i en header. Når et token må reise i en lenke, som i en e-post for tilbakestilling, gjør det til et engangstoken med kort levetid, og sett en Referrer-Policy som holder det hjemme.

Én side svarer på fem adresser. http og https, med og uten www, med og uten skråstrek til slutt, /About og /about. Skjema og vert skiller per definisjon ikke mellom store og små bokstaver, mens stien gjør det, med mindre serveren bestemmer noe annet. Søkemotorer deler sidens anseelse mellom kopiene, cacher lagrer hver av dem for seg, og webanalysen teller dem hver for seg. Velg én form, omdiriger alle andre former permanent til den, og oppgi den som kanonisk URL.

En relativ lenke løses opp mot feil base. En referanse som img/logo.png erstatter alt etter den siste skråstreken i den gjeldende stien. På /docs/guide løses den opp til /docs/img/logo.png; på /docs/guide/ løses den opp til /docs/guide/img/logo.png. Én avsluttende skråstrek flytter hver relative lenke på siden. Rotrelative lenker, som starter med /, går utenom problemet.

Logikken avhenger av fragmentet. Omdirigeringer på serveren, tilgangslogger og webanalyse som leser forespørselen, ser alt fram til # og stopper der. Alt som må nå serveren, hører hjemme i stien eller i spørrestrengen.

Les mer

Ordliste