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

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