On 11 Sep 2015, at 23:49, Jacob Champion <champio...@gmail.com> wrote:
> Hi Alex, > > On 09/11/2015 10:02 AM, Alex Bligh wrote: >> mod_proxy_wstunnel forwards the websocket connection without >> interpreting the protocol (i.e. needs to be directed at a websocket >> server); my module (which just plugs into mod_websocket) forwards it >> as a TCP port. EG for VNC over Websockets you'd just need to point my >> module at port 5900, whereas with mod_websocket you'd need something >> further to decode it. > > Oh, neat! I assume there are specific protocol designs that can't be proxied > over WebSocket? (For example, anything that requires the application-level > use of a TCP half-close would presumably be iffy?) What are the sorts of > protocols that work best with this setup? There are some that cannot be proxied directly, but not many due to the prevalence of UNIX 'everything is a file' paradigm. One such example is the guacamole protocol (a bit like VNC) which requires that a guacamole frame travelling toward the client is not split across websockets frames. You will find in the example I sent a processor for that which interprets client-bound data and splits them up into specific frames rather than treating them as a stream. I've not come across any issues with half close, but I suppose that might be an issue. > At this point I want to avoid biting off more than I can chew -- I want to > get the current code in order before absorbing more functionality -- but > this is a really neat idea. I'll need to think about security corner cases > with a generic TCP proxy setup too... more research needed. Sure - I was more thinking to add it as an example. As I say, it's a *user* of your module (well, disconnect's module), not a code change to it. There's probably piles of stuff you can strip out. Oh, and allegedly it doesn't compile on Windows (I wouldn't be able to test that). -- Alex Bligh
