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

Jamie Lokier <jamie@shareable.org> Thu, 20 August 2009 19:02 UTC

Return-Path: <jamie@shareable.org>
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 52A9E3A6A0C for <hybi@core3.amsl.com>; Thu, 20 Aug 2009 12:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.064
X-Spam-Level:
X-Spam-Status: No, score=-4.064 tagged_above=-999 required=5 tests=[AWL=-1.465, BAYES_00=-2.599]
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 1o5jkVBgIp+O for <hybi@core3.amsl.com>; Thu, 20 Aug 2009 12:01:59 -0700 (PDT)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 50DBD3A689E for <hybi@ietf.org>; Thu, 20 Aug 2009 12:01:59 -0700 (PDT)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1MeCtZ-0001wu-QH; Thu, 20 Aug 2009 20:01:57 +0100
Date: Thu, 20 Aug 2009 20:01:57 +0100
From: Jamie Lokier <jamie@shareable.org>
To: noah_mendelsohn@us.ibm.com
Message-ID: <20090820190157.GB6066@shareable.org>
References: <20090820005933.GA14005@shareable.org> <OF8D5BA760.E7D4B460-ON85257618.0058E88A-85257618.005AD481@lotus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <OF8D5BA760.E7D4B460-ON85257618.0058E88A-85257618.005AD481@lotus.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: hybi@ietf.org, URI <uri@w3.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: Thu, 20 Aug 2009 19:02:00 -0000

noah_mendelsohn@us.ibm.com wrote:
 If the server (I.e. the same software that would have 
> processed the Web socket upgrade) chooses to, it can respond with metadata 
> explaining that this is a Websocket resource, perhaps providing 
> information about its purpose and correct use, etc.  The means for 
> returning that metadata might be along the lines of [1].  That 
> discoverability seems to have some value. 

Hey, I like that idea.  Wish I'd thought of it :-)

For round-trip reduction I favour being able to try an upgrade
request, with your own optional headers, and have the server reject it
if it doesn't see what it wants, perhaps referrring to the information
you've described.  It also leaves the door for servers to respond with
different protocols depending on the request - in the same way as SSH1
and SSH2 are negotiated, for example, without needing extra round-trips.

That looks a *lot* like HTTP negotiation, and people are very
familiar with that.  Servers have good support for it too.

> Web socket endpoints are not documents (or "Information Resources"
> [2] in the language of AWWW), suggesting that new schemes are indeed
> appropriate;

I agree.

A comet server on http://cometd.org.example/cometd.cgi?protocol=bayeux
(example may not be realistic) is not a document in any useful sense
either.  Where are we going with this?  Should that become a legacy
hack?  Should we have a different scheme for all
"protocol-over-HTTP-misused-as-a-transport"?

> 2) (happy accident) 

> I suspect the choice of an HTTP-compatible handshake was made to get
> through firewalls,

I suspect it was so that it could connect to random servers and get a
useful error message if they don't support WebSockets (that has been
explained on the hybi list), and to connect to servers which are
handling HTTP on the same port.

For getting through firewalls - including ISPs who don't firewall but
are running intercepting proxies on port 80 - I think it's basically
going to fail at that because it doesn't consider proxy issues at all
- and because UPGRADE has never been deployed (as far as I know).  But
to be honest I don't know if it'll fail as much as I think in the real
world without measurements from a wide range of internet locations.
I'm not the only person who thinks so, though.

-- Jamie