Http request node returning error

General
1

A colleague sent me an example flow to obtain data from the Met Office Datahub, which worked fine.
However, using that flow as a template, my version failed, and produced errors that say that the api structure is incorrect, despite the nodes being configure the same. After a lot of testing, I've isolated the problem down to the http request nodes (which again are configured identically).
The request node imported from my colleague works, whilst mine from my palette does not :thinking:

met

Obviously, I'm moving the link between the 2 http request nodes and deploying (to ensure that they are both getting exactly the same input)

The http request nodes are configured the same;

works
works421×621 22 KB

doesnt
doesnt418×626 22.3 KB

The first node produces a valid response, whilst the second has errors;

errors

I can't forum share the flow as it contains my personal api key/secret, but could share to a team member via DM.

2

are you injecting a decimal value (as the message suggests) ?

hmm if you just connect the wire from the first to the second node, yes that would be weird.

3

Yes.
My point is that it works with one http request node, and not the other, despite them both being identically configured.

4

Are you injecting them both at the same time (perhaps hitting API rate limitations?)

5

I'm switching between the 2, and the responses are consistent.
I'm should not be hitting API rate limitations.

6

Are you victim to an object reference changing shape, and being used again in the 2nd call :man_shrugging:

Just a guess

1 Like
7

Upon 2nd thoughts, not likely :sweat_smile:
Highlight each http request node and check the properties in the side bar.

8

Is that in the inject node? If so then edit it to change the key and post the flow. Perhaps there is a subtle difference that does not show in the dialog.

9

No, they are in the change node.
But here's a copy where they have been sanitized, which won't of course work.

[{"id":"fe89dd5d43b6ba32","type":"inject","z":"1543d308b342690a","name":"","props":[{"p":"payload","v":"","vt":"date"},{"p":"topic","v":"","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":2410,"wires":[["c8e007f9979e333b"]],"l":false},{"id":"c8e007f9979e333b","type":"change","z":"1543d308b342690a","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"{\"excludeParameterMetadata\":false,\"includeLocationName\":true,\"latitude\":52.4729210,\"longitude\":-1.0567790}","tot":"json"},{"t":"set","p":"headers","pt":"msg","to":"{\"accept\":\"application/json\",\"x-ibm-client-secret\":\"eb284bCXXXXXXXX3bc\",\"x-ibm-client-id\":\"5f6c295abXXXXXXXXXXXXXXc8b8\"}","tot":"json"},{"t":"set","p":"url","pt":"msg","to":"https://api-metoffice.apiconnect.ibmcloud.com/metoffice/production/v0/forecasts/point/hourly","tot":"str"},{"t":"set","p":"method","pt":"msg","to":"GET","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":300,"y":2410,"wires":[["26566e0283a11c41"]],"l":false,"info":"[https://metoffice.apiconnect.ibmcloud.com/metoffice/production/api](https://metoffice.apiconnect.ibmcloud.com/metoffice/production/api)"},{"id":"26566e0283a11c41","type":"http request","z":"1543d308b342690a","name":"Doesn't work","method":"use","ret":"obj","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":525,"y":2430,"wires":[["da17a2650e86e8df"]]},{"id":"f820f20109811d05","type":"http request","z":"1543d308b342690a","name":"Works","method":"use","ret":"obj","paytoqs":"query","url":"","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":506,"y":2394,"wires":[["da17a2650e86e8df"]]},{"id":"da17a2650e86e8df","type":"debug","z":"1543d308b342690a","name":"debug 22","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":695,"y":2410,"wires":[]}]
10

paytoqs
I think the payload is NOT being appended to the URL

First

Screenshot 2022-11-23 at 12.16.54
Screenshot 2022-11-23 at 12.16.54591×586 27.4 KB

Second

Screenshot 2022-11-23 at 12.17.21
Screenshot 2022-11-23 at 12.17.21579×551 28.6 KB

Set method to GET - then you can select the payload behaviour

11

Yes I also noted the differences in the 2 screenshots (paytoqs).
The GET command is already configured via msg.method in the change node.

12

I think the payload behaviour can only be chosen if the method is known during config.

  • set to GET
  • set to use payload as query
  • deploy
  • then set the method back to msg.method

this is just to allow us to set the payload behavior, and is only revealed when set to GET

13

Thank Marcus, but is that documented anywhere? I've never heard of that, and it sort of defeats the purpose of passing in node properties using messages.

14

Hi @Paul-Reed

It’s what I observed in using it myself.

The paytoqs property controls how the payload should be treated for GET requests.

But from experience, it can only be set in the node config, the problem is, this option is only revealed to the user when the node is set to GET.

You can momentarily set it to GET to get to these options, but I would agree, it might be a slight over look with the editor layout for this node.

15

I think that should be submitted as a node-red issue at Issues · node-red/node-red · GitHub

16
3 Likes
17

If you make the suggested change in your failing node, does it fix it?

18

Yes it did, Marcus is correct.
I've already DM'd the example flow to @Steve-Mcl

19

Excellent, could you mark one Marcus' replies as the solution so the forum will mark it as solved please.

1 Like
20

Weird one, well done Marcus for spotting it.

1 Like