Good news everyone: CVE-2022-23529 got withdrawn. So need to upgrade to v9.

https://github.com/github/advisory-database/pull/1595#event-8377382060

Just a nitpick: would have called it fastify-whatwg-response.

Probably the typical strategy to wait it out. After some weeks and months devs will be forced anyway by product and engineering managers to upgrade jsonwebtoken, so that superiors get their security audits clear.

And then people like @taladrane will close this issue as stale.

Well. I just try to have a unit test.

Cant even get it done with a slow loris attack...

'use strict'

const { test } = require('tap')
const Fastify = require('..')

test('requestTimeout should be resilient against a slow loris attack and return 408', t => {
  t.plan(2)

  const fastify = Fastify({ requestTimeout: 1000 })
  fastify.get('/', function (req, reply) {
    reply.send({ hello: 'world' })
  })
  let socket
  let intervalId

  fastify.listen({ port: 0 }, err => {
    t.error(err)
    t.teardown(() => {
      fastify.close()
      socket.destroy()
      clearInterval(intervalId)
    })

    const {
      address: host,
      port
    } = fastify.server.address()

    socket = require('net').connect({ port, host }, () => {
      socket.write(`GET / HTTP/1.1\r\n`);
      socket.write(`Host: ${host}:${port}\r\n`);
      socket.write('Accept: */*\r\n');
      socket.write(
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\n"
      );

      intervalId = setInterval(() => {
        console.log('KeepAlive')
        socket.write(`KeepAlive: ${Math.random() * 1000}\r\n`);
      }, 500);
    });

    socket.setTimeout(0);

    socket.on('timeout', () => {
      console.log('timeout')
    })
    socket.on('data', (data) => {
      const result = data.toString()
      console.log(result)
      t.ok(result.indexOf('HTTP/1.1 408') !== -1)
    })
  })
})

'use strict'

const { test } = require('tap')
const Fastify = require('..')

test('requestTimeout should be resilient against a slow loris attack and return 408', t => {
  t.plan(2)

  const fastify = Fastify({ requestTimeout: 1 })
  fastify.post('/', function (req, reply) {
    reply.send({ hello: 'world' })
  })
  let socket
  let intervalId

  fastify.listen({ port: 0 }, err => {
    t.error(err)
    t.teardown(() => {
      fastify.close()
      socket.destroy()
      clearInterval(intervalId)
    })

    const {
      address: host,
      port
    } = fastify.server.address()

    socket = require('net').connect({ port, host }, () => {
      socket.write(`POST / HTTP/1.1\r\n`);
      socket.write(`Host: ${host}:${port}\r\n`);
      socket.write('Accept: */*\r\n');
      socket.write('Content-Length: 1024\r\n');
      socket.write('User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)\r\n');
      socket.write('Connection: Keep-Alive')
      socket.write('Content-Type: application/x-www-form-urlencoded')

      // intervalId = setInterval(() => {
      //   console.log('KeepAlive')
      //   socket.write(`KeepAlive: ${Math.random() * 1000}\r\n`);
      // }, 500);
    });

    socket.setTimeout(0);

    // socket.on('timeout', () => {
    //   console.log('timeout')
    // })
    socket.on('data', (data) => {
      const result = data.toString()
      console.log(result)
      t.ok(result.indexOf('HTTP/1.1 408') !== -1)
    })
  })
})

Here a failing unit test.

Strangely: Node 14 and Node 16 return a 400 Bad Request Error. Node 18 returns 200

So there seems to be bigger issue under the hood?

'use strict'

const { test } = require('tap')
const Fastify = require('..')
const sget = require('simple-get').concat

test('requestTimeout should return 408', t => {
  t.plan(3)

  const fastify = Fastify({ requestTimeout: 10 })
  fastify.get('/', async function (req, reply) {
    await new Promise(resolve => setTimeout(resolve, 100))
    return reply.send({ hello: 'world' })
  })

  fastify.listen({ port: 0 }, err => {
    t.error(err)
    t.teardown(() => { fastify.close() })

    sget({
      method: 'GET',
      url: 'http://localhost:' + fastify.server.address().port
    }, (err, response, body) => {
      t.error(err)
      t.equal(response.statusCode, 408)
    })
  })
})

fix mkdirp

