Subject: Changes to HTTP/2 from IESG review (and beyond)

From: "Martin Thomson" <[email-masked]>
Date: Fri, 21 Jan 2022 17:42:09 +1100

Hi folks,

I'm about to cut another version of HTTP/2 based on feedback during IESG review.

Here are the changes all together:
https://www.ietf.org/rfcdiff?url1=draft-ietf-httpbis-http2bis-06&url2=https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.txt

Of note:

 * We clarified (aggressively) rules around dynamic table size updates and how you are expected to react to changes in the setting.

 * The draft has a fancy new title.

 * Restored the change to registry rules that eliminates the Experimental Use sections.  Ben Kaduk found this in the changelog that wasn't in the doc.  My fault, I accidentally deleted it when cleaning up.

 * Noted a stream state transition that is not on the state diagram.

 * Described the fields in SETTINGS properly.

 * Noted the hazards involved in validating pseudo-header fields, especially if you then concatenate them and send them out in HTTP/1.1 requests.

 * A handful of editorial changes.

Please, take a quick look and tell me if you see anything that worries you.

Cheers,
Martin

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Jan 2022 17:48:47 +1100

Thanks, Martin.

Folks, please have a look at this -- if you see any issues, point them out ASAP. If we don't hear anything by early next week, the editors will submit a new draft and that's what will go forward to the RFC Editor.

Cheers,

> On 21 Jan 2022, at 5:42 pm, Martin Thomson <[email-masked]> wrote:
> 
> Hi folks,
> 

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 21 Jan 2022 10:00:06 +0100

> Please, take a quick look and tell me if you see anything that worries you.

Looks very good overall. I noticed one nit in 6.5.3:

  "some allowance need to be made ..."

It seems to me that "allowance" is singular hence we ought to have
"needs to" here, but I'm not a native speaker and could be wrong.

Another point, I remember that during my early implementation I was
in trouble trying to figure how to perform a late stream close after
a transfer (e.g. headers only, or end of data detected). I was advised
that the normal way to do this was to send a zero-length DATA frame
with the ES flag set in this case. It's not obvious at all that it's
the normal way to do it, especially when dealing with methods or
statuses that do not take data.

The current text about the DATA frame speaks a lot about padding tricks
but never mentions anything about zero length being valid. There's a
useful note at the end saying "A frame can be increased in size by one
octet by including a Pad Length field with a value of zero". I think
the spec would benefit from one extra such note saying:

   "A late end of stream may be signaled by sending a DATA frame
    with a length of zero octets and the END_STREAM flag set".

Otherwise everything looks pretty nice to me :-)

Willy