Managed Server Srl corrige le bug ennuyeux de l'absence de $http_host dans HTTP/3 sur ANGIE et peut-être ensuite NGINX

Introduction

Quiconque travaille quotidiennement avec des serveurs Web sait que les détails font la différenceUne petite variable manquante, un comportement non documenté ou un oubli dans l'implémentation d'un protocole peuvent rendre inutilisables des fonctionnalités qui, sur le papier, devraient améliorer les performances et la sécurité.

Nous Serveur géré Srl nous sommes tombés sur un de ces cas concrets, en travaillant sur un projet réel, un e-commerce basé sur Magento 2. Un problème apparemment marginal – l’absence de $http_host dans les connexions HTTP/3 – il s’est avéré qu’il s’agissait d’un véritable obstacle à l'adoption du protocole, à tel point qu'il bloque l'activation native de HTTP/3 sur le site.

Le chemin qui nous a conduit à identifier, documenter et finalement corriger ce bug Ce fut un processus tortueux : nous avons d'abord essayé avec l'équipe officielle NGINX (sans succès), puis nous avons décidé de les contacter directement ANGIE, le fork russe développé par d'anciens ingénieurs de NGINX après la crise avec F5 Networks.

Le résultat? Un patch accepté et déjà intégré dans le code d'ANGIE (commit 140c3a6), qui corrige une fois pour toutes un bug ennuyeux mais très impactant.

Voici le récit détaillé de cette histoire.

Contexte : HTTP/3 et NGINX

HTTP/3 n'est pas simplement « la dernière version du protocole HTTP » qui suit la numérotation progressive des spécifications précédentes. Il s'agit en réalité de : un changement de paradigme dans la manière dont les navigateurs et les serveurs communiquent sur Internet.

Pour comprendre sa portée, il faut se rappeler comment nous travaillions avec les versions précédentes :

• Avec HTTP / 1.1Les connexions TCP étaient persistantes, mais chaque requête entraînait une surcharge importante. Le chargement des pages riches en ressources (images, CSS, JS) était souvent lent.
• Avec HTTP / 2, officiellement introduit en 2015, un grand pas en avant a été réalisé grâce à la multiplexage sur le même canal TCP : plusieurs requêtes pouvaient coexister sans avoir à ouvrir de connexions séparées. Cependant, TCP restait le talon d'Achille, notamment dans les cas de perte de paquets. Un seul paquet manquant suffisait à bloquer l'ensemble du flux jusqu'à sa retransmission : ce qu'on appelle blocage en tête de ligne.

Avec HTTP/3, la perspective change complètement :

• TCP est abandonné au profit de QUIC, un protocole construit sur UDP qui intègre directement les fonctionnalités retransmission, contrôle de congestion et sécurité cryptographique.
• La latence est considérablement réduite, en particulier dans le poignée de main:Avec QUIC, la négociation TLS est intégrée au protocole lui-même, éliminant ainsi les allers-retours inutiles.
• Le problème du blocage en tête de ligne disparaît : chaque flux circule indépendamment, sans qu'un paquet perdu ne bloque toute la connexion.

Ce n’est pas un hasard si de grands acteurs comme Cloudflare, Google, Méta, Akamai De nombreux CDN ont fortement œuvré pour l'adoption de HTTP/3. Une part importante du trafic mondial transite déjà par ce protocole, même si les utilisateurs finaux l'ignorent souvent.

D'un point de vue système, activer HTTP/3 sur un serveur web moderne comme NGINX semble une opération triviale : il suffit de compiler la version compatible QUIC et HTTP/3 (désormais fournie par défaut dans tous les paquets rpm et deb des dernières versions de NGINX), d'ajouter quelques directives de configuration et, théoriquement, le tour est joué. En réalité, dans de rares cas, la différence entre manuel et production est abyssaleC'est là qu'entrent en jeu les subtilités, les variables manquantes et les incompatibilités avec des applications complexes comme les CMS ou le e-commerce.

Le cas réel : bselfie.it sur Magento 2 — quand $http_host ça fait la différence

Début 2024, nous avons hérité de la gestion du système de bselfie.it, un e-commerce de cosmétiques techniques basé sur Magento 2La transition s'est produite à partir d'une architecture Amazon AWS à notre infrastructure optimisée, avec une des réductions de coûts d'environ 90 % e des performances nettement supérieures.
La réduction des coûts a été possible car nous avons éliminé plusieurs couches redondantes (services gérés « en tant que service », instances excédentaires et composants non essentiels) et consolidé sur Serveur dédié NVMe avec stockage et pile OpenZFS NGINX + PHP-FPM + Varnish Cache + MariaDB/Redis + ElasticSearch Optimisé pour Magento 2.

