Un testeur d’expressions régulières pour NGINX et NGINX Plus

Rick NelsonVice-président régional, ingénierie des solutions

Alors que je travaillais sur une expression régulière (regex) destinée à être utilisée avec NGINX, j’ai eu l’idée d’un moyen de tester facilement une regex directement dans une véritable configuration NGINX. (L’outil de test des regex fonctionne exactement de la même manière avec NGINX Open Source et NGINX Plus, et pour faciliter la lecture, j’utiliserai simplement le terme « NGINX » dans cet article.)

La prise en charge des expressions régulières est l’une des fonctionnalités puissantes de NGINX, mais celles-ci peuvent être complexes et difficiles à maîtriser, surtout si vous ne les utilisez pas régulièrement. NGINX permet d’utiliser des expressions régulières dans plusieurs parties d’une configuration, par exemple dans les emplacements, les tables de correspondance, les réécritures et les noms de serveur. L’outil de test décrit ici est destiné aux expressions régulières utilisées dans les emplacements et les tables de correspondance.

Il existe d’autres outils gratuits en ligne pour tester les expressions régulières, qui conviennent à la plupart d’entre elles, mais NGINX utilise certains raccourcis non standard optimisés pour les applications web. Par exemple, il n’est pas nécessaire d’échapper la barre oblique (/) dans un URI, contrairement à ce qui se fait dans une expression régulière standard. De plus, lorsque vous utilisez une expression régulière dans une directive map, vous indiquez la valeur à définir en cas de correspondance. Avec d’autres outils de test, vous devrez peut-être modifier l’expression régulière ou, dans le cas d’une directive map, déduire la valeur qui sera définie. Enfin, il est toujours préférable de pouvoir tester une expression régulière avec le véritable moteur d’expressions régulières, dans l’environnement réel.

Remarques :

• NGINX utilise les expressions régulières compatibles avec Perl (PCRE), et cet article suppose que vous possédez des connaissances de base sur NGINX et les expressions régulières. La création d’expressions régulières dépasse le cadre de cet article et nous regrettons de ne pas pouvoir répondre dans les commentaires à d’autres questions sur la manière de les construire. De nombreux sites web proposent des outils ou de la documentation pour créer des expressions régulières. En voici deux que nous avons trouvés utiles :
  • regex101.com
  • Regular-expressions.info
• L’outil de test prend en charge les expressions régulières dans deux contextes : les blocs map{} et les blocs HTTP location{}. Vous trouverez ci-dessous une brève présentation du fonctionnement des expressions régulières dans chacun de ces cas. La manière dont NGINX gère les expressions régulières dans tous les contextes dépasse le cadre de cet article ; consultez notre documentation :
  • Contrôles d’intégrité :
    • HTTP – nginx.org et Guide d’administration de NGINX Plus
    • TCP – nginx.org et Guide d’administration de NGINX Plus
    • UDP – nginx.org et Guide d’administration de NGINX Plus
  • location{} blocs – nginx.org et Guide d’administration de NGINX Plus
  • map{} blocs – nginx.org
  • Réécritures d’URI – nginx.org et Guide d’administration de NGINX Plus
  • Noms de serveurs virtuels – nginx.org et Guide d’administration de NGINX Plus
• L’outil de test est délibérément conçu pour être aussi simple que possible et remplir un seul objectif : tester les expressions régulières telles qu’elles sont saisies par l’utilisateur, à l’aide du véritable moteur d’expressions régulières de NGINX pour les mappages et les emplacements HTTP. Par conséquent, il vous suffit de fournir un minimum d’informations pour créer une configuration NGINX fonctionnelle. Nous ne prévoyons pas d’ajouter de fonctionnalités (comme la validation de l’expression régulière avant le test), car cela irait à l’encontre du principe directeur de simplicité. Nous sommes bien entendu disposés à corriger les bogues ; veuillez les signaler dans l’onglet Issues de notre dépôt GitHub.

Vue d’ensemble

Avant d’entrer dans les détails de l’outil de test des expressions régulières, voyons d’abord comment celles-ci peuvent être utilisées dans les blocs location et les directives map de NGINX.

Emplacements

Les expressions régulières dans les blocs location{} de NGINX se présentent sous la forme suivante :

location regex {
    #...
}

Par exemple, un bloc location{} utilisant l’expression régulière suivante traite toutes les requêtes PHP dont l’URI se termine par myapp/nomdefichier.php, telles que /test/myapp/hello.php et /myapp/hello.php. L’astérisque placé après le tilde (~*) rend la correspondance insensible à la casse.

location ~* /myapp/.+\.php$ {
    #...
}

NGINX et le testeur d’expressions régulières prennent en charge les groupes de capture positionnels dans les blocs location{}. Dans l’exemple suivant, le premier groupe capture tout ce qui précède le nom du fichier PHP, tandis que le second capture le nom du fichier PHP :

location ~* (.*/myapp)/(.+\.php)$ {
    #...
}

Pour l’URI « /myapp/hello.php », la variable « $1 » est définie sur « /myapp » et « $2 » est définie sur « hello.php ».

NGINX prend également en charge les groupes de capture nommés :

