h2 definition of HTTP2-Settings

This comment is in reference to sections 3.2.1 and 11 of

http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt

> 3.2.1.  HTTP2-Settings Header Field
> 
>    A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly
>    one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field
>    is a hop-by-hop header field that includes parameters that govern the
>    HTTP/2 connection, provided in anticipation of the server accepting
>    the request to upgrade.
> 
>      HTTP2-Settings    = token68

There are no hop-by-hop header fields, so don't call it that.

Why use a 14 character required field-name to provide options for a
supposedly faster protocol?  Just call it "H2".

>    A server MUST reject an attempt to upgrade if this header field is
>    not present.  A server MUST NOT send this header field.
> 
>    The content of the "HTTP2-Settings" header field is the payload of a
>    SETTINGS frame (Section 6.5), encoded as a base64url string (that is,
>    the URL- and filename-safe Base64 encoding described in Section 5 of
>    [RFC4648], with any trailing '=' characters omitted).  The ABNF
>    [RFC5234] production for "token68" is defined in Section 2.1 of
>    [RFC7235].
> 
>    As a hop-by-hop header field, the "Connection" header field MUST
>    include a value of "HTTP2-Settings" in addition to "Upgrade" when
>    upgrading to HTTP/2.

No!  What it should say is:

   Since the upgrade is only intended to apply to the immediate connection,
   a client sending H2 MUST also send H2 as a connection option in the
   "Connection" header field to prevent it from being forwarded downstream.

IOW, the only thing that makes a field hop-by-hop is the requirements
in Connection.  It is not a characteristic of the field.


Cheers,

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

Received on Monday, 1 September 2014 03:42:26 UTC