Re: HTTP 1.1 --> 2.0 Upgrade

On Mon, Aug 20, 2012 at 10:39 AM, Eliot Lear <lear@cisco.com> wrote:

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

For my part, I don't really care which record is chosen to bear the
information, but do believe that DNS is a good mechanism for providing an
appropriate hint.


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

The argument for also doing upgrade is that it would be awesome if we could
get upgrade to work reliably on port 80 so that replacements to HTTP/2 can
be done reliably in the clear on port 80.
Additionally, upgrade could be an alternate-protocol hint,
e.g. alternate-protocol: 80:upgrade-http/2

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

Ditto.


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

The same problem (figuring out when to fall back to using HTTP/1.1) exists
in the same form with upgrade over port 80 and intermediaries. This problem
must be solved regardless of the negotiation hint/solution, even if it
affects small percentages of users, because the nature of the error would
be persistent. There has to be a decent heuristic mandated which allows a
user to eventually get their data.
-=R


>
> Eliot
>
>