Annonce de NGINX Plus R25

Zach WestallResponsable senior du marketing produit

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus Release 25 (R25). Basé sur NGINX Open Source, NGINX Plus est la seule solution logicielle tout-en-un faisant office de serveur web, d’équilibreur de charge, de proxy inverse, de cache de contenu et de passerelle API.

Les nouvelles fonctionnalités de NGINX Plus R25 incluent :

• Cas d’utilisation supplémentaires et plus avancés des jetons Web JSON – NGINX Plus R25 étend la prise en charge des jetons Web JSON chiffrés (JWE) introduite dans NGINX Plus R24.
• Rapports plus détaillés sur les codes de réponse HTTP – L’API NGINX Plus comptabilise désormais les codes de réponse HTTP individuellement, ainsi que de manière agrégée par classe. Vous devrez peut-être augmenter la mémoire allouée ; consultez Allouer suffisamment de mémoire pour éviter les échecs au démarrage.
• Chargement dynamique des certificats clients SSL/TLS pour les connexions mandataires – Vous pouvez utiliser des variables pour sélectionner dynamiquement les certificats des connexions mTLS entre NGINX Plus et les serveurs backend.
• Sécurité renforcée pour le traitement des requêtes HTTP – NGINX Plus effectue plusieurs vérifications supplémentaires sur les requêtes HTTP afin de protéger vos applications contre d’éventuelles attaques.
• Persistance de l’état des contrôles d’intégrité lors des rechargements pour les applications TCP/UDP – Les résultats des contrôles d’intégrité obligatoires des serveurs TCP/UDP peuvent désormais être conservés lors des rechargements de la configuration.
• Améliorations apportées au module JavaScript NGINX – La compatibilité avec JavaScript ES6 est renforcée.

Modifications importantes du comportement

Augmentation de la mémoire requise pour les zones upstream

Comme décrit en détail dans Rapports plus détaillés sur les codes de réponse HTTP, NGINX Plus R25 fournit le nombre d’occurrences de chaque code d’état ainsi que des totaux agrégés par classe. Lorsque NGINX Plus est configuré comme proxy inverse ou équilibreur de charge, vous devrez peut-être augmenter la taille de la zone de mémoire partagée utilisée pour surveiller les « pairs » en amont (serveurs backend), s’ils sont plus de 20.

NGINX Plus R25 ne démarre pas si les zones de mémoire partagée ne disposent pas de suffisamment de mémoire, ce qui entraîne l’échec des mises à niveau. Avant toute mise à niveau, il est important de vérifier l’utilisation de la mémoire de chaque zone en amont. Pour savoir comment vérifier et ajuster l’allocation de mémoire, consultez Allouer suffisamment de mémoire pour éviter les échecs de démarrage.

Modifications apportées à l’organisation du dépôt NGINX Plus et à la procédure d’installation

Lors de la sortie de NGINX Plus R24, les dépôts de paquets de tous les logiciels NGINX ont été réorganisés, ce qui a entraîné des modifications de la procédure d’installation de NGINX Plus.

Lorsque vous installez ou mettez à niveau NGINX Plus, le gestionnaire de paquets du système d’exploitation (apt, yum ou équivalent) est configuré avec le dépôt de logiciels de NGINX Plus. Sur les systèmes existants configurés pour utiliser l’ancien dépôt (ceux exécutant NGINX Plus R23 ou une version antérieure), vous devez mettre à jour le gestionnaire de paquets afin qu’il utilise le nouveau dépôt. Consultez les instructions dans la base de connaissances F5.

Si vous effectuez une première installation de NGINX Plus R25, consultez la section « Installation de NGINX Plus » du Guide d’administration de NGINX Plus.

Remarque : Vous devez utiliser le nouveau dépôt de logiciels. L’ancien dépôt ne sera plus mis à jour et risque de provoquer des erreurs lors des prochaines installations et mises à niveau.

Module Cookie-Flag obsolète

Comme annoncé lors de la sortie de NGINX Plus R23, le module tiers Cookie‑Flag est obsolète et sera supprimé du dépôt de modules dynamiques dans NGINX Plus R26. La directive set_cookie_flag définie dans ce module est remplacée par la directive intégrée proxy_cookie_flags. Nous vous recommandons de remplacer dès que possible toutes les directives set_cookie_flag de votre configuration par des directives proxy_cookie_flags.

