Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

Patrick McManus <pmcmanus@mozilla.com> Tue, 17 October 2017 14:34 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706F7132D49 for <hybi@ietfa.amsl.com>; Tue, 17 Oct 2017 07:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level:
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 r5SKazCwrT24 for <hybi@ietfa.amsl.com>; Tue, 17 Oct 2017 07:34:21 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 26E68132D51 for <hybi@ietf.org>; Tue, 17 Oct 2017 07:34:21 -0700 (PDT)
Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id 009633A0A9 for <hybi@ietf.org>; Tue, 17 Oct 2017 10:34:18 -0400 (EDT)
Received: by mail-lf0-f54.google.com with SMTP id b190so2253149lfg.9 for <hybi@ietf.org>; Tue, 17 Oct 2017 07:34:18 -0700 (PDT)
X-Gm-Message-State: AMCzsaW7QF8+YGHK9HY7EsR6Umw5NE0hpCCz4zSSjrNCGUbyrBIAnG6v B7U25A8xS4BIcZecQw7ruEU588mwScHGxBbbtGU=
X-Google-Smtp-Source: ABhQp+SEg6rQghuwGfPEsZelzeaCeCD2OHJdGBmuxzG0N9iZZUbDP5oE8O+vdmdY2pycHCCZmbBAW+X5iaqoeglIyIw=
X-Received: by 10.25.234.66 with SMTP id i63mr4608092lfh.188.1508250857615; Tue, 17 Oct 2017 07:34:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.21.22 with HTTP; Tue, 17 Oct 2017 07:34:16 -0700 (PDT)
In-Reply-To: <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de>
References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <CAOdDvNqhaTJmLcEk3CwBBaAbdOroc4U46z+nJzC7+chd1ErSDA@mail.gmail.com> <FEBB57D4-E841-4F45-9B62-81FFC653FF70@lukasa.co.uk> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <CAOdDvNpCVxsaKEzoW3EWsK1hmWSBPOP+GHnK-DcP4QO4om_khQ@mail.gmail.com> <f4bb6b5c-b12e-dc59-6faa-15588b692574@warmcat.com> <CABkgnnUfDwYmxi72f-x=z=iwf4+3L_rcLqufJRYvEMpP=Fb3MA@mail.gmail.com> <a4229e61-fb04-30b1-f2c7-a862645d0059@warmcat.com> <CABkgnnX0uXm1mDHL+dy6Z+mCZdofkEshd5jy-a0jV-Hsp88yQA@mail.gmail.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <CABkgnnWfTcGyUDBfSs1S+M4xaeELZKXa=9JP79kKKvsSjL_ouA@mail.gmail.com> <dda4b424-b2e3-7096-c2ce-f61e54df2384@warmcat.com> <CABkgnnVeXGzw2HjxkUWW8O_EOjhe6j3p1yqJUuezvMnBtHxtLQ@mail.gmail.com> <e971cda1-f022-50a6-0e3b-d1a264d6f358@warmcat.com> <CAOdDvNrZf-19CmPnZFma_H+iajVgXkUjFiPH0jX3MAVVKju5hg@mail.gmail.com> <MWHPR21MB0141A705D0182DA51B934280874F0@MWHPR21MB0141.namprd21.prod.outlook.com> <CAOdDvNpCGnZcAUaVaVq7eOLkvQFMbd5qf5BAX30nR8iU9=696A@mail.gmail.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 17 Oct 2017 10:34:16 -0400
X-Gmail-Original-Message-ID: <CAOdDvNrKDEhbFzdMfOwZOBr8pTSJiMqmYs0VDPpSsQr_TUhQig@mail.gmail.com>
Message-ID: <CAOdDvNrKDEhbFzdMfOwZOBr8pTSJiMqmYs0VDPpSsQr_TUhQig@mail.gmail.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Andy Green <andy@warmcat.com>, Martin Thomson <martin.thomson@gmail.com>, hybi <hybi@ietf.org>, Cory Benfield <cory@lukasa.co.uk>, McManus Patrick <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="94eb2c0ebae099b7b4055bbf0417"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/MqmF6NoxJp4Z5IMQYUK6MBguDmg>
Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Tue, 17 Oct 2017 14:34:28 -0000

Clearly substituting the h1 exchange out in favor of a new websockets
specific exchange that contained sub-protocol and version tokens would look
better on paper... I actually thought diverging from 6455 would make people
LESS likely to implement. Maybe I'm wrong.

So let's poll - please speak up if you have a ws impl (either client or
server):

If the spec added a new websockets specific parameter negotiation and
removed the H1 syntax it would make me
 a] MORE likely to implement
 b] LESS likely to implement
 c] wouldn't change my behavior but I like it more
 d] wouldn't change my behavior but it would be more painful (or like it
less)
 e] really don't care at all.

On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <
stefan.eissing@greenbytes.de>; wrote:

