Node: Proxy Protocol native support

[btmdave]

Are there any plans to support Proxy Protocol natively for http/https? There's some wrappers available, but seems like it would be appropriate to offer this as a native solution. Common use case is using ELB's with TCP.

[devsnek]

this would probably need to get wrapped into http-parser (although that would break the name 😉)

/cc @bnoordhuis @ry

[bnoordhuis]

You mean if there are plans to support PROXY, what haproxy speaks? No.

[btmdave]

@bnoordhuis Basically the proxy protocol implementation found here:

Apache: https://roadrunner2.github.io/mod-proxy-protocol/mod_proxy_protocol.html
Nginx: http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_protocol
Lighttpd: https://redmine.lighttpd.net/projects/1/wiki/Docs_ModExtForward (extforward.hap-PROXY)

Essentially enabling to receive the client IP address from proxy connection header.

The reason for this is if behind a load balancer, if you want ssl for 443 to be handled in the underlaying servers (node), you have to use TCP instead of HTTPS. When using TCP, there's no X-Forwarded-Forso it's not possible to receive the client IP, unless there's support for proxy protocol.

[bnoordhuis]

We're talking about the same thing then. No, there are no plans to support it, but you are welcome to come up with a pull request.

[refack]

Put into https://github.com/nodejs/node/projects/13 backlog

[hansott]

@refack @bnoordhuis I don't think there's anyone working on this? I understand this is kind of an exotic feature request since most people will terminate TLS with a web server. If you want to use SNICallback when running node.js in Kubernetes, proxy protocol seems the only option to get the real IP address I think. Currently using https://github.com/findhit/proxywrap to do this... I would love a native solution though. If you're willing to accept a pull request, I'm happy to look into it! If that's the case, can you describe how node.js wants to see this implemented? Thanks!

[bnoordhuis]

@hansott No one's working on this, no. Can you explain why you think built-in support would be better? I expect that Node.js core would take the exact same approach as the module you link to.

[hansott]

Thanks for getting back so quickly Ben!

I think adding native PROXY PROTOCOL support is worth for a few reasons:

• I'm dependent on proxywrap. I will not be able to upgrade to newer versions of Node.js if the package has no support that version (e.g. if the API of https or tls changes)
• The package has no support for the binary version of the protocol
• The internals of the package look quite error prone to me (copying object properties, emitting events, juggling with bytes, ...)
• There's no other way to get the real IP address if you handle TLS with Node.js (You might need this for supporting Cloudflare, Kubernetes without an ingress, ...)
• A lot of web servers have support for this protocol, like mentioned in https://github.com/nodejs/node/issues/17126#issuecomment-345473256
• Things like https://github.com/cloudflare/mmproxy are difficult to use in containers

[bnoordhuis]

Of the reasons you list, most are quality-of-implementation issues with the third-party package, but that isn't a valid reason for inclusion in Node.js core.

The rule of thumb is: if it _can_ be done as a package, it _should_ be done as a package. If the package isn't up to snuff, fix the package. (Or fork it. Or start a better one.)

---

Breaking changes to the https or tls modules isn't a reason per se either. Third-party code that follows the documented behavior has almost zero chance of breaking between major releases.

You can nominate a package for inclusion in citgm so it gets tested regularly against Node.js master.

---

A better argument might be that other languages or runtimes support PROXY out of the box, but I don't think that's the case.

Not that I want to discourage you. You're welcome to open a pull request and see how it's received, but you should be aware that it might get rejected for being too esoteric.

For example, there's no built-in support for SOCKS either, even though that's arguably a much better known protocol than PROXY.