--- title: "Fastify v5.9.0 ajoute `request.mediaType` et `onMaxParamLength`, durcit la confiance dans les en-têtes `forwarded`, découpe les grandes réponses HTTP/2 et migre les tests de types vers TSTyche" description: "Fastify v5.9.0, publié le 2026-06-28 (github.com/fastify/fastify), est la première version mineure de la ligne v5 en 2026 et un cycle substantiel de 65 PR. Les fonctionnalités principales sont `request.mediaType` (un accesseur typé pour le type de média négocié, [#6653](https://github.com/fastify/fastify/pull/6653) par climba03003), l'option de route `onMaxParamLength` ([#6716](https://github.com/fastify/fastify/pull/6716) par climba03003), et un correctif de sécurité qui ne fait plus confiance à `X-Forwarded-Host` et `X-Forwarded-Proto` quand le socket entrant est absent ([#6684](https://github.com/fastify/fastify/pull/6684) par mcollina). Le cycle livre un correctif de découpage en morceaux du buffer HTTP/2 pour les grandes réponses ([#6746](https://github.com/fastify/fastify/pull/6746) par mcollina), trois gains de performance liés au schéma (parsing différé du ContentType dans `getSchemaSerializer` #6692, mise en cache des objets `ContentType` analysés dans `ContentTypeParser` #6694, garde `typeof` avant `toString.call` dans `send` / `onSendEnd` #6693 par aquie00t), Node.js 26 ajouté à la matrice de tests ([#6728](https://github.com/fastify/fastify/pull/6728) par Fdawgs) et Node.js 20 retiré de la matrice yarn CI ([#6662](https://github.com/fastify/fastify/pull/6662) par Tony133), la migration de la suite de tests de types d'assertions `expect-type` artisanales vers [TSTyche](https://github.com/mrazauskas/tstyche) ([#6532](https://github.com/fastify/fastify/pull/6532) par mrazauskas, avec les suites #6726 et #6727), et un bump de fastify-plugin v6.0.0 purement TypeScript. Autres correctifs notables : déduplication de `res.end` du trailer (#6676), garde de complétion dupliquée du trailer (#6714), `error.code` sur les erreurs de routage (#6678), `hasRequestDecorator` / `hasReplyDecorator` détectant les propriétés natives assignées par constructeur (#6753), `getValidationFunction()` autorisé à retourner `undefined` (#6665), et un nettoyage du `_meta` du socket qui ferme une fuite keep-alive (#6799)." date: 2026-07-01 image: "/images/heroes/2026-07-01--fastify-v5-9-0-security-perf-http2-buffer-chunking.png" author: lschvn tags: ["runtimes", "security"] tldr: - "[Fastify v5.9.0](https://github.com/fastify/fastify/releases/tag/v5.9.0), publié le 2026-06-28, est la première mineure de la ligne v5 en 2026. Les deux nouvelles API publiques sont `request.mediaType` ([#6653](https://github.com/fastify/fastify/pull/6653)), un accesseur typé qui retourne le type de média négocié depuis l'en-tête `Accept` (ou `undefined` si aucun n'a été négocié), et l'option de route `onMaxParamLength` ([#6716](https://github.com/fastify/fastify/pull/6716)) qui permet à un hook de route de gérer les URLs dont un seul paramètre dépasse le `maxParamLength` configuré, au lieu de jeter une `FST_ERR_VALIDATION` synchrone. Les deux sont additives : aucun changement cassant sur la surface publique, et la ligne v5 reste en `0.x` du semver patch." - "Le cycle livre un correctif de sécurité qui ferme une faille de spoofing de requête : [#6684](https://github.com/fastify/fastify/pull/6684) (mcollina) refuse de faire confiance aux en-têtes `X-Forwarded-Host` et `X-Forwarded-Proto` quand le socket entrant de la requête est absent (par exemple derrière un transport qui supprime la connexion source), forçant la route à retomber sur le `request.host` brut à la place. Le même correctif signale les accesseurs de métadonnées de la `request` comme `untrusted input` dans le fichier de déclaration TypeScript ([#6572](https://github.com/fastify/fastify/pull/6572)). La version ajoute aussi le support de `useContentType` comme clé de schéma, pour que la recherche de schéma de réponse respecte le type de contenu négocié ([#6685](https://github.com/fastify/fastify/pull/6685) par UlisesGascon), ainsi que trois autres petits commits de durcissement autour des codes d'erreur de routage ([#6678](https://github.com/fastify/fastify/pull/6678)) et de `checkDependencies` ([#6774](https://github.com/fastify/fastify/pull/6774))." - "Le travail de performance se regroupe autour du parsing du type de contenu sur le chemin chaud. [#6692](https://github.com/fastify/fastify/pull/6692) (aquie00t) diffère le parsing `ContentType` à l'intérieur de `getSchemaSerializer` jusqu'à ce que le schéma soit réellement lu, [#6694](https://github.com/fastify/fastify/pull/6694) met en cache les objets `ContentType` analysés à l'intérieur du `ContentTypeParser`, et [#6693](https://github.com/fastify/fastify/pull/6693) ajoute une garde `typeof` devant `toString.call` dans `send` et `onSendEnd`. La version découpe aussi en morceaux les grandes réponses buffer HTTP/2 pour garder la mémoire bornée sous des charges utiles importantes ([#6746](https://github.com/fastify/fastify/pull/6746) par mcollina). La suite de tests de types est migrée des assertions `expect-type` artisanales vers [TSTyche](https://github.com/mrazauskas/tstyche) ([#6532](https://github.com/fastify/fastify/pull/6532) par mrazauskas, plus #6726 et #6727), et Node.js 26 est ajouté à la matrice de tests ([#6728](https://github.com/fastify/fastify/pull/6728) par Fdawgs) tandis que Node.js 20 est retiré de la matrice yarn ([#6662](https://github.com/fastify/fastify/pull/6662) par Tony133)." faq: - question: "Qu'est-ce que `request.mediaType` et pourquoi est-il nouveau en v5.9.0 ?" answer: "`request.mediaType` est un accesseur typé sur la requête Fastify qui retourne le type de média négocié depuis l'en-tête `Accept`, ou `undefined` si aucun type de média n'a été négocié. Avant la v5.9.0, le code d'application parsait `request.headers['accept']` à la main, parcourait la liste des q-values, choisissait la meilleure correspondance, puis comparait avec un `Content-Type` qu'il espérait servi par la route. Le nouvel accesseur (ajouté par [PR #6653](https://github.com/fastify/fastify/pull/6653) par climba03003) fait le parsing et la correspondance en un seul endroit. L'implémentation vit dans `lib/request.js` et la surface TypeScript est exportée dans `fastify.d.ts`. Pour une `req` qui demande `application/json`, l'accesseur retourne `'application/json'` ; pour une `req` sans en-tête `Accept`, il retourne `undefined`. L'accesseur est additif, aucune migration nécessaire pour les routes existantes qui lisent l'en-tête `Accept` elles-mêmes, mais le nouveau code est censé l'utiliser." - question: "Que fait l'option `onMaxParamLength` ?" answer: "`onMaxParamLength` est un hook par route qui se déclenche quand un seul paramètre d'URL dépasse le `maxParamLength` configuré (100 caractères par défaut). Sans l'option, Fastify jette une `FST_ERR_VALIDATION` synchrone. Avec l'option, la route peut faire quelque chose avec la requête fautive : journaliser un avertissement, incrémenter une métrique, rediriger, ou retourner une erreur personnalisée. Le hook est ajouté par [PR #6716](https://github.com/fastify/fastify/pull/6716) (climba03003). L'option est une option de route normale (`{ onMaxParamLength: (req, reply, maxParamLength) => void }`), à côté de `preHandler`, `onRequest` et du reste des hooks de cycle de vie. Le changement est additif : les routes qui n'ont pas défini l'option conservent l'ancien comportement, et l'option est désactivée par défaut." - question: "Que change concrètement le correctif de confiance dans l'en-tête `forwarded` ?" answer: "[PR #6684](https://github.com/fastify/fastify/pull/6684) (mcollina) ferme une faille de spoofing de requête dans le chemin de confiance des en-têtes forwarded. Avant le correctif, Fastify faisait confiance aux en-têtes `X-Forwarded-Host` et `X-Forwarded-Proto` même quand le `request.socket` entrant était absent ou non défini (une situation qui peut se produire derrière un transport qui supprime la connexion source, ou quand la requête est reconstruite depuis un corps analysé dans un test). Le nouveau code refuse de lire les en-têtes forwarded dans ce cas, retombe sur le `request.host` brut, et signale la situation comme `untrusted input` dans le fichier de déclaration TypeScript via [PR #6572](https://github.com/fastify/fastify/pull/6572) (mcollina, qui marque les accesseurs de métadonnées de la requête `request.ip`, `request.host`, `request.protocol`, `request.ips` avec des avertissements JSDoc explicites indiquant qu'ils ne doivent pas être utilisés pour des décisions de sécurité). Le correctif est invisible pour les proxies correctement configurés (qui ont toujours un vrai socket sur la requête entrante) et le changement est du côté sûr : socket absent signifie pas d'en-tête forwarded, même si l'en-tête est présent dans la requête." - question: "De quoi parle le correctif de découpage en morceaux du buffer HTTP/2 ?" answer: "[PR #6746](https://github.com/fastify/fastify/pull/6746) (mcollina) adresse un problème mémoire dans le chemin de réponse HTTP/2. Avant le correctif, une route qui retournait une charge utile très volumineuse (le genre de taille que l'on verrait dans un export en streaming ou un blob binaire généré) mettait en buffer la totalité de la charge utile en mémoire avant de l'envoyer sur la connexion HTTP/2. Pour un export de 1 Go, cela voulait dire 1 Go de mémoire résidente sur le serveur. Le correctif découpe le buffer en morceaux plus petits et les streame au fur et à mesure que la connexion HTTP/2 peut les absorber, donc le coût mémoire est borné par la taille du chunk plutôt que par la taille de la charge utile. Le changement est invisible pour le code d'application ; il vit dans le chemin d'envoi HTTP/2. Les routes qui retournent de petites charges utiles ne voient aucun changement. Les routes qui retournent de très grandes charges utiles ne détiennent maintenant qu'une quantité bornée de mémoire quelle que soit la taille de la charge utile." - question: "Pourquoi la migration vers TSTyche pour les tests de types est-elle intéressante ?" answer: "Fastify a une suite de tests de types de longue durée qui vérifie que la surface TypeScript publique a la forme documentée par les mainteneurs. La suite était auparavant construite sur des assertions `expect-type` artisanales, qui sont une vérification runtime légère. [PR #6532](https://github.com/fastify/fastify/pull/6532) (mrazauskas) migre la suite vers [TSTyche](https://github.com/mrazauskas/tstyche), un lanceur de tests de types dédié qui s'exécute à l'étape de compilation TypeScript plutôt qu'au runtime, et qui donne de meilleurs diagnostics quand une assertion échoue (l'échec pointe sur la ligne et le type attendu vs. réel, plutôt qu'un `false` runtime de `expect-type`). Les suites [#6726](https://github.com/fastify/fastify/pull/6726) et [#6727](https://github.com/fastify/fastify/pull/6727) terminent la migration en deux lots. Le changement est invisible pour les utilisateurs de Fastify ; il accélère la CI des mainteneurs et leur donne de meilleurs messages d'erreur quand un test de type échoue." - question: "Qu'est-ce qui a changé dans l'empreinte des dépendances de Fastify v5.9.0 ?" answer: "La version épingle un bump de `fastify-plugin` de 5.1.0 à 6.0.0 ([#6801](https://github.com/fastify/fastify/pull/6801)), qui est un major purement TypeScript. La dépendance de dev `concurrently` est bumpée à 10.0.0 ([#6752](https://github.com/fastify/fastify/pull/6752)), `actions/checkout` est bumpée à 7 ([#6812](https://github.com/fastify/fastify/pull/6812)), `actions/github-script` est bumpée de 8 à 9 ([#6705](https://github.com/fastify/fastify/pull/6705)), et `pnpm/action-setup` est bumpée à 6.0.4 ([#6704](https://github.com/fastify/fastify/pull/6704)). Node.js 20 est retirée de la matrice yarn CI ([#6662](https://github.com/fastify/fastify/pull/6662) par Tony133) et Node.js 26 est ajoutée à la matrice de tests ([#6728](https://github.com/fastify/fastify/pull/6728) par Fdawgs), ce qui aligne la CI de Fastify sur la [ligne Node.js 26](https://nodejs.org/en/blog/release/v26.4.0) que l'équipe Node.js a mise en current en juin." - question: "Est-il sûr de passer à Fastify v5.9.0 aujourd'hui ?" answer: "Oui. La version est la première mineure de la ligne v5 en 2026, la surface publique n'a aucun changement cassant, et le correctif de sécurité de [PR #6684](https://github.com/fastify/fastify/pull/6684) est du côté sûr (il refuse de faire confiance aux en-têtes forwarded quand le socket est absent). Les seules personnes qui devraient hésiter sont les équipes qui dépendent d'un comportement spécifique des en-têtes `forwarded` dans des configurations de test synthétiques qui simulent une requête sans socket, donc ces tests verront maintenant `request.host` retomber sur l'en-tête brut au lieu de la valeur forwardée, ce qui est le comportement correct mais un changement de comportement. Pour tous les autres, `npm install fastify@5.9` (ou la mineure courante de la version majeure) est sans accroc." --- [Fastify v5.9.0](https://github.com/fastify/fastify/releases/tag/v5.9.0), publié le 2026-06-28, est la première version mineure de la ligne v5 de Fastify en 2026 et un cycle substantiel de 65 PR. Les deux nouvelles API publiques de la version sont [`request.mediaType`](https://github.com/fastify/fastify/pull/6653), un accesseur typé pour le type de média négocié, et l'option de route [`onMaxParamLength`](https://github.com/fastify/fastify/pull/6716), qui permet à un hook de route de gérer les URLs dont un seul paramètre dépasse le `maxParamLength` configuré, au lieu de jeter une `FST_ERR_VALIDATION` synchrone. Le cycle livre aussi un correctif de sécurité qui ne fait plus confiance à `X-Forwarded-Host` et `X-Forwarded-Proto` quand le socket entrant est absent ([#6684](https://github.com/fastify/fastify/pull/6684) par mcollina), découpe en morceaux les grandes réponses buffer HTTP/2 ([#6746](https://github.com/fastify/fastify/pull/6746)), migre la suite de tests de types d'assertions `expect-type` artisanales vers [TSTyche](https://github.com/mrazauskas/tstyche) ([#6532](https://github.com/fastify/fastify/pull/6532)), et ajoute Node.js 26 à la matrice de tests tout en retirant Node.js 20 de la matrice yarn. La version est la troisième mineure de la ligne v5 cette année. [Fastify v5.8.0](https://github.com/fastify/fastify/releases/tag/v5.8.0) est sorti le 5 mars 2026, et [v5.8.5](https://github.com/fastify/fastify/releases/tag/v5.8.5) était le dernier 5.8.x le 14 avril 2026. v5.9.0 est la première depuis ce patch 5.8.5 qui livre une nouvelle API publique. ## Les deux nouvelles API publiques [`request.mediaType`](https://github.com/fastify/fastify/pull/6653) (climba03003) est la fonctionnalité phare. Avant la v5.9.0, le code d'application qui voulait savoir quel type de média le client demandait parsait `request.headers['accept']` à la main, parcourait la liste des q-values, choisissait la meilleure correspondance, puis comparait avec un `Content-Type` qu'il espérait servi par la route. Le nouvel accesseur fait le parsing et la correspondance en un seul endroit. Pour une `req` qui demande `application/json`, l'accesseur retourne `'application/json'` ; pour une `req` sans en-tête `Accept`, il retourne `undefined`. L'accesseur est additif, et la surface publique est inchangée. L'implémentation vit dans `lib/request.js` et la surface TypeScript est exportée dans `fastify.d.ts`. [`onMaxParamLength`](https://github.com/fastify/fastify/pull/6716) (climba03003) est la deuxième. Sans l'option, Fastify jette une `FST_ERR_VALIDATION` synchrone quand un seul paramètre d'URL dépasse le `maxParamLength` configuré (100 caractères par défaut). Avec l'option, la route peut faire quelque chose avec la requête fautive : journaliser un avertissement, incrémenter une métrique, rediriger, ou retourner une erreur personnalisée. Le hook est une option de route normale (`{ onMaxParamLength: (req, reply, maxParamLength) => void }`), à côté de `preHandler`, `onRequest` et du reste des hooks de cycle de vie. Le changement est additif : les routes qui n'ont pas défini l'option conservent l'ancien comportement, et l'option est désactivée par défaut. ## Le correctif de sécurité et les travaux liés [PR #6684](https://github.com/fastify/fastify/pull/6684) (mcollina) ferme une faille de spoofing de requête dans le chemin de confiance des en-têtes forwarded. Avant le correctif, Fastify faisait confiance aux en-têtes `X-Forwarded-Host` et `X-Forwarded-Proto` même quand le `request.socket` entrant était absent ou non défini (une situation qui peut se produire derrière un transport qui supprime la connexion source, ou quand la requête est reconstruite depuis un corps analysé dans un test). Le nouveau code refuse de lire les en-têtes forwarded dans ce cas, retombe sur le `request.host` brut, et signale la situation comme `untrusted input` dans le fichier de déclaration TypeScript via [PR #6572](https://github.com/fastify/fastify/pull/6572) (mcollina), qui marque les accesseurs de métadonnées de la requête `request.ip`, `request.host`, `request.protocol`, `request.ips` avec des avertissements JSDoc explicites indiquant qu'ils ne doivent pas être utilisés pour des décisions de sécurité. Le correctif est invisible pour les proxies correctement configurés (qui ont toujours un vrai socket sur la requête entrante) et le changement est du côté sûr : socket absent signifie pas d'en-tête forwarded, même si l'en-tête est présent dans la requête. La version ajoute aussi le support de `useContentType` comme clé de schéma, pour que la recherche de schéma de réponse respecte le type de contenu négocié ([#6685](https://github.com/fastify/fastify/pull/6685) par UlisesGascon), trois petits commits de durcissement autour des codes d'erreur de routage ([#6678](https://github.com/fastify/fastify/pull/6678)) et de `checkDependencies` ([#6774](https://github.com/fastify/fastify/pull/6774)), et marque les accesseurs de métadonnées de la `request` comme entrées non fiables dans le fichier de déclaration TypeScript ([#6572](https://github.com/fastify/fastify/pull/6572) par mcollina). ## Le travail de performance se regroupe sur le chemin chaud du type de contenu Trois des quatre entrées de perf du cycle vivent sur le même chemin chaud. [PR #6692](https://github.com/fastify/fastify/pull/6692) (aquie00t) diffère le parsing `ContentType` à l'intérieur de `getSchemaSerializer` jusqu'à ce que le schéma soit réellement lu, [#6694](https://github.com/fastify/fastify/pull/6694) (aquie00t) met en cache les objets `ContentType` analysés à l'intérieur du `ContentTypeParser`, et [#6693](https://github.com/fastify/fastify/pull/6693) (aquie00t) ajoute une garde `typeof` devant `toString.call` dans `send` et `onSendEnd`. Le quatrième est le [correctif de découpage en morceaux du buffer HTTP/2](https://github.com/fastify/fastify/pull/6746) (mcollina) pour les grandes réponses : l'ancien code mettait en buffer la totalité de la charge utile en mémoire avant de l'envoyer sur la connexion HTTP/2 (un export de 1 Go voulait dire 1 Go de mémoire résidente sur le serveur) ; le nouveau code découpe le buffer en morceaux plus petits et les streame au fur et à mesure que la connexion HTTP/2 peut les absorber, donc le coût mémoire est borné par la taille du chunk plutôt que par la taille de la charge utile. L'[article Vite 8.1 du 24 juin](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode) couvrait une forme similaire de travail de perf dans le chemin de build du dev server : un petit changement sur un chemin chaud, répété tout au long du cycle de vie de la requête, qui s'additionne en une amélioration notable. Le travail de Fastify v5.9.0 est la même idée, sur un runtime différent. ## Trailer, validation, et autres correctifs Le cycle livre un groupe de correctifs autour des chemins de trailer et de validation. [#6676](https://github.com/fastify/fastify/pull/6676) (climba03003) empêche un `res.end` dupliqué dans `sendTrailer` quand un callback synchrone déclenche le trailer, et [#6714](https://github.com/fastify/fastify/pull/6714) (mcollina) ignore les complétions de trailer dupliquées. [#6678](https://github.com/fastify/fastify/pull/6678) (mcollina) restaure le `error.code` sur les erreurs de routage qui le supprimaient silencieusement, et [#6665](https://github.com/fastify/fastify/pull/6665) (trivikr) autorise `request.getValidationFunction()` à retourner `undefined` dans la déclaration TypeScript, ce qui correspond au comportement runtime réel. [#6753](https://github.com/fastify/fastify/pull/6753) (LeSingh1) fait que `hasRequestDecorator` et `hasReplyDecorator` détectent les propriétés natives assignées par constructeur qui étaient précédemment manquées, ce qui ferme un écart de longue date où les décorateurs étaient faussement signalés comme absents sur une requête ou un reply qui avait été encapsulé par un natif. La version livre aussi un bump de la matrice de tests Node.js. [#6728](https://github.com/fastify/fastify/pull/6728) (Fdawgs) ajoute Node.js 26 à la matrice de tests, ce qui s'aligne sur la [version Node.js 26.4.0 du 25 juin](/articles/2026-06-25--node-js-26-4-current-vfs-loader-package-maps), et [#6662](https://github.com/fastify/fastify/pull/6662) (Tony133) retire Node.js 20 de la matrice yarn CI, ce qui est cohérent avec le [calendrier de fin de vie de Node.js 20](https://nodejs.org/en/about/previous-releases) du projet Node.js et avec l'[article Deno 2.9 du 26 juin](/articles/2026-06-26--deno-2-9-cold-start-supply-chain-tests) qui couvre le paysage des runtimes. ## TSTyche pour les tests de types, fastify-plugin v6.0.0 La migration de la suite de tests de types de Fastify d'assertions `expect-type` artisanales vers [TSTyche](https://github.com/mrazauskas/tstyche) est le changement d'infrastructure le plus intéressant du cycle. [PR #6532](https://github.com/fastify/fastify/pull/6532) (mrazauskas) introduit TSTyche, et [#6726](https://github.com/fastify/fastify/pull/6726) et [#6727](https://github.com/fastify/fastify/pull/6727) terminent la migration en deux lots. TSTyche est un lanceur de tests de types dédié qui s'exécute à l'étape de compilation TypeScript plutôt qu'au runtime, et qui donne de meilleurs diagnostics quand une assertion échoue (l'échec pointe sur la ligne et le type attendu vs. réel, plutôt qu'un `false` runtime de `expect-type`). Le changement est invisible pour les utilisateurs de Fastify ; il accélère la CI des mainteneurs et leur donne de meilleurs messages d'erreur quand un test de type échoue. La version épingle aussi un bump de `fastify-plugin` de 5.1.0 à 6.0.0 ([#6801](https://github.com/fastify/fastify/pull/6801)). `fastify-plugin` est un peer purement TypeScript de Fastify ; v6.0.0 est un bump de version majeure qui supprime certains des anciens chemins de code style CommonJS et aligne la surface API sur la ligne Fastify v5. Le bump est sur une ligne de `dependencies` que les auteurs de plugins consomment via `peerDependencies` ; le code d'application qui utilise Fastify directement n'est pas affecté. ## Pourquoi c'est important Fastify v5.9.0 est la version où le framework est à mi-chemin d'un cycle de durcissement d'un an. La ligne v5.0 est sortie fin 2024 et le projet ajoute régulièrement des accesseurs type-safe, durcit le chemin de confiance des en-têtes forwarded, et migre l'infrastructure de test vers des outils qui sont un meilleur choix pour la base de code. v5.9.0 est la première version de ce cycle qui livre à la fois une nouvelle API publique et un correctif pertinent pour la sécurité, ce qui est le schéma qui fait qu'une mineure vaut la peine d'être écrite. Pour les développeurs d'application, le changement pratique est petit et concret. Les deux nouvelles API publiques sont additives et le correctif de sécurité est du côté sûr. La surface TypeScript obtient un nouvel accesseur et les accesseurs de métadonnées de la `request` sont explicitement marqués comme entrées non fiables, ce qui est la bonne chose à faire et le bon moment pour le faire. Le correctif de découpage en morceaux du buffer HTTP/2 est invisible pour les petites charges utiles et significatif pour les très grandes, ce qui est la forme de correctif qui compte pour une route qui sert un blob binaire généré. Pour l'espace plus large des frameworks web Node.js, Fastify v5.9.0 s'aligne sur les [mises à jour du runtime Bun](/articles/2026-04-13--bun-1-3-12-webview-browser-automation-using-await-using) et les [notes de version Deno 2.9](/articles/2026-06-26--deno-2-9-cold-start-supply-chain-tests) pour montrer que les trois grands runtimes JavaScript durcissent tous leurs chemins HTTP et de gestion de requête en parallèle. Fastify est la contrepartie au niveau framework de ces changements au niveau runtime.