Subject: 2817 for TLS (was Re: I-D Action: draft-ietf-httpbis-http2-09)

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 17:46:16 -0800

Hi Jim,

On 4 December 2013 16:40, James Cloos <[email-masked]> wrote:
> It would be useful for §3.2 (Starting HTTP/2.0 for “http” URIs) also to
> include an example of combining HTTP/1.1 → HTTP/2.0 upgrade with rfc 2817
> style cleartext → TLS upgrade.  Without, that is, relying on ALPN after
> the 2817 upgrade to get to HTTP/2.0.

That presupposes a number of things that are still under discussion.
Using 2817 to upgrade to TLS is one of many options that has been
proposed, though whether HTTP/2.0 appears in the Upgrade header or in
ALPN is very much undecided, particularly since we are discussing
Alt-Svc, Alternate-Protocol, and other options at the same time.

Please do join the discussion if you have a preference.  I can't in
good conscience add an example at this point.

---

From: James Cloos <[email-masked]>
Date: Thu, 05 Dec 2013 14:42:51 -0500

>>>>> "MT" == Martin Thomson <[email-masked]> writes:

MT> Using 2817 to upgrade to TLS is one of many options that has been
MT> proposed,

MT> though whether HTTP/2.0 appears in the Upgrade header or in
MT> ALPN is very much undecided,

Technically speaking, it is already there.  Asking for tls using 2817
with the expectation to try to get 2.0 via alpn only requires that the
server support rfc 2616, rfc 2817 and draft-ietf-tls-applayerprotoneg.
(Or npn. ;^)

Any server which supports 2817 and alpn would Just Work notwithstanding
discussion here.

But asking for both tls and 2.0 in a single upgrade request also should
just work.  You'd get whatever subset of the two the server supports,
of course, and the client should proceed accordingly.  But it is the
only way optionally to upgrade to the common subset of { TLS HTTP/2.0 }
shared by the client and server without wasting round trips.

An example will answer questions such as "One Upgrade: header listing
both desires vs multiple headers, one per desire", what the possible
responces mean, et cetera.

MT> particularly since we are discussing Alt-Svc, Alternate-Protocol,
MT> and other options at the same time.

Some of the threads have been too long-winded to get through in one
sitting, but I haven't completely ignored any.  And an example of how
optimally to combine 3.2's Upgrade usage with the exsting 2817 Upgrade
usage seems like the Right Thing To Do, even if other options may be
added before publication as an rfc.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 12:48:42 -0800

> Any server which supports 2817 and alpn would Just Work notwithstanding

If only that were true.  It's true if the idea of "support" is broad enough.

If we really care about achieving interoperability, what we will do is
specify what options for upgrade we expect to work every time.  Maybe
throw in a few "MUST"s here and there.

The same goes for 2817 with Upgrade: TLS + HTTP/2.0.  We'd have to say
"do that" with some degree of specificity lest we risk things
breaking.

(I'm not going to make any assessments about what is or is not the
"Right Thing To Do", but I don't think that your assertion fits in
light of the discussion thus far.)