Subject: Re: [Technical Errata Reported] RFC7540 (5249)

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Jul 2018 09:19:57 -0700

Any further thoughts on this?

It looks like we agree that something needs to change; AFAICT we can either accept the proposed errata, or change the MUST on sending HTTP2-Settings.

Cheers,

> On 31 Jan 2018, at 5:43 pm, Martin Thomson <[email-masked]> wrote:
> 
> The observation is correct.  However, I'm not sure that this is the
> solution I would choose.  I'm not sure, but I think that an empty
> header field would cause problems.  Maybe the right conclusion to draw
> here is that you have to include at least one setting if you use this
> header field.
> 
> On Thu, Feb 1, 2018 at 12:19 PM, RFC Errata System
> <[email-masked]> wrote:
>> The following errata report has been submitted for RFC7540,
>> "Hypertext Transfer Protocol Version 2 (HTTP/2)".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5249
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Vasiliy Faronov <[email-masked]>
>> 
>> Section: 3.2.1
>> 
>> Original Text
>> -------------
>>     HTTP2-Settings    = token68
>> 
>> Corrected Text
>> --------------
>>     HTTP2-Settings    = [ token68 ]
>> 
>> Notes
>> -----
>> An initial SETTINGS frame is explicitly allowed by Section 3.5 to be empty. The payload of an empty SETTINGS frame is an empty sequence of octets, whose base64url encoding is an empty string. Thus, the HTTP2-Settings header field ought to permit an empty string as value. But the ABNF for "token68" does not match an empty string.
>> 
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --------------------------------------
>> RFC7540 (draft-ietf-httpbis-http2-17)
>> --------------------------------------
>> Title               : Hypertext Transfer Protocol Version 2 (HTTP/2)
>> Publication Date    : May 2015
>> Author(s)           : M. Belshe, R. Peon, M. Thomson, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Hypertext Transfer Protocol Bis APP
>> Area                : Applications
>> Stream              : IETF
>> Verifying Party     : IESG
> 

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Jul 2018 17:44:48 -0700

The problem is that HTTP2-Settings MUST be present. What should someone who doesn't have something to send do? Fake setting?

Maybe we should talk about greasing settings first, then say to send a greased value if there's nothing to say...

> On 26 Jul 2018, at 5:43 pm, Martin Thomson <[email-masked]> wrote:
> 
> Or, we could just acknowledge that this implies a need to advertise at
> least one setting.  That's not as serious an erratum.
> On Fri, Jul 27, 2018 at 2:23 AM Mark Nottingham <[email-masked]> wrote:
>>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Jul 2018 10:43:23 +1000

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Jul 2018 10:50:23 +1000

Nothing that complex.  Many of the settings have defaults, but you
don't have to omit a value if it has a default.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Jul 2018 13:52:13 +1000

So that sounds like we should reject this errata. Another one to clarify would probably be useful.

Cheers,

> On 27 Jul 2018, at 10:50 am, Martin Thomson <[email-masked]> wrote:
>

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 30 Jul 2018 18:00:12 +1200

> So that sounds like we should reject this errata. Another one to clarify would probably be useful.

Nod. There are at least two implementations (squid and squidclient h2
experimental builds) which send the default settings as a probe to see
explicitly if h2 support is accepted.

Amos