Subject: Re: h2 definition of HTTP2-Settings

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Sep 2014 15:29:23 -0700

On 31 August 2014 20:42, Roy T. Fielding <[email-masked]> wrote:
>
>    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.

Done.  Thanks.

The name change, I will defer to others on.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Sep 2014 08:26:11 +0300

On 1 Sep 2014, at 6:42 am, Roy T. Fielding <[email-masked]> wrote:

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

Looks like Martin has already taken care of this editorially.

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

Raised as <https://github.com/http2/http2-spec/issues/601>.

Roy, my take here is that since this is only sent once — when an upgrade is attempted — the size of the header field is less-than critical. If it were being sent on every request, it’d be different, of course. I’d be interested to hear what other people think.

>>   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:
> 
> IOW, the only thing that makes a field hop-by-hop is the requirements
> in Connection.  It is not a characteristic of the field.

Likewise, already taken care of.

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 Sep 2014 14:15:24 -0700

> Roy, my take here is that since this is only sent once — when an upgrade is attempted — the size of the header field is less-than critical. If it were being sent on every request, it’d be different…

It certainly isn't critical.  I just get annoyed when folks mint new
header fields that are longer than necessary to fit the purpose, mostly
due to my regret after minting If-Modified-Since.

....Roy