Modifications de la prise en charge des plateformes

• Nouveaux systèmes d’exploitation pris en charge :
  • Debian 11 (x86_64, aarch64)
  • Alpine Linux 3.14 (x86_64, aarch64)
• Anciens systèmes d’exploitation supprimés :
  • Alpine Linux 3.10 ; la version la plus ancienne prise en charge est la 3.11
  • Amazon Linux 1 (2018.03+) ; passez à Amazon Linux 2 LTS
  • FreeBSD 11.4+ ; la version la plus ancienne prise en charge est la 12.1+
  • Ubuntu 16.04 LTS ; la plus ancienne version prise en charge est la 18.04 LTS
• Anciens systèmes d’exploitation obsolètes dont la suppression est prévue dans NGINX Plus R26 :
  • Alpine Linux 3.11

Nouvelles fonctionnalités en détail

Cas d’usage et fonctionnalités supplémentaires des jetons Web JSON

NGINX Plus R24 a introduit une prise en charge initiale des jetons Web JSON chiffrés (JWE), ajoutant ainsi la confidentialité des données à l’une des méthodes d’authentification des clients les plus répandues. NGINX Plus R25 s’appuie sur cette fonctionnalité et prend en charge des cas d’usage d’authentification supplémentaires et plus avancés, qui contribuent à renforcer la sécurité de l’authentification basée sur les JWT, aussi bien pour les jetons signés (JWS) que chiffrés (JWE). Ces améliorations réduisent le risque de fuite d’informations personnelles identifiables (PII) tout en offrant davantage de flexibilité. Les nouvelles fonctionnalités JWT et les améliorations apportées à NGINX Plus comprennent :

• Une nouvelle variable pour le texte chiffré JWE déchiffré
• Prise en charge des JWT imbriqués
• Chiffrement asymétrique pour JWE
• Prise en charge des clés Web JSON provenant de plusieurs sources
• Règles de validation JWT personnalisées supplémentaires

Variable pour le texte chiffré JWE déchiffré

Les JWT constituent une méthode largement utilisée et reconnue pour l’authentification sans état des requêtes HTTP (c’est-à-dire l’authentification basée sur des jetons). En transmettant les attributs de l’utilisateur final dans la charge utile du jeton, les JWT contribuent à renforcer la sécurité des requêtes. Toutefois, les chercheurs en sécurité et les professionnels du DevSecOps s’accordent à dire que le stockage de données à caractère personnel non chiffrées sur les clients web présente un risque préoccupant, d’où l’élaboration de la norme JSON Web Encryption (RFC 7516), qui fournit des recommandations pour la mise en œuvre de jetons chiffrés.

NGINX Plus R24 a introduit la prise en charge de JWE, garantissant l’intégrité et la confidentialité des données pour l’ensemble des revendications. L’encodage des données personnelles identifiables (PII) dans le jeton chiffré réduit considérablement le risque de fuite de données lors de l’utilisation de JWT.

NGINX Plus R25 étend la prise en charge initiale de JWE grâce à une nouvelle variable, $jwt_payload, qui permet à NGINX Plus de déchiffrer le JWE et le texte chiffré, puis d’accéder au texte en clair lors du traitement de la requête HTTP. Cette nouvelle fonctionnalité peut servir à mettre en œuvre des stratégies avancées de contrôle d’accès et des décisions de routage des requêtes, tout en permettant aux utilisateurs de déployer NGINX Plus comme couche de déchiffrement JWE pour les applications backend.

Prise en charge des JWT imbriqués

Les jetons JWE protègent efficacement les données à caractère personnel, le texte chiffré permettant de préserver leur confidentialité, même lorsqu’elles transitent par des CDN et d’autres proxys assurant la terminaison TLS. Cependant, le chiffrement est une arme à double tranchant, car les JWE peuvent complexifier l’environnement applicatif. L’utilisation de JWT imbriqués permet de remédier à ce problème.

Anatomie d’un JWT imbriqué

