W3C home > Mailing lists > Public > uri@w3.org > August 2009

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

From: Køištof Želechovski <giecrilj@stegny.2a.pl>
Date: Sat, 15 Aug 2009 01:50:01 +0200
To: "'Jamie Lokier'" <jamie@shareable.org>
Cc: "'David Booth'" <david@dbooth.org>, "'Ian Hickson'" <ian@hixie.ch>, <uri-review@ietf.org>, <hybi@ietf.org>, <uri@w3.org>
Message-ID: <4A34F11EEE154334888DC41B426E6979@POCZTOWIEC>
 1.  Maybe it is just me but I cannot see how breaking with undefined
behavior could be obviously useful.  Undefined behavior might as well amount
to accidentally starting WW III.
 2.  If we do not want spiders to connect to Web sockets, it seems using a
special URL scheme is a way to prevent this, and therefore it would be

-----Original Message-----
From: Jamie Lokier [mailto:jamie@shareable.org] 
Sent: Friday, August 14, 2009 11:38 PM
To: Kristof Zelechovski
Cc: 'David Booth'; 'Ian Hickson'; uri-review@ietf.org; hybi@ietf.org;
Subject: Re: [hybi] [Uri-review] ws: and wss: schemes

>  2.  While we are at it, a Web Sockets connection is useless without
> 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
> 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 23:50:46 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:52 UTC