URL decoderen

Procentreeksen zijn eenduidig: `%20` is een spatie, waar de tekst ook vandaan komt. Het plusteken is dat niet. In een query string die uit een HTML-formulier komt, staat het voor een spatie; in een pad, in een fragment of in een willekeurige tekst is het een gewone plus.

Daarom staat die keuze hier als schakelaar en wordt er niet gegokt. Verkeerd gokken doet het meeste kwaad bij waarden waar een plus juist betekenis heeft: een internationaal telefoonnummer als `+31612345678` en een adres met subadressering als `[email protected]` worden dan onherkenbaar, en het verlies is onomkeerbaar.

Elke procentreeks is één byte, en een teken buiten ASCII bestaat uit meerdere. `%C3%AB` samen is een `ë`; los gelezen zijn het twee bytes die als tekens niets betekenen. Daarom worden hier eerst alle bytes verzameld en pas daarna als UTF-8 gelezen.

Decoders die dat per reeks doen, leveren precies de bekende reeks vreemde tekens op waar één letter hoorde te staan. Zie je die, dan is het meestal niet de invoer die stuk is maar de decoder die te vroeg heeft omgezet — en het herstel is de bytes opnieuw samen lezen, niet de tekens repareren.

Blijft er na het decoderen nog een `%20` of een `%3A` staan, dan was de tekst twee keer gecodeerd: `%2520` decodeert naar `%20` en dat is een geldige uitkomst, geen fout. De eerste ronde levert de gecodeerde vorm op, en pas een tweede levert de tekst.

Dat is meteen de manier om de oorzaak te vinden. Twee keer decoderen tot er iets leesbaars staat, is het symptoom bestrijden; de fout zit in de keten die twee keer codeert, meestal een framework dat het al doet en een sjabloon dat het nog eens overdoet. Repareer daar één van de twee.

Een complete URL decoderen is zelden wat je wilt. Zit er in een parameter een `%2F` die daar met opzet staat, dan wordt die na het decoderen een echte schuine streep — en daarmee verandert de structuur van het adres in plaats van de leesbaarheid.

De gedecodeerde vorm is dus goed om te lezen en niet om opnieuw te gebruiken. Wil je een adres aanpassen, doe dat dan per parameter: decodeer de waarde, verander die, en codeer haar terug voordat ze weer in de URL gaat. De volledige tekst decoderen en opnieuw versturen is de kortste weg naar een link die net iets anders betekent.

Alles achter `#` blijft in de browser en bereikt geen server. Een URL die je uit een toegangslogboek plakt, heeft dus per definitie geen fragment, ook al stond er in de adresbalk van de bezoeker wel een.

Dat is nuttig om te weten bij het reconstrueren van wat iemand deed. Ontbreekt het deel dat je zoekt, dan is het niet verloren gegaan bij het loggen: het is er nooit geweest. Wie dat deel toch nodig heeft, moet het in de applicatie meten, want het netwerkverkeer bevat het niet.

Op volgorde van hoe vaak: een zoekterm, een doorstuurdoel, een trackingparameter, een filter uit een productoverzicht. Dat is onschuldig materiaal, en het is de reden dat deze pagina vaak gewoon een leeshulp is.

De uitzonderingen zijn de moeite van het opmerken waard. Een e-mailadres, een sessiesleutel of een token in een parameter is een bevinding, want zulke waarden horen daar niet: ze belanden in logboeken, in de geschiedenis en in de referrer-header van de volgende klik. Zie je er een, dan is dat het echte resultaat van deze pagina.

`utm_source`, `utm_medium`, `utm_campaign`, `utm_term` en `utm_content` komen van Urchin, het pakket waar Google Analytics uit is voortgekomen — vandaar de naam. Op de server doen ze niets: het is tekst die een meetscript in de browser leest.

Omdat ze niets doen, kun je ze zonder gevolgen weghalen als je een link doorstuurt en de statistiek van de afzender niet met de jouwe wilt mengen. En omdat ze in het adres staan, belanden ze in geschiedenissen, in gedeelde links en in bladwijzers — de reden dat sommige nieuwsbrieflinks absurd lang zijn.

Een `%` die niet door twee hexadecimale cijfers wordt gevolgd, is geen geldige codering. Dat gebeurt vaker dan je denkt: een tekst die is afgekapt op een veldlengte, een logregel die op de laatste tekens is geknipt, of een letterlijke procentteken dat nooit als `%25` is geschreven.

Hier wordt dat gemeld in plaats van de reeks stil te laten staan of het procentteken weg te gooien. Dat onderscheid telt: als een waarde is afgekapt, is de gedecodeerde tekst hoe dan ook onvolledig, en dan is de mededeling nuttiger dan een resultaat dat compleet lijkt.

Een gedecodeerde waarde is ruwe invoer van buiten. Hij komt uit een adres dat iedereen kan samenstellen, dus hij kan alles bevatten: HTML, aanhalingstekens, een pad met `..`, een doorstuurdoel naar een vreemd domein.

Decoderen is dus de eerste stap en niet de laatste. Gaat de waarde daarna een pagina in, dan hoort er HTML-ontsnapping overheen; wordt het een pad, dan hoort het genormaliseerd en gecontroleerd te worden; is het een doorstuurdoel, dan hoort het tegen een lijst toegestane hosts te worden gelegd. De leesbare vorm is nergens veiliger dan de gecodeerde.

De tekst wordt gedecodeerd, niet bezocht. Er is geen voorbeeldweergave, geen verzoek naar de host en geen doorstuurketen die wordt gevolgd, en dat is een besluit en geen ontbrekende functie: wie een verdachte link onderzoekt, is de laatste die wil dat het hulpmiddel hem opent.

Openen zou bovendien iets verraden. Het verzoek zou van een server komen, het IP-adres en het tijdstip zouden in het logboek van de andere kant belanden, en bij een link voor eenmalig gebruik — een bevestiging, een wachtwoordherstel — zou het hem onderweg opmaken. Decoderen is de ongevaarlijke bewerking, en het is de enige die hier gebeurt.

URL’s uit toegangslogboeken en uit exports van statistiekpakketten dragen regelmatig persoonsgegevens: zoektermen, e-mailadressen als parameter, identifiers die aan een account hangen. Omdat het decoderen op de pagina gebeurt, wordt niets daarvan aan ons verstrekt.

Dat is de voorwaarde om zo’n export met een onlinehulpmiddel te mogen bekijken. Een dienst die op afstand zou decoderen, had de regel ontvangen en zou hem in haar logboeken hebben staan — met precies het soort gegevens waarvan de verstrekking de aanleiding is voor de meeste interne richtlijnen.