Les JWT imbriqués intègrent un JWS en tant que texte chiffré d’un JWE. NGINX Plus R25 permet d’utiliser les JWT imbriqués comme méthode d’authentification des requêtes HTTP en prenant simultanément en charge les JWS et les JWE. En une seule opération, NGINX Plus peut désormais déchiffrer le texte chiffré du JWE, valider le texte en clair obtenu en tant que JWS et utiliser les revendications exp (date d’expiration) et nbf (date de début de validité) du jeton inclus pour vérifier sa validité. Cela permet d’ajouter le chiffrement de la charge utile à un environnement JWS existant en l’encapsulant dans un JWE.

L’extrait de configuration suivant illustre le processus. Le nouveau paramètre « nested » de la directive auth_jwt_type indique à NGINX Plus d’effectuer à la fois le déchiffrement JWE et la validation JWS. Il modifie également la manière dont sont évaluées les variables des en-têtes et des revendications JWT :

• La directive auth_jwt_header_set s’applique aux en-têtes JWE externes.
• La directive « auth_jwt_claim_set » agit sur les revendications du JWS imbriqué.
• $jwt_header_name contient les propriétés de l’en-tête JWE externe.
• $jwt_claim_name contient les revendications du JWS imbriqué.

Chargement de l’exemple de code…

Avec la configuration suivante, NGINX Plus crée et envoie des en-têtes de requête HTTP supplémentaires à l’application backend. L’algorithme de chiffrement issu de l’en-tête JWE (la variable $jwt_header_enc) et la revendication d’objet du JWT issue de la charge utile JWS (la variable $jwt_claim_sub) sont transmis avec la requête d’origine. Les applications peuvent ainsi tirer parti de l’authentification basée sur JWE en exploitant simplement les en-têtes HTTP, sans avoir à implémenter de code ni de bibliothèques cryptographiques.

Chargement de l’exemple de code…

Pour les utilisateurs travaillant dans des architectures Zero Trust, la configuration suivante permet à l’application backend de valider le jeton JWS tel qu’il est enregistré dans la variable « $jwt_payload ». Cette variable contient la version en texte clair déchiffrée du texte chiffré JWE. En présence d’un JWT imbriqué, le JWS peut être transmis à l’application backend en tant que jeton Bearer.

Chargement de l’exemple de code…

En substance, les JWT imbriqués rationalisent les opérations et renforcent la sécurité des applications en permettant à NGINX Plus de déchiffrer et de valider simultanément les jetons sécurisés, tout en analysant ou en transmettant par proxy le jeton signé « JWT standard » aux applications backend.

Chiffrement asymétrique pour JWE

NGINX Plus R24 a introduit la prise en charge du chiffrement symétrique des jetons à l’aide de la norme AES. NGINX Plus R25 ajoute la prise en charge du chiffrement asymétrique avec des paires de clés RSA. La cryptographie asymétrique utilise des clés différentes (publique et privée) pour le chiffrement et le déchiffrement, qui sont mathématiquement liées entre elles par l’algorithme RSA (Rivest–Shamir–Adleman), le même mécanisme que celui utilisé pour le chiffrement SSL/TLS du trafic HTTPS entre le client et le serveur.

NGINX Plus R25 prend en charge RSA avec le remplissage optimal pour le chiffrement asymétrique (OEAP) comme algorithme de gestion des clés, sans qu’aucune configuration explicite soit requise côté NGINX Plus. Les valeurs prises en charge pour l’en-tête JWS alg (algorithme) sont RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384 et RSA-OAEP-512.

La configuration suivante montre que, pour mettre en œuvre le chiffrement asymétrique pour JWE, il suffit de spécifier le fichier JSON Web Key (JWK) contenant les clés RSA privées (de désencapsulation) comme paramètre de la directive auth_jwt_key_file (la directive auth_jwt_key_request peut également être utilisée).

Chargement de l’exemple de code…

Prise en charge des JWK provenant de plusieurs sources

L’utilisation de JWT imbriqués implique que les JWK associées sont susceptibles de provenir de plusieurs sources. NGINX Plus R25 prend en charge plusieurs directives auth_jwt_key_file et auth_jwt_key_request dans un même contexte. NGINX Plus charge les clés depuis toutes les sources spécifiées et recherche la clé de vérification correspondante dans l’ensemble de clés ainsi constitué. Cette fonctionnalité est particulièrement utile lorsqu’un JWS émis par un fournisseur d’identité externe est imbriqué dans un JWE dont le chiffrement a été effectué par un processus distinct.

