W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: James Cloos <cloos@jhcloos.com>
Date: Thu, 05 Dec 2013 14:42:51 -0500
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <m3vbz3ozhn.fsf@carbon.jhcloos.org>
>>>>> "MT" == Martin Thomson <martin.thomson@gmail.com> 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 <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
Received on Thursday, 5 December 2013 19:50:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC