Re: [hybi] [Uri-review] ws: and wss: schemes

Kristof Zelechovski wrote:
>  1.  Encouraging the user to enter a Web Sockets URL does not make sense if
> cross-domain connections are not allowed, which I hope will be the case (the
> draft specification [1] does not contain security considerations).

It was originally thought XHR (XmlHttpRequest) didn't need to be
cross-domain, but then people thought of lots of reasons why it's
useful and had to use hacks to workaround the limitation, so now
there's a draft standard to support cross-domain XHR - being careful
to address cross-domain security.

I suspect WebSockets could benefit from a look at the mechanisms used
by cross-domain XHR to check for permission to proceed.

>  2.  While we are at it, a Web Sockets connection is useless without knowing
> the protocol, and the protocol to be used is not contained within the URL.
> That means a ws URL is not self-contained and thus useless as a stand-alone
> locator.

The same is true of HTTP.

A HTTP URL does not tell you the type of resource, only where to find
_a_ resource.  For example there are places where a user can enter the
URL of a CalDAV calendar resource.  The CalDAV protocol is used (over
HTTP) to work with that resource, but the URL doesn't say what it is.

The only difference with WebSockets is that it (so far) seems to avoid
any descriptive metadata, which means there will still be applications
which ask for a WebSockets URL, but when the URL is for a different
protocol on top, it'll simply break with undefined behaviour instead
of a clean error message or fallback behaviour.

It doesn't matter if you think nobody should do that.  It will still
be done anyway - because it's so obviously useful.

-- Jamie

Received on Friday, 14 August 2009 21:38:35 UTC