Re: [hybi] workability (or otherwise) of HTTP upgrade
Greg Wilkins <gregw@webtide.com> Fri, 26 November 2010 12:54 UTC
Return-Path: <gregw@webtide.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 5463B3A6AF5 for <hybi@core3.amsl.com>; Fri, 26 Nov 2010 04:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.781
X-Spam-Level:
X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 J3UqqSyRm79q for <hybi@core3.amsl.com>; Fri, 26 Nov 2010 04:54:55 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 37C333A6AFB for <hybi@ietf.org>; Fri, 26 Nov 2010 04:54:55 -0800 (PST)
Received: by ywh2 with SMTP id 2so924746ywh.31 for <hybi@ietf.org>; Fri, 26 Nov 2010 04:55:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.34.1 with SMTP id h1mr1609443anh.188.1290776158343; Fri, 26 Nov 2010 04:55:58 -0800 (PST)
Received: by 10.236.42.204 with HTTP; Fri, 26 Nov 2010 04:55:58 -0800 (PST)
In-Reply-To: <20101126000352.ad396b9a.eric@bisonsystems.net>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <20101126000352.ad396b9a.eric@bisonsystems.net>
Date: Fri, 26 Nov 2010 23:55:58 +1100
Message-ID: <AANLkTimzQyG4hugOvHqoNrBrZFA4fGbGXQ7MZ2i+68dO@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: "Eric J. Bowman" <eric@bisonsystems.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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: Fri, 26 Nov 2010 12:54:56 -0000
On 26 November 2010 18:03, Eric J. Bowman <eric@bisonsystems.net> wrote: > What about: 3) Use another port? I've seen that opinion voiced, so I > haven't signed up to the hybi list to voice it myself. No criticism of > Web Sockets is intended or implied here, it's just a concrete example of > something which increasingly concerns me regarding Upgrade. The problem with another port, is that the success rate of opening an arbitrary port through firewalls is not that high. Thus if websocket was allocated it's own sockets, then there would still be need for a websocket over 80 protocol (eg like there is BOSH for XMPP). I would like to see a dedicated port for websocket so that over time it could be opened as needed, but I think there will be a desire to function over 80 for some time to come. This could be done with some enhanced HTTP (eg SPDY), but I'm not sure if such a protocol would match all the features of websocket (eg improved data density), nor fit with your HTTP-like restrictions described below. > It's perhaps fundamentally flawed for HTTP to be the handshake mechanism > for protocols that are not even remotely similar to HTTP. In this case, > we have a half-duplex, request/response, resource/representation > protocol establishing a full-duplex, asynchronous, opaque-bits-on-the- > wire connection that's fundamentally incompatible with the deployed > architecture of port 80 (caches, security gateways); and which nobody > seems happy with. > > My suggested fixes to 9.8, based on the notion that HTTP 1.0, 1.1 > and 2.0, and PTTH 1.0, are not "incompatible" protocols: > > "The 'Upgrade' general-header field allows the client to specify which > version of the communication protocol it would like to use, if the > server chooses to switch versions. Additionally, the server MUST use > the Upgrade header field within a 101 (Switching Protocols) response to > indicate the version(s) being switched to. > > The Upgrade header field is intended to provide a simple mechanism for > transitioning from HTTP/1.1 to some newer, compatible protocol... This > eases the difficult transition between versions of compatible protocols > by allowing the client to initiate a request..." > > This opens a whole can of worms about what constitutes a compatible > protocol, instead of the current wording: "The capabilities and nature > of the application-layer communication after the protocol change is > entirely dependent upon the new protocol chosen," which seems like the > sort of free-for-all that leads to unintended security consequences. Indeed. Is HTTP over SSL a compatible protocol? semantically yes, but it is fundamentally different on the wire. Would this restriction also apply to protocols like SPDY that are enhanced HTTP-like protocols, but with additional features. > My issue is whether it's overreaching to extend Upgrade from being a > versioning mechanism for HTTP, into a general-purpose protocol tunneling > mechanism. Or securable. Does a registry need to be defined here, and > if so, shouldn't there be some fidelity with the notions of the media > type and request/response architectural paradigms? RFC2817 would appear to have gone beyond that already. >> So I'd ask the httpbis readers, are there any reasons you know of that >> would prevent Upgrade being used for websocket? >> > > Yes -- Web Sockets is fundamentally different from anything I'd expect > to see on port 80. The fact that this is exactly what Upgrade allows, > even encourages with the proposed registry, gives me the heebie-jeebies. And do you get similar feeling to think about using the CONNECT method to establish tunnels for arbitrary protocols? cheers
- [hybi] workability (or otherwise) of HTTP upgrade Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… Jamie Lokier
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Dave Cridland
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Joe Mason
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Brian McKelvey
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Jack Moffitt
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Collin Jackson
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… SM
- Re: [hybi] workability (or otherwise) of HTTP upg… Pat McManus @Mozilla
- Re: [hybi] workability (or otherwise) of HTTP upg… Scott Ferguson
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Gabriel Montenegro
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Martin J. Dürst
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… James Graham
- Re: [hybi] workability (or otherwise) of HTTP upg… Michael
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu