Mit curl geprüft heißt das Falsche geprüft
Ein Zähleraufruf, der ohne Browserkennung ankommt, schreibt an zwei der zwölf Stellen, die ein gezählter Besuch sonst berührt. Er antwortet 200. Er liefert ein gültiges Zählerbild. Nirgends steht, dass zehn der zwölf übersprungen wurden.
Wofür der Filter da ist, und was er einen kostet
Zähler hier trennen Roboter von Menschen, und getrennt wird nach der Kennung, die der Aufrufer über sich selbst angibt. Die Liste der Merkmale ist kurz und mit Absicht eindeutig, und curl/ steht darauf. Eine leere Kennung ebenfalls, mit der Überlegung, dass ein Aufruf ganz ohne Kennung kein Browser ist.
Beides ist richtig. Der Dienst hat nicht unrecht, ein blankes curl als Roboter zu behandeln; das ist es. Das Problem ist, dass die Person hinter dem curl meistens nicht prüft, ob die Roboter-Erkennung funktioniert. Sie prüft, ob das Zählen funktioniert — und hat unbemerkt den Roboterpfad bestellt.
Was sie bekommt: die Tagessumme steigt um eins, die Bot-Spalte steigt um eins, und das war es. Keine Zeile für einen eindeutigen Besucher, also nichts über Besucher. Kein Eintrag in der Online-Liste. Keine Seite, kein Land, kein Browser, kein Betriebssystem, kein Gerät, keine Stunde. Genau die Teile, die man prüfen wollte, sind die Teile, die nicht gelaufen sind.
Der Fehlschlag hat kein Anzeichen
Das ist der Teil, bei dem man verweilen sollte. Eine Prüfung, die nichts misst, meldet sich sonst: ein Fehler, ein leeres Ergebnis, eine Null, wo eine Zahl stehen sollte. Hier ist die Antwort 200. Der Rumpf ist ein echtes Zählerbild, 3.361 Byte davon. Die Zahl im Bild ist sogar gestiegen, denn die Tagessumme ist eines der beiden Dinge, die passiert sind.
Die Probe sieht also nach Bestanden aus. Alles, was daraus folgt — „der Zählpfad läuft", „die neue Spalte wird geschrieben", „die Änderung hat nichts kaputtgemacht" — ist ein Schluss aus einem Lauf, der den größten Teil des Codes ausgelassen hat, den er prüfen sollte.
Es ist beim Schreiben passiert
Die erste Fassung der Messung hinter diesem Beitrag rief /c/<Nummer> ab. Das ist nicht die Adresse eines Zählerbildes; die echte trägt den Entwurf und eine Endung, /c/<Nummer>-<Entwurf>.png. Der Aufruf antwortete 404.
Das Skript meldete dreimal: schreibt an 0 von 12 Stellen. Was stimmt — und was zugleich genau so aussieht wie ein funktionierender Bot-Filter, wenn man die Augen zusammenkneift. Die 404 stand in derselben Ausgabe, eine Zeile über den Nullen. Sie blieb eine Minute lang ungelesen, weil die Nullen das Interessante waren und zu dem passten, was erwartet wurde.
Das ist derselbe Fehler wie der, um den es hier geht, eine Ebene höher: eine Messung, die aus einem ungeprüften Grund ein plausibles Ergebnis lieferte. Gefangen wurde er nur, weil das Skript Zeilen in zwölf Tabellen zählt statt dem Aufruf zu glauben — ein Aufruf, der scheitert, und einer, der gefiltert wird, sehen von außen gleich aus.
Was stattdessen zu tun ist
Eine Browserkennung mitschicken. Ein Schalter, -A mit einer echten Kennung, und derselbe Aufruf schreibt an zehn statt an zwei der zwölf Stellen.
Und auf der anderen Seite nachzählen. Der Statuscode sagt, dass der Aufruf angekommen ist; er sagt nicht, was der Aufruf getan hat. Überall, wo es auf die Nebenwirkung ankommt — ein Zähler, eine Warteschlange, eine Protokollzeile, eine Zeile irgendwo — muss die Probe die Nebenwirkung ansehen. Zählen vorher und nachher über jede beteiligte Tabelle hat hier zwanzig Zeilen gekostet und ein zweideutiges Ergebnis zweimal eindeutig gemacht: einmal für den Filter, einmal für die 404.
Zwei der zwölf Stellen blieben auch mit Browserkennung leer: die Bot-Spalte, richtigerweise, und die Verweisliste, die den mitgeschickten Verweis nicht aufgenommen hat. Das Zweite wird hier nicht erklärt, weil es noch nicht verfolgt wurde. Es steht da, weil die Alternative wäre, eine Tabelle mit elf Zeilen zu zeigen und zwölf dazuzusagen.