Cependant, nous n'avons pas réussi à couronner le tout en activant HTTP/3. Dès que nous avons procédé de manière « classique », les boutiques multilingues allemande et anglaise ont automatiquement cessé de fonctionner.

Dans notre cas spécifique, la plateforme était NGINX 1.28.3, avec une installation de Magento 2 qu'il a hébergé trois sites multilingues:Italien, anglais et allemand.

Pour gérer le Magento multi-boutique, nous avons adopté une configuration atypique (héritée de l'ancienne société qui les a suivis) basée sur la directive map, qui utilise la valeur de $http_host pour déterminer le code d'exécution (MAGE_RUN_CODE) correct.

En pratique, la logique était la suivante :

map $http_host $MAGE_RUN_CODE {
www.bselfie.it website_it;
www.bselfie.it/en website_en;
www.bselfie.de website_de;
}

Pourquoi cette configuration a parfaitement fonctionné avec HTTP/2

Avec HTTP / 2, la variable $http_host il est correctement valorisé à partir de l'en-tête Host.
donc:

• Une demande à www.bselfie.it activé le magasin italien.
• Une demande à www.bselfie.it/en activé le magasin anglais.
• Une demande à www.bselfie.de activé le magasin allemand.

La cartographie basée sur $http_host Il était fiable, cohérent et garantissait que chaque langue/marché recevait sa configuration correcte.

Que se passe-t-il avec HTTP/3

Avec l'activation de HTTP / 3, le scénario change radicalement.
Ce protocole n'utilise plus directement l'en-tête Hostmais lo pseudo-en-tête :authority.
Le problème est que, dans notre configuration, $http_host n'est pas automatiquement renseigné par :authority.

résultat:

• $http_host Rimane vide en HTTP/3.
• La directive map n'a plus de valeur d'entrée valide.
• Toutes les requêtes finissent par tomber dans le magasin par défaut (dans ce cas celui italien).

Exemple pratique :

• Une demande à www.bselfie.it/en n'est plus activé website_enparce $http_host c'était vide.
• Magento a interprété la demande comme si elle était dirigée vers le magasin principal, brisant ainsi la logique multi-magasins.

En d'autres termes: le routage était en cours d'arrêt et toute l'infrastructure multilingue s'est effondrée sur une seule boutique. C'était inacceptable, et entre un site avec un support multilingue défaillant et un site parfaitement fonctionnel avec HTTP/3 désactivé, nous avons opté pour cette option, car le TTFB restait bon même avec seulement HTTP72.

Pourquoi $host ce n'était pas une solution viable

Une objection technique possible pourrait être : « Pourquoi ne pas remplacer $http_host avec $host? ".
C'est vrai : dans le monde NGINX/ANGIE c'est maintenant devenu le pratique courante.
Lors de la migration d'une configuration existante depuis HTTP/2 vers HTTP/3, il est presque toujours recommandé de remplacer $http_host avec $host, car cette dernière variable est correctement renseignée même avec HTTP/3.

Dans la plupart des cas, cette « solution de contournement » fonctionne sans problème :

• $host contient le domaine demandé par le client,
• Il est géré directement par le noyau NGINX,
• et évite de se retrouver avec une variable vide comme c'est le cas avec $http_host en HTTP/3.

Cependant, dans notre cas spécifique — un Magento 2 multilingue et multi-boutiques comme bselfie.it - $host n'était pas un remplacement adéquatVoici les principales raisons.

1) $host contient uniquement le domaine

• $host améliore exclusivement le nom de domainepar exemple www.bselfie.it.
• Il ne prend pas en compte les pièces supplémentaires telles que /en o /de, qui dans notre configuration étaient indispensables pour déterminer correctement le magasin à servir.
• Résultat : toutes les requêtes tomberaient sur le même domaine, perte de distinction linguistique et l'effondrement du routage multi-magasins.

2) Repli indésirable

• Si l'en-tête Host est manquant ou invalide, $host tombe sur le premier server_name du bloc de configuration ou même sur l'IP du serveur.
• Dans un contexte Magento multilingue, cela signifie diriger les demandes légitimes vers le mauvais magasin, avec des conséquences imprévisibles sur les flux d’utilisateurs et les conversions.

