False response errored messages

[szegheo]

False response errored messages

[szegheo]

OK, finally I figured out, that it occurs when the client request arrives with Connection: keep-alive (default on HTTP/1.1 requests). Run the code below and wait ~3 sec:

const Fastify = require('fastify')
const fastifyHttpProxy = require('@fastify/http-proxy')

// PROXY TARGET
const fastifyProxyTarget = Fastify({
  logger: { level: 'debug' },
  disableRequestLogging: false,
}).put('/api', async (request, reply) => reply.code(204).send())

// CLIENT REQUESTS RECEIVER
const fastify = Fastify({
  logger: { level: 'debug' },
  disableRequestLogging: false,
});

fastify.register(fastifyHttpProxy, {
  upstream: 'http://localhost:3000/',
  prefix: '/proxytest',
  http2: false,
  http: {
    requestOptions: {
      timeout: 2000 //2sec
    }
  }
});

async function startTest() {
  await fastifyProxyTarget.listen({ port: 3000 });
  await fastify.listen({ port: 5000 });

  await fetch('http://localhost:5000/proxytest/api', {
    method: 'PUT',
    headers: {
      // 'Connection': 'close' // OK
      'Connection': 'keep-alive' // response errored
    }
  });
}

startTest()

The above code triggers the "response errored" warning with (current) v4.25.1, but not with 4.23.2

[szegheo]

Testing it further, it's now clear that it happens when the response code is 204 (method independent) and only with Node's http request (proxy options).

[Eomm]

Thanks for reporting!

Did you get the chance to debug it?
I think the fastifyHttpProxy is waiting for the content-length IMHO, but I'm only guessing

[szegheo]

Thanks for reporting!

Did you get the chance to debug it? I think the fastifyHttpProxy is waiting for the content-length IMHO, but I'm only guessing

Ok, I'll try to look into it deeper, but unfortunately I'm not a Fastify expert (doing FE things mostly)

[szegheo]

From the side of Fastify, it seems quite clear, that this issue was brought in with this change.
Currently, that new if block runs here because of the statusCode 204, and then it returns.
When I skip that if block, the issue is gone.
When I copy the next sendStream block into this new block, the issue is gone too.

Looking at the code of fastify-reply-from, the timeout error (that I reported) is created by handleHttp1Req, so maybe there should be some new check here to decide if the error should be forwarded or not.

The original timeout event is coming from Node's http module:

Emitted when the underlying socket times out from inactivity. This only notifies that the socket has been idle. The request must be destroyed manually.

Unfortunately, I do not have the necessary (deep) http knowledge to create a proper fix, but I hope at least these information will somehow useful. Honestly, I also wondering if the fix should be done here in reply-from or in Fastify (or both).

Thank you!