I'm seeing a difference in behaviour in the HTTP Request node between v3.1.1 and v4.0.9. Has something changed?
I've been on v3.1.1 for quite a while, and use several HTTP Request nodes to update HealthChecks.io for a few different things. On v3 these worked without fail, but on v4 they fail with a timeout more often than not. And the timeout always occurs after a second or two, despite setting the timeout period (either using settings.json
or msg.requestTimeout
).
I'm running under docker, and switching back to v3 always works, and then in v4 it fails. If I connect to the container, a "curl" to the url always works on v4. In v3 it generally takes more than a few seconds to return. Anecdotally, it looks like v4 has a 1 or 2 second timeout which isn't being overridden.
The url is of the form https://hc-ping.com/(token).
As shown below it's failing in v4 after a second.
If I switch back to v3 it works after about 16 seconds (my internet seems slow today):
I don't see this behaviour.
I tested this by calling a http endpoint in node-red with a 16s delay.
Http-in -> delay node -> http-response
It worked fine/as expected in node-red v4.0.9 (resolved after 16s).
I even set the equivalent timeout setting in settings.js to 5s and I got a timeout after 5s. I then I overrode it with msg.requestTimeout set to 20000. It resolved correctly after 16s.
Note: this was using node v20 on windows.
Just out of interest, check the DNS resolution time (e.g. run nslookup hc-ping,com
) and see if that takes longer than 2 seconds.
The underlying HTTP library we use is GOT, it is possible that the version used in 4.0.x changed it's timeout for the different stages of the request, rather than the total time.
If you have very slow DNS lookups this could be the cause.
Responding to the above comments:
- I also tried the in-delay-out and that responds as expected.
- The DNS lookup is fast - I run pihole and it is cached. Using an exec code responds immediately.
My internet seems to be happier today, so most of them are coming back straight away. They still sometimes fail though and still before the timeout. I assume there's nothing that a server can respond with to "cause" a timeout early?
I gave up and converted all of these http request nodes to exec nodes just doing a curl. They are working every time.