Cette fonctionnalité renforce encore la flexibilité, la sécurité et la puissance de NGINX Plus lorsqu’il est déployé en tant que passerelle API.

Règles personnalisées de validation des JWT

Lorsque NGINX Plus est déployé en tant que passerelle d’API, il est courant d’examiner les revendications JWT afin de mettre en œuvre un contrôle d’accès précis. Cela peut conduire à des configurations complexes. Dans les versions précédentes de NGINX Plus, vous pouviez utiliser des blocs de configuration if pour évaluer les revendications JWT, mais cette approche était quelque peu limitée et ne fonctionnait pas avec les jetons chiffrés.

NGINX Plus R25 remédie à cette limitation en offrant un moyen natif d’effectuer des vérifications supplémentaires sur le jeton pendant le processus de validation JWT. La directive « auth_jwt_require » ajoute une étape facultative et personnalisable au processus de validation JWT. Elle accepte une liste de chaînes séparées par des espaces, qui doivent toutes être non vides et différentes de 0 (zéro) pour que la validation JWT réussisse. Cela confère une très grande souplesse au processus de validation JWT.

La norme JWT ne définit pas les revendications obligatoires. Vous pouvez donc utiliser auth_jwt_require pour répertorier les revendications appropriées à chaque environnement.

La configuration suivante garantit que les revendications exp et sub sont présentes dans chaque jeton.

Chargement de l’exemple de code…

Vous pouvez configurer des cas d’utilisation plus complexes à l’aide de blocs map ou du magasin clé-valeur de NGINX Plus afin de transmettre des valeurs booléennes à la directive auth_jwt_require. Vous pouvez également utiliser le module JavaScript de NGINX pour mettre en œuvre des solutions d’authentification avancées, telles que les jetons d’accès liés au certificat client pour l’authentification TLS mutuelle (mTLS), définis dans la RFC 8705.

La configuration suivante effectue à la fois l’authentification par certificat client (mTLS) et la validation du JWT. La directive « auth_jwt_require » à la ligne 14 demande l’évaluation de la variable « $thumbprint_match », et la validation du JWT ne réussit que si sa valeur est différente de zéro. Cette variable est évaluée en exécutant la fonction JavaScript appelée à la ligne 2.

Chargement de l’exemple de code…

Voici le code de la fonction « validate » appelée à la ligne 2 de l’extrait précédent :

Chargement de l’exemple de code…

Rapports plus détaillés sur les codes de réponse HTTP

La surveillance et la visibilité sont essentielles aux performances, à la disponibilité et à la sécurité des applications. Les codes de réponse HTTP constituent l’une des principales sources d’informations sur l’état des applications. L’API NGINX Plus assure le suivi des codes de réponse HTTP aussi bien pour les interactions entre NGINX et les clients que pour celles entre NGINX et les serveurs en amont ; les décomptes sont affichés dans les onglets correspondants du tableau de bord de surveillance de l’activité en temps réel.

Les versions précédentes de l’API NGINX Plus regroupaient le nombre de codes de réponse HTTP par classe (2xx, 4xx, etc.). Désormais, les codes sont également comptabilisés individuellement (200, 404, 503, etc.). Vous bénéficiez ainsi d’une visibilité plus précise sur ce qui se passe exactement au niveau d’une application, en distinguant les erreurs dont les causes sont très différentes, telles que les pics d’échecs d’authentification (403) et les contenus introuvables (404). Pour savoir comment configurer la collecte des métriques, consultez le Guide d’administration de NGINX Plus.

La dernière version de l’API NGINX Plus (version 7), publiée avec NGINX Plus R25, comprend un objet codes au sein de l’objet responses afin de permettre le comptage individuel des codes de réponse HTTP. Les réponses agrégées restent disponibles, et les versions précédentes de l’API NGINX Plus, qui ne comprennent pas l’objet codes, peuvent toujours être utilisées avec NGINX Plus R25. Voici un exemple du nouvel ensemble de métriques :

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq{
  "processing": 31,
  "requests": 63192,
  "responses": {
    "1xx": 0,
    "2xx": 54368,
    "3xx": 8454,
    "4xx": 330,
    "5xx": 9,
    "codes": {
      "200": 54368,
      "302": 8454,
      "401": 30,
      "404": 200,
      "429": 100,
      "503": 9
    },
    "total": 63161
  },
  "discarded": 0,
  "received": 693436,
  "sent": 13843478
}

