Fastify 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, un accesseur typé pour le type de média négocié, et l'option de route onMaxParamLength, 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 par mcollina), découpe en morceaux les grandes réponses buffer HTTP/2 (#6746), migre la suite de tests de types d'assertions expect-type artisanales vers TSTyche (#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 est sorti le 5 mars 2026, et 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 (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 (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 (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 (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 par UlisesGascon), trois petits commits de durcissement autour des codes d'erreur de routage (#6678) et de checkDependencies (#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 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 (aquie00t) diffère le parsing ContentType à l'intérieur de getSchemaSerializer jusqu'à ce que le schéma soit réellement lu, #6694 (aquie00t) met en cache les objets ContentType analysés à l'intérieur du ContentTypeParser, et #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 (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 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 (climba03003) empêche un res.end dupliqué dans sendTrailer quand un callback synchrone déclenche le trailer, et #6714 (mcollina) ignore les complétions de trailer dupliquées. #6678 (mcollina) restaure le error.code sur les erreurs de routage qui le supprimaient silencieusement, et #6665 (trivikr) autorise request.getValidationFunction() à retourner undefined dans la déclaration TypeScript, ce qui correspond au comportement runtime réel. #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 (Fdawgs) ajoute Node.js 26 à la matrice de tests, ce qui s'aligne sur la version Node.js 26.4.0 du 25 juin, et #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 du projet Node.js et avec l'article Deno 2.9 du 26 juin 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 est le changement d'infrastructure le plus intéressant du cycle. PR #6532 (mrazauskas) introduit TSTyche, et #6726 et #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). 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 et les notes de version Deno 2.9 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.
