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

Re: h2 use of Upgrade

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 3 Sep 2014 14:08:55 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E29F0339-1B46-4E5B-9DF0-FF605343DA42@gbiv.com>
To: Mark Nottingham <mnot@mnot.net>
On Sep 2, 2014, at 11:03 PM, Mark Nottingham wrote:
> On 1 Sep 2014, at 6:16 am, Roy T. Fielding <fielding@gbiv.com> wrote:
>> This comment is in reference to section 3.2 of
>> http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt
>>> 3.2.  Starting HTTP/2 for "http" URIs
>>>  A client that makes a request to an "http" URI without prior
>>>  knowledge about support for HTTP/2 uses the HTTP Upgrade mechanism
>>>  (Section 6.7 of [RFC7230]).  The client makes an HTTP/1.1 request
>>>  that includes an Upgrade header field identifying HTTP/2 with the
>>>  "h2c" token.  The HTTP/1.1 request MUST include exactly one
>>>  HTTP2-Settings (Section 3.2.1) header field.
>>>  For example:
>>>    GET / HTTP/1.1
>>>    Host: server.example.com
>>>    Connection: Upgrade, HTTP2-Settings
>>>    Upgrade: h2c
>>>    HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
>> The protocol-name is HTTP and the protocol-version is 2, so the correct
>> upgrade protocol is HTTP/2 and the correct HTTP/1.1 response is
>>    GET / HTTP/1.1
>>    Host: server.example.com
>>    Connection: Upgrade, HTTP2-Settings
>>    Upgrade: HTTP/2
>>    HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
>> That is, unless we want to change the name of this protocol to h2c
>> (seems unlikely given the rest of the text).
> This was always going to be a bit of a hack, because HTTP/1 and TLS each has their own name space to identify the protocol to be spoken. 
> We chose to use the ALPN token because that’s the primary way to indicate breaking changes in HTTP/2, so future revisions (or variants) would presumably do the same thing. Given that the HTTP protocol name space is pretty static and small, that seemed like a reasonable thing to do.

I don't see the point.  The protocol name is HTTP.  HTTP/1.1 is what you
are sending in this message, and HTTP/1.1 says that the protocol name is
HTTP.  It even uses HTTP/2.0 in the examples.

> Re-reading 7230 here, there isn’t a lot of semantic heft in the protocol-identifier. I think the most you can say is that we’re wilfully not reusing the existing “HTTP” protocol-name, and choosing not to use the (optional) protocol-version; instead, we’re choosing to align with ALPN, so that this revision (and future ones) don’t have to define both an ALPN token as well as a HTTP protocol-version.
> Does doing so cause problems?

Yes, it contradicts RFC7230, which is a bad example to be setting.
Unless there is a strong reason to do so, and I have seen none here,
then the right choice is to follow the HTTP/1.1 design as intended.
Note also that

  Upgrade: TLS, HTTP/2

is already defined to mean: upgrade the connection to some version of
TLS and HTTP/2 at the same time.

Received on Wednesday, 3 September 2014 21:09:17 UTC

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