3) Incohérence avec la configuration existante

• L'ensemble de la pile Magento (et de nombreux modules tiers) attend la variable HTTP_HOST correspond exactement à l'hôte fourni par le client.
• Modifier ce comportement en forçant $host au lieu de $http_host conduit à Redirections indésirables, boucles infinies ou URL générées de manière incohérente.

Pour la plupart des sites Web et des applications Web, en bref, remplacer $http_host avec $host C'est une astuce rapide, utilisée pratiquement déjà pour faire fonctionner HTTP/3 avec les configurations NGINX existantes.
Mais dans le cas de bselfie.it et d'autres scénarios complexes avec routage multi-magasins ou multi-langues, $host c'est tout simplement trop « normalisé » et pauvre en informations pour gérer la charge de logique d'application requise par Magento.

Il était donc essentiel que $http_host serait également correctement renseigné dans HTTP/3, en s'appuyant sur le pseudo-en-tête :authority.

La solution proposée

D'après l'analyse que nous avons faite sur le cas réel de bselfie.it, la conclusion était immédiate :
NGINX (et les forks comme ANGIE) devraient être remplis $http_host même en HTTP/3, en le prenant directement à partir de la valeur du pseudohader :authority.

Nous ne parlons pas d’un changement révolutionnaire, mais simplement d’un maintenir la cohérence entre les protocoles:

• in HTTP / 1.1 e HTTP / 2, $http_host est correctement renseigné par l'en-tête Host;
• in HTTP / 3où Host n'existe plus et est remplacé par :authority, il est naturel que $http_host doit hériter de cette valeur.

De cette façon:

• applications qui dépendent de $http_host (comme Magento 2 dans notre cas) continuerait à fonctionner sans aucun changement ;
• Il ne serait pas nécessaire d’intervenir manuellement sur la configuration avec des solutions de contournement telles que :

fastcgi_param HTTP_HOST $hôte;

ce qui, comme nous l'avons expliqué, fonctionne dans la plupart des scénarios mais pas dans les configurations avancées et multi-magasins.

Cela nous a semblé la chose la plus logique et la plus pacifique : ne cassez pas ce qui fonctionne déjà dans HTTP/2, simplement en s'assurant que dans HTTP/3 $http_host être rempli par :authority.

Chronologie essentielle des demandes

• Janvier 16 2025 — Ouvrons le rapport sur Nginx expliquant que dans HTTP/3 $http_host reste vide car il n'est pas initialisé par :authority, proposant d'aligner le comportement sur HTTP/1.1 et HTTP/2.
  Question: « Prise en charge du remplissage de $http_host avec l'en-tête :authority dans HTTP/3 (QUIC) » (NGINX #455).
• Janvier 23 2025 — Nous proposons à nouveau la même demande sur ANGIE (Fourche drop-in NGINX).
  Question: « Prise en charge du remplissage de $http_host avec l'en-tête :authority dans HTTP/3 (QUIC) » (ANGIE #109).
• Août 12 2025 - ANGIE accepte et intègre le patch: « HTTP/3 : initialiser l'en-tête « Host » à partir de l'autorité. » Le commit (SHA 140c3a6) s'initialise correctement Host/$http_host à partir de :authority quand le champ Host il n'est pas présent, alignement avec la RFC 9114.
• 29 septembre 2025 — Valentin V. Bartenev « VBart », le mainteneur d'ANGIE de Web Server LLC à Moscou, nous informe que notre demande a été clôturée et la mise en œuvre nous a été communiquée et distribution ultérieure dans la prochaine version d'ANGIE.

Il est curieux que, même dans ANGIE, la première réponse du mainteneur - qui est arrivée le lendemain de l'ouverture de notre demande - ait été utilisation $host au lieu de $http_host, rejetant ainsi la proposition. Une suggestion qui, bien que courante lors des migrations vers HTTP/3, dans notre contexte il n'aurait jamais résisté à la production ni sur le plan fonctionnel ni en termes de cohérence avec les configurations existantes. Ensuite, grâce à une analyse plus approfondie en août, la position a changé : il a été reconnu que initialiser $http_host da :authority c'est le bon choix et, plus qu'une exception, il représente la norme pour assurer la continuité entre HTTP/2 et HTTP/3 sans rompre les piles d'applications.

