Auto-prefix URL — en liten detalj som sparer minutter

Du skriver inn allegro.pl i skjemaet. Du klikker. Og hva så?

I de fleste forkortere får du på dette tidspunktet en feilmelding. Noe i stil med "dette er ikke en gyldig URL". Fordi det mangler https:// foran. Så du går tilbake, legger til protokollen, klikker igjen, og først nå har du din korte lenke.

cutty.dev gjør ikke dette. Den bare legger til https:// selv og fortsetter videre, som om ingenting har skjedd.

Jeg vet hvordan det høres ut. Som en funksjon som knapt fortjener et avsnitt, for ikke å snakke om et helt innlegg. Men likevel sitter jeg og skriver om det, fordi nettopp denne lille detaljen er mitt lille manifest på hvordan jeg i det hele tatt tenker rundt utviklingen av et auto-prefix URL-verktøy og resten av disse usynlige bekvemmelighetene.

To sekunder mot tjue

La oss regne. Seriøst, se på tallene, ellers er det bare prat.

Første vei: du limer inn, får en lenke, lukker vinduet. To sekunder. Kanskje tre.

Andre vei: du limer inn, feil, leser meldingen (et sekund eller to for å forstå hva det gjelder), legger til protokollen, klikker igjen, først nå lenken. Femten, tjue sekunder. Pluss det lille øyeblikket med irritasjon, det stille "å ja, riktig, protokoll", som ikke koster noe hver for seg, men som bygger seg opp.

Og nå multipliser med hvor mange ganger i måneden du limer inn en adresse. For meg er det dusinvis. For noen som administrerer lenker profesjonelt — hundrevis. Plutselig akkumuleres denne "knapt verdt en omtale"-detaljen til minutter per måned. Per person.

Dette er nettopp den aritmetikken som de fleste overser, fordi hvert enkelt tilfelle ser for lite ut til at man bryr seg om det.

Hva er det egentlig som ligger under overflaten

Mekanismen er banal og jeg skjuler ikke det i det hele tatt. Du limer inn tekst i feltet. Før noe sendes til serveren, sjekker en bit med JavaScript om det du skrev begynner med et hvilket som helst protokoll — http://, https://, ftp://, mailto:, hva som helst. Hvis det ikke begynner med det, antar systemet at du mener et vanlig domene og legger til https:// foran.

I praksis:

• allegro.pl endres til https://allegro.pl
• github.com/twoj-profil/projekt til https://github.com/twoj-profil/projekt
• www.gazeta.pl til https://www.gazeta.pl

Og hvis protokollen allerede er der, selv om den er merkelig, overskriver ikke systemet den. Den beholder den og sjekker videre hva man skal gjøre med det. http://example.com går gjennom (tillatt). ftp://example.com havner i søpla, fordi vi bare aksepterer http og https. Og javascript:alert(1) blir kastet umiddelbart, fordi dette ikke er en adresse, men et forsøk på å injisere noe ekkelt (klassisk XSS, takk, nei).

Hvorfor har jeg dette, mens halvparten av markedet ikke har det

Her blir det interessant, for svaret er litt morsomt.

Standard måte å validere en adresse i nettleseren på er konstruktøren new URL(string). Og denne konstruktøren er streng. Uforsonlig. Mangler protokollen — den kaster en feil. new URL("allegro.pl") gir deg bare en TypeError og det er alt.

Og vet du hva? Dette er korrekt oppførsel. For det store flertallet av applikasjoner er det nøyaktig dette du ønsker. Men i et skjema for forkorting av lenker, hvor man kopierer en adresse fra nettleserfeltet eller fra noen andres melding, forvandles denne strengheten fra en fordel til et hinder. Plutselig tvinger et verktøy som skal spare deg for tid, deg til å rette opp noe som det egentlig forstår helt perfekt.

En omvei rundt dette er bokstavelig talt noen få linjer:

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalej leci normalna walidacja przez new URL(normalized)
}

Fem linjer. Et dusin sekunder mindre friksjon, hver dag, for alle som limer inn adresser. Jeg vet ærlig talt ikke hvorfor dette ikke er standard overalt. Jeg mistenker at det handler om at "URL-konstruktøren bare fungerer slik" og at ingen hadde lyst til å røre den. Treghet, ikke ond vilje.

En liten digresjon om hva det betyr å være "standard"

