httpNodeMiddleware in settings

[marcus-j-davies]

Hey 👋

I am in the middle of evaluating FlowForge With around 5 Node RED Instances.
so far all is great!

But I have run into a hurdle.

One of our legacy systems has broken mime types when POSTing data to Node RED, this is a 3rd party system, and is no longer supported.

application/xml -> xml
application/json-> json

Therefore in Node RED, I add middleware to correct it, before it reaches the HTTP in node, else we get TypeError: invalid media type
which is to be expected.

httpNodeMiddleware: function(req, res, next) {

    if (req.headers['content-type']) {
        const ContentType = req.headers['content-type'];
        if (ContentType === 'xml' || ContentType === 'json') {
            req.headers['content-type'] = `application/${ContentType}`;
        }
    }

    next();
},

Is there a way to do this in FlowForge?
If its on the todo, is there an interim measure one can take?

I have recently posted questions on The forums, and didn't want to start spamming it with various questions.

[hardillb]

Hi,

There isn't currently a way to include user supplied custom middleware with FlowForge.

It's not something on our current roadmap, but we can look at if it would make sense (no promises on if/when at this point)

Unfortunately I don't think there any other options from a Node-RED point of view as the content-type needs fixing before it gets passed to the parser which is already in the middleware queue.

A really hacky/nasty solution would be to point the broken app at a small proxy that can fix the header before forwarding the request to Node-RED.

[marcus-j-davies]

Hi @hardillb

Thanks for the reply.

No worries, but if an opportunity arises to review it - that will be great.
Presently, I opted for the filthy, dirty route.

I implemented a proxy inside Node RED itself - and it actually runs great (I set the TCP out node as a Reply)
and set all TCP nodes as streams

This is just a test - but currently is having the affect I need.
I will correct the content-type header in the function node (or Change node).

[hardillb]

Cool,

Just a quick notes, the reason I didn't suggest doing it in NR is because the TCP nodes are only available with the localfs build of FlowForge. They will not work with Docker/Kubernetes because the projects are exposed via a reverse HTTP proxy (hence why we need DNS entries to do virtual host routing)

For LocalFS this looks like it will work well, but for the other drivers a little standalone app shouldn't be too hard as I think there are a few node packages that let you build full http proxies with some intercept modification options.

I have raised a feature request to cover adding middleware.

#1693

Ben

[marcus-j-davies]

Noted! Thanks @hardillb

[knolleary]

To be honest, I think we should look at addressing this in Node-RED.

Having the HTTP In nodes better handle malformed requests would be more widely useful without users having to know anything about middlewares.

I also have reservations around the security consequences of allows arbitrary code get added at the middleware level.

[marcus-j-davies]

Having some leniency within the HTTP in node, will always be much more welcoming.
maybe adding a user modifiable setting in the Node 'strict content-type' or something to that affect.

I guess it needs to be very specific on what header(s) its tolerant on, at least make sure its a half decent http request that can be parsed, i.e. at least make sure it has a content-length for POSTS etc etc.

the content-type can be overlooked at least - most users know what the incoming type is