I'm designing a front-end on Node-RED dashboard which interfaces with a soap API backend that at first it requires an API login in order perform subsequent API requests. The backed-end expect me to first send the credentials to the url http://10.10.10.10:8888/, then it reply with a new URL in the locaiton header (sample response http://10.10.10.10:8888/lskdh234hv02n), this new URL I must use in the next API requets.
In order to use the newly provided URL by the response, the first HTTP request should keep the initial HTTP request tcp connection open by using keep-alive property, however this is not happening when sending HTTP request from the "http request" node on Node-RED. I confirmed this using wireshark and compared the capture with another capture doing same API requests with postman.
I also tried to inject the header "connection: keep-alive" in the before the http request node, however Node-Red is overwriting this header value with "connection: close\r\n" specifically. It seems like the HTTP request node is not maintaining persistent connection.
Here is what I'm injecting before the http request node to enfore the connection header:
msg.headers = {
"connection" : "keep-alive",
"my-custom-header": "samplevalue",
"User-Agent": "My User Agent"
}
return msg;
Actually regardless the connection header is set to keep-alive or close, I always see the FIN flag in the TCP connection initiated by Node-RED (not the server). It seems like Node-RED is not maintaining HTTP connections eventhough the keep-alive header.
Now I start to think that Node-RED http requets node is not allowing http connection reuse (persistant http connection) and I'm wondering whether there is a workaround on Node-RED to allow it or some settings on Node-RED itself to make it capable of maintaining persistent connection?
Hello, I am wondering the same thing. I want to automate a login. On the website a key is in the main page and just for a POST request after you submit the login. My quess is that after my first GET action to retrieve the key the "login page" closes and on the backend the key is not valid anymore so the POST uses an old key. Could this be happening?
Did you solve it or can you suggest me some tools to look what is happening?
actually, I just opened a post regarding my case with more info. If needed it is here
Hello, I am wondering the same thing. I want to automate login. On the website, a key is on the main page and just for a POST request after you submit the login. My guess is that after my first GET action to retrieve the key the "login page" closes and on the backend, the key is not valid anymore so the POST uses an old key. Could this be happening?
Yes, sounds similar to an issue I faced before and found that keep-alive was not handled by default on node-red http-request module.
Did you solve it or can you suggest some tools to look at what is happening?
Yes, managed to solve it by code update on the HTTP request function.
Then I submitted a pull request and got the keep-alive feature merged in the dev branch. I suggest installing the new version of node-red and see if you will find the options of enabling the connection keep-alive.
You can expect to see an option to keep-alive on the new http-request. In your case, you will need to tick the box of Enable connection keep-alive and then try to login to your router followed by your post request.
Hope this will solve your problem. Let me know should you need further help.
Thanks for the fast reply. I now use the "enable connection keep-alive" function but as your previous observation in the output of the node is still shows "connection : close".
Do I have an old version of the node and if I understand correctly is the function fixed by your PR in a current release to keep the connection open? (my current node red version = 1.0.6)
Can you do Wireshark trace and see if your connection is kept alive or not?
This will confirm if the connection keep-alive is on, by observing continuous TCP connections from your node-red host toward your router of the same source and destination port going back and forth.
Hello @Ibrahim.nezar I have similar problem - in my case service is not correctly handling request when there is "connection: Close" header present. Is there any way to not send it by default?
Hi @Ibrahim.nezar
I performed following tests: curl -H "Connection: close" http://myservice/myendpoint - not working curl -H "Connection: keep-alive" http://myservice/myendpoint - not working curl http://myservice/myendpoint - working
I know it is strange behaviour but this is actually proprietary hardware device providing http interface.
It looks like your proprietary hardware doesn't like extra headers and that's clear in your first two tests. You could tell this because the curl -v http://myservice/myendpoint shows no carriage of header connection in the debug message.
When I checked the http-request node-red module, I found it using the "request" library behind the curtain to perform http/https requests and apparently this library is adding the header 'Connection: close' no matter you add or delete headers from the node-red or even when using it directly from any javascript code on a different compiler.
Perhaps you should try the exec module on node-red to perform the curl command for you and return the output, then parse it with a function.