For denne historien med new URL() er et flott eksempel på noe mer omfattende. Mange ting i programvare som anses som "slik man gjør det", er egentlig bare "slik ble det med standardinnstillingene til et bibliotek som ingen satte spørsmålstegn ved". Konstruktørens strict mode er ikke en beslutning tatt av designere hos cutty eller konkurrenter — det er en beslutning tatt av forfatterne av URL-spesifikasjonen, tatt i en helt annen kontekst, for helt andre bruksområder.

Og deretter arver hele markedet dette standardvalget og kaller det en "standard". Jeg har en følelse av at de beste produktene blir til nettopp på de stedene hvor noen stoppet opp og spurte: vent litt, tjener denne oppførselen egentlig brukeren min, eller bare biblioteket mitt? Som oftest er svaret: biblioteket. Og da er det verdt å bruke fem linjer på å skifte fokus tilbake til mennesket.

Det er flere av disse småtingene enn man ser

---

Auto-prefix er bare ett av mange slike elementer som du ikke vil finne på noen liste over funksjoner. For hvis de ble skrevet der, ville hver enkelt se latterlig liten ut:

• trimming av mellomrom før validering, slik at et tilfeldig mellomrom på slutten av en limt inn adresse ikke ødelegger alt
• bevaring av anker, det vil si at #section i https://example.com/page#section ikke forsvinner etter forkorting
• spørreparametre (?utm_source=test) overføres i sin helhet, ingenting blir kuttet underveis
• domener med polske tegn, źdźbło.pl, konverteres automatisk til punycode
• polske bokstaver i egen slug erstattes med ASCII (różowy-link blir rozowy-link)
• usikre protokoller — javascript:, data:, file: — avvises med en spesifikk, forståelig melding

(Det er fortsatt planlagt en automatisk oppgradering fra http:// til https:// når målserveren støtter kryptering. Dette fungerer ikke live ennå, så jeg skal ikke late som om det gjør det.)

Hver av disse detaljene sparer noen for fem, ti, tretti sekunder og et sukk. Alene ingenting. Sammen er det forskjellen mellom "fungerer OK" og "jeg liker å bruke den".

Hva jeg gjerne vil legge til i tillegg

Ønskeliste for fremtiden, fordi det å tenke på det rett og slett gir meg glede:

• intelligent liming — oppdage en adresse skjult midt i en setning og trekke ut selve URL-en fra ordene
• bulkliming — en liste med adresser, én per linje, og lage en separat kort lenke for hver av dem umiddelbart
• foreslåtte endelser — foreslå tre merkede slugs å velge mellom basert på tittelen til målsiden
• Open Graph-forhåndsvisning umiddelbart etter liming, før du i det hele tatt klikker på "forkort"

Hver av disse er igjen en "femlinjers funksjon som ikke ser ut til noe". Og alle sammen? Det er nettopp den grensen mellom et verktøy som er helt greit, og et du bruker hver dag uten å tenke deg om. Hvis du vil se hvordan det fungerer nå, lim inn hva som helst uten protokoll i cutty.dev — allegro.pl, github.com, news.ycombinator.com — og se at ingenting legger hindringer i veien for deg.

Til slutt, litt personlig

Lenge trodde jeg at produkter vant med store funksjoner. Med den ene imponerende tingen som kan vises på et lysbilde og som folk vil skrive om. Og ja, noen ganger er det slik.

Men jo lenger jeg bygger cutty, desto sterkere føler jeg at brukertroskap oppstår et annet sted — i de hundrevis av mikrosekundene som ingen bevisst legger merke til. Du husker ikke at verktøyet selv la til https://. Du husker bare det generelle inntrykket av at "det er greit å bruke", "det er ikke irriterende". Dette inntrykket kommer ikke fra intet sted. Det består av dusinvis av femlinjers beslutninger som ingen individuelt ville forsvart overfor seg selv som "verdt tiden".

Kanskje det er nettopp det som er håndverket. Ikke i den ene store bevegelsen, men i staheten til å igjen og igjen ta menneskets side ved skjemaet — selv om det bare gjelder to ynkelige sekunder. Og du? Hva har irritert deg sist med et verktøy, så lite at det nesten er flaut å innrømme det? For vanligvis er det nettopp der den beste jobben ligger og venter på å bli gjort.