W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: HTTP 1.1 --> 2.0 Upgrade

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 20 Aug 2012 13:47:56 -0700
Message-ID: <CAP+FsNerGpQY6kRWuAgBs9f8LNgiR25YYNbH1Qgtpb+xE5Wpuw@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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.


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

> Eliot
Received on Monday, 20 August 2012 20:48:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC