- From: Loïc Hoguin <essen@ninenines.eu>
- Date: Tue, 17 Oct 2017 15:45:47 +0100
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Tuesday, 17 October 2017 14:46:17 UTC