Response header set via `reply.header()` in a custom handler never gets sent

🐛 Bug Report

A response header that’s set via reply.header() or reply.headers() in a custom handler will never be sent.

This is because Fastify buffers headers internally instead of setting them on the http.ServerResponse instance, and only sends them after reply.send() is called. But since Next.js calls .end() directly on the http.ServerResponse instance, Fastify never has an opportunity to set response headers, and the buffered headers never get sent.

One way to address this might be for fastify-nextjs to iterate over Fastify’s response headers and call reply.res.setHeader(...) to set each header on the http.ServerResponse before passing control to the custom handler or Next.js. Unfortunately, Fastify doesn’t appear to provide any public API to get all the internally buffered headers; the only option is to get an individual header by name via reply.getHeader(), which is insufficient. I’m curious if anyone has ideas.

To Reproduce

Here’s a failing test that reproduces this:

test('should serve Fastify response headers set by a custom handler', t => {
  t.plan(3)

  const fastify = Fastify()

  fastify
    .register(require('./index'))
    .after(() => {
      fastify.next('/hello', (app, req, reply) => {
        reply.header('test-header', 'hello');
        app.render(req.req, reply.res, '/hello', req.query, {})
      })
    })

  fastify.inject({
    url: '/hello',
    method: 'GET'
  }, (err, res) => {
    t.error(err)
    t.equal(res.statusCode, 200)
    t.equal(res.headers['test-header'], 'hello')
  })

  fastify.close()
});

Expected behavior

The response served by Next.js should include headers set by Fastify, and the test above should pass.

Your Environment

• node version: 12.15.0
• fastify version: 2.12.1
• os: Mac, Linux

[mcollina]

There are quite a few reasons to not do what express does, for completeness, I’m listing a few here:

1. IncomingMessage and ServerResponse are extremely tied to the HTTP/1 implementation of Node.js core. Which make supporting http/2 and in the future http/3 impossible for Express.
2. Avoid monkeypatching - in order to work, Express monkeypatches the internals of those instances, fundamentally changing how they work. This makes it brittle and complex to maintain over time. Fastify relies only on public methods.
3. Encapsulation and performance. A large amount of the performance gap between Express and Fastify can be attributed to the use of our won custom and Request and Reply instances.

[mcollina]

That’d be nice, yes!