Skulle du logge deg på, måtte du oppgi passordet som en del av URL-en

I denne fjerde og siste artikkelen i serien om URL-ens historie, skal vi blant annet se litt nærmer på noen tegn og kombinasjoner som forekommer i mange URL-er, men som ofte bare framstår som uryddig støy for de uinnvidde.

Men aller først skal vi starte med en noe som nok var praktisk, men som i dagens internett- og webomgivelser framstår som en veldig dårlig idé, nemlig muligheten for å kunne oppgi brukernavn og passord i URL-en, på denne måten:

Dette skal ha vært den første autentiseringsmåten på weben, men den hadde flere åpenbare svakheter. Riktignok ble brukernavnet og passordet kodet med Base64, men for alle med tilgang til å avlytte forbindelsen, var det en smal sak å dekode innloggingsinformasjonen.

For da dette kom, var det fortsatt lenge igjen før de fleste nettsteder hadde tatt i bruk krypterte forbindelser med HTTPS.

Når vi skriver om dette i preteritum, er det fordi denne måten å gjøre autentisering på, har blitt frarådet i alle fall siden 2005. Den støttes likevel av enkelte nettlesere.

Spørringsparametere

Fra starten av var websider i stor grad statiske dokumenter som var lagret i filer i et mappehierarki, og dette gjenspeilet seg hva URL-ene inneholdt av informasjon. Med tradisjonelle, dynamisk genererte websider – hvor HTML-dokumentene som leveres til nettleserne typisk består av data fra en database som er satt inn i en mal – vil URL-ene ofte kunne inneholde spørringsparametre («query parameters») slik som dette:

Det er tre ting å legge merke til her. For det første så er det ikke oppgitt noe dokument, slik som index.html. Det betyr ikke at det ikke er et. Dersom det ikke er oppgitt noe dokument, vil webserveren velge det som er oppgitt som standarddokument i programvarens konfigurasjon.

Spørsmåltegnet (?) i URL-en over indikerer at det er her spørringen starter. Først settes en id-verdi og deretter språkverdi (lang).

De to verdiene er skilt med en ampersand (og-tegn). Id-verdien kan være id-en til en artikkel, mens språkverdien kan bestemme hvilket språk innholdet i artikkelen skal være på. HTML er i utgangspunktet basert på SGML (Standard General Markup Language), en standard for markeringsspråk hvor & er tegnet for nøkkel/verdipar fra hverandre.

& kan skape problemer

Spørsmåltegnet er uproblematisk, men & brukes også som først tegn i tegnkoder i HTML. For eksempel er ­ en HTML-kode for myk bindestrek. Tegnkoden for & er & eller & – hvor 38 er desimalverdien for & i tegnsett som ASCII og UTF-8.

Det finnes tilfeller hvor det doble betydningen av og-tegnet kan skape problemer. Et eksempel som er nevnt i HTML5-spesifikasjonen, tilsvarer dette:

© er en HTML-kode for copyrighttegnet ©. Men selv om tegnkoden © ikke er avsluttet med semikolon i URL-en over, så skal URL-en tolkes av nettleserne som:

Da peker URL-en et annet sted enn det som var tenkt. Løsningen på dette er å bruke HTML-koden for og-tegnet også i URL-en, altså slik:

I praksis er dette en form for «escape» for at og-tegnet skal tolkes riktig. I henhold til HTML5-spesifikasjonen er det ikke nødvendig å bruke & i URL-en i lenker dersom det ikke er noen fare for forveksling.

Semikolon istedenfor?

I alle fall i HTML 2.0 fra 1995 ble nettleserleverandørene oppfordret til å støtte bruk av semikolon som erstatning for og-tegnet i URL-ene for å unngå disse problemene. Det er uklart om oppfordringen ble fulgt av noen. Uansett ser det ikke ut til å fungere i dagens nettlesere.

Mange nettsteder skjuler bruken av spørringsparametre ved å bruke omskrivningsregler på webserveren. URL-en fra et av eksemplene over kan da for eksempel se slik ut hos nettleserbrukeren:

Men internt på serveren skrives den om til dette:

Slike teknikker er svært utbredt i dag.

Fragmentene

Den aller siste URL-delen vi skal omtale i denne artikkelserien, kalles for fragmenter. Det som kommer etter tegnet # i en URL, er et slikt fragment.

Tim Berners-Lee forklarte i 2000 at hadde et behov for å skille mellom hele dokumentet og noe som finnes inni dokumentet, for eksempel et gitt avsnitt. Han skriver i at i alle fall i vanlige postadresser i USA, er det vanlig å bruke nummertegnet # til å indikere blant annet leilighetsnummer i en bygning. Dermed var det naturlig å bruke dette tegnet til en slik oppgave. Han var ikke alene om å tenke dette.

