Re: HTTP 1.1 --> 2.0 Upgrade

Hi Patrick,

On 8/20/12 3:45 PM, 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)

Ok.

>
> 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.

As in happy eyeballs?  Sure.

>
> 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?

Reasonable?  Yes.  Best course of action?  I don't know.  I know I'm
beginning to sound like a broken record, but I don't know if SRV is the
right record for the job.  For one thing, if you use another record, you
can use that same optimistic approach for an explicit port in the URI. 
Of course, then there is the added implementation headache of a new
record.  We've gotten around that elseewhere with TXT records, but I
don't recommend it here.

>
> 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.

I'd be a bit nervous about cache management, and specifically how/when
to invalidate.  Two obvious cases are when the IP address changes, and
when for some reason the other side starts barfing on SPDY.

Eliot

Received on Monday, 20 August 2012 17:40:01 UTC