A curl-lel végzett teszt rossz dolgot tesztel

Az a számlálókérés, amely böngészőazonosító nélkül érkezik, abból a tizenkét helyből, amelyet egy megszámolt látogatás általában érint, csak kettőbe ír. 200-as kóddal válaszol. Érvényes számlálóképet ad vissza. Sehol semmi nem jelzi, hogy a tizenkettőből tíz kimaradt.

Mire való a szűrő, és mibe kerül

Itt a számlálók elválasztják a robotokat az emberektől, és az elválasztás azon az azonosítón alapul, amelyet a kliens saját magáról megad. A jelzők listája rövid és szándékosan egyértelmű, és a curl/ is rajta van. Ahogy az üres azonosító is, azzal az indoklással, hogy egy user agent nélküli kérés nem böngésző.

Mindkettő helyes. A szolgáltatás nem téved, amikor egy puszta curl kérést robotként kezel; hiszen az. A gond az, hogy aki a curl-parancsot futtatja, általában nem azt teszteli, hogy működik-e a robotfelismerés. Azt teszteli, hogy működik-e a számlálás, és közben észrevétlenül a robotok útját kérte.

Amit kap: a napi megtekintésszám eggyel nő, a bot oszlop eggyel nő, és ennyi. Nincs egyedilátogató-sor, tehát semmi a látogatókról. Nincs bejegyzés az online listában. Nincs oldal, ország, böngésző, operációs rendszer, eszköz vagy óra. A rendszernek éppen azok a részei nem futottak le, amelyeket bárki ténylegesen ellenőrizni szeretne.

A hibának nincs tünete

Ennél a résznél érdemes elidőzni. Egy teszt, amely semmit sem mér, általában elárulja magát: hiba, üres eredmény, nulla ott, ahol számnak kellene lennie. Itt a válasz 200. A törzs valódi számlálókép, 3 361 bájt. A képen lévő szám még nőtt is, mert a megtekintésszám egyike annak a két dolognak, ami megtörtént.

A próba tehát sikeresnek tűnik. Minden, ami erre épül — „a számlálási útvonal működik”, „az új oszlop íródik”, „a változtatás nem rontott el semmit” —, olyan futásból levont következtetés, amely kihagyta a kód nagy részét, amelyet ki kellett volna próbálnia.

Épp e bejegyzés írása közben történt

A bejegyzés mögötti mérés első változata ezt kérte le: /c/<number>. Ez nem egy számlálókép címe; a valódi tartalmazza a dizájnt és egy kiterjesztést: /c/<number>-<design>.png. A kérés 404-et adott vissza.

A szkript háromszor kiírta: 12 helyből 0-ba ír. Ez igaz, és első ránézésre pontosan így festene egy működő botszűrő is. A 404 ott volt a kimenetben, ugyanabban a táblázatban, egy sorral a nullák fölött. Egy percig olvasatlan maradt, mert a nullák voltak az érdekes rész, és azt mutatták, amit vártunk.

Ez ugyanaz a hiba, mint amelyről ez a bejegyzés szól, csak egy szinttel feljebb: egy mérés, amely hihető választ adott, olyan okból, amelyet senki sem ellenőrzött. Csak azért derült ki, mert a szkript tizenkét táblában számolta a sorokat ahelyett, hogy a kérésben bízott volna — egy sikertelen és egy kiszűrt kérés kívülről pontosan ugyanúgy néz ki.

Mit tegyünk helyette

Küldjön böngészőazonosítót. Egyetlen kapcsoló, -A egy valódi user agent karakterlánccal, és ugyanaz a kérés a tizenkét hely közül kettő helyett tízbe ír.

És számoljon meg valamit a másik oldalon. A válaszkód azt mondja meg, hogy a kérés megérkezett; arról semmit, hogy mit csinált. Mindennél, ahol a lényeg a mellékhatás — egy számláló, egy várólista, egy naplósor, egy sor valahol —, a próbának a mellékhatást kell megnéznie. Az összes érintett tábla sorainak megszámolása előtte és utána itt húsz kódsort igényelt, és kétszer tett egyértelművé egy kétértelmű eredményt: egyszer a szűrőnél, egyszer a 404-nél.

A tizenkét helyből kettő böngészőazonosítóval is üres maradt: a bot oszlop, helyesen, és a hivatkozó oldalak listája, amely nem rögzítette az elküldött hivatkozó oldalt. A másodikra itt nincs magyarázat, mert még nem jártunk a végére. Azért szerepel, mert a másik lehetőség az lenne, hogy közzéteszünk egy tizenegy soros táblázatot, és tizenkét sorosnak nevezzük.