- 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>
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 desirable. Chris -----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; uri@w3.org Subject: Re: [hybi] [Uri-review] ws: and wss: schemes > 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 23:50:46 UTC