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

Loïc Hoguin <essen@ninenines.eu> Tue, 17 October 2017 14:45 UTC

Return-Path: <essen@ninenines.eu>
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 215FC13421D for <hybi@ietfa.amsl.com>; Tue, 17 Oct 2017 07:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham 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 et1PXNbEZBGq for <hybi@ietfa.amsl.com>; Tue, 17 Oct 2017 07:45:53 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0057E134218 for <hybi@ietf.org>; Tue, 17 Oct 2017 07:45:52 -0700 (PDT)
Received: from [192.168.1.102] ([85.60.142.46]) by mrelayeu.kundenserver.de (mreue101 [212.227.15.183]) with ESMTPSA (Nemesis) id 0LjrTN-1dXtGG1C1Z-00bsAW; Tue, 17 Oct 2017 16:45:49 +0200
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.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> <CAOdDvNrKDEhbFzdMfOwZOBr8pTSJiMqmYs0VDPpSsQr_TUhQig@mail.gmail.com>
From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= <essen@ninenines.eu>
Organization: Nine Nines
Message-ID: <b89cdbd1-61d9-2e17-daf2-a2bdf7d773dc@ninenines.eu>
Date: Tue, 17 Oct 2017 15:45:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAOdDvNrKDEhbFzdMfOwZOBr8pTSJiMqmYs0VDPpSsQr_TUhQig@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:Ccbk0ddPFrqAnwmOeFa1UMunE4TQ/C2BNoPGQOe64aTEaPJX3sl cLNnUa+EwJxNTzD+vx+21TL13YJQh0wRkzRoseCRwqF5I92SZB1KZbVFZfNoolQLsq/B8O+ 4yhNt3qZGhxR+HAi38yp3Xik9d/pdBg8P3L7jUtUjRDv1sDKQ7q+rScr0h/72AXrIDatnz9 2gWKQnu624z0zs2vs5OYw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ziSbF9cB//A=:EK3ZyHYMRE1/34kmwRL2p+ V1o/ZRlewjZwFrbDCgOEgR766bZh8kAWvXtKP6VJG1R8OHUuVvR7QEYQP1TxYEQR8yY5sZ1hj 4FTvmL/XTYYBXCtnLies7Vm8zvUqWZmAOrRXi1cXSQHf6j6Oy3rOt0FKcBiE3JNx/aLDcgeeG Ytlf3g9Mdlx4UR5HUznR+hc1nW8JAPGi2GEfugKxnJTLSh2jRsnV4fFIQJi/kSrvqe9Jwh97n 7/6y1G/CVoDF+xUrgJ2kpUhA3FBCIh7zMFSqBXKYUqAYZqlCzk8vEOaDNDjQZMpH3XFiYaPON okoJVvB7cVrBMQALxpRLcWJCqVRNR35NK1HGicDvNvhgU6O3iVwNWql5emYetDai84rNrfJXh J4Kv4wYmELBMfs2mKwr7/SFjfPT5LikYo7gC0c/95o6iLO6WICROKh72tGqrTBV+FugQSpv4I TLbGHDtPmLSU2au8RZ+t9BSAg37hnutcV1tk5AP/7dX/OF96GDDX/oEskZaSZqVXNtKcnfCV3 mxUQomaCTjlLrjUa5uwGx5Nts67qrLJryXHpLrPn5zQJAmHK5I+V75tHRFkCckP0p6gvUzOzD RIvvQYO296GyZ1GZ2nYq3RdJHaOu8alKZHzvV8VkyYeFebEwRP17sbxJMiaMhWKcddtX8QZDZ 2/dJ/U8JWVoalCZ8FHs6ITwsh5JVBvNPPN3pOiVwrn2JdPg+Z9AuXwxtTs4GPSgRmPxMau6D6 QljQGd1H8tsSC1e8GlVNU5ILXPWH+ZjbAzEaiLcHg4oAWcUvmWn0x3e9MBA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/K2S3_SXO53JFV8zBHNUgxBSjrzg>
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:45:57 -0000

I maintain both a client and server that support Websocket. My opinion:

c] wouldn't change my behavior but I like it more

I would implement either way, but I currently do not have an 
implementation for "HTTP/1.1 over h2 DATA frames" so I would need to 
write new code regardless. It's probably worth pointing out that new 
implementers only interested in h2 and Websocket could skip the whole 
HTTP/1.1 text parsing and all its pitfalls entirely.

I would also be very happy to drop the masking on the Websocket frames 
when using Websocket with h2.

On 10/17/2017 03:34 PM, Patrick McManus wrote:
> 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 <mailto:stefan.eissing@greenbytes.de>> wrote:
> 
> 
> 
>     > Am 16.10.2017 um 23:31 schrieb Patrick McManus <pmcmanus@mozilla.com <mailto:pmcmanus@mozilla.com>>:
>     >
>     > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <Michael.Bishop@microsoft.com <mailto: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
>     <mailto:pmcmanus@mozilla.com>]
>      > Sent: Monday, October 16, 2017 5:16 AM
>      > To: Andy Green <andy@warmcat.com <mailto:andy@warmcat.com>>
>      > Cc: Martin Thomson <martin.thomson@gmail.com
>     <mailto:martin.thomson@gmail.com>>; Patrick McManus
>     <pmcmanus@mozilla.com <mailto:pmcmanus@mozilla.com>>; hybi
>     <hybi@ietf.org <mailto:hybi@ietf.org>>; Cory Benfield
>     <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>>; Patrick McManus
>     <mcmanus@ducksong.com <mailto:mcmanus@ducksong.com>>; HTTP Working
>     Group <ietf-http-wg@w3.org <mailto: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
>     <mailto: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
>      >
>      >
>      >
>      >
> 
> 
> 
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
> 

-- 
Loïc Hoguin
https://ninenines.eu