- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 1 Apr 2015 18:44:13 +0200
- To: Florian Bösch <pyalot@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Domenic Denicola <d@domenic.me>, "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>, public-webapps <public-webapps@w3.org>, Device APIs Working Group <public-device-apis@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, "slightlyoff@chromium.org" <slightlyoff@chromium.org>, "yasskin@gmail.com" <yasskin@gmail.com>
On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch <pyalot@gmail.com> wrote:
> 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.
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
Received on Wednesday, 1 April 2015 16:45:13 UTC