5+ seconds response on some status codes < 200ms on others

[justintime4tea]

When I proxy a request and the target immediately returns a 200 or a 404 (no work) the request doesn't take much longer than without the proxy.

When I proxy a request where the target returns a 204 (with no work, immediately reply, and some other status codes) it always takes at least 5+ seconds.

When I don't proxy a request where the target returns a 204 (no work, immediate reply) it takes a few milliseconds. This is the same for all other status codes with no proxy and immediate reply (no work).

Not sure this is a gateway issue but all projects I'm proxing against are using fastify, the test project I tested against is literally a single file with dumb routes/handlers which immediately return a code and response.

Any help would be great! Want to return an appropriate status code.

[jkyberneees]

Hi @justintime4tea, as you can note here: https://github.com/jkyberneees/fastify-gateway/blob/master/test/feature.test.js#L44, I have added some checks for this particular status code. I have to say that the issue is not reproducible on my side. I would appreciate if you can provide more information here...

Best Regards, Rolando

[justintime4tea]

I'll retry with fastify 1.14 (using 1.13.1 I think?) It may be a fastify bug? Or perhaps the OS. My work development machine is Windows and Windows does some funny things on their TCP/IP stack so I'll also test on my personal Dev machine which is Linux. I'll post a gist with my testing JS file and link here as well. I'll also test with your latest release too. Thanks for adding a test case and looking into this! Awesome module you have made!

[justintime4tea]

Forked and created a branch: slow-204

In my fork I commented out the last step of the unit test file so that both the restana and fastify "remote" servers remain listening after the tests run through. Tested this with both fastify 1.13.4 (which I had been using) as well as the fastify version used in this project. Both produced the same results. Both the latest release of this project as well as the most previous version produce the same results.

All tests pass however... I discovered the following when leaving the remote servers running and manually running HTTP requests against them using both Insomnia (like Postman GUI HTTP client) and CURL from command line.

These experiences occur on both Windows and Linux.

• Issue a POST request to http://127.0.0.1:8080/fastify/response-time/204 and you will experience a 5+ second response time if there is a body sent with the 204 code reply.

• You will also experience this on a GET if the 204 code reply is sent with a body , when coming from fastify (via proxy), the test file does not contain a GET 204 for fastify.

• If you make a POST or GET directly against the test file fastify server they both respond fine and quickly regardless if there is a body in the 204 reply or not.

• At no time did restana reply slowly with or without a body in the 204 reply. Always responded "fine" either proxied or direct, with or without body.

To reproduce these experiences just clone down my fork and checkout slow-204 branch. Run 'npm run test' and then let it stay on and listening for requests. Open Insomnia or Postman or use command line HTTP request client and issue requests to the following:

Proxied Response time of ~5+ seconds with body in reply POST http://127.0.0.1:8080/fastify/response-time/204

Response time of ~15ms GET http://127.0.0.1:8080/fastify/response-time/204

Direct Response time of ~16ms with body in reply POST http://127.0.0.1:9090/204

Response time of ~16ms GET http://127.0.0.1:9090/204

Conclusion: After re-reading the specifications on 204 (RFC 7231) it is apparent that when issuing a 204 response it is not allowed to have a body. Whenever I sent the body, whether proxied or direct, I never received the body, as per the spec, so at this point I will just make sure I update my code to not send bodies for 204s, more closely follow HTTP//RFC specs and all will be well and no delays will occur LOL

I'm sure you will find that this issue can be closed LOL

Well that was fun 👍

[jkyberneees]

Hi @justintime4tea, I find very valuable your findings and cooperation. Thanks for spending so much time on it.

As soon as I have time I will review what is difference with fastify as remote (and body: 204). I will let you know in any case, for now I will let this issue open until we have all details.

Thanks again, Rolando

[justintime4tea]

You're very much welcome and thank you for the wonderful project. I will keep a close eye and if I can help at all and have the time I will be glad to do so!