Curl POST command returns a 404 but 'http request' POST returns a 200

General
1

BACKGROUND:
I'm playing with ticktickDB (a time series database) which I have installed and running on a PI 2 model B (I've documented the install process but not posted it yet) and tying to get it to work with NR.

While trying to get it to work in NR I ran into a problem: no data was being saved. I'm using an http request node to send (POST) the data to the DB but ran into a problem. The data wasn't being posted but I kept getting a 200 as the return code.

{
  "time2": 1696264444,
  "payload": "",
  "put": "d 'put pressure 1696264444 1012 location=Office'",
  "_msgid": "c1c28e0c17edfccb",
  "statusCode": 200,
  "headers": {
    "content-length": "0",
    "content-type": "text/plain",
    "x-node-red-request-node": "4717b58c"
  },
  "responseUrl": "http://192.168.1.197:6182/api/put",
  "redirectList": [
  ],
  "retry": 0
}

When I used an http request node to send the data I got a 404:

*   Trying 192.168.1.197:6182...
* Connected to 192.168.1.197 (192.168.1.197) port 6182 (#0)
> GET /api/put HTTP/1.1
> Host: 192.168.1.197:6182
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Content-Length: 0
< Content-Type: text/plain
< 
* Connection #0 to host 192.168.1.197 left intact
* Could not resolve host: d
* Closing connection 1
curl: (6) Could not resolve host: d
* Closing connection -1
curl: (3) URL using bad/illegal format or missing URL

After a lot of hair pulling, I discovered the issue, a missing- (!&@^#%) I was sending:
d 'put pressure 1696264444 1012 location=Office'
but it needed to be (note the added '-' at the beginning)
-d 'put pressure 1696264444 1012 location=Office'

Shouldn't the http request node be returning a 404?

2

No. the -d tells curl "the next bit is data" - without it (depending on how the curl was structured) it was probably trying to access a server with the address d
image

Where as in Node-RED, the payload IS data (the -d is implicit / not required). The fact the d was present in the payload is imaterial (and up to the server to reject it with a suitable error - if the server cared enough or was strict enough about the "d" in the payload you would have (probably) gotten a 400 Bad Request

3

Well that's good to know but I still think it should have returned something other than a 200. If I run the curl without the dash I get the 404 Not Found.

So shouldn't node-red catch it as an error?

4

404 means "not found" so when you run curl without the - it THINKS you want to access URL "d" - I.E. curl is trying to access a NON existent end point. In short - your request goes nowhere (because d is not an end point)

Try yourself curl d - you will get what i did

Node-red succeeds because the URL is correct. It is the end device that responds 200 (nothing to do with Node-RED)

5

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.