Re: 6455 Websockets and the relationship to HTTP

Andy Green <andy@warmcat.com> Fri, 02 December 2016 02:38 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA010129500 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Dec 2016 18:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.687
X-Spam-Level:
X-Spam-Status: No, score=-9.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=warmcat.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyAHWS8UF0aG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Dec 2016 18:38:12 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204EB1296E7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 1 Dec 2016 18:38:10 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCdg9-0004fg-86 for ietf-http-wg-dist@listhub.w3.org; Fri, 02 Dec 2016 02:34:25 +0000
Resent-Date: Fri, 02 Dec 2016 02:34:25 +0000
Resent-Message-Id: <E1cCdg9-0004fg-86@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <andy@warmcat.com>) id 1cCdfx-0004ep-Ne for ietf-http-wg@listhub.w3.org; Fri, 02 Dec 2016 02:34:13 +0000
Received: from mail.warmcat.com ([163.172.24.82]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <andy@warmcat.com>) id 1cCdfq-0003Y8-SQ for ietf-http-wg@w3.org; Fri, 02 Dec 2016 02:34:08 +0000
DKIM-Filter: OpenDKIM Filter v2.10.3 warmcat.warmcat.com 3E624A1B6E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=warmcat.com; s=dkim; t=1480646013; bh=DC1akJIJB6UWvLAc91soZs5PWgzL8DGaHPtzmUsnHWQ=; h=Subject:From:To:Date:In-Reply-To:References:From; b=JLu6CKcahBmqrWMVfTyoe/AFpxCz79vdQyIJusbrLt10zAlwfiJ3KayO87i/sll/R sYZ3NFGipJWmanr/tL4takncY5SxuXyJC9j1NGo0A08JQlLLhb0vwGlcMXTUnIEViL tdlgtruup91deDKzDHrlLU1O4wa51D/NzSUE6pWo=
Message-ID: <1480646012.4219.21.camel@warmcat.com>
From: Andy Green <andy@warmcat.com>
To: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Date: Fri, 02 Dec 2016 10:33:32 +0800
In-Reply-To: <9e6f1a46-a782-a688-5b16-836d28032823@treenet.co.nz>
References: <CAOdDvNqk7W_oNWUismMb-ZuhvdboZNDQ0YV2BLsbka-FGC-7oA@mail.gmail.com> <39F32B28-7116-478A-B02A-E8310EA6E189@mnot.net> <CABkgnnVZeLQGES5Dige8u+ukSgqSfJNKiCuL=oK3gQnAb_3LNw@mail.gmail.com> <CANatvzwoUYaC_YPTTF6fdwN5aOiwrttyH9Xj7xYVR1i1DZ27bA@mail.gmail.com> <037D2D57-7423-4375-9FEC-50B3106F42ED@mnot.net> <CANatvzx=mOQ3kE-vnvwNvD2w26+RNTueHgu7BhHLnJixn0vRcw@mail.gmail.com> <9e6f1a46-a782-a688-5b16-836d28032823@treenet.co.nz>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=163.172.24.82; envelope-from=andy@warmcat.com; helo=mail.warmcat.com
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=-0.122, BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cCdfq-0003Y8-SQ 0732d89da0c8bae3a16314e718c6d1ec
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <http://www.w3.org/mid/1480646012.4219.21.camel@warmcat.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33083
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Fri, 2016-12-02 at 14:53 +1300, Amos Jeffries wrote:
> On 2/12/2016 2:13 p.m., Kazuho Oku wrote:
> > 2016-12-02 10:00 GMT+09:00 Mark Nottingham:
> > 
> > > 
> > > > On 2 Dec. 2016, at 11:56 am, Kazuho Oku wrote:
> > > > 
> > > > 
> > > > 
> > > > 2016-12-02 9:19 GMT+09:00 Martin Thomson:
> > > > On 2 December 2016 at 11:09, Mark Nottingham wrote:
> > > > > In particular, my recollection of the outcome of the
> > > > > discussion of WS
> > > 
> > > in H2 was that a new SETTING or a new ALPN token could be used to
> > > indicate
> > > that a connection supports both H2 and WS. If there's a problem
> > > with doing
> > > so, that would be good to talk about as well. Especially
> > > considering QUIC.
> > > > 
> > > > There seems to be some reluctance to exercise that option.  I
> > > > don't
> > > > understand why; I've a bunch of candidate theories, but none of
> > > > them
> > > > make a lot of sense.
> > > > 
> > > > 
> > > > My understanding is that the cons of using SETTINGS only is
> > > > that it
> > > 
> > > requires an additional roundtrip on connection establishment.
> > > I've heard
> > > people oppose to the use of ALPN since they want to use both H2
> > > and WS (and
> > > possibly DNS?) on the same connection.
> > > 
> > > The semantics of the ALPN token can be "this connection supports
> > > H2 *and*
> > > WS."
> > > 
> > > It's true that taken to an extreme, this could lead to a
> > > combinatorial
> > > explosion.
> > 
> > 
> > Agreed. While I believe it would be a good idea to have some kind
> > of
> > mechanism to restrict the use of an H2 connection, a client need to
> > be
> > forbidden for making an anticipation that the connection can also
> > handle
> > HTTP requests.
> 
> Please don't go there. The 'h' in h2 means HTTP by definition.
> 
> WS/1 has its own TCP based sockets etc for use by connections without
> HTTP.

ws does not exist standalone without http first, since the ws protocol
is negotiated in http before the upgrade and there's no way to do it
after the upgrade.

The actual game here is "provide a transport for JS WS API on h2".  It
does not need to retain any relationship at all to "WS/1" transport
implementation.  Eg as was discussed here a long time ago there may be
a way for the whole overkill 64-bit ws fragment size business to go and
just use h2 framing.

> An ALPN for that or for a separate WS/2 protocol spec that references
> HTTP/2 mechanisms and framing as a re-use (like ICAP with HTTP/1)
> should
> be sufficient.

Since there will be servers that support ws/2 and those that don't,
something is needed.  Whatever it is preferably shouldn't force new tcp
connections or roundtrips on ws/2 needlessly.

> But not re-defining h2 to mean non-HTTP-only traffic.

-Andy

> Amos
> 
>