On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> Not saying that we can use CORS to solve this, or that we should > extend CORS to solve this. My point is that CORS works because it was > specified and implemented across browsers. If we'd do something like > what Domenic proposes, I think that would be true here too. > > However, in my experience the use case for the TCPSocket and UDPSocket > APIs is to connect to existing hardware and software systems. Like > printers or mail servers. Server-side opt-in is generally not possible > for them. > Isn't the problem that these existing systems can't be changed (let's say an IRC server) to support say WebSockets, and thus it'd be convenient to be able to TCP to it. I think that is something CORS-like could actually solve. You could deploy (on the same origin) a webserver that handles the opt-in for that origin/port/protocol and then the webserver can open a connection to it. For example: var socket = new Socket(); socket.connect('example.com', 194); -> RAW-SOCKET-OPTIONS HTTP/1.1 port: 194 host: example.com -> HTTP/1.1 200 OK Access-Control-Allow-Origin: example.com -> browser opens a TCP connection to example.com 194. So you don't need to upgrade the existing system for server authorization. You just need to deploy a (http compatible) authorative source on the same origin that can give a browser the answer it desires.