h2 use of Upgrade

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

>    Requests that contain an entity body MUST be sent in their entirety
>    before the client can send HTTP/2 frames.  This means that a large
>    request entity can block the use of the connection until it is
>    completely sent.
> 
>    If concurrency of an initial request with subsequent requests is
>    important, a small request can be used to perform the upgrade to
>    HTTP/2, at the cost of an additional round-trip.

s/a small request/an OPTIONS request/

>    A server that does not support HTTP/2 can respond to the request as
>    though the Upgrade header field were absent:
> 
>      HTTP/1.1 200 OK
>      Content-Length: 243
>      Content-Type: text/html
> 
>      ...
> 
>    A server MUST ignore a "h2" token in an Upgrade header field.
>    Presence of a token with "h2" implies HTTP/2 over TLS, which is
>    instead negotiated as described in Section 3.3.

There is no such token.  ALPN tokens have nothing to do with Upgrade
and this is an HTTP/1.1 request, so this spec has no ability to make
such an (unnecessary) requirement.

>    A server that supports HTTP/2 can accept the upgrade with a 101
>    (Switching Protocols) response.  After the empty line that terminates
>    the 101 response, the server can begin sending HTTP/2 frames.  These
>    frames MUST include a response to the request that initiated the
>    Upgrade.
> 
>      HTTP/1.1 101 Switching Protocols
>      Connection: Upgrade
>      Upgrade: h2c
> 
>      [ HTTP/2 connection ...
> 
>    The first HTTP/2 frame sent by the server is a SETTINGS frame
>    (Section 6.5).  Upon receiving the 101 response, the client sends a
>    connection preface (Section 3.5), which includes a SETTINGS frame.

Note that the SETTINGS frame is a sufficient response if the request
was for OPTIONS.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Monday, 1 September 2014 03:16:56 UTC