Tbh, the wildcard option in fastify-static has the wrong name and behavour.

I quote:

wildcard

Default: true

If set to true, @fastify/static adds a wildcard route to serve files. If set to false, @fastify/static globs the filesystem for all defined files in the served folder (${root}/**/**), and just creates the routes needed for those and it will not serve the newly added file on the filesystem.

The default options of https://www.npmjs.com/package/glob are applied for getting the file list.

This option cannot be set to false with redirect set to true on a server with ignoreTrailingSlash set to true.

If I set wildcard false, than potentially a gazillion routes are added. But the documentatin says: it will not serve the newly added file on the filesystem.. So it sounds more like a "only existing files at start are supplied by wildcard false. But what if I delete the file after start? I guess you get 500 Internal Server Error but I would expect 404 Not found.

So what is the purpose of the wildcard false option? Maybe we should not allow the wildcard false option anyway...

I can confirm this performance bottleneck. You also need the wildcard option set to false.

You can basically reproduce it with this:

'use strict'

const path = require('path')

const fastify = require('fastify')({ logger: { level: 'trace' } })

fastify
  .register(require('..'), {
    // go crazy and expose big fat node_modules folder.
    root: path.join(__dirname, '../node_modules'),

    wildcard: false,
  })
  .listen({ port: 3000 }, err => {
    if (err) throw err
  })

Setting wildcard to true avoids that issue and the server spins up immediatly. Also the memory footprint is horrible with wildcards: false as each file gets its own route.

Platforms like npm keep track of open issues. Other pages like snyk determine the health of projects/npm packages also on the open issues counter. See https://snyk.io/advisor/npm-package/fastify

So basically by opening non-issues or keeping non-issues open can reduce the calculate quality/project health. And tbh we have already a "fastify is excellent" issue, which you also commented. So I really dont see a necessity for this issue to be open.

I am currently trying to implement some other keywords like

• enum
• maxProperties
• minProperties
• maxLength
• minLength
• maxItems
• minItems
• minimum
• maximum

Just to get the feeling on how we can implement it properly. Already enum is pain in the ass, because somehow i get an additional } but i dont know why. Lol. Fixing that and i could push the commit.

But looks good so far.

forgot this one variable in #600

Checklist

• [ ] run npm run test and npm run benchmark
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message and code follows the Developer's Certification of Origin and the Code of conduct

add genFuncNameCounter to context (#601)

No issue here, just: I love it. Fastify is awesome! I totally agree with the pinned issue.

Closing as it is no issue ;)

forgot this one variable in #600

Checklist

• [ ] run npm run test and npm run benchmark
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message and code follows the Developer's Certification of Origin and the Code of conduct

small reorder

fix merge error

improve mechanics and test coverage for largeArraySize-option (#575)

invalid value for patternproperties are validated by ajv (#576)

remove semver and proxyquire (#584)

add trunc as rounding method (#583)

improve coverage of serializer.js to 100% (#580)

• improve coverage of date formats

• add test for date error

• improve coverage for serializer.js to 100%

move tap options into .taprc (#587)

improve test coverage of ref-resolver (#586)

remove luxon (#585)

• remove luxon

• fix dates

• set timezone to UTC

improve perf of creation (#588)

only pass rounding option to serializer of standalone (#593)

branchless addComma (#590)

sort objectKeywords by probability (#591)

avoid main encapsulation for simple object (#594)

• avoid main encapsulation for simple object

• avoid ternary operation and add a comment

improve performance of asInteger serializer (#589)

improve asString performance (#592)

• improve asString performance

• Update lib/serializer.js

Co-authored-by: Rafael Gonzaga rafael.nunu@hotmail.com

• fix lint issue

Co-authored-by: Rafael Gonzaga rafael.nunu@hotmail.com

improve performance of asNumber (#595)

avoid intermediate strings. use const and let (#596)

avoid generation of intermediate array (#598)

instead of global variables create context object and pass iit as parameter (#600)

Merge branch 'master' into const-is-validated

Properly encapsulate the whole state of the builder. Preparation for further changes like implementing a possible strict mode as discussed in #579

Checklist

• [ ] run npm run test and npm run benchmark
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message and code follows the Developer's Certification of Origin and the Code of conduct

instead of global variables create context object and pass iit as parameter (#600)