4 ms·

Does the backend which nginx talks to have to speak the Websocket protocol? If this is the case, and you're running a pure TCP application like IRC, you still

by csense 14y ago

Does the backend which nginx talks to have to speak the Websocket protocol? If this is the case, and you're running a pure TCP application like IRC, you still need a separate Websocket-to-TCP bridge application running on the server to sit between nginx and your IRC server. How is this an improvement from the status quo? ("IRC" is just an example, you can feel free to replace it with your favorite protocol.) Granted, this change makes life a little easier for users behind outbound-restricting firewalls, since you can now multiplex both HTTP and IRC on port 80. But IMHO it would be more logical to just have nginx directly proxy the IRC server to the client-side JS over Websocket. Then again, maybe this patch is as close as it's possible to get without major revisions to the Websocket protocol: With Websocket's non-optional framing "feature," you might need IRC-specific knowledge to translate an IRC stream into frames in a way that won't break anything. Any Websocket experts are welcome to weigh in!

jcheng 14y ago
The changes to nginx appear to be to support HTTP Upgrade in general, nothing specific for websockets. But I can't think of any other upgrade protocols that general purpose web browsers would give your JS code access to. But for those of us who are writing websockets-enabled web applications and trying to run them in nginx-heavy environments, just being able to share a port is a significant improvement over the status quo!
rdtsc 14y ago
> Does the backend which nginx talks to have to speak the Websocket protocol? Isn't that what the "supporting websockets for the proxying layer" statement means? I don't even know why you'd expect anything else to happen. > it would be more logical to just have nginx directly proxy the IRC server to the client-side JS over Websocket. Again, I don't see the logic there at all. There is a TCP proxy external module you can compile in (and that was how you'd get it to proxy websocket connection before). But you want nginx to proxy and arbitrarily translate between some random protocol and transport of your choice. > With Websocket's non-optional framing "feature," you might need IRC-specific knowledge to translate an IRC stream into frames in a way that won't break anything. Yes framing is a feature. Why are you including in quotes sarcastically implying it is a bad feature. It sounds like you just need a firewall with some rules, if you just want plain TCP connections to be forwarded to your backend, why involve a nginx at all then?
- csense 14y ago
  I was thinking that a prominent use-case for JS websockets would be writing a JS client for $PROTOCOL which runs in the browser, where $PROTOCOL is some TCP-based protocol like IRC that was developed years before websockets existed. > Why are you including in quotes sarcastically Because framing means the websocket spec can't easily support this use case. > if you just want plain TCP connections to be forwarded to your backend That's exactly what I want -- from a Javascript client in an unmodified browser. AFAIK I can't get such connections in JS clients; I can only get the Websocket protocol. I was thinking some cool hacks become possible if you could talk to an arbitrary TCP server from JS, using nginx as the middleman (with all its scalable non-blocking goodness). Too bad Java is going the way of the dodo; Java applets could do TCP connections to the same origin back in the '90s.
  - rdtsc 14y ago
    > writing a JS client for $PROTOCOL which runs in the browser, where $PROTOCOL is some TCP-based protocol like IRC that was developed years before websockets existed. Yes that would be cool. Websockets make it doable. Framing is not as big of an issue. Most TCP based protocols (save for file streaming) already have some messaging at a higher level. In IRC you can think of the line as a message. Almost every protocol I built on top of the TCP transport had to have framing and I had to mess with buffers, message headers, terminators, partially filled messages. > I can only get the Websocket protocol. One cool new feature is WebRTC it should support a datachannel connections and peer-to-peer (now you can make the web server a peer as well). So there it seems would be another case of streaming binary data to the server. > I was thinking some cool hacks become possible if you could talk to an arbitrary TCP server from JS, Yeah that would be cool. JS code would instead have to dealt with websockets or WebRTC data channels. It wouldn't open a TCP, socket, bind, listen, connect all those things. Now on the server side you can anything you want. For example I like the web STOMP adopter that RabbitMQ people have. You can effectively send and receive MQ (STOMP) messages from a browswer to an exchange. That is cool. There are VNC viewers built with websockets and canvas. So it is doable but I don't think its place is to put in nginx as a standard compiled in features. These all can be plugins.

by csense 14y ago

jcheng 14y ago

The changes to nginx appear to be to support HTTP Upgrade in general, nothing specific for websockets. But I can't think of any other upgrade protocols that general purpose web browsers would give your JS code access to. But for those of us who are writing websockets-enabled web applications and trying to run them in nginx-heavy environments, just being able to share a port is a significant improvement over the status quo!

rdtsc 14y ago

> Does the backend which nginx talks to have to speak the Websocket protocol? Isn't that what the "supporting websockets for the proxying layer" statement means? I don't even know why you'd expect anything else to happen. > it would be more logical to just have nginx directly proxy the IRC server to the client-side JS over Websocket. Again, I don't see the logic there at all. There is a TCP proxy external module you can compile in (and that was how you'd get it to proxy websocket connection before). But you want nginx to proxy and arbitrarily translate between some random protocol and transport of your choice. > With Websocket's non-optional framing "feature," you might need IRC-specific knowledge to translate an IRC stream into frames in a way that won't break anything. Yes framing is a feature. Why are you including in quotes sarcastically implying it is a bad feature. It sounds like you just need a firewall with some rules, if you just want plain TCP connections to be forwarded to your backend, why involve a nginx at all then?

csense 14y ago
I was thinking that a prominent use-case for JS websockets would be writing a JS client for $PROTOCOL which runs in the browser, where $PROTOCOL is some TCP-based protocol like IRC that was developed years before websockets existed. > Why are you including in quotes sarcastically Because framing means the websocket spec can't easily support this use case. > if you just want plain TCP connections to be forwarded to your backend That's exactly what I want -- from a Javascript client in an unmodified browser. AFAIK I can't get such connections in JS clients; I can only get the Websocket protocol. I was thinking some cool hacks become possible if you could talk to an arbitrary TCP server from JS, using nginx as the middleman (with all its scalable non-blocking goodness). Too bad Java is going the way of the dodo; Java applets could do TCP connections to the same origin back in the '90s.
- rdtsc 14y ago
  > writing a JS client for $PROTOCOL which runs in the browser, where $PROTOCOL is some TCP-based protocol like IRC that was developed years before websockets existed. Yes that would be cool. Websockets make it doable. Framing is not as big of an issue. Most TCP based protocols (save for file streaming) already have some messaging at a higher level. In IRC you can think of the line as a message. Almost every protocol I built on top of the TCP transport had to have framing and I had to mess with buffers, message headers, terminators, partially filled messages. > I can only get the Websocket protocol. One cool new feature is WebRTC it should support a datachannel connections and peer-to-peer (now you can make the web server a peer as well). So there it seems would be another case of streaming binary data to the server. > I was thinking some cool hacks become possible if you could talk to an arbitrary TCP server from JS, Yeah that would be cool. JS code would instead have to dealt with websockets or WebRTC data channels. It wouldn't open a TCP, socket, bind, listen, connect all those things. Now on the server side you can anything you want. For example I like the web STOMP adopter that RabbitMQ people have. You can effectively send and receive MQ (STOMP) messages from a browswer to an exchange. That is cool. There are VNC viewers built with websockets and canvas. So it is doable but I don't think its place is to put in nginx as a standard compiled in features. These all can be plugins.