Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8C6133070 for ; Tue, 17 Oct 2017 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgvxPF-GUK82 for ; Tue, 17 Oct 2017 11:19:42 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC63126B6E for ; Tue, 17 Oct 2017 11:19:41 -0700 (PDT) Date: Wed, 18 Oct 2017 02:19:00 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <3dd5002d-49ca-4af5-1b38-f1dbe530b98e@warmcat.com> <1B8ED5DE-6147-4463-AA8C-561B6E03C1F0@greenbytes.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Patrick McManus , Stefan Eissing CC: Mike Bishop , Martin Thomson , hybi , Cory Benfield , McManus Patrick , HTTP Working Group From: Andy Green Message-ID: Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:19:44 -0000 On October 17, 2017 10:34:16 PM GMT+08:00, 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=2E=2E=2E I actually thought diverging from 6455 would mak= e >people >LESS likely to implement=2E Maybe I'm wrong=2E > >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=2E c) =2E=2E=2E as discussed before only three persistant things come from th= e ws dance, agreement on both sides the stream is in an upgraded state, and= the server telling which protocol and any extensions + extension options a= pply=2E For the case where the peer is actually h1 ws hitching a ride on h2, the e= xtra 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=2E For the case the peer is natively h2 - surely it will become the common ca= se when this arrives in today's h2-preferring web browsers - doing a simple= r upgrade in native h2 is easier to implement, just don't do any of the old= Sec-key stuff at all=2E -Andy >On Tue, Oct 17, 2017 at 4:58 AM, Stefan Eissing < >stefan=2Eeissing@greenbytes=2Ede> wrote: > >> >> >> > Am 16=2E10=2E2017 um 23:31 schrieb Patrick McManus >: >> > >> > On Mon, Oct 16, 2017 at 1:13 PM, Mike Bishop < >> Michael=2EBishop@microsoft=2Ecom> wrote: >> [=2E=2E=2E] >> > >> > I hear what you're saying=2E=2E but I think you're going a touch too >far=2E >> websocket means 6455 which has all that h1 stuff as part of its >> configuration=2E=2E I think it would be totally fair to say such a serv= er >could >> have a more constrained parser that failed any non-ws compliant >handshake >> even if it were valid h1=2E Mostly I think it becomes an insanely ugly >what >> to do websocket parameter exchange=2E >> > >> > I think of origin info (scheme and authority) more as keys to route >the >> CONNECT request=2E=2E it's :protocol that defines what to do in the >tunnel=2E I >> admit I did consider calling it :alpn (which has a similar kind of >> property=2E=2E its a route of sorts but it doesn't bear the SETTINGS or >magic >> of h2) >> >> Me stupid=2E Me asking, why not :upgrade? >> >> ht;dr (have time, do read) >> >> As proposed, the CONNNECT seems to say: let's talk HTTP/1=2E1 on this >stream >> from now on, afaict=2E >> >> From a server implementation pov that opens a larger can of worms=2E It >> would mean warming up the HTTP/1=2E1 engine for the DATA on this >stream=2E That >> needs some extra care so that it does only safe things inside a h2 >stream=2E >> On first glance, it seems to be easier and safer to do the stream >:upgrade >> inside the h2 protocol handling itself=2E >> >> Just my initial gut reaction=2E=2E=2E >> >> -Stefan >> >> > You have kind of let the cat out of the bag at just doing an h1 >connect=2E >> That's actually possible with the draft (or at least envisioned) as I >> defined :protocol separate from the websocket specific stuff=2E=2E=2E b= ut I >kinda >> hope to never speak of it again :) >> > >> > This is a tough one - its definitely going for simplicity as its >main >> goal=2E=2E that means ignoring many places that can be improved=2E 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=2E >> > >> > ymmv (more than usual on this one!) >> > >> > -P >> > >> > >> > >> > >> > 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=2E1 tunnel? That=E2=80=99s then treated as HTTP/1=2E1 over TCP,= which is >fully >> allowed to do Upgrade itself=2E 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=2E= 1 inside >the >> stream=2E Incidentally, that might be a nice alternative for dealing >with >> HTTP_1_1_REQUIRED responses, too! >> > >> > >> > >> > From: Patrick McManus [mailto:pmcmanus@mozilla=2Ecom] >> > Sent: Monday, October 16, 2017 5:16 AM >> > To: Andy Green >> > Cc: Martin Thomson ; Patrick McManus < >> pmcmanus@mozilla=2Ecom>; hybi ; Cory Benfield < >> cory@lukasa=2Eco=2Euk>; Patrick McManus ; HTTP >Working >> Group >> > Subject: Re: [hybi] New Version Notification for >> draft-mcmanus-httpbis-h2-websockets-00=2Etxt >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Oct 16, 2017 at 12:44 AM, Andy Green >wrote: >> > >> > >> > You can probably pipeline the CONNECT + ws handshake though, >Patrick >> shows them sequentially and I didn't think about it myself=2E >> > >> > >> > >> > right=2E The example is just for clarity and cannot show all >expressions >> of h2 flows=2E >> > >> > >> > >> > CONNECT + DATA before the response headers is pretty much the h2 >analog >> of TCP Fast Open=2E The devil is in the details=2E=2E 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=2E >> > >> > >> > >> > 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=2E >> > >> > >> > >> > >> > >> > Still only two round trips=2E >> > >> > >> > - SETTINGS - SETTINGS >> > - GET /index=2Ehtml >> > - 200 HEADERS + DATA >> > >> > - :method CONNECT >> > - DATA ws handshake >> > - 200 HEADERS >> > - DATA ws handshake final >> > - DATA=2E=2E=2E >> > >> > - DATA =2E=2E=2E - DATA=2E=2E=2E >> > >> > With the part of the pipelining that is legal for ws, two round >trips >> before the client can start to send data and 1=2E5 before the server >can send >> data=2E=2E=2E if it's true then you're right it's not so bad=2E >> > >> > 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=2E= =20 >But >> you're right at least the CONNECT + ws handshake can probably be >pipelined=2E >> > >> > 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=2E >> > >> > -Andy >> > >> > >> > >> > >> >>