Fastify v5.9.0, veröffentlicht am 2026-06-28, ist die erste Minor-Version der Fastify-v5-Linie im Jahr 2026 und ein substanzieller 65-PR-Zyklus. Die beiden neuen öffentlichen APIs der Version sind request.mediaType, ein typisierter Accessor für den ausgehandelten Medientyp, und die Routen-Option onMaxParamLength, die es einem Routen-Hook ermöglicht, URLs zu behandeln, deren einzelner Parameter das konfigurierte maxParamLength überschreitet, anstatt synchron eine FST_ERR_VALIDATION zu werfen. Der Zyklus liefert auch einen Sicherheitsfix, der X-Forwarded-Host und X-Forwarded-Proto nicht mehr vertraut, wenn der eingehende Socket fehlt (#6684 von mcollina), chunkiert große HTTP/2-Buffer-Antworten (#6746), migriert die Typ-Test-Suite von handgeschriebenen expect-type-Assertions zu TSTyche (#6532), und fügt Node.js 26 zur Test-Matrix hinzu, während Node.js 20 aus der yarn-Matrix entfernt wird.
Die Version ist die dritte Minor der v5-Linie in diesem Jahr. Fastify v5.8.0 wurde am 5. März 2026 veröffentlicht, und v5.8.5 war der letzte 5.8.x am 14. April 2026. v5.9.0 ist die erste seit diesem 5.8.5-Patch, die eine neue öffentliche API ausliefert.
Die beiden neuen öffentlichen APIs
request.mediaType (climba03003) ist die Hauptfunktion. Vor v5.9.0 hat Anwendungscode, der wissen wollte, welchen Medientyp der Client angefordert hat, request.headers['accept'] von Hand geparst, die Q-Value-Liste durchlaufen, die beste Übereinstimmung ausgewählt und dann mit einem Content-Type verglichen, den die Route hoffentlich auslieferte. Der neue Accessor erledigt das Parsen und den Abgleich an einer Stelle. Für eine req, die application/json angefordert hat, gibt der Accessor 'application/json' zurück; für eine req ohne Accept-Header gibt er undefined zurück. Der Accessor ist additiv, und die öffentliche Oberfläche ist unverändert. Die Implementierung lebt in lib/request.js, und die TypeScript-Oberfläche ist in fastify.d.ts exportiert.
onMaxParamLength (climba03003) ist die zweite. Ohne die Option wirft Fastify synchron eine FST_ERR_VALIDATION, wenn ein einzelner URL-Parameter das konfigurierte maxParamLength überschreitet (standardmäßig 100 Zeichen). Mit der Option kann die Route etwas mit der fehlerhaften Anfrage tun: eine Warnung protokollieren, eine Metrik inkrementieren, umleiten oder einen benutzerdefinierten Fehler zurückgeben. Der Hook ist eine normale Routen-Option ({ onMaxParamLength: (req, reply, maxParamLength) => void }), neben preHandler, onRequest und dem Rest der Lifecycle-Hooks. Die Änderung ist additiv: Routen, die die Option nicht gesetzt haben, behalten das alte Verhalten, und die Option ist standardmäßig aus.
Der Sicherheitsfix und die zugehörigen Arbeiten
PR #6684 (mcollina) schließt eine Request-Spoofing-Lücke im Vertrauenspfad der Forwarded-Header. Vor dem Fix hat Fastify den X-Forwarded-Host- und X-Forwarded-Proto-Headern vertraut, auch wenn der eingehende request.socket fehlte oder undefiniert war (eine Situation, die hinter einem Transport auftreten kann, der die Quellverbindung entfernt, oder wenn die Anfrage aus einem geparsten Body in einem Test rekonstruiert wird). Der neue Code weigert sich, die Forwarded-Header in diesem Fall zu lesen, fällt auf das rohe request.host zurück und kennzeichnet die Situation als untrusted input in der TypeScript-Deklarationsdatei via PR #6572 (mcollina), das die Anfrage-Metadaten-Accessoren request.ip, request.host, request.protocol, request.ips mit expliziten JSDoc-Warnungen versieht, dass sie nicht für Sicherheitsentscheidungen vertrauenswürdig sind. Der Fix ist für korrekt konfigurierte Proxies unsichtbar (die immer einen echten Socket an der eingehenden Anfrage haben), und die Änderung liegt auf der sicheren Seite: fehlender Socket bedeutet keinen Forwarded-Header, selbst wenn der Header in der Anfrage vorhanden ist.
Die Version fügt auch useContentType-als-Schema-Schlüssel-Unterstützung hinzu, sodass die Antwort-Schema-Suche den ausgehandelten Content-Type berücksichtigt (#6685 von UlisesGascon), drei kleine Härtungs-Commits rund um Routing-Fehler-Codes (#6678) und checkDependencies (#6774), und markiert die request-Metadaten-Accessoren als untrusted input in der TypeScript-Deklarationsdatei (#6572 von mcollina).
Die Performance-Arbeit clustert sich auf dem Content-Type-Hot-Path
Drei der vier Perf-Einträge des Zyklus leben auf demselben Hot Path. PR #6692 (aquie00t) verzögert das ContentType-Parsen innerhalb von getSchemaSerializer, bis das Schema tatsächlich gelesen wird, #6694 (aquie00t) cachet geparste ContentType-Objekte innerhalb des ContentTypeParser, und #6693 (aquie00t) fügt eine typeof-Wache vor toString.call in send und onSendEnd hinzu. Der vierte ist der HTTP/2-Buffer-Chunking-Fix (mcollina) für große Antworten: Der alte Code hat die gesamte Payload im Speicher gepuffert, bevor sie über die HTTP/2-Verbindung gesendet wurde (ein 1-GB-Export bedeutete 1 GB residenten Speicher auf dem Server); der neue Code chunkiert den Buffer in kleinere Stücke und streamt sie, sobald die HTTP/2-Verbindung sie aufnehmen kann, sodass die Speicherkosten durch die Chunk-Größe begrenzt sind, nicht durch die Payload-Größe.
Der Vite-8.1-Artikel vom 24. Juni behandelte eine ähnliche Form von Performance-Arbeit im Dev-Server-Build-Pfad: eine kleine Änderung auf einem Hot Path, wiederholt über den Anfrage-Lebenszyklus, die sich zu einer bemerkenswerten Verbesserung summiert. Die Fastify-v5.9.0-Arbeit ist dieselbe Idee, auf einem anderen Runtime.
Trailer, Validierung und andere Fixes
Der Zyklus liefert ein Bündel von Fixes rund um die Trailer- und Validierungspfade. #6676 (climba03003) verhindert ein dupliziertes res.end in sendTrailer, wenn ein synchroner Callback den Trailer auslöst, und #6714 (mcollina) ignoriert duplizierte Trailer-Completion-Ereignisse. #6678 (mcollina) stellt den error.code auf Routing-Fehlern wieder her, die ihn stillschweigend fallen ließen, und #6665 (trivikr) erlaubt request.getValidationFunction(), in der TypeScript-Deklaration undefined zurückzugeben, was dem tatsächlichen Runtime-Verhalten entspricht. #6753 (LeSingh1) sorgt dafür, dass hasRequestDecorator und hasReplyDecorator konstruktor-zugewiesene Built-in-Eigenschaften erkennen, die zuvor übersehen wurden, was eine langjährige Lücke schließt, in der die Dekoratoren fälschlich als nicht vorhanden gemeldet wurden, wenn eine Anfrage oder Reply von einem Built-in umhüllt war.
Die Version liefert auch einen Node.js-Test-Matrix-Bump. #6728 (Fdawgs) fügt Node.js 26 zur Test-Matrix hinzu, was sich mit der Node.js-26.4.0-Veröffentlichung am 25. Juni deckt, und #6662 (Tony133) entfernt Node.js 20 aus der yarn-CI-Matrix, was mit dem End-of-Life-Zeitplan für Node.js 20 des Node.js-Projekts konsistent ist und mit dem Deno-2.9-Artikel vom 26. Juni, der die Runtime-Landschaft abdeckt.
TSTyche für Typ-Tests, fastify-plugin v6.0.0
Die Migration von Fastifys Typ-Test-Suite von handgeschriebenen expect-type-Assertions zu TSTyche ist die interessanteste Infrastrukturänderung des Zyklus. PR #6532 (mrazauskas) führt TSTyche ein, und #6726 und #6727 beenden die Migration in zwei Chargen. TSTyche ist ein zweckgebauter Typ-Test-Runner, der beim TypeScript-Compile-Schritt läuft statt zur Runtime, und der bessere Diagnosen liefert, wenn eine Assertion fehlschlägt (der Fehler verweist auf die Zeile und den erwarteten vs. tatsächlichen Typ, statt ein Runtime-false von expect-type). Die Änderung ist für Fastify-Nutzer unsichtbar; sie beschleunigt die CI der Maintainer und gibt ihnen bessere Fehlermeldungen, wenn ein Typ-Test fehlschlägt.
Die Version pinnt auch einen fastify-plugin-Bump von 5.1.0 auf 6.0.0 (#6801). fastify-plugin ist ein rein-typisierter Peer von Fastify; v6.0.0 ist ein Major-Versions-Bump, der einige der älteren CommonJS-Style-Codepfade entfernt und die API-Oberfläche auf die v5-Fastify-Linie ausrichtet. Der Bump liegt auf einer dependencies-Zeile, die Plugin-Autoren über peerDependencies konsumieren; Anwendungscode, der Fastify direkt verwendet, ist nicht betroffen.
Warum das wichtig ist
Fastify v5.9.0 ist die Version, in der das Framework auf halbem Weg eines einjährigen Härtungszyklus ist. Die v5.0-Linie wurde Ende 2024 veröffentlicht, und das Projekt fügt stetig typisierte Accessoren hinzu, härtet den Vertrauenspfad der Forwarded-Header und migriert die Test-Infrastruktur zu Tools, die besser zur Codebasis passen. v5.9.0 ist die erste Version in diesem Zyklus, die sowohl eine neue öffentliche API als auch einen sicherheitsrelevanten Fix liefert, was das Muster ist, das eine Minor-Versionsnotiz wert macht.
Für Anwendungsentwickler ist die praktische Änderung klein und konkret. Die beiden neuen öffentlichen APIs sind additiv, und der Sicherheitsfix liegt auf der sicheren Seite. Die TypeScript-Oberfläche bekommt einen neuen Accessor, und die request-Metadaten-Accessoren sind explizit als untrusted input markiert, was die richtige Sache ist und der richtige Zeitpunkt, es zu tun. Der HTTP/2-Buffer-Chunking-Fix ist für kleine Payloads unsichtbar und signifikant für sehr große, was die Form eines Fixes ist, die für eine Route zählt, die einen generierten Binär-Blob ausliefert.
Für den breiteren Node.js-Web-Framework-Bereich reiht sich Fastify v5.9.0 neben die Bun-Runtime-Updates und die Deno-2.9-Versionshinweise ein und zeigt, dass die drei großen JavaScript-Runtimes alle ihre HTTP- und Anfrage-Behandlungspfade parallel härten. Fastify ist das Gegenstück auf Framework-Ebene zu diesen Änderungen auf Runtime-Ebene.
