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

[Andy Green <[e-mail]>]

On October 17, 2017 10:34:16 PM GMT+08:00, Patrick McManus <[e-mail]> 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.

c) ... as discussed before only three persistant things come from the ws dance, agreement on both sides the stream is in an upgraded state, and the server telling which protocol and any extensions + extension options apply.

For the case where the peer is actually h1 ws hitching a ride on h2, the extra RFC6455-only h1 header bits like Sec key hashes can be synthesized at the boundary where the h1 stuff interfaces to the h2 stream, since they don't feature in the state after upgrade establishment and an h2 server doesn't need to see them at all.

For the case the peer is natively h2 - surely it will become the common case when this arrives in today's h2-preferring web browsers - doing a simpler upgrade in native h2 is easier to implement, just don't do any of the old Sec-key stuff at all.

-Andy

>On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing <
>[e-mail]> wrote:
>
>>
>>
>> > Am 16.10.2017 um 23:31 schrieb Patrick McManus
><[e-mail]>:
>> >
>> > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop <
>> [e-mail]> 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:[e-mail]]
>> > Sent: Monday, October 16, 2017 5:16 AM
>> > To: Andy Green <[e-mail]>
>> > Cc: Martin Thomson <[e-mail]>; Patrick McManus <
>> [e-mail]>; hybi <[e-mail]>; Cory Benfield <
>> [e-mail]>; Patrick McManus <[e-mail]>; HTTP
>Working
>> Group <[e-mail]>
>> > 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 <[e-mail]>
>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
>> >
>> >
>> >
>> >
>>
>>