– Det viste seg senere at et annet hypertekstprosjekt hos IBM, i tillegg til Doug Englebarts NLS-system, begge og uavhengig av hverandre hadde brukt # til dette formålet, skriver Berners-Lee.

Opprinnelig ble fragmentene knyttet til spesielle referansepunkter i dokumentene, et a-element uten noen URL oppgitt i href-attributtet. Dersom et slikt a-element hadde et name-attributt, for eksempel «kapittel2», så ville nettleseren automatisk skrolle ned til dette referansepunktet dersom URL-en til var utformet slik:

Med HTML5 har bruken av name-attributtet blitt erstattet med bruken av id-attributtet, og ikke bare i forbindelse med a-elementet, men globalt i hele HTML-dokumentet. Hvert id-attributt som er i bruk i en HTML-dokument, må ha en unik verdi. Et eksempel på bruk av fram, er denne URL-en her i digi.no, som får nettleseren til å hoppe rett ned til kommentarene under artikkelen, hvor det finnes et HTML-element hvor verdien til id-attributtet er «discussion»:

Lenkeråte

URL-ene har altså vært i bruk i rundt 30 år, uten store endringer. Det må dermed kunne sies å være en temmelig vellykket og framsynt oppfinnelse, som brukes mange milliarder ganger hver dag.

Det er likevel en betydelig svakhet ved URL-er. De har det nemlig med å slutte å fungere. Selv om det heter at alt som publiseres på internett, blir på internett for alltid, er det ikke alltid slik. Innhold kan i alle fall ofte være vanskelig å finne igjen.

Dette skjer ikke helt av seg selv, selvfølgelig. Det er, som Digi.no nylig skrev, flere årsaker til at URL-er slutter å fungere. Nettsteder går iblant dukken. Andre ganger fjernes innhold fordi det ikke lenger er relevant eller ønskelig. Mange eldre artikler i nettaviser er ikke lenger tilgjengelige for andre enn abonnentene, fordi artiklene har blitt puttet bak betalingsmuren. Og noen ganger slutter URL-er å fungere fordi innholdet blir lagt ut på nytt på en annen publiseringsplattform som ikke støtter det opprinnelige URL-formatet.

Arkivert innhold

Innholdet som har forsvunnet helt fra weben, kan i mange tilfeller være mulig å finne igjen i Wayback Machine-tjenesten til Internet Archive. Der kan man ofte også finne igjen ulike versjoner av de samme websidene. Selv om det også til en viss grad er mulig å søke etter stikkord i Wayback Machine, er tjenesten i stor grad basert på at brukerne vet den opprinnelige URL-en og kan søke etter denne.

Flere ganger har det blitt presentert forslag om at weben i tillegg til lokaliseringsinformasjonen som en URL inneholder, også har behov for unike identifikatorer som gjør det mulig å finne igjen det samme innholdet, uavhengig av hvor det er lokalisert. Dette kan til en viss grad sammenlignes med ISBN-nummeret til bøker.

Uniforme ressursnavn

URL-en, slik vi kjenner den, er egentlig en spesifikk form for Uniform Resource Identifier (URI), en overordnet standard som også inkluderer Uniform Resource Name (URN).

I motsetning til URL-en, er en URN både globalt unik og varig. Den endres ikke selv om websiden over tid leveres fra skiftende URL-er. Alle typer innhold på webressurser kan tildeles en URN, en verdi som kunne ha vært søkbar i søkemotorer som Googles.

Nasjonalbiblioteket i Norge har tildelt URN-er til alt det digitaliserte innholdet.

Et eksempel på en slik URN, er:

I praksis består URN-en av tre deler:

Alle starter med bokstavene URN. Deretter følger en NID (Namespace Idenfier), som er en kode for den eller de som er ansvarlig for en serie med URN-er innen et navnerom. I eksempel over er NBN en NID. NBN står for National Bibliographic Number og brukes av nasjonalbibliotek i flere land.

Den siste delen av URN-en kalles for Namespace Specific String (NSS). Dette er en kode som er unik innenfor et gitt navnerom. Det skilles også mellom store og små bokstaver. Den samme NSS-en kan godt brukes til å identifisere helt andre ressurser i andre navnerom. Det er kombinasjon av NID og NIS som utgjør den universelt unike identifikatoren.

Nasjonalbiblioteket tilbyr en egen søketjeneste for URN-er på denne siden. Men det er også mulig å finne ressursen ved å sette inn http://urn.nb.no/foran URN-en, som på denne måten:

Lenken over peker til et 20 år gammelt hefte om internett. Selv om internett har utviklet seg veldig fort og mye siden den gang, er langt ifra alt i heftet helt utdatert.

Denne artikkelserien er inspirert av et blogginnlegg som Cloudflare publiserte i begynnelsen av mars.