fastify 3.25.2 → 3.27.1

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2016-2020 The Fastify Team
+Copyright (c) 2016-2022 The Fastify Team
 
 The Fastify team members are listed at https://github.com/fastify/fastify#team
 and in the README file.

package/build/build-validation.js

@@ -15,6 +15,7 @@ const ajv = new Ajv({
 const defaultInitOptions = {
   connectionTimeout: 0, // 0 sec
   keepAliveTimeout: 5000, // 5 sec
+  forceCloseConnections: false, // keep-alive connections
   maxRequestsPerSocket: 0, // no limit
   requestTimeout: 0, // no limit
   bodyLimit: 1024 * 1024, // 1 MiB
@@ -49,6 +50,7 @@ const schema = {
   properties: {
     connectionTimeout: { type: 'integer', default: defaultInitOptions.connectionTimeout },
     keepAliveTimeout: { type: 'integer', default: defaultInitOptions.keepAliveTimeout },
+    forceCloseConnections: { type: 'boolean', default: defaultInitOptions.forceCloseConnections },
     maxRequestsPerSocket: { type: 'integer', default: defaultInitOptions.maxRequestsPerSocket, nullable: true },
     requestTimeout: { type: 'integer', default: defaultInitOptions.requestTimeout },
     bodyLimit: { type: 'integer', default: defaultInitOptions.bodyLimit },

package/docs/Guides/Index.md

@@ -20,6 +20,8 @@ This table of contents is in alphabetical order.
   Fastify v3 from earlier versions.
 + [Plugins Guide](./Plugins-Guide.md): An informal introduction to writing
   Fastify plugins.
++ [Prototype Poisoning](./Prototype-Poisoning.md): A description of how the
+  prototype poisoning attack works and is mitigated.
 + [Recommendations](./Recommendations.md): Recommendations for how to deploy
   Fastify into production environments.
 + [Serverless](./Serverless.md): Details on how to deploy Fastify applications

package/docs/Guides/Prototype-Poisoning.md

@@ -0,0 +1,391 @@
+> The following is an article written by Eran Hammer.
+> It is reproduced here for posterity [with permission](https://github.com/fastify/fastify/issues/1426#issuecomment-817957913).
+> It has been reformatted from the original HTML source to Markdown source,
+> but otherwise remains the same. The original HTML can be retrieved from the
+> above permission link.
+
+## A Tale of (prototype) Poisoning
+<a id="pp"></a>
+
+This story is a behind-the-scenes look at the process and drama created by a
+particularity interesting web security issue. It is also a perfect illustration
+of the efforts required to maintain popular pieces of open source software and
+the limitations of existing communication channels.
+
+But first, if you use a JavaScript framework to process incoming JSON data, take
+a moment to read up on [Prototype
+Poisoning](https://medium.com/intrinsic/javascript-prototype-poisoning-vulnerabilities-in-the-wild-7bc15347c96)
+in general, and the specific [technical
+details](https://github.com/hapijs/hapi/issues/3916) of this issue. I'll explain
+it all in a bit, but since this could be a critical issue, you might want to
+verify your own code first. While this story is focused on a specific framework,
+any solution that uses `JSON.parse()` to process external data is potentially at
+risk.
+
+### BOOM
+<a id="pp-boom"></a>
+
+Our story begins with a bang.
+
+The engineering team at Lob (long time generous supporters of my work!) reported
+a critical security vulnerability they identified in our data validation
+module — [joi](https://github.com/hapijs/joi). They provided some technical
+details and a proposed solution.
+
+The main purpose of a data validation library is to ensure the output fully
+complies with the rules defined. If it doesn't, validation fails. If it passes,
+your can blindly trust that the data you are working with is safe. In fact, most
+developers treat validated input as completely safe from a system integrity
+perspective. This is crucial.
+
+In our case, the Lob team provided an example where some data was able to sneak
+by the validation logic and pass through undetected. This is the worst possible
+defect a validation library can have.
+
+### Prototype in a nutshell
+<a id="pp-nutshell"></a>
+
+To understand this story, you need to understand how JavaScript works a bit.
+Every object in JavaScript can have a prototype. It is a set of methods and
+properties it "inherits" from another object. I put inherits in quotes because
+JavaScript isn't really an object oriented language.
+
+A long time ago, for a bunch of irrelevant reasons, someone decided that it
+would be a good idea to use the special property name `__proto__` to access (and
+set) an object's prototype. This has since been deprecated but nevertheless,
+fully supported.
+
+To demonstrate:
+
+```
+> const a = { b: 5 };
+> a.b;
+5
+> a.__proto__ = { c: 6 };
+> a.c;
+6
+> a;
+{ b: 5 }
+```
+
+As you can see, the object doesn't have a `c` property, but its prototype does.
+When validating the object, the validation library ignores the prototype and
+only validates the object's own properties. This allows `c` to sneak in via the
+prototype.
+
+Another important part of this story is the way `JSON.parse()` — a utility
+provided by the language to convert JSON formatted text into objects  —  handles
+this magic `__proto__` property name.
+
+```
+> const text = '{ "b": 5, "__proto__": { "c": 6 } }';
+> const a = JSON.parse(text);
+> a;
+{ b: 5, __proto__: { c: 6 } }
+```
+
+Notice how `a` has a `__proto__` property. This is not a prototype reference. It
+is a simple object property key, just like `b`. As we've seen from the first
+example, we can't actually create this key through assignment as that invokes
+the prototype magic and sets an actual prototype. `JSON.parse()` however, sets a
+simple property with that poisonous name.
+
+By itself, the object created by `JSON.parse()` is perfectly safe. It doesn't
+have a prototype of its own. It has a seemingly harmless property that just
+happens to overlap with a built-in JavaScript magic name.
+
+However, other methods are not as lucky:
+
+```
+> const x = Object.assign({}, a);
+> x;
+{ b: 5}
+> x.c;
+6;
+```
+
+If we take the `a` object created earlier by `JSON.parse()` and pass it to the
+helpful `Object.assign()` method (used to perform a shallow copy of all the top
+level properties of `a` into the provided empty `{}` object), the magic
+`__proto__` property "leaks" and becomes `x` 's actual prototype.
+
+Surprise!
+
+Put together, if you get some external text input, parse it with `JSON.parse()`
+then perform some simple manipulation of that object (say, shallow clone and add
+an `id` ), and then pass it to our validation library, anything passed through
+via `__proto__` would sneak in undetected.
+
+### Oh joi!
+<a id="pp-oh-joi"></a>
+
+The first question is, of course, why does the validation module **joi** ignore
+the prototype and let potentially harmful data through? We asked ourselves the
+same question and our instant thought was "it was an oversight". A bug. A really
+big mistake. The joi module should not have allowed this to happen. But…
+
+While joi is used primarily for validating web input data, it also has a
+significant user base using it to validate internal objects, some of which have
+prototypes. The fact that joi ignores the prototype is a helpful "feature". It
+allows validating the object's own properties while ignoring what could be a
+very complicated prototype structure (with many methods and literal properties).
+
+Any solution at the joi level would mean breaking some currently working code.
+
+### The right thing
+<a id="pp-right-thing"></a>
+
+At this point, we were looking at a devastatingly bad security vulnerability.
+Right up there in the upper echelons of epic security failures. All we knew is
+that our extremely popular data validation library fails to block harmful data,
+and that this data is trivial to sneak through. All you need to do is add
+`__proto__` and some crap to a JSON input and send it on its way to an
+application built using our tools.
+
+(Dramatic pause)
+
+We knew we had to fix joi to prevent this but given the scale of this issue, we
+had to do it in a way that will put a fix out without drawing too much attention
+to it — without making it too easy to exploit — at least for a few days until
+most systems received the update.
+
+Sneaking a fix isn't the hardest thing to accomplish. If you combine it with an
+otherwise purposeless refactor of the code, and throw in a few unrelated bug
+fixes and maybe a cool new feature, you can publish a new version without
+drawing attention to the real issue being fixed.
+
+The problem was, the right fix was going to break valid use cases. You see, joi
+has no way of knowing if you want it to ignore the prototype you set, or block
+the prototype set by an attacker. A solution that fixes the exploit will break
+code and breaking code tends to get a lot of attention.
+
+On the other hand, if we released a proper ([semantically
+versioned](https://semver.org/)) fix, mark it as a breaking change, and add a
+new API to explicitly tell joi what you want it to do with the prototype, we
+will share with the world how to exploit this vulnerability while also making it
+more time consuming for systems to upgrade (breaking changes never get applied
+automatically by build tools).
+
+Lose — Lose.
+
+### A detour
+<a id="pp-detour"></a>
+
+While the issue at hand was about incoming request payloads, we had to pause and
+check if it could also impact data coming via the query string, cookies, and
+headers. Basically, anything that gets serialized into objects from text.
+
+We quickly confirmed node default query string parser was fine as well as its
+header parser. I identified one potential issue with base64-encoded JSON cookies
+as well as the usage of custom query string parsers. We also wrote some tests to
+confirm that the most popular third-party query string parser  —
+[qs](https://www.npmjs.com/package/qs) —  was not vulnerable (it is not!).
+
+### A development
+<a id="pp-a-development"></a>
+
+Throughout this triage, we just assumed that the offending input with its
+poisoned prototype was coming into joi from hapi, the web framework connecting
+the hapi.js ecosystem. Further investigation by the Lob team found that the
+problem was a bit more nuanced.
+
+hapi used `JSON.parse()` to process incoming data. It first set the result
+object as a `payload` property of the incoming request, and then passed that
+same object for validation by joi before being passed to the application
+business logic for processing. Since `JSON.parse()` doesn't actually leak the
+`__proto__` property, it would arrive to joi with an invalid key and fail
+validation.
+
+However, hapi provides two extension points where the payload data can be
+inspected (and processed) prior to validation. It is all properly documented and
+well understood by most developers. The extension points are there to allow you
+to interact with the raw inputs prior to validation for legitimate (and often
+security related) reasons.
+
+If during one of these two extension points, a developer used `Object.assign()`
+or a similar method on the payload, the `__proto__` property would leak and
+become an actual prototype.
+
+### Sigh of relief
+<a id="pp-sigh-of-relief"></a>
+
+We were now dealing with a much different level of awfulness. Manipulating the
+payload object prior to validation is not common which meant this was no longer
+a doomsday scenario. It was still potentially catastrophic but the exposure
+dropped from every joi user to some very specific implementations.
+
+We were no longer looking at a secretive joi release. The issue in joi is still
+there, but we can now address it properly with a new API and breaking release
+over the next few weeks.
+
+We also knew that we can easily mitigate this vulnerability at the framework
+level since it knows which data is coming from the outside and which is
+internally generated. The framework is really the only piece that can protect
+developers against making such unexpected mistakes.
+
+### Good news, bad news, no news?
+<a id="pp-good-news-no-news"></a>
+
+The good news was that this wasn't our fault. It wasn't a bug in hapi or joi. It
+was only possible through a complex combination of actions that was not unique
+to hapi or joi. This can happen with every other JavaScript framework. If hapi
+is broken, then the world is broken.
+
+Great — we solved the blame game.
+
+The bad news is that when there is nothing to blame (other than JavaScript
+itself), it is much harder getting it fixed.
+
+The first question people ask once a security issue is found is if there is
+going to be a CVE published. A CVE — Common Vulnerabilities and Exposures — is a
+[database](https://cve.mitre.org/) of known security issues. It is a critical
+component of web security. The benefit of publishing a CVE is that it
+immediately triggers alarms and informs and often breaks automated builds until
+the issue is resolved.
+
+But what do we pin this to?
+
+Probably, nothing. We are still debating whether we should tag some versions of
+hapi with a warning. The "we" is the node security process. Since we now have a
+new version of hapi that mitigate the problem by default, it can be considered a
+fix. But because the fix isn't to a problem in hapi itself, it is not exactly
+kosher to declare older versions harmful.
+
+Publishing an advisory on previous versions of hapi for the sole purpose of
+nudging people into awareness and upgrade is an abuse of the advisory process.
+I'm personally fine with abusing it for the purpose of improving security but
+that's not my call. As of this writing, it is still being debated.
+
+### The solution business
+<a id="pp-solution-business"></a>
+
+Mitigating the issue wasn't hard. Making it scale and safe was a bit more
+involved. Since we knew where harmful data can enter the system, and we knew
+where we used the problematic `JSON.parse()` we could replace it with a safe
+implementation.
+
+One problem. Validating data can be costly and we are now planning on validating
+every incoming JSON text. The built-in `JSON.parse()` implementation is fast.
+Really really fast. It is unlikely we can build a replacement that will be more
+secure and anywhere as fast. Especially not overnight and without introducing
+new bugs.
+
+It was obvious we were going to wrap the existing `JSON.parse()` method with
+some additional logic. We just had to make sure it was not adding too much
+overhead. This isn't just a performance consideration but also a security one.
+If we make it easy to slow down a system by simply sending specific data, we
+make it easy to execute a [DoS
+attack](https://en.wikipedia.org/wiki/Denial-of-service_attack) at very low
+cost.
+
+I came up with a stupidly simple solution: first parse the text using the
+existing tools. If this didn't fail, scan the original raw text for the
+offending string "__proto__". Only if we find it, perform an actual scan of the
+object. We can't block every reference to "__proto__" — sometimes it is
+perfectly valid value (like when writing about it here and sending this text
+over to Medium for publication).
+
+This made the "happy path" practically as fast as before. It just added one
+function call, a quick text scan (again, very fast built-in implementation), and
+a conditional return. The solution had negligible impact on the vast majority of
+data expected to pass through it.
+
+Next problem. The prototype property doesn't have to be at the top level of the
+incoming object. It can be nested deep inside. This means we cannot just check
+for the presence of it at the top level. We need to recursively iterate through
+the object.
+
+While recursive functions are a favorite tool, they could be disastrous when
+writing security-conscious code. You see, recursive function increase the size
+of the runtime call stack. The more times you loop, the longer the call stack
+gets. At some point — KABOOM— you reach the maximum length and the process dies.
+
+If you cannot guarantee the shape of the incoming data, recursive iteration
+becomes an open threat. An attacker only needs to craft a deep enough object to
+crash your servers.
+
+I used a flat loop implementation that is both more memory efficient (less
+function calls, less passing of temporary arguments) and more secure. I am not
+pointing this out to brag, but to highlight how basic engineering practices can
+create (or avoid) security pitfalls.
+
+### Putting it to the test
+<a id="pp-putting-to-test"></a>
+
+I sent the code to two people. First to [Nathan
+LaFreniere](https://github.com/nlf) to double check the security properties of
+the solution, and then to [Matteo Collina](https://github.com/mcollina) to
+review the performance. They are among the very best at what they do and often
+my go-to people.
+
+The performance benchmarks confirmed that the "happy path" was practically
+unaffected. The interesting findings was that removing the offending values was
+faster then throwing an exception. This raised the question of what should be
+the default behavior of the new module — which I called
+[**bourne**](https://github.com/hapijs/bourne) —  error or sanitize.
+
+The concern, again, was exposing the application to a DoS attack. If sending a
+request with `__proto__` makes things 500% slower, that could be an easy vector
+to exploit. But after a bit more testing we confirmed that sending **any**
+invalid JSON text was creating a very similar cost.
+
+In other words, if you parse JSON, invalid values are going to cost you more,
+regardless of what makes them invalid. It is also important to remember that
+while the benchmark showed the significant % cost of scanning suspected objects,
+the actual cost in CPU time was still in the fraction of milliseconds. Important
+to note and measure but not actually harmful.
+
+### hapi ever-after
+<a id="pp-hapi-ever-after"></a>
+
+There are a bunch of things to be grateful for.
+
+The initial disclosure by the Lob team was perfect. It was reported privately,
+to the right people, with the right information. They followed up with
+additional findings, and gave us the time and space to resolve it the right way.
+Lob also was a major sponsor of my work on hapi over the years and that
+financial support is critical to allow everything else to happen. More on that
+in a bit.
+
+Triage was stressful but staffed with the right people. Having folks like
+[Nicolas Morel](https://github.com/Marsup), Nathan, and Matteo, available and
+eager to help is critical. This isn't easy to deal with without the pressure,
+but with it, mistakes are likely without proper team collaboration.
+
+We got lucky with the actual vulnerability. What started up looking like a
+catastrophic problem, ended up being a delicate but straight-forward problem to
+address.
+
+We also got lucky by having full access to mitigate it at the source — didn't
+need to send emails to some unknown framework maintainer and hope for a quick
+answer. hapi's total control over all of its dependencies proved its usefulness
+and security again. Not using [hapi](http://hapijs.com)? [Maybe you
+should](https://hueniverse.com/why-you-should-consider-hapi-6163689bd7c2).
+
+### The after in happy ever-after
+<a id="pp-after-ever-after"></a>
+
+This is where I have to take advantage of this incident to reiterate the cost
+and need for sustainable and secure open source.
+
+My time alone on this one issue exceeded 20 hours. That's half a working week.
+It came at the end of a month were I already spent over 30 hours publishing a
+new major release of hapi (most of the work was done in December). This puts me
+at a personal financial loss of over $5000 this month (I had to cut back on paid
+client work to make time for it).
+
+If you rely on code I maintain, this is exactly the level of support, quality,
+and commitment you want (and lets be honest — expect). Most of you take it for
+granted — not just my work but the work of hundreds of other dedicated open
+source maintainers.
+
+Because this work is important, I decided to try and make it not just
+financially sustainable but to grow and expand it. There is so much to improve.
+This is exactly what motivates me to implement the new [commercial licensing
+plan](https://web.archive.org/web/20190201220503/https://hueniverse.com/on-hapi-licensing-a-preview-f982662ee898)
+coming in March. You can read more about it
+[here](https://web.archive.org/web/20190201220503/https://hueniverse.com/on-hapi-licensing-a-preview-f982662ee898).
+
+Of all the time consuming things, security is at the very top. I hope this story
+successfully conveyed not just the technical details, but also the human drama and
+what it takes to keep the web secure.

package/docs/Guides/Recommendations.md

@@ -255,7 +255,7 @@ server {
   # group specified above. Note the additional headers that forward
   # information about the original request. You might want to set
   # trustProxy to the address of your NGINX server so the X-Forwarded
-  * fields are used by fastify.
+  # fields are used by fastify.
   location / {
     # more info: http://nginx.org/en/docs/http/ngx_http_proxy_module.html
     proxy_http_version 1.1;

package/docs/Reference/Plugins.md

@@ -181,7 +181,7 @@ callback.
 Example:
 ```js
 module.exports = function (fastify, opts, done) {
-  fastify.decorate('utility', () => {})
+  fastify.decorate('utility', function () {})
 
   fastify.get('/', handler)
 
@@ -191,7 +191,7 @@ module.exports = function (fastify, opts, done) {
 You can also use `register` inside another `register`:
 ```js
 module.exports = function (fastify, opts, done) {
-  fastify.decorate('utility', () => {})
+  fastify.decorate('utility', function () {})
 
   fastify.get('/', handler)
 
@@ -226,7 +226,7 @@ plugin will support.
 const fp = require('fastify-plugin')
 
 module.exports = fp(function (fastify, opts, done) {
-  fastify.decorate('utility', () => {})
+  fastify.decorate('utility', function () {})
   done()
 }, '0.x')
 ```
@@ -239,7 +239,7 @@ changes it will be your responsibility to update the module, while if you use
 `fastify-plugin`, you can be sure about backward compatibility.
 ```js
 function yourPlugin (fastify, opts, done) {
-  fastify.decorate('utility', () => {})
+  fastify.decorate('utility', function () {})
   done()
 }
 yourPlugin[Symbol.for('skip-override')] = true

package/docs/Reference/Request.md

@@ -57,6 +57,9 @@ This operation will add to the request headers the new values that can be read
 calling `request.headers.bar`. Moreover, you can still access the standard
 request's headers with the `request.raw.headers` property.
 
+> Note: For performance reason on `not found` route, you may see that we will add
+an extra property `Symbol('fastify.RequestAcceptVersion')` on the headers.
+
 ```js
 fastify.post('/:params', options, function (request, reply) {
   console.log(request.body)

package/docs/Reference/Server.md

@@ -13,6 +13,7 @@ describes the properties available in that options object.
   - [`https`](#https)
   - [`connectionTimeout`](#connectiontimeout)
   - [`keepAliveTimeout`](#keepalivetimeout)
+  - [`forceCloseConnections`](#forcecloseconnections)
   - [`maxRequestsPerSocket`](#maxrequestspersocket)
   - [`requestTimeout`](#requesttimeout)
   - [`ignoreTrailingSlash`](#ignoretrailingslash)
@@ -124,6 +125,19 @@ use. Also, when `serverFactory` option is specified, this option is ignored.
 
 + Default: `5000` (5 seconds)
 
+### `forceCloseConnections`
+<a id="forcecloseconnections"></a>
+
+When set to `true` requests with the header `connection: keep-alive` will be
+tracked by the server. Upon [`close`](#close), the server will iterate the
+current persistent connections and [destroy their
+sockets](https://nodejs.org/dist/latest-v16.x/docs/api/net.html#socketdestroyerror).
+This means the server will shutdown immediately instead of waiting for existing
+persistent connections to timeout first. Important: connections are not
+inspected to determine if requests have been completed.
+
++ Default: `false`
+
 ### `maxRequestsPerSocket`
 <a id="factory-max-requests-per-socket"></a>
 
@@ -207,7 +221,7 @@ Defines the maximum payload, in bytes, the server is allowed to accept.
 Defines what action the framework must take when parsing a JSON object with
 `__proto__`. This functionality is provided by
 [secure-json-parse](https://github.com/fastify/secure-json-parse). See
-https://hueniverse.com/a-tale-of-prototype-poisoning-2610fa170061 for more
+[Prototype Poisoning](../Guides/Prototype-Poisoning.md) for more
 details about prototype poisoning attacks.
 
 Possible values are `'error'`, `'remove'` and `'ignore'`.
@@ -220,7 +234,7 @@ Possible values are `'error'`, `'remove'` and `'ignore'`.
 Defines what action the framework must take when parsing a JSON object with
 `constructor`. This functionality is provided by
 [secure-json-parse](https://github.com/fastify/secure-json-parse). See
-https://hueniverse.com/a-tale-of-prototype-poisoning-2610fa170061 for more
+[Prototype Poisoning](../Guides/Prototype-Poisoning.md) for more
 details about prototype poisoning attacks.
 
 Possible values are `'error'`, `'remove'` and `'ignore'`.

package/docs/Reference/TypeScript.md

@@ -1384,7 +1384,7 @@ body parsing happens before the `preHandler` hook.
 
 [src](https://github.com/fastify/fastify/blob/main/types/hooks.d.ts#L35)
 
-preParsing` is the second hook to be executed in the request lifecycle. The
+`preParsing` is the second hook to be executed in the request lifecycle. The
 previous hook was `onRequest`, the next hook will be `preValidation`.
 
 Notice: in the `preParsing` hook, request.body will always be null, because the

package/fastify.d.ts

@@ -98,6 +98,7 @@ export type FastifyServerOptions<
   connectionTimeout?: number,
   keepAliveTimeout?: number,
   maxRequestsPerSocket?: number,
+  forceCloseConnections?: boolean,
   requestTimeout?: number,
   pluginTimeout?: number,
   bodyLimit?: number,
@@ -144,7 +145,7 @@ export type FastifyServerOptions<
   return503OnClosing?: boolean,
   ajv?: {
     customOptions?: AjvOptions,
-    plugins?: Function[]
+    plugins?: (Function | [Function, unknown])[]
   },
   frameworkErrors?: <RequestGeneric extends RequestGenericInterface = RequestGenericInterface>(
     error: FastifyError,

package/fastify.js

@@ -1,6 +1,6 @@
 'use strict'
 
-const VERSION = '3.25.2'
+const VERSION = '3.27.1'
 
 const Avvio = require('avvio')
 const http = require('http')
@@ -16,6 +16,7 @@ const {
   kLogSerializers,
   kHooks,
   kSchemaController,
+  kRequestAcceptVersion,
   kReplySerializerDefault,
   kContentTypeParser,
   kReply,
@@ -25,7 +26,8 @@ const {
   kOptions,
   kPluginNameChain,
   kSchemaErrorFormatter,
-  kErrorHandler
+  kErrorHandler,
+  kKeepAliveConnections
 } = require('./lib/symbols.js')
 
 const { createServer } = require('./lib/server')
@@ -44,6 +46,7 @@ const build404 = require('./lib/fourOhFour')
 const getSecuredInitialConfig = require('./lib/initialConfigValidation')
 const override = require('./lib/pluginOverride')
 const warning = require('./lib/warnings')
+const noopSet = require('./lib/noop-set')
 const { defaultInitOptions } = getSecuredInitialConfig
 
 const {
@@ -132,6 +135,7 @@ function fastify (options) {
   // Update the options with the fixed values
   options.connectionTimeout = options.connectionTimeout || defaultInitOptions.connectionTimeout
   options.keepAliveTimeout = options.keepAliveTimeout || defaultInitOptions.keepAliveTimeout
+  options.forceCloseConnections = typeof options.forceCloseConnections === 'boolean' ? options.forceCloseConnections : defaultInitOptions.forceCloseConnections
   options.maxRequestsPerSocket = options.maxRequestsPerSocket || defaultInitOptions.maxRequestsPerSocket
   options.requestTimeout = options.requestTimeout || defaultInitOptions.requestTimeout
   options.logger = logger
@@ -145,6 +149,7 @@ function fastify (options) {
   options.exposeHeadRoutes = exposeHeadRoutes
 
   const initialConfig = getSecuredInitialConfig(options)
+  const keepAliveConnections = options.forceCloseConnections === true ? new Set() : noopSet()
 
   let constraints = options.constraints
   if (options.versioning) {
@@ -175,7 +180,8 @@ function fastify (options) {
       maxParamLength: options.maxParamLength || defaultInitOptions.maxParamLength,
       caseSensitive: options.caseSensitive,
       buildPrettyMeta: defaultBuildPrettyMeta
-    }
+    },
+    keepAliveConnections
   })
 
   // 404 router, used for handling encapsulated 404 handlers
@@ -199,6 +205,7 @@ function fastify (options) {
       closing: false,
       started: false
     },
+    [kKeepAliveConnections]: keepAliveConnections,
     [kOptions]: options,
     [kChildren]: [],
     [kBodyLimit]: bodyLimit,
@@ -374,6 +381,15 @@ function fastify (options) {
       if (fastify[kState].listening) {
         // No new TCP connections are accepted
         instance.server.close(done)
+
+        for (const conn of fastify[kKeepAliveConnections]) {
+          // We must invoke the destroy method instead of merely unreffing
+          // the sockets. If we only unref, then the callback passed to
+          // `fastify.close` will never be invoked; nor will any of the
+          // registered `onClose` hooks.
+          conn.destroy()
+          fastify[kKeepAliveConnections].delete(conn)
+        }
       } else {
         done(null)
       }
@@ -520,10 +536,8 @@ function fastify (options) {
     }
 
     if (name === 'onClose') {
-      this[kHooks].validate(name, fn)
       this.onClose(fn)
     } else if (name === 'onReady') {
-      this[kHooks].validate(name, fn)
       this[kHooks].add(name, fn)
     } else {
       this.after((err, done) => {
@@ -578,6 +592,10 @@ function fastify (options) {
   // req and res are Node.js core objects
   function defaultRoute (req, res) {
     if (req.headers['accept-version'] !== undefined) {
+      // we remove the accept-version header for performance result
+      // because we do not want to go through the constraint checking
+      // the usage of symbol here to prevent any colision on custom header name
+      req.headers[kRequestAcceptVersion] = req.headers['accept-version']
       req.headers['accept-version'] = undefined
     }
     fourOhFour.router.lookup(req, res)

package/lib/errors.js

@@ -210,6 +210,11 @@ const codes = {
     500,
     TypeError
   ),
+  FST_ERR_INVALID_URL: createError(
+    'FST_ERR_INVALID_URL',
+    "URL must be a string. Received '%s'",
+    400
+  ),
 
   /**
    *  again listen when close server