On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch <pya...@gmail.com> wrote: > 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.
Again, the use case here is to enable someone to develop, for example, a browser base mail client which has support for POP/IMAP/SMTP. It's going to be very hard for that email client to get any significant user base if their "install steps" are: 1. Go to awesomeEmail2000.com 2. Contact your mail provider and ask them to install a http server on their mail server 3. There is no step three :) / Jonas