Du point de vue des spécifications, le RFC 9114 (HTTP/3) partie 4.3.1 « Champs de pseudo-en-tête de demande » précise que les clients ils doivent utiliser :authority au lieu de Host et, lorsque les deux sont présents, doit contenir la même valeurL'implémentation dans ANGIE rend donc le comportement de HTTP/3 cohérent avec celui de HTTP/2 même au niveau pratique des variables serveur.

y compris la traduction correspondante en italien :

Si le champ pseudo-en-tête :scheme identifie un schéma qui nécessite un composant d'autorité (y compris "http" e "https"), la demande DEVE contenir ou le champ pseudo-en-tête :authority ou l'en-tête Host. Si ces champs sont présents, ILS NE DOIVENT PAS être vide. Si les deux champs sont présents, ILS DOIVENT contiennent la même valeur. Si le schéma n'inclut pas de composant d'autorité obligatoire et qu'aucun n'est fourni dans la cible de la requête, la requête NE DOIT PAS contenir des champs de pseudo-en-tête :authority ou l'en-tête Host.

Une requête HTTP qui omet les champs de pseudo-en-tête obligatoires ou contient des valeurs non valides pour ces champs de pseudo-en-tête est malformé.

HTTP/3 ne définit pas de méthode pour transporter l'identifiant de version inclus dans la ligne de requête HTTP/1.1. Les requêtes HTTP/3 ont implicitement une version de protocole de "3.0".

Parce que pour nous cette solution était pacifique et « logiquement parfaite »

Il convient de clarifier pourquoi, de notre point de vue opérationnel et architectural, ce choix a été évidentL'objectif était de préserver le comportement attendu des applications lors du passage de HTTP/2 à HTTP/3, en évitant les solutions de contournement fragiles et en garantissant la continuité sans affecter les configurations éprouvées. Autrement dit : compatibilité maximale, friction minimale et alignement complet des normes.

• Cohérence entre les protocoles : en HTTP/1.1 et HTTP/2 $http_host est toujours valorisé ; dans HTTP/3, l'équivalent sémantique est :authority. Populaire $http_host da :authority éviter les régressions sur les piles d'applications qui attendent HTTP_HOST (Magento multi-boutique avant tout).
• Aucune intervention sur les configurations existantes : il n'est pas nécessaire d'introduire ou de diffuser la solution de contournement avec $host, ce qui dans les cas complexes peut conduire à des incohérences.
• Adhésion explicite au cahier des charges : le raccordement à :authority C'est précisément ce que la RFC indique comme source faisant autorité côté client ; l'implémentation côté serveur qui en résulte est naturelle.

De plus, il ne s'agissait pas d'entreprendre une tâche titanesque, mais simplement de remplir une variable vide avec le contenu d'une autre variable, si elle était présente. Ni plus ni moins.

Pourquoi NGINX d'abord et ensuite ANGIE ?

Notre stratégie était claire dès le début : Faire valider et introduire la fonctionnalité par au moins l'un des deux projets, NGINX ou ANGIE, créant ainsi un précédent technique fort qui, dans un quelques jours ou au plus quelques mois, a également poussé l'autre parti à s'aligner simplement inertie technique et la cohérence avec les spécifications (RFC 9114).

Cette ligne d’action s’inscrit dans un cadre historique et géopolitique non trivial : NGINX est né en Russie au début des années 2000 (dirigé par Igor Sysoev), il devient un pilier du web moderne et est ensuite acquis par F5 Networks; avec l'apparition de la guerre entre la Russie et l'Ukraine, le tableau se complique, F5 ferme sa branche russe et plusieurs ingénieurs historiques – laissés sans place – ils ont fondé ANGIE en Russie, un remplacement instantané compatible avec la syntaxe et la philosophie de NGINX, techniquement très réactif. Dans ce contexte, entreprise européenne, nous sommes tenus à une stricte conformité:entre sanctions, contraintes réglementaires, gestion du risque pays et politiques internes, nous ne pouvons pas adopter ANGIE en production, dans la mesure où nous reconnaissons sa valeur technique.

