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

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