>
>
> > Am 16.10.2017 um 23:31 schrieb Patrick McManus <pmcmanus@mozilla.com>;:
> >
> > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <
> Michael.Bishop@microsoft.com>; wrote:
> [...]
> >
> > I hear what you're saying.. but I think you're going a touch too far.
> websocket means 6455 which has all that h1 stuff as part of its
> configuration.. I think it would be totally fair to say such a server could
> have a more constrained parser that failed any non-ws compliant handshake
> even if it were valid h1. Mostly I think it becomes an insanely ugly what
> to do websocket parameter exchange.
> >
> > I think of origin info (scheme and authority) more as keys to route the
> CONNECT request.. it's :protocol that defines what to do in the tunnel. I
> admit I did consider calling it :alpn (which has a similar kind of
> property.. its a route of sorts but it doesn't bear the SETTINGS or magic
> of h2)
>
> Me stupid. Me asking, why not :upgrade?
>
> ht;dr (have time, do read)
>
> As proposed, the CONNNECT seems to say: let's talk HTTP/1.1 on this stream
> from now on, afaict.
>
> From a server implementation pov that opens a larger can of worms. It
> would mean warming up the HTTP/1.1 engine for the DATA on this stream. That
> needs some extra care so that it does only safe things inside a h2 stream.
> On first glance, it seems to be easier and safer to do the stream :upgrade
> inside the h2 protocol handling itself.
>
> Just my initial gut reaction...
>
> -Stefan
>
> > You have kind of let the cat out of the bag at just doing an h1 connect.
> That's actually possible with the draft (or at least envisioned) as I
> defined :protocol separate from the websocket specific stuff... but I kinda
> hope to never speak of it again :)
> >
> > This is a tough one - its definitely going for simplicity as its main
> goal.. that means ignoring many places that can be improved. That's a
> choice based on
> >  a] the history of other efforts seem to suggest there is no stomach for
> complexity/risk here
> >  b] we hear about this problem enough that I think its worth seeing if
> this can be m ade a consensus mvp
> >  c] my belief that websockets is a transitional technology - it will be
> around for years but some kind of native http will supplant it.
> >
> > ymmv (more than usual on this one!)
> >
> > -P
> >
> >
> >
> >
> > Given that you’re doing the full Upgrade-to-WebSockets dance inside the
> tunneled connection, why don’t you just say that you’re CONNECTing to an
> HTTP/1.1 tunnel?  That’s then treated as HTTP/1.1 over TCP, which is fully
> allowed to do Upgrade itself.  If you’re sure that’s the path you want,
> then simply say in the HTTP/2 layer that you’re doing HTTP/1.1 inside the
> stream.  Incidentally, that might be a nice alternative for dealing with
> HTTP_1_1_REQUIRED responses, too!
> >
> >
> >
> > From: Patrick McManus [mailto:pmcmanus@mozilla.com]
> > Sent: Monday, October 16, 2017 5:16 AM
> > To: Andy Green <andy@warmcat.com>;
> > Cc: Martin Thomson <martin.thomson@gmail.com>;; Patrick McManus <
> pmcmanus@mozilla.com>;; hybi <hybi@ietf.org>;; Cory Benfield <
> cory@lukasa.co.uk>;; Patrick McManus <mcmanus@ducksong.com>;; HTTP Working
> Group <ietf-http-wg@w3.org>;
> > Subject: Re: [hybi] New Version Notification for
> draft-mcmanus-httpbis-h2-websockets-00.txt
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <andy@warmcat.com>; wrote:
> >
> >
> > You can probably pipeline the CONNECT + ws handshake though, Patrick
> shows them sequentially and I didn't think about it myself.
> >
> >
> >
> > right. The example is just for clarity and cannot show all expressions
> of h2 flows.
> >
> >
> >
> > CONNECT + DATA before the response headers is pretty much the h2 analog
> of TCP Fast Open. The devil is in the details.. That's a general CONNECT +
> DATA issue not limited to the protocol upgrade described here so I don't
> think its worth discussion in a websockets rfc.
> >
> >
> >
> > I think the path to success here hinges on a very tight scoping of work
> and therefore optimizing handshake latency is a non-goal of this effort.
> >
> >
> >
> >
> >
> > Still only two round trips.
> >
> >
> >  - SETTINGS                      - SETTINGS
> >  - GET /index.html
> >                  - 200 HEADERS + DATA
> >
> >  - :method CONNECT
> >  - DATA ws handshake
> >                   - 200 HEADERS
> >                   - DATA ws handshake final
> >                   - DATA...
> >
> >  - DATA ...             - DATA...
> >
> > With the part of the pipelining that is legal for ws, two round trips
> before the client can start to send data and 1.5 before the server can send
> data... if it's true then you're right it's not so bad.
> >
> > Were you concerned that the client needs to learn that the server
> > supports websockets and not just :protocol?
> >
> >
> > No I just followed Patrick's sequencing; he shows them serialized.  But
> you're right at least the CONNECT + ws handshake can probably be pipelined.
> >
> > That's also going to be a variation from normal h2 HEADERS flow if I
> understood it, on one stream there will be END_HEADERs coming twice (for
> the CONNECT and the ws handshake separately)
> >
> > Anyway you are right, it makes any difference with PUSH_PROMISE probably
> not worth the effort.
> >
> > -Andy
> >
> >
> >
> >
>
>