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>
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
Precedence: list



> Am 16.10.2017 um 23:31 schrieb Patrick McManus <pmcmanus@mozilla.com>:
>=20
> On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop =
<Michael.Bishop@microsoft.com> wrote:
[...]
>=20
> 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.
>=20
> 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.

=46rom 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 :)
>=20
> 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.
>=20
> ymmv (more than usual on this one!)
>=20
> -P
>=20
> =20
> =20
>=20
> Given that you=E2=80=99re doing the full Upgrade-to-WebSockets dance =
inside the tunneled connection, why don=E2=80=99t you just say that =
you=E2=80=99re CONNECTing to an HTTP/1.1 tunnel?  That=E2=80=99s then =
treated as HTTP/1.1 over TCP, which is fully allowed to do Upgrade =
itself.  If you=E2=80=99re sure that=E2=80=99s the path you want, then =
simply say in the HTTP/2 layer that you=E2=80=99re doing HTTP/1.1 inside =
the stream.  Incidentally, that might be a nice alternative for dealing =
with HTTP_1_1_REQUIRED responses, too!
>=20
> =20
>=20
> From: Patrick McManus [mailto:pmcmanus@mozilla.com]=20
> 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
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> On Mon, Oct 16, 2017 at 12:44 AM, Andy Green <andy@warmcat.com> wrote:
>=20
>=20
> You can probably pipeline the CONNECT + ws handshake though, Patrick =
shows them sequentially and I didn't think about it myself.
>=20
> =20
>=20
> right. The example is just for clarity and cannot show all expressions =
of h2 flows.
>=20
> =20
>=20
> 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.
>=20
> =20
>=20
> 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.
>=20
> =20
>=20
> =20
>=20
> Still only two round trips.
>=20
>=20
>  - SETTINGS                      - SETTINGS
>  - GET /index.html
>                  - 200 HEADERS + DATA
>=20
>  - :method CONNECT
>  - DATA ws handshake
>                   - 200 HEADERS
>                   - DATA ws handshake final
>                   - DATA...
>=20
>  - DATA ...             - DATA...
>=20
> 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.
>=20
> Were you concerned that the client needs to learn that the server
> supports websockets and not just :protocol?
>=20
>=20
> 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.
>=20
> 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)
>=20
> Anyway you are right, it makes any difference with PUSH_PROMISE =
probably not worth the effort.
>=20
> -Andy
>=20
> =20
>=20
>=20