18 comments

[ 2.5 ms ] story [ 56.6 ms ] thread
Would be neat to have the ability to forward any TCP connection on port X to host Y port Z.

Maybe could even add the ability to peek into the stream to determine which host to forward to based on protocol (think FTP etc.).

This is only for http but I think you should take a look at Netcat. http://nc110.sourceforge.net/
For 'dumb' (not protocol aware) redirection you can just use iptables, it'll probably be much faster.

For protocol aware redirection, there are various reverse proxies with that ability. TCPMUX was probably one of the firsts, but it requires explicit support by the client. Delegate[1], on the other hand, can identify the protocol and multiplex based on that, IINM.

[1]: http://www.delegate.org/delegate/

  Since bouncy is just parsing the http headers and sending along the raw tcp stream
How does it deal with a second HTTP requests on one kept-alive connection that should be routed to another server?
I guess what I was saying there isn't the whole story, since bouncy uses node's http parser directly to handle splitting up keep-alive requests. What I meant was more that bouncy sends data over a tcp stream instead of simply passing the request object through to an http client request.
Ok, then this is awesome. Also, does it maintain the upstream connections?

E.g. do two requests on one kept-alive connection get translated into two separate requests for the upstream server or will the upstream connection also be kept-alive/reused?

You have to roll this yourself right now with a connection pool of stream objects. I'll probably build this out as a separate module.
Please do. I think there is no (open source) proxy out there that supports this.
What's the advantage of using this over tunneling with SSH?
This software fills the same niche that something like HAProxy or apache virtual hosts fills right now. Bouncy is great for when you have services on your internal network or on different ports and you want to map them to subdomains.
Thanks for your clarification, comparing with existing products. Makes it much easier to understand now. :)
Different thing, no?

This seems to redirect locally. It seems to be more of a dynamic port redirection (the article could've been a little clearer..).

You wouldn't use SSH to redirect stuff from port x on localhost to port y and you couldn't do it dynamically (unless you'd like to spawn ssh for each connection, setting up -L according to header information in the request).

Be awesome if this had a jsgi and/or connect interface to drop in HTTP middleware components for given routes.. is this on your roadmap?
Why would I want to use something like this?
It's handy if you want to map ports or host:port combos to subdomains so they all can share the same port on the same server.
Wouldn't it make more sense to use a reverse proxy like nginx?
Yes. Better still would be a proper health-monitoring load balancer like HAProxy.
It's a cool hack, but if you are going to have a server in front of a web server why not use something like Varnish instead and get caching as well as load balancing.