Rather than put statements into Roy's mouth... here are the relevant posts which were not disputed;
https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0152.html https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0169.html It seems to me that we -can- implement Connection: Upgrade Upgrade: h2 on a plaintext connection, which is simply shorthand for Upgrade: TLS/1.x, HTTP/2 where the TLS connection *must* handshake with the ALPN token 'h2' (the 102 Switching Protocols would be followed by a TLS HELO), and that restricted set of TLS protocols and ciphers acceptable to the HTTP/2 protocol. The advantage is plainly obvious, no need to tear down and start back up some new connection to transition to h2. On Fri, Jun 10, 2016 at 9:22 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Fri, Jun 10, 2016 at 4:03 AM, Stefan Eissing < > stefan.eiss...@greenbytes.de> wrote: > >> Withdrawn the proposal in r1747668 after reading the comment from Roy >> again. >> > > Let's look at what Roy said... that httpd's implementation of HTTP/1.1 may > choose > to honor a Connection-Upgrade request header of h2, or http/2, or any > other values > we choose, because we are bound by the HTTP/1.1 RFC, not some arbitrary > choice > by the HTTP/2 RFC. Wrong RFC to change HTTP/1.1 behavior, these headers are > only to be used in conformance with > https://tools.ietf.org/html/rfc7230#section-6.7 > > So the http/1.1 Upgrade response header must mirror what the server will > honor > for the Connection: Upgrade http/1.1 -> {something else} > Upgrade request value. > > My initial response is still correct, *if* httpd is willing to honor > Upgrade: h2 > or Upgrade: http/2 request header values, then it is appropriate to offer > these > in the response headers. And as Roy says, we *can* do so irrespective of > any claims within https://tools.ietf.org/html/rfc7540#section-3.2 because > that > is not the binding specification during the http/1.1 phase of the request. > > https://tools.ietf.org/html/rfc7540#page-78 registered the h2c token for > the > Upgrade token, HTTP (including HTTP/2) was already registered. However, > no token 'h2' is registered. That doesn't prevent us or others from > sending > and respecting other values, SSL/ was long considered valid, but I don't > see where 'h2' should be used in the context of the 'Upgrade' header. > > http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml > > For right now, 'h2' should not be presented if 'h2' will not be honored, > IMHO. >
