That is indeed weird. The http-request node (currently) uses the "request" NPM library under the cover, and when you look at their readme page you see that they even support credentials embedded in the URL like you do:
I thought we had a similar issue in the past, but cannot remember anymore what the outcome was. And most likely that was on an older version of Node-RED, where the http-request node was using the follow-redirects NPM library underneath ...
P.S. But to make sure, which version of Node-RED are you using?
Hey Mike,
I would indeed upgrade, but now I'm not sure if your problems is going to be solved. If you have a look at the Node-RED changelog, you will see that the httprequest node uses the "request" library since 0.19.0:
HTTP Request: Move to request module
And there is another problem. I wrote some time ago the node-red-contrib-http-logger to see which http request is being send underneath. However that node doesn't work anymore with newer NodeJs versions. Have been working on it this week, but my new version isn't complete yet. But perhaps it works on your NodeJs version, and then you can see what is being send. Perhaps you can see something strange ...
Some more data. I'm not bad at gathering Wireshare data. I'm bad at reading it.
Here is a successful http-request from chrome:
GET /status.xml HTTP/1.1
Host: 192.168.110.12
Connection: keep-alive
Cache-Control: max-age=0
Authorization: Basic YTph
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
DNT: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
HTTP/1.1 200 OK
Connection: close
Content-Type: text/xml
Cache-Control: no-cache
<response>
blah blah blah and off we go with the xml data.
This is the failing request from NodeRed
GET /status.xml HTTP/1.1
host: 192.168.110.12
Connection: close
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Protected"
Connection: close
Mike,
I'm not a security expert, but in this older post there was a rather similar problem.
Could it be that your web switch also uses digest authentication instead of basic authentication? Both methods require a username and password. But the request library uses basic authentication, unless it is specified explicit that digest authentication is required.
If you update to the latest Node-RED version, then your http-request node will support Digest Authentication:
Would be nice if you could test whether that solves the problem!
Have you found out more about this?
I am brand new to Node-Red and running into the exact same issue.
I am trying to pull data from a device. The curl version works perfectly but not the http-request node runs into an authentication error. Exactly as you describe.