On 11/03/2015 04:32 AM, Daniel P. Berrange wrote: > On Fri, Oct 30, 2015 at 03:52:56PM -0500, Jeremy White wrote: >> We do this by auto detecting the inbound http(s) 'GET' and probing >> for a well formulated WebSocket binary connection, such as used >> by the spice-html5 client. If detected, we implement a set of >> cover functions that abstract the read/write/writev functions, >> in a fashion similar to the SASL implemented. > > I'm not really a huge fan of overloading two protocols on the > same socket in this way. Yeah, I see your unease, but I still think the approach I've chosen is the best option. > > I'd be rather inclined to have a separate port open for the > websockets protocol, in the same way that QEMU does the VNC > server. I think the more apt analogy is the SASL layer, which, afaik, is not inherently a different protocol, but a layer on top of the core protocol. I believe my proposed implementation implements WebSocket support the way we support SASL. > > Admins should be able to choose which protocol is available > to their clients. For example, they might launch QEMU with > both protocols available, but only wish to make one of the > protocols available to the public internet. By overloading > both protocols on the same port, you prevent them from > being able todo this in firewall rules. I'm a fan of choice, although option overload becomes an issue. But I find myself hard pressed to imagine someone wanting to have the regular protocol open but not the WebSocket protocol. If the regular port is open, an evil doer can easily use websockify to get in anyway. Further, you start to get a combinatorial problem. What you're proposing would add a --websocket-port option, but then it also requires a --websocket-secure-port. And if we implement SASL over WebSocket... Cheers, Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel