Global context variable in http request headers?

[ThingsTinkerer]

Is it possible to use context variables in http request header fields?

Like this:

Because I can't get it to work (results in 401 unauthorized). Instead, I add msg.token in a function node before http request to get the token from global context.

I thought all fields could take context variables? Can HTTP request headers take them?

[Steve-Mcl]

@ThingsTinkerer

Is it possible to use context variables in http request header fields?

Yes. several ways. Easiest is use a change node BEFORE the http request and set msg.xxx to global.yyy then set the header option to msg. and enter xxx (use better names)

Alternatively, dont add any headers in the dialog and set them up in a function node

msg.headers = {
   "my-header": global.get("my-value")
}
return msg

[ThingsTinkerer]

Yeah that's what I've done, using the function node beforehand. So no way of using context variables directly? I thought this was a feature in some nodes.

msg.token = global.get("TOKEN");
return msg;

Then add msg.token to header field in http request node.

This is extra node and extra code to extract the value, instead of simply using it directly in the http request node. Hoped there was a way to do this with less code (less code is usually better code)

Ideally, the http request node would have an option like this:

source:
Variables in edit fields - General - Node-RED Forum (nodered.org)

[Steve-Mcl]

@ThingsTinkerer

So no way of using context variables directly? I thought this was a feature in some nodes.

In some nodes yes. When this feature was added, it was decided not to support anything other than msg.

@ThingsTinkerer

Ideally, the http request node would have an option like this

I am on the fence here. Historically, I would have said "yeah, lets add every option, cos options are good" however, I am slowly learning that presenting too many options is not always the best course of action. As it stands, this is a very clean interface as it is and TBH, it is not terribly difficult to prepare your headers atomically in a node beforehand.

PS, by "I am on the fence here" I mean - if lots of folk request this, I personally wouldnt block more things being added to the typed input on the RH side on this node.

[ThingsTinkerer]

Yeah I guess the downsides is presenting all the options in GUI. Because in code you always have all these options available. So it's a matter between more GUI options vs more nodes/code.