Allouer suffisamment de mémoire pour éviter les échecs au démarrage

Remarque importante : Lorsque NGINX Plus est configuré en tant que proxy inverse ou équilibreur de charge, le comptage des codes individuels augmente l’utilisation de la mémoire dans la zone de mémoire partagée de chaque groupe de serveurs en amont. Si le groupe de serveurs en amont compte plus de 20 pairs, vous devrez peut-être augmenter la taille de la mémoire, telle que configurée avec la directive zone.

NGINX Plus R25 ne démarre pas si les zones en amont sont sous-dimensionnées, ce qui entraîne l’échec des mises à niveau.

Voici une configuration type de la zone de mémoire partagée pour un groupe de serveurs en amont :

Chargement de l’exemple de code…

Avant de procéder à la mise à niveau vers NGINX Plus R25, il est important de vérifier l’utilisation de la mémoire des zones upstream existantes. Pour ce faire, assurez-vous que l’API NGINX Plus est activée avant d’utiliser l’une des méthodes suivantes :

• Consultez l’onglet « Serveurs en amont HTTP » du tableau de bord de surveillance de l’activité en temps réel, comme dans cet exemple tiré de demo.nginx.com, où le taux d’utilisation est de 54 % :
  
• Utilisez l’API NGINX Plus directement depuis l’hôte en exécutant la commande suivante. Tout d’abord :

$ API=http://localhost:8080/api; for i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; do echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; done

• Installez l’utilitaire « jq » si nécessaire
• Définissez la variable « API » sur l’emplacement où la directive « api » est activée

Si l’utilisation actuelle est supérieure à 40 % (comme dans la capture d’écran), augmentez le deuxième paramètre (taille) de la directive zone d’au moins 2,5 fois. Par exemple, nous recommandons de faire passer 64k à 160k dans l’extrait de configuration ci-dessus.

Chargement dynamique des certificats clients SSL/TLS pour le proxy

Le TLS mutuel (mTLS) est une pratique d’authentification courante qui consiste à vérifier l’identité du client et du serveur. Avec NGINX Plus, vous pouvez définir dynamiquement et à l’aide de variables les serveurs d’un groupe en amont. Cela signifie que vous devrez peut-être également pouvoir sélectionner dynamiquement le certificat TLS utilisé par NGINX Plus pour s’authentifier auprès de ces serveurs en amont.

NGINX Plus R25 étend les directives de configuration utilisées pour le mTLS vers un serveur backend afin qu’elles acceptent une variable représentant le certificat. Cette variable peut faire référence à l’un des éléments suivants :

• Un fichier sur le disque
• Données brutes au format PEM, précédées de data:

Cela permet à NGINX Plus de sélectionner dynamiquement un certificat et une clé privée, ce qui est utile pour les environnements applicatifs modernes soumis à des changements constants. Vous pouvez stocker le certificat et la clé privée dans le magasin clé-valeur de NGINX Plus, ce qui renforce la sécurité, car la clé privée est stockée en mémoire plutôt que sur disque. Un autre cas d’utilisation est la rotation automatisée des certificats, qui consiste à utiliser un appel d’API pour mettre à jour les certificats dans le magasin clé-valeur.

Dans la configuration suivante, NGINX Plus achemine les requêtes vers différents groupes de serveurs en amont en fonction du nom d’hôte. La connexion mandataire est établie à l’aide de mTLS, et le certificat client approprié pour chaque groupe de serveurs en amont est sélectionné dynamiquement.

Chargement de l’exemple de code…

Les directives suivantes prennent en charge le chargement dynamique des certificats pour le mTLS avec les serveurs en amont :

• grpc_ssl_certificate
• grpc_ssl_certificate_key
• proxy_ssl_certificate
• proxy_ssl_certificate_key
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_key

Sécurité renforcée pour le traitement des requêtes HTTP

L’un des principes fondamentaux de la philosophie de NGINX est l’amélioration continue, notamment en matière de sécurité. Nous mobilisons toutes les ressources disponibles, notamment la collaboration avec des chercheurs en sécurité, l’intégration à nos produits des technologies de sécurité de pointe de F5 et nos efforts de développement en interne.

