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

Stefan Eissing <stefan.eissing@greenbytes.de> Tue, 17 October 2017 08:59 UTC

Return-Path: <stefan.eissing@greenbytes.de>
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 0CB5E1320D9 for <hybi@ietfa.amsl.com>; Tue, 17 Oct 2017 01:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=cld4VgDj; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=MiUT/LZ4
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 aFpHGsFN8H63 for <hybi@ietfa.amsl.com>; Tue, 17 Oct 2017 01:59:08 -0700 (PDT)
Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CABC1332D5 for <hybi@ietf.org>; Tue, 17 Oct 2017 01:59:07 -0700 (PDT)
Received: by mail.greenbytes.de (Postfix, from userid 117) id E4F9F15A0F37; Tue, 17 Oct 2017 10:59:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508230745; bh=IBoiWGPBP6zK8wPy+02UCfezao2se0tCb5he+sZ6w6w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cld4VgDjqTuRZaElQzC9rReZ5d8heAYR4nrntjTfdwxYGXOCSpyYz2ueAYxBnh50g XaeUXjSrGCAYKegjqFFHQwQ+DsiLthHBMLv0rr+Xu6R63HT+MQcIzJRebKzBsuR2D0 UgbzY1fHgIZ+uLAUfD54bDZStsJZsm4SyR1pC5PU=
Received: from resistance.greenbytes.local (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 223BE15A0A6F; Tue, 17 Oct 2017 10:59:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1508230740; bh=IBoiWGPBP6zK8wPy+02UCfezao2se0tCb5he+sZ6w6w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MiUT/LZ4aLPFONXDm4Y9FymMS8slHWjmQ+OQugBfe+OzBpa37eNtqCnFog8YFb3hF g/+illBv+pylzFf6dpOSA4RWq5S9op0H34auR1WaNTRVrrqdzig3/Au2YYjBJSLfx3 ZB5fzehQCEn5m5fZavOO35xOhuWh1RK+yIbhmZdE=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <CAOdDvNpCGnZcAUaVaVq7eOLkvQFMbd5qf5BAX30nR8iU9=696A@mail.gmail.com>
Date: Tue, 17 Oct 2017 10:58:59 +0200
Cc: 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-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Patrick McManus <pmcmanus@mozilla.com>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/7nUM-5J3DpCPzdBd1bf6xRzUXbk>
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 08:59:11 -0000


> 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
> 
>  
> 
>