On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking <jonas@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.