On 6/12/2013 3:40 p.m., Adrien de Croy wrote: > > I'd still advertise the highest supported version. The receiver can > then at least decide what to do. > > Any protocol I ever had the misfortune to work with that didn't have a > version field was a train wreck when it came to extending or changing it. > > > > > ------ Original Message ------ > From: "Patrick McManus" > Sent: 6/12/2013 3:36:28 p.m. > Subject: Re: Our ALPN protocol IDs >> there is no requirement on which peer sends first, so there really >> can't be a handshake even as part of the initial settings and/or magic >> bits.. an upgrade of a running session perhaps, but not a negotiation. >> *PN ftw. >> >> >> On Thu, Dec 5, 2013 at 9:26 PM, Adrien de Croy <adrien@qbik.com> wrote: >>> >>> right, so if we decide that HTTP/2.0 won't be forced to go over TLS, >>> then we can't rely on ALPN even being there. >>> >>> At that point it would be problematic to assume a mapping between >>> port and version. Much easier and more deterministic to put a >>> version field back into (at least) the initial message(s). >>> >>> Adrien >>> We do have the Connection Header magic which is transmitted on all connections regardless of mechanism used to start the protocol. This contains the "HTTP/2.0" moniker embeded, so it would seem we do already have the version transmitted in some form already. It is just not transmitted per-message like HTTP/1. ** all version 3.0 need do is change the magic ** version 2.x are supposed to be binary capable, so I would think these are all limited to extensions adding new frames types and mechanism semantics. No train wreck or problems there. *provided* we get a clear consensus and definition of what 2.0 proxies etc is to do with those unknown/future frame types. AmosReceived on Friday, 6 December 2013 06:06:29 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:39 UTC