C'est pourquoi nous avons procédé ainsi : premier NGINX, qui est le serveur Web que nous utilisons tous les jours et le destinataire naturel de notre proposition ; puis ANGIE, afin d'augmenter les chances que la solution soit analysée et mise en œuvre rapidement, créant ainsi un « effet de priorité » susceptible d'entraîner également l'autre projet. En substance, nous souhaitions l'un des deux l'a mis en œuvre en premier la cartographie de :authority su $http_host en HTTP/3, en évitant les régressions d'application et les solutions de contournement fragiles : si ANGIE l'avait fait (comme cela s'est réellement produit), NGINX aurait eu un grand intérêt à converger; si NGINX l'avait fait, ANGIE aurait suivi Pour des raisons de compatibilité et pour son ambition même de remplacement direct. Une stratégie simple, concrète et réaliste : mettre la solution en production là où la vitesse d'intégration est plus grande, et laisser le reste de l’écosystème se réaligner en conséquence.

Rappelons que ANGIE est un remplacement direct de NGINX: en pratique, cela signifie qu'il peut remplacer NGINX sans aucun changement (ou avec des changements minimes) à la configuration, aux commandes et aux flux opérationnels. syntaxe de nginx.confle directives (serveur, localisation, carte, en amont, etc.), la disposition du hôte virtuelle indicateurs de ligne de commande et le comportement des directeurs modules (http/stream/mail) Ils restent compatibles, vous pouvez donc remplacer le binaire et continuer à utiliser les mêmes fichiers et procédures.

Le code d'ANGIE est largement dérivé/compatible avec celui de NGINX, donc le patch qui initialise $http_host da :authority c'est conceptuellement Portable même sur NGINX avec des différences minimes (sous réserve de différences d'arborescence, de système de compilation, de modules dynamiques et de politiques de licence). Autrement dit, Le correctif introduit dans ANGIE est techniquement rétroportable vers NGINX, et c'est précisément la valeur d'un véritable drop-in : compatibilité opérationnelle immédiate e facilité de réutilisation du travail entre les deux projets.

Conclusions et considérations

En conclusion, ce qui continue de nous laisser perplexes est comme une demande simple, bien documenté et parfaitement aligné avec la RFC a été accueilli avec peu d'intérêt da NGINX (F5 Networks), tandis que - même après une invitation initiale à « se replier sur $host" — était à la place reconnu comme valide et mis en œuvre par anciens développeurs russes de NGINX dans la fourche ANGIEDe notre point de vue opérationnel, la proposition relevait du pur bon sens : populaire $http_host da :authority en HTTP/3 pour s'assurer continuité avec HTTP/1.1/HTTP/2 et éviter les régressions sur les applications de production. C'est une petite amélioration, mais fort impact, en particulier dans les écosystèmes complexes comme Magento multi-store.

Il existe ensuite un plan plus vaste, presque « culturel ». Difficile de ne pas le remarquer. l'âme originelle de NGINX — celle faite de pragmatisme et d’attention à la production réelle — semble être restée en Russie, dans la branche désormais fermée d'où provenait le groupe qui a donné vie à ANGIE. Si les limitations géopolitiques le permettent, dans un avenir souhaitable de paix, nous serions très heureux de déplacer nos charges vers ANGIE:les faits montrent que l'équipe a été capable de écouter, évaluer et fonder une correction ciblée et conforme aux normes, confirmant — avec une pointe d'ironie — que « Les Russes le font mieux »Il ne s’agit pas d’encourager : il s’agit d’évaluer. tecnica de réactivité et qualité de mise en œuvre.

Sur le front de NGINX, une nouvelle étape a été franchie de notre part responsabilité envers l'écosystème: nous avons mis à jour la proposition ouvert à l'origine à Janvier 2024, soulignant que ANGIE a déjà intégré le correctif et rappelant explicitement la RFC 9114Le message est clair : nous ne demandons pas une révolution, mais cohérence inter-protocoles et la protection des déploiements réels. Nous espérons que cette fois, la demande ne sera pas rejetée. prise sous les bras et que nous le verrons en production dans la prochaine version 1.29.2 d'ici fin octobre 2025Qu'il s'agisse d'un vin rare et exotique ou du même vin dans différents millésimes, quel que soit votre choix au au plus tard d'ici fin 2025Ce serait un signal important : pour ceux qui développent en amont, pour ceux qui maintiennent la production et, surtout, pour ceux qui — comme nous — travaillent chaque jour pour rendre le web plus performant. rapide, fiable et cohérent des standards jusqu'au code qui sert les pages aux utilisateurs, parfois même - comme dans ce cas - en mettant les mains dans le cambouis - contrairement à nos « collègues » vendeurs d'hébergement du dimanche - qui se limitent à écrire des articles sur comment « Installer un plugin WordPress », ou comment créer une boîte mail sur Plesk ou cPanel.

Pathétique.

Publication de correctif pour NGINX et demande de fusion dans la branche principale.

Cinq jours après la sortie du patch initial, et profitant de quelques heures gratuites un dimanche calme d'octobre, en Serveur géré Srl nous avons décidé de faire un pas de plus en avant : apporter la modification développée dans le contexte ANGIE directement à NGINX, le principal projet open source.
L'objectif était de redonner à la communauté une amélioration qui s'est avérée utile et stable dans nos environnements de test et de production, tout en garantissant une conformité totale avec les dernières normes techniques, en particulier la RFC 9114 (HTTP/3).

L'initiative a été menée par Marco Marcoaldi, en tant que CTO de Managed Server Srl, qui a personnellement suivi l'intégralité du processus d'adaptation, de validation et de proposition officielle. La décision d'intervenir a été prise après avoir constaté, dans plusieurs contextes réels d'hébergement géré, un comportement anormal du module HTTP/3 NGINX : la variable $http_host il n'a pas été évalué correctement en présence du champ pseudo-en-tête :authority.
Un détail technique, certes, mais avec des implications importantes pour ceux qui utilisent des réécritures complexes, des règles de journalisation basées sur les en-têtes HTTP ou une logique de routage conditionnelle.

La première étape a consisté à analyser en profondeur les différences entre ANGIE, le fork de NGINX développé par Serveur Web LLC, et la version principale maintenue par l'équipe officielle NGINX (désormais sous l'égide de F5). Le correctif était déjà présent dans ANGIE, mais son implémentation était légèrement différente : certains appels internes n'étaient plus totalement compatibles avec les versions actuelles du noyau NGINX 1.29.x.
L'adaptation a donc nécessité un examen détaillé des fonctions d'analyse et de gestion des en-têtes dans ngx_http_v3_request.c, en respectant la logique interne du module HTTP/3 (QUIC) et en garantissant que l'initialisation de la structure r->headers_in s'est produit de manière cohérente et thread-safe.

Après un premier cycle de tests dans un environnement isolé, nous avons vérifié le bon fonctionnement du $http_host même en présence d'en-têtes dupliqués ou de valeurs non canoniques. Par la suite, le correctif a été porté vers Production contrôlée sur l'un de nos clusters d'hébergement WordPress à fort trafic, pour évaluer sa stabilité avec des charges réelles et des connexions QUIC simultanées.
Le résultat a été totalement positif : aucune régression, aucun impact sur les performances et, surtout, une compatibilité totale avec les règles de réécriture et la logique de routage existantes.

Une fois les tests consolidés, nous avons procédé à la fork du dépôt officiel NGINX et en envoyant le Demande de tirage n° 917, disponible à cette adresse :

La proposition contient la description technique complète, la motivation et la référence à la RFC 9114, ainsi qu'une différence minimale mais significative : l'ajout de la fonction ngx_http_v3_set_host() et l'adaptation de la logique de validation entre Host e :authority. De cette façon, lorsque l'en-tête Host il est absent mais :authority est présent (comme prévu par HTTP/3), NGINX se charge automatiquement de la configuration $http_host de manière cohérente, en alignant le comportement sur celui déjà consolidé dans HTTP/1.1 et HTTP/2.

Le patch est actuellement en cours "Ouvert", en attente de révision par l'équipe de développement NGINX. Conformément à la pratique, le Contrat de licence de contributeur (CLA) de F5 pour assurer l’attribution correcte des contributions et le respect des politiques d’intégration du projet.
Nous prévoyons que l'examen aura lieu dans les semaines à venir, avec une éventuelle inclusion dans le prochaine version de la série stable.

Ce type d'intervention incarne parfaitement la philosophie de Managed Server Srl : ne pas se limiter à l'utilisation d'outils open source, mais contribuer activement à leur amélioration, en partageant des expériences de terrain, des cas réels et des solutions qui découlent des besoins quotidiens de production.
Nous attendons donc la fusion officielle dans la branche principale de NGINX, certains que ce petit mais important correctif simplifiera la vie de nombreux administrateurs système et développeurs qui adoptent HTTP/3 dans leurs piles d'applications.