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

Křištof Želechovski <giecrilj@stegny.2a.pl> Fri, 14 August 2009 23:50 UTC

Return-Path: <giecrilj@stegny.2a.pl>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38B43A6884; Fri, 14 Aug 2009 16:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0oxy6GiTGwg; Fri, 14 Aug 2009 16:50:03 -0700 (PDT)
Received: from shark.2a.pl (shark.2a.pl [195.117.102.3]) by core3.amsl.com (Postfix) with ESMTP id 1D9293A6765; Fri, 14 Aug 2009 16:50:02 -0700 (PDT)
Received: from av.2a.pl (av.2a.pl [195.117.102.9]) by shark.2a.pl (Postfix) with ESMTP id 2405A2A6C64; Sat, 15 Aug 2009 01:50:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at 2a.pl
Received: from shark.2a.pl ([195.117.102.3]) by av.2a.pl (av.2a.pl [195.117.102.9]) (amavisd-new, port 10024) with ESMTP id XxwtlozLupvG; Sat, 15 Aug 2009 01:49:59 +0200 (CEST)
Received: from POCZTOWIEC (unknown [10.8.1.26]) by shark.2a.pl (Postfix) with ESMTPA id B2F1A2A6BEA; Sat, 15 Aug 2009 01:49:59 +0200 (CEST)
From: Křištof Želechovski <giecrilj@stegny.2a.pl>
To: 'Jamie Lokier' <jamie@shareable.org>
References: <Pine.LNX.4.62.0908070531430.28566@hixie.dreamhostps.com> <1249651007.25446.8934.camel@dbooth-laptop> <0B450D619CC0486E8BD51C31FBA214AD@POCZTOWIEC> <20090812021926.GC19298@shareable.org> <AB9A0CF094F04D39BC7DC5DEAFF7FC1C@POCZTOWIEC> <20090814213754.GD12021@shareable.org>
Date: Sat, 15 Aug 2009 01:50:01 +0200
Message-ID: <4A34F11EEE154334888DC41B426E6979@POCZTOWIEC>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20090814213754.GD12021@shareable.org>
thread-index: AcodJ4QPXpKWqJt9T3mD7WXZMT9bRgAEX3Cg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: uri-review@ietf.org, hybi@ietf.org, uri@w3.org, 'David Booth' <david@dbooth.org>
Subject: Re: [hybi] [Uri-review] ws: and wss: schemes
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2009 23:50:04 -0000

 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