Re: HTTP 1.1 --> 2.0 Upgrade


this is a good analysis, but my main quibble is that case 3b should be
renumbered to be case 0

Connecting to port 80 and upgrading to the protocol/version that you
want to use should be the basically defined way that a http semantic
connection is established, regardless of wire protocol and version
used.  All other mechanisms (NPN on 443, DNS SRV, cached redirection
to known HTTP/2.0 ports) should all be considered as optimisations of
the basic case.

Saving round trips is important and I'm all for optimisations for that
- but I think it is a MUST that HTTP/2.0 will work in an environment
where there is only port 80 and the ability to make a single

So I guess that means I support both  3a and 3b.


PS.  Does upgrade really mean an extra round trip?  Can't we pipeline
HTTP/2.0 request behind the upgrade request if we are confident of

On 20 August 2012 06:45, Patrick McManus <> wrote:
> 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

Greg Wilkins <>
Developer advice and support from the Jetty & CometD experts.

Received on Monday, 1 October 2012 16:50:12 UTC