À titre d’exemple de ce dernier point, NGINX Plus R25 effectue plusieurs vérifications supplémentaires sur les requêtes HTTP afin de protéger vos applications contre des attaques potentielles, telles que la désynchronisation des requêtes HTTP. Il renvoie une erreur dans les cas suivants :

• Une requête HTTP/1.0 contient l’en-tête « Transfer-Encoding »
• Les en-têtes « Transfer-Encoding » et « Content-Length » sont tous deux présents
• La ligne de requête ou le nom d’un en-tête contient des espaces ou des caractères de contrôle
• Il y a des espaces ou des caractères de contrôle dans l’en-tête « Host »
• La méthode « CONNECT » est utilisée

En outre, les caractères suivants sont désormais toujours échappés dans un URI transmis par proxy : ", <, >, \, ^, `, {, |, }.

Veuillez noter que ces modifications constituent des améliorations proactives de la sécurité et ne font suite à aucune vulnérabilité connue.

Persistance de l’état du contrôle d’intégrité obligatoire lors du rechargement des applications TCP/UDP

NGINX Plus utilise des contrôles d’intégrité obligatoires pour s’assurer que les nouveaux serveurs ajoutés aux groupes en amont sont testés et opérationnels avant que les requêtes des clients ne leur soient transmises par proxy. Dans NGINX Plus R23 et les versions antérieures, les serveurs en amont étaient considérés comme défaillants après le rechargement de la configuration, quel que soit leur état avant ce rechargement. Par conséquent, NGINX Plus n’envoyait aucune requête à un serveur tant que le premier contrôle obligatoire n’avait pas réussi.

NGINX Plus R24 a introduit, pour les applications HTTP, la possibilité de conserver l’état des contrôles d’intégrité obligatoires lors des rechargements. Si le dernier contrôle d’intégrité obligatoire effectué avant un rechargement a réussi, NGINX Plus peut envoyer immédiatement des requêtes à un serveur au lieu d’attendre la réussite d’un contrôle d’intégrité obligatoire après le rechargement.

NGINX Plus R25 étend cette fonctionnalité aux applications TCP/UDP (dans le contexte stream). Comme pour HTTP, ajoutez le paramètre persistent à la directive health_check avec le paramètre mandatory.

Chargement de l’exemple de code…

Améliorations apportées au module JavaScript NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.6.2, avec plusieurs corrections de bogues et quelques améliorations fonctionnelles qui renforcent la compatibilité avec JavaScript ES6.

Déclaration de variables avec les mots-clés « let » et « const »

NGINX JavaScript prend désormais en charge la déclaration de variables à portée limitée à l’aide des mots-clés let et const. Les versions précédentes de NGINX Plus et de njs ne prenaient en charge que le mot-clé var pour déclarer et affecter des variables. Cela ne permettait pas de définir des variables limitées à la portée d’une instruction block, alors que celles-ci sont nécessaires pour gérer la complexité qui survient souvent lorsque différents projets, langages de programmation et équipes d’ingénierie collaborent sur des bases de code ou des bibliothèques partagées.

JavaScript ES6 fournit les mots-clés « let » et « const » pour définir des variables à portée limitée :

• letLes variables sont limitées à la portée d’une instruction block ou d’une expression dans laquelle elles sont utilisées. En revanche, le mot-clé var déclare une variable globalement, ou localement dans l’ensemble d’une fonction, indépendamment de la portée des blocs.
• const ont une portée limitée au bloc, tout comme les variables déclarées à l’aide du mot-clé let. La valeur d’une constante ne peut pas être modifiée par réaffectation, et la constante ne peut pas être redéclarée.

Prise en charge de toutes les méthodes du constructeur « Promise »

Avec l’ajout des méthodes de constructeur Promise.all(), Promise.allSettled(), Promise.any(), et Promise.race()، njs prend désormais en charge l’ensemble des méthodes de constructeur définies dans la norme JavaScript ES6.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R25 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela permettra à NGINX de mieux vous aider lorsque vous aurez besoin d’ouvrir un ticket d’assistance.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le faire, que ce soit pour la sécurité, l’équilibrage de charge et la passerelle d’API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer dès aujourd’hui avec un essai gratuit de 30 jours.

À propos de l’auteur

Zach WestallResponsable senior du marketing produit

Autres articles de Zach Westall