Met curl testen test het verkeerde
Een telleraanvraag die zonder browseridentiteit binnenkomt, schrijft in twee van de twaalf plaatsen die een geteld bezoek normaal aanraakt. Hij antwoordt 200. Hij geeft een geldige tellerafbeelding terug. Nergens staat dat tien van de twaalf zijn overgeslagen.
Waar het filter voor is, en wat het kost
Tellers hier scheiden robots van mensen, en die scheiding gebeurt op de identiteit die de client zichzelf geeft. De lijst met kenmerken is kort en met opzet eenduidig, en curl/ staat erop. Een lege identiteit ook, op grond van de redenering dat een aanvraag zonder enige user agent geen browser is.
Allebei kloppen die. De dienst heeft geen ongelijk door een kale curl als robot te behandelen; dat is wat het is. Het probleem is dat wie de curl bestuurt meestal niet aan het testen is of robotherkenning werkt. Ze testen of het tellen werkt, en ze hebben stilletjes om het robotpad gevraagd.
Wat ze krijgen: het treffertotaal van de dag gaat met één omhoog, de botkolom gaat met één omhoog, en dat is alles. Geen regel voor unieke bezoekers, dus niets over bezoekers. Geen vermelding in de online lijst. Geen pagina, geen land, geen browser, geen besturingssysteem, geen apparaat, geen uur. De delen van het systeem die iemand werkelijk zou willen nakijken, zijn de delen die niet gedraaid hebben.
De mislukking heeft geen symptoom
Dit is het deel dat het stilstaan waard is. Een proef die niets meet, kondigt zichzelf meestal aan: een fout, een leeg resultaat, een nul waar een getal hoort. Hier is het antwoord 200. De inhoud is een echte tellerafbeelding, 3.361 bytes ervan. Het getal in het plaatje ging zelfs omhoog, want het treffertotaal is een van de twee dingen die wél gebeurden.
De proef ziet er dus uit als geslaagd. Alles wat erop volgt — "het telpad werkt", "de nieuwe kolom wordt geschreven", "de wijziging heeft niets gebroken" — is een conclusie uit een draai die het grootste deel van de code oversloeg die hij had moeten uitoefenen.
Het gebeurde tijdens het schrijven hiervan
De eerste versie van de meting achter dit bericht vroeg /c/<number> op. Dat is niet het adres van een tellerafbeelding; het echte draagt het ontwerp en een extensie, /c/<number>-<design>.png. De aanvraag gaf 404 terug.
Het script drukte drie keer af: schrijft in 0 van 12 plaatsen. Wat waar is, en wat ook precies is hoe een werkend botfilter er op het eerste gezicht uitziet. De 404 stond in de uitvoer, in dezelfde tabel, één regel boven de nullen. Die bleef een minuut ongelezen omdat de nullen het interessante waren en ze overeenkwamen met wat verwacht werd.
Dat is dezelfde fout als die waar dit bericht over gaat, één niveau hoger: een meting die een geloofwaardig antwoord opleverde om een reden die niemand nakeek. Ze is alleen gevangen omdat het script regels in twaalf tabellen telde in plaats van de aanvraag te vertrouwen — een aanvraag die mislukt en een aanvraag die gefilterd wordt, zien er van buiten precies zo uit.
Wat je in plaats daarvan doet
Stuur een browseridentiteit mee. Eén vlag, -A met een echte user-agenttekenreeks, en dezelfde aanvraag schrijft in tien van de twaalf plaatsen in plaats van in twee.
En tel iets aan de andere kant. De antwoordcode zegt dat de aanvraag aankwam; ze zegt niets over wat de aanvraag deed. Voor alles waarbij het om het neveneffect gaat — een teller, een wachtrij, een logregel, een regel ergens — moet de proef naar het neveneffect kijken. Tellingen voor en na over elke betrokken tabel kostten hier twintig regels en maakten twee keer van een dubbelzinnige uitkomst een ondubbelzinnige: één keer voor het filter, één keer voor de 404.
Twee van de twaalf plaatsen bleven ook met een browseridentiteit leeg: de botkolom, terecht, en de verwijzerslijst, die de meegestuurde verwijzer niet vastlegde. Dat tweede wordt hier niet verklaard, want het is nog niet uitgezocht. Het wordt gemeld omdat het alternatief is een tabel met elf regels te publiceren en hem twaalf te noemen.