Re: h2 use of Upgrade

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.

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?

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 3 September 2014 06:03:29 UTC