Le piège == false en Fastly VCL

La référence VCL officielle de Fastly documente la priorité des opérateurs dans une table à quatre niveaux : () → ! → && → ||. Les opérateurs de comparaison ( ==, !=, ~, >, <, etc.) sont totalement absents de cette table.

Dans le parser open-source de Varnish (vcc_expr.c), les fonctions de descente récursive suivent une hiérarchie stricte : vcc_expr_cmp (comparaisons) est appelé depuis vcc_expr_not, ce qui signifie que == a naturellement une priorité plus élevée que &&. Si le fork de Fastly dévie de cette hiérarchie, a == false && b pourrait être analysé comme a == (false && b).

Si == et && partagent la même priorité et se lient de gauche à droite, l’expression A == false && B == false && (C == D) est analysée comme ((((A == false) && B) == false) && (C == D)). En déroulant l’évaluation : A == false → true, true && B → false, false == false → true — mais ensuite true && (C == D) → false. Le dernier && devrait ramener le résultat à false. Pourtant, le PoC montre que l’expression s’évalue à true.

Cela indique un problème de génération de code pour le court-circuit qui s’ajoute au problème de précédence. Les compilateurs optimisent couramment X == false dans une chaîne && en inversant la condition de branchement — au lieu de calculer la comparaison et de brancher sur le résultat, ils évaluent X directement et inversent la polarité du saut. Avec deux == false dans la même chaîne, la seconde inversion peut corrompre la cible du saut, provoquant le saut des conditions restantes et l’exécution directe du corps du bloc. C’est cohérent avec les quatre résultats du PoC : le bug nécessite exactement deux == false dans la chaîne (Test 1), un seul fonctionne correctement (Test 3), ! utilise un chemin de code entièrement différent (Test 2), et les parenthèses explicites forcent les comparaisons à être pré-évaluées avant d’entrer dans la chaîne de court-circuit (Test 4).

Les en-têtes HTTP en VCL sont des chaînes. Écrire req.http.X-Bot == false compare une STRING à un BOOL. La documentation de Fastly indique « l’égalité est définie pour tous les types » mais ne spécifie pas ce qui se passe lorsque les types diffèrent.

Est-ce que “0” == false s’évalue à true ? Et "" == false ? Qu’en est-il d’un en-tête manquant ? Le système de types de Varnish est strict, mais le fork de Fastly pourrait gérer les comparaisons inter-types avec une conversion implicite. Ce comportement non documenté, combiné au problème de priorité, crée un champ de mines pour les conditions composées.

Utilisez ! au lieu de == false.

L’opérateur de négation a une priorité bien définie dans la documentation de Fastly. L’opérateur d’égalité, non.

Ne comparez pas les en-têtes HTTP à des booléens. Les en-têtes sont des chaînes. Utilisez !req.http.X-Bot (teste l’existence/véracité) plutôt que req.http.X-Bot == false.

Soyez particulièrement prudent avec les conditions composées.

Le bug ne se manifestait qu’avec deux == false dans une chaîne. Les utilisations isolées semblaient fonctionner, rendant ce problème extrêmement difficile à détecter lors des tests.