location ~* (?<begin>.*myapp)/(?<end>.+\.php)$ {
    #...
}

Dans ce cas, la variable « $begin » est définie sur « /myapp » et « $end » est définie sur « hello.php ».

Le testeur d’expressions régulières prend en charge les groupes de capture nommés, mais les traite comme des groupes de capture positionnels dans sa sortie, en affichant leur numéro d’ordre plutôt que leur nom.

Maps

Les blocs map{} de NGINX qui utilisent des expressions régulières se présentent sous la forme suivante :

map variable-to-test variable-to-set {
    regex1 value-to-set-if-match;
    regex2 value-to-set-if-match;
    #...
    regexN value-to-set-if-match;
    default value-to-set-if-no-match;
}

Par exemple, ce bloc map{} définit la variable $isphp sur 1 si l’URI (telle qu’enregistrée dans la variable $uri) se termine par .php, et sur 0 dans le cas contraire (la correspondance est sensible à la casse) :

map $uri $isphp {
    ~\.php$ 1;
    default 0;
}

Pour les directives map, NGINX et l’outil de test des expressions régulières prennent en charge les groupes de capture positionnels et nommés.

Par exemple, les deux mappages suivants définissent la variable « $fileext » sur la valeur de l’extension de fichier, qui est également capturée dans « $1 » dans cet exemple :

map $uri $fileext {
    ~*.+\.(.+)$  $1;
    default      '';
}

Et comme $ext dans cet exemple :

map $uri $fileext {
    ~*.+\.(?<ext>.+)$  $ext;
    default            '';
}

Vous pouvez utiliser l’outil de test des expressions régulières pour les blocs map{} dans les contextes http{} et stream{} car la syntaxe et le comportement des mappages sont identiques dans les deux contextes. Notez toutefois que si votre mappage se trouve dans le contexte stream{} vous ne pouvez utiliser que le bloc map{} provenant de la sortie de l’outil de test. Consultez la note ci-dessous pour plus de détails.

Le testeur d’expressions régulières

Le testeur d’expressions régulières est implémenté dans un conteneur Docker avec NGINX et NGINX Unit installés. NGINX Unit propose deux variantes d’une page PHP, l’une pour les expressions régulières dans les blocs location{} et l’autre pour celles dans les blocs map{}. Les deux pages invitent l’utilisateur à saisir des données différentes :

• Page « Location » :
  • L’expression régulière
  • Sensibilité à la casse
  • L’URI
• Page de la carte :
  • L’expression régulière
  • Sensibilité à la casse
  • La valeur à tester (la valeur de la variable qui constitue le premier paramètre de la directive « map »)
  • La valeur à affecter à la variable spécifiée comme deuxième paramètre de la directive « map »

Après avoir fourni les informations, cliquez sur le bouton « Tester ». L’outil de test génère le fichier de configuration NGINX nécessaire, recharge la configuration, puis envoie une requête afin de tester l’expression régulière. Les résultats s’affichent ensuite et indiquent si une correspondance a été trouvée. Si c’est le cas, les valeurs des groupes de capture sont affichées sur la page « Testeur d’emplacement », tandis que la valeur définie par la directive map est indiquée sur la page « Testeur de map ».

Exemple de page Location

Cet exemple présente les résultats d’un test insensible à la casse de l’expression régulière « (.*myapp)/(.+\.php)$ » sur l’URI « /myapp/hello.php » :

Exemple de page de carte

Cet exemple présente les résultats d’un test insensible à la casse de l’expression régulière .+\.(?<ext>.*)$ sur la valeur /myapp/hello.php, avec le groupe de capture nommé $ext comme valeur à définir :

Remarque : Si votre map se trouve dans le contexte stream{} vous pouvez utiliser uniquement le bloc map{} de la sortie dans votre configuration. Le bloc server{} n’est pas valide, car il inclut un bloc location{} qui n’est pas pris en charge dans le contexte stream{}.

Conclusion

Comme vous pouvez le constater, la configuration de NGINX est assez courte et simple. Le gros du travail est effectué par la page PHP, qui génère le fichier de configuration NGINX nécessaire à partir des valeurs saisies par l’utilisateur, recharge NGINX, lui envoie une requête et affiche les résultats.

Vous pouvez essayer vous-même l’outil de test d’expressions régulières : tout le code est disponible dans notre dépôt GitHub (https://github.com/nginxinc/NGINX-Demos/tree/master/nginx-regex-tester).

Pour faciliter la mise en service de l’outil de test d’expressions régulières, tous les fichiers nécessaires sont inclus. Pour créer l’image Docker et le conteneur, exécutez simplement la commande suivante :

$ docker-compose up -d

Ensuite, accédez à l’adresse http://Docker-host/regextester.php dans votre navigateur.

J’espère que cet outil de test vous sera utile pour utiliser des expressions régulières et qu’il vous donnera un aperçu de la puissance, de la flexibilité et de la simplicité de NGINX.

Pour essayer l’outil de test d’expressions régulières avec NGINX Plus, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Rick NelsonVice-président régional, ingénierie des solutions

Autres articles de Rick Nelson