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
