Comments needed: upcoming HTTP Node changes

[Nicholas O'Leary]

Hi,

in our next main release, we plan to update the version of Express we use in Node-RED. The version we use currently, 3.x, is quite old and is no longer getting any fixes by its maintainers.

The move to Express 4.x is fairly straightforward but it isn't an upgrade we can do entirely under the covers without a risk of impacting existing users. The purpose of this email is to both publicise the changes and to get your feedback.

The main place where Express 3.x leaks out to the end user is the msg.req and msg.res properties emitted by the HTTP In node. These properties are the request/response objects generated by Express itself, so with the move to 4.x, these objects inevitably change.

I've said before that the way we expose these objects is one of the things I would do differently if we had the luxury of starting from scratch. This is because these objects are not serializable to JSON, making it impossible to fully encode a message containing them.

With the upgrade to 4.x, we're going to alter these objects to be ones we create ourselves rather than directly expose the Express ones. But to do so, we need to make sure we keep things as backwards compatible as possible.

The proposal is that msg.req will be an object that contains just the cloneable properties of the original request - headers, params, query, body etc. It will not contain any of the functions that the express object exposes.

What I really want feedback on is how any of you make use of msg.res, the response object. It exposes a number of functions for setting how the request is responded to. If you're using the HTTP Response node, chances are you don't touch msg.res yourself. When using the response node, you can set the status code, headers and the body via top-level message properties (msg.statusCode, msg.headers and msg.payload).

So, the question is: do you call any of the functions under msg.res directly? And if so, for what purpose?

We want to get to the point where msg.res is no longer emitted by the node at all and any functionality it exposed can be done by passing appropriate properties to the HTTP Response node. The first step will be to deprecate the functions in the next release (with log messages when calls to the functions are detected), and then remove them entirely in NextRelease+1.

Nick

[Boris Adryan]

I think all I ever needed from msg.res were form values through msg.res.body['xxx']. But I think you're going to cover that case if I understand correctly.

Boris

[Julian Knight]

Agreed. I've never needed to do anything especially clever with either res or req inside NR.

Indeed, I'd say those objects in their raw Express format are an absolute nightmare for anyone not well familiar with JavaScript since they will get you chasing your tail infinitely if you aren't careful! So the choice seems eminently sensible.

[Brian Williams]

One thing we do is pull the client certificate off of the msg.req.socket with code like this:

var cert = msg.req.socket.getPeerCertificate();
if (msg.req.socket.authorized)
  ... do stuff like access cert.subject.CN

Would this still be possible with the changes you propose?

[Nicholas O'Leary]

Hi Brian,

msg.req.socket as it exists today is something we specifically want to remove access to - it is the raw socket object and impossible to serialise.

I need to look more closely at what the socket object provides - it isn't documented as being part of the Express msg.req object, so wasn't part of the plan to maintain. But if there is a good reason to be able to access some of the information it contains - as you've highlighted there is - then we'll need to include it in some form.

As with the msg.req object, we'd only include the cloneable properties - not any of its functions. So getPeerCertificate would not be available. It may be we attach the result of calling the function in its place. Conscious of the overhead this brings, we may expose an option on the node as to whether to include the socket information in the message - for the vast majority of users, it wouldn't be of any use.

Clearly some more thought needed here - thanks for the feedback.

Nick

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nicholas O'Leary]

For those following along at home, the 'next' branch on github, which will soon become the 0.12 release, has been updated to use Express 4. It also includes deprecation warnings if you use any of the functions attached to msg.req and msg.res objects.

If you are already playing with this branch, you'll need to 'npm update' after pulling these changes to get express upgraded.

If you use node-red as an embedded application, you may want to try it out to see if it works as you expect.

Nick

[karthhic Mukil]

hi,

I am new to Node-Red and IOT. I tried Node-Red in my Tablet, i can edit, delete blocks, but i cant able to delete the wiring between two nodes... Is there any way to delete the wiring through touch devices?

Best Regards,
Karthhic

[Nicholas O'Leary]

Hi,

no, that was something that got missed when we added very basic touch support to the UI. I will put it on the list for the next release otherwise I'll keep forgetting to address it.

Apologies for the inconvenience.

Nick

--