URL-oppfinneren angret på at han kopierte løsningen til Apollo

Da Tim Berners-Lee rundt 1989 fant opp det som fikk navnet World Wide Web, så var det ikke bare selve språket for å beskrive websidene han fant opp, men også webservere, webklienten (nettleseren), en protokoll for kommunikasjonen mellom dem, tillegg til URL-en, som denne artikkelserien omhandler.

I denne tredje artikkelen i serien skal vi kikke litt nærmere på protokolldelen av URL-en, i tillegg til portdelen og en detalj som Berners-Lee angrer på at ble som den ble.

Protokollene

Den første delen av alle komplette URL-er, starter med å fortelle hvilken applikasjonsprotokoll som skal benyttes. Bortsett fra mailto, som brukes i lenker for å sende e-post, starter nesten alle URL-er i dag med http eller https, som altså forteller nettleseren at det er protokollen Hypertext Transfer Protocol (HTTP) som skal benyttes, eventuelt den mer sikre utgaven av denne, HTTPS.

Men HTTP var på ingen måte den første protokollen i sitt slag, og heller ikke den eneste som støttes av URL-er. Så sent som i 1994 nevner Berners-Lee et nokså begrenset antall slike protokoller (eller «schemes»), men åpner samtidig for at det vil kunne bli flere. De som nevnes, er:

• ftp (File Transfer Protocol), som flere nettlesere nå faser ut støtten for.
• gopher, en protokoll og tjeneste som har visse likheter med weben, inkludert støtte for hyperlenker.
• mailto, altså e-post.
• news, referanser til nyhetsgrupper og individuelle artikler i Usenet. URL-formatet er news:<newsgroup-name> eller news:<message-id>.
• nntp (Network News Transfer Protocol), alternativ metode for å referere til Usenet-innhold. URL-formatet er: nntp://<host>:<port>/<newsgroup-name>/<article-number>.
• telnet, ukryptert protokoll for kommandolinjebasert kommunikasjon mellom datamaskiner via nettverk.
• wais (Wide Area Information Server), protokoll for søk i databaser via nettverk. Også brukt som søkemotor for Gopher
• file, peker til en fil på en gitt vert. Fungerer for eksempel i lokalnett (SMB).
• prospero, for oppslag i katalogtjenesten Prospero Directory Service

I ettertid har denne listen blitt kraftig utvidet, slik at det nå finnes mer enn 300 «URI schemes».

Portnummer

Alle de vanlige protokollene du har hørt om, og mange du sannsynligvis aldri har hørt om, er i utgangspunktet tildelt et portnummer. Når det sendes datapakker via internett, inneholder disse ikke bare informasjon om hvilken IP-adresse mottakeren har, men også et portnummer som noe forenklet forklart forteller mottakerenheten hvilken programvareprosess pakken er ment for.

Ideen om å ha faste porter, eller sockets, for offentlig tilgjengelige nettverkstjenester eller -funksjoner, stammer fra tidlig 1970-tall. Definisjonen på en nettverksocket i Arpanet ble skrevet i 1971, mens den første listen med tildelinger kom året etter. Noen av disse, som echo og discard, har samme portnummer den dag i dag.

Den første listen var begrenset til 255 portnumre (8 bit). Dette har senere blitt utvidet til 65535 (16 bit) lovlige verdier. De første 1024 av disse er reserverte systemporter. For eksempel bruker HTTP normalt port 80, HTTPS port 443, SSH port 22, og så videre.

Nettopp fordi de fleste nettverksbaserte tjenester bruker portnummeret som er tildelt den protokollen tjenesten er basert på, er det vanligvis ikke nødvendig å oppgi noe portnummer i URL. Det er mulig å tilby å tildele tjenestene andre portnumre, fortrinnsvis 1024 og høyere.

For eksempel kunne Digi.no godt ha blitt tilbudt for eksempel på port 8080. Da ville URL-en til forsiden ha sett slik ut:

Men den ville ha vært mye vanskeligere å finne, siden de fleste ikke ville ha visst hvilken port den var tilgjengelig på. Samtidig kan det være gode grunner til å benytte et alternativt portnummer, for eksempel når man har private tjenester som må være lett tilgjengelige, men ikke for enkle å oppdage.

Det kunne ha vært > istedenfor /

Som vi allerede har sett, er mye av det Tim Berners-Lee tok i bruk i URL-formatet ting som var gjenkjennelig for mange fra før. Dette gjaldt også bruken av skråstreker i URL-en. Som nevnt i den første artikkelen i denne serien, så brukes skråstrek (/) i URL ofte til å indikere et virkelig mappe- og filhierarki på webserveren, selv om det i realiteten ikke alltid er slik. Altså:

Det å bruke skråstreker for å separere delene i et hierarkisk system, ble ifølge Berners-Lee hentet fra Unix-verdenen.

– Den relative URI-syntaksen er bare syntaksen til Unix-filbaner gjenbrukt uten unnskyldning. Enhver som hadde brukt Unix, ville finne den temmelig selvfølgelig, skriver Berners-Lee.

Det kunne like gjerne ha vært et annet tegn, nemlig «større enn»-symbolet >. Dette ble brukt i Multics-operativsystemet (Multiplexed Information and Computing Service), som var det første operativsystemet med et hierarkisk filsystem.

Unix var inspirert av Multics, men Unix-oppfinnerne Ken Thompson og Dennis Ritchie valgte å bruke > (og <) til omdirigering av inn- og utdata. Dermed var det skråstreken som fikk rollen som skilletegn i fil- og mappehierarkiet.

Angret på //

Også den doble skråstreken har sin bakgrunn. Berners-Lee forklarer at han ønsket at syntaksen til URL-en skulle skille mellom domene- og vertsnavndelen på den ene siden, og resten av adressen.

Ideen hentet han fra Apollo/Domain, som var en serie med arbeidsstasjoner selskapet Apollo Computer produserte på 1980-tallet. Disse hadde operativsystemet Domain/OS, som blant annet støttet et nettverksfilsystem med en filnavnsyntakt som tillot noe tilsvarende dette:

I ettertid skal Berners-Lee ha angret på dette valget og gitt uttrykk for at han mener dagens URL-syntaks er klosset.

– Jeg ville ha likt at http://www.example.com/foo/bar/baz ble skrevet som http:com/example/foo/bar/baz, hvor klienten ville ha funnet ut at www.example.com eksisterte og var serveren som skulle kontaktes. Men det er for sent nå, skrev han for snart 20 år siden.

Det er for øvrig i mange tilfeller mulig å skrive URL-er uten både protokoll, vertsnavn- og domenenavndelene, men avhengig av at de er oppgitt i en lenke på webside eller sette inn i adressefeltet til nettleseren. Dette kalles for relative referanser.

Med dette begynner vi å nærme oss slutten. De siste delene av URL-en tar vi for oss i siste artikkel.

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