Re: HTTP 1.1 --> 2.0 Upgrade

In vancouver we agreed not to slaughter too many bytes over mandatory
TLS; but we also talked about the need to describe how HTTP/2 binds to
TLS. I'm going to narrowly scope this email to the issues involved with
those situations and how the upgrade should, imo, work without getting
into every detail:

Case 1: https:// scheme - go to the port in the url (default 443) and
use NPN to select http/2 or http/1 (default is http/1 in the case NPN is
not implemented on the server)

Case 2: http:// scheme with default port - optimistically consult DNS
SRV looking for either http2-tls or http2-plaintext depending on what
the client wants. If you get a SRV result back "quickly" go to the host
and port provided and start speaking http2 over tls or plaintext as
appropriate. No extra indirections, no use of http/1. Reasonable server
implementations are forseeable.

Case 3: http:// scheme with an explicit port or lack of SRV information.
This is where we need to bootstrap from HTTP/1. AFAICT people want two
different patterns:

Case 3a: Direct the traffic to another location like Alternate-Protocol
does... basically bundling srv information with an http/1 response..
"here is the answer to your http/1 request and btw over on port 443 we
speak http2-tls and on port 8080 we speak http2-plaintext".. clients can
decide whether they want to jump over there right away or overlap some
more http/1 transactions with the handshake on the other port.. its
probably not important for http/2 to define exactly what happens other
than the lifespan of that alternate-protocol announcement.

Case 3b: transform the current connection into an http/2 connection
(possibly even adding in tls the same way CONNECT does) with http/1
upgrade roughly like websockets does. 

Does that framing seem reasonable?

Does anyone want to make an argument for having both? I'd prefer not to
at this stage but the question seems worth asking.

In favor of 3a - 1] the results are cached and future connections are
pure http/2 without bootstrapping them each time. 2] It also can move
http/2 to a non-port-80 location which alleviates concerns about
transparent proxies being confused.

In favor of 3b - 1] it doesn't require another connection as the current
one is transformed in place. 2] it sidesteps issues about caching the
discovery information of alternate-protocol and its scope and maybe even
security considerations with it. 3] websockets uses port 80 and I'm not
overwhelemed with bug reports about unreachable services due to the http
proxy problem, though the amount of use of websockets is tiny compared
to http and many websockets applications have comet/etc fallbacks just
to support browsers without a ws implementation - so the truth here
might not yet be known.

Mostly I favor 3a because the caching reduces the need for latency
inducing bootstraps while maximizing the amount of http/2 that is used.
I don't constantly like redoing that bootstrap. It also dovetails nicely
with the srv approach as it basically tunnels the srv into http/1.

-Patrick

Received on Monday, 20 August 2012 13:45:47 UTC