Een pagina-adres langer dan zijn kolom
Op 9 augustus 2026 lukte het twintig tellerafbeeldingen niet om te tekenen. Niet verkeerd getekend, niet traag getekend — de bezoeker kreeg helemaal niets waar een teller had moeten staan.
De oorzaak was een pagina-adres van meer dan 255 tekens. Het wordt nu bij het wegschrijven afgekapt, en de tellerafbeelding hangt niet meer af van de lengte van het adres dat haar wordt doorgegeven.
De keten
De kolom waarin staat op welke pagina een bezoek is geland, is varchar(255). Het adres kwam langer binnen. Het invoegen mislukte met SQLSTATE 22001, gegevens te lang voor de kolom, wat in deze code een uitzondering opwierp.
En het wegschrijven van de statistieken gebeurt voordat de afbeelding getekend wordt. De uitzondering verloor dus niet alleen één regel statistiek. Ze brak de aanvraag af, en de aanvraag was juist degene die de tellerafbeelding maakt. Een pagina met een lang adres maakte haar eigen teller kapot, geruisloos, voor elke bezoeker.
Lange adressen zijn niet exotisch. Een galerie met geneste paden, een winkel met een dozijn volgparameters die een advertentieplatform eraan plakt, een pagina met zoekresultaten — elk daarvan haalt zonder moeite de 255 tekens.
De oplossing, en de oplossing die niet gekozen is
Het adres wordt nu vóór het invoegen op de kolombreedte afgeknipt. Twintig tekens van een heel lange URL gaan verloren uit de paginalijst; verder verandert er niets.
Het alternatief was de kolom breder maken. Dat is afgewezen: er is geen breedte die niet overschreden kan worden, en een groter getal kiezen schuift dezelfde mislukking alleen verder weg, waar ze moeilijker te herkennen zal zijn wanneer ze aankomt. De manier van mislukken moet ophouden fataal te zijn, niet zeldzamer worden.
Het invoegen in een try/catch wikkelen zou het zichtbare verschijnsel ook verholpen hebben, en het zou erger geweest zijn: de teller zou tekenen, de regel zou geruisloos verdwijnen, en in de paginalijst zouden voor altijd precies de pagina's met de ingewikkeldste adressen ontbreken, zonder dat er iets in enig logboek stond.
Twee dingen om mee te nemen
Invoer van buiten hoort op de kolombreedte afgeknipt te worden, niet gehoopt dat ze past. Alles wat van buiten komt — een adres, een verwijzer, een user agent, een titel — is zo lang als iemand anders besloten heeft, en de database heeft daar een mening over die ze uit door te weigeren.
Weet wat er verder benedenstrooms van een mislukking staat. Dit was een statistiekfout in een statistiekdienst, en de zichtbare schade was een ontbrekende afbeelding. Het wegschrijven en het tekenen deelden één aanvraag; nergens in de code stond dat ze gekoppeld waren, en niets waarschuwde dat een mislukt invoegen de afbeelding zou meenemen.
Twintig kapotte afbeeldingen op een dag is weinig. Het is gevonden door logboeken te lezen voor iets heel anders, wat de gebruikelijke manier is waarop zulke dingen gevonden worden, en de reden om ze te blijven lezen.