Re: [hybi] workability (or otherwise) of HTTP upgrade

"Pat McManus @Mozilla" <mcmanus@ducksong.com> Thu, 09 December 2010 14:44 UTC

Return-Path: <mcmanus@ducksong.com>
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 96B0328C10A for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 06:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 y1P9Z017O3m3 for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 06:44:05 -0800 (PST)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id CD85928C0FF for <hybi@ietf.org>; Thu, 9 Dec 2010 06:43:48 -0800 (PST)
Received: by linode.ducksong.com (Postfix, from userid 1000) id D4E0C10157; Thu, 9 Dec 2010 09:45:17 -0500 (EST)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id BAF4A10300 for <hybi@ietf.org>; Thu, 9 Dec 2010 09:45:12 -0500 (EST)
From: "Pat McManus @Mozilla" <mcmanus@ducksong.com>
To: hybi <hybi@ietf.org>
In-Reply-To: <20C2FBB9-901F-4235-AF23-EC8262585905@mnot.net>
References: <BB947F6D-15AA-455D-B830-5E12C80C1ACD@mnot.net> <81870DB1-B177-4253-8233-52C4168BE99D@apple.com> <F4D1B715-3606-4E9A-BFB2-8B7BC11BE331@mnot.net> <57D4B885-B1D8-482F-8747-6460C0FFF166@apple.com> <37A00E8D-B55C-49AD-A85C-A299C80FFF17@mnot.net> <4F2580A7-79C2-4B0A-BCE5-7FB6D9AA0ED7@apple.com> <BB31C4AB95A70042A256109D461991260583956C@XCH117CNC.rim.net> <EA41A6C7-971C-4EC8-AA6F-96363B7FDC4C@gmail.com> <73E53F19-E0E7-4ADB-B765-ABAF0B4A6736@mnot.net> <r2f0g6d7bj770kg0db5ptr027ninmckns8@hive.bjoern.hoehrmann.de> <20C2FBB9-901F-4235-AF23-EC8262585905@mnot.net>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 09 Dec 2010 09:45:41 -0500
Message-ID: <1291905941.2315.2113.camel@ds9.ducksong.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
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, 09 Dec 2010 14:44:06 -0000

On Thu, 2010-12-09 at 14:30 +1100, Mark Nottingham wrote:

> 
> I still haven't seen anyone explain why CONNECT is better than, say,
> WEBSOCKET_PLEASE.

I think WEBSOCKET_PLEASE and GET/POST+Upgrade share a concern that an
implementation will have to deal with them in a path dedicated to
"things I don't understand". A reasonable path for a proxy is to just
forward it on as if it were any other message - and we haven't broken
the message parsing rules so this will appear to work just fine. It is a
pragmatic concern, not one based strictly on the specification.

WEBSOCKET_PLEASE feels a bit better in that an unknown method is a
stronger bit of breakage than an unknown header, but I'm not comfortable
with it.

CONNECT is different in that it is more reasonable to assume it doesn't
show up in the proxy list of "things I don't understand". If nothing
else has made them aware viruses have done so. A new method will of
course be unknown, and Upgrade has almost no visibility on the net so it
too might be unknown - but CONNECT is much closer to the core services
and dates back a lot longer than Upgrade. We aren't relying on the
handling of CONNECT being unknown, at least as a first line of defense.

If we going with a port/80/http handshake I still support the "CONNECT
to invalid" approach. I haven't seen anything to suggest real problems
with it and there is evidence to believe it will work.

That being said, I've always preferred that WebSockets not be HTTP/80
based at all - but the group had really reached consensus on that topic
and I believe in working forward within that consensus. I think the
minutes say the "focus will be on leveraging HTTP infrastructure" while
noting that it doesn't actually preclude the group from looking at other
alternatives - but I read the clear sense of the group as wanting to
base WebSockets on the one-true-port.

I am in favor of revisiting the non HTTP approach, but I don't think
there will be agreement on it. And lacking agreement, I think CONNECT is
workable and a way forward to make some progress.

-Patrick

-- 
http://www.getfirefox.com/