Supporting wss:// and https:// protocol

[snowmantw]

I did some modifications in my forked project, but they're all dirty hack. So, maybe @dhruvbird can support them officially ?

What I modified:

• https-server.js: Copy http-server.js and add cert/key options in it. Now we have HTTPServer and HTTPSServer...
• bosh.js & main.js: Create HTTPSServer while cert/key options given.
• options flow: Some options detecting and loading cert steps in several files.
• run-server.js: Options and tips ( ws:// -> wss:// ; http:// -> https:// )

[dhruvbird]

@snowmantw Thanks for the patch.

Some thoughts:

1. TLS processing is heavy, so my initial idea was not to include TLS endpoints. If you do want them, put NXB behind apache or nginx. Either ways, you probably have a web-site that apache/nginx is serving, so you'll have these set up.
2. I can add this to a TLS branch for sure.
3. Depending on how many (or badly) people want this change, it could go on master.

[sonnyp]

@dhruvbird any reason why TLS processing would be particularly heavy for node-xmpp-bosh/Node.js?

[dhruvbird]

@sonnyp My reasons are not founded in numbers (they should ideally be), but it seems that people have casually mentioned that TLS processing is heavy. This is especially bad if you're running on a single CPU (which we are). Plus, I would expect a production deployment to have nginx or some other reverse proxy to handle gzip and TLS termination. Plus it makes it easy to manage TLS certs. if done that way rather than having everyone update SSL certs. at the node.js application layer.

Hey, I could be totally wrong, and these might not be valid deployment concerns - just saying based on conversations I've had with the ops. folks at my previous org.

[sonnyp]

@dhruvbird We proxy the traffic using haproxy, I was interested in technical implications and your arguments against performances make sense.

[dhruvbird]

@sonnyp (y) - let me know if you have any numbers online suggesting that it is a bad idea since profiling before concluding is a good idea. We didn't have a pressing need to support TLS on http/ws since we were deploying stuff behind nginx/elastic-LB since https termination almost always happened elsewhere... Good to know that you guys also use a proxy in front of node.js.