Code change:
MUST terminate the connection with a ConnectionErrorHandler of type COMPRESSION_ERROR if it does not decompress a field block. <ins> A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. 4.3.1. Field compression is stateful.  One compression context and one decompression context are used for the entire connection. COMPRESSION defines the dynamic table, which is the primary state that is used for field compression. The dynamic table has a maximum size that is set by a decoder using the SETTINGS_HEADER_TABLE_SIZE setting; see SettingValues.  The encoder can set the dynamic table to any size up to the maximum value set by the decoder.  The encoder declares the size of the dynamic table with a Dynamic Table Size Update instruction (COMPRESSION). The encoder at both client and server is initialized with a dynamic table size of 4,096 bytes, the initial value of the SETTINGS_HEADER_TABLE_SIZE setting. Any change to the maximum value set by the decoder takes effect when the encoder SettingsSync.  The first field block sent by an encoder after a change in SETTINGS_HEADER_TABLE_SIZE starts with at least one Dynamic Table Size Update instruction; see COMPRESSION.  An encoder sends a Dynamic Table Size Update instruction after acknowledging a change of SETTINGS_HEADER_TABLE_SIZE even if it is not changing the size of the dynamic table or an increase to the maximum size is subsequently reverted before the field block is sent.  An encoder MAY treat the absence of Dynamic Table Size Update instructions in a field block following an acknowledgment of a change to SETTINGS_HEADER_TABLE_SIZE as a ConnectionErrorHandler of type COMPRESSION_ERROR. </ins> 5. A "stream" is an independent, bidirectional sequence of frames

Related discussion:
text: As they relate to changes in SETTINGSHEADERTABLE_SIZE. This is the strict, by-the-book interpretation. That is, if the value changes, you have to send the update, even if it is pointless (that is, you aren't changing the size of the table). Note that I'm eliding the point about multiple instructions, which are necessary if the decoder reduces the maximum below the current size. The only nod in that direction is "at least one" and a reference to the section that talks about the need for multiple updates. This pulls in more of RFC 7541 than I might have liked, but we have to deal with the integration somewhere and this seems like a reasonable place to do that. It might have been better to put this text in a -bis revision of RFC 7541, but we decided to leave that document as-is.
LGTM, this is a nice clarification that removes the possibility of a different interpretation that's known to have caused interoperability issues (nghttp2 vs haproxy). Let's merge it!
Oh I see this PR already being merged. Opened .
I think this PR is in the correct direction. Endpoints have to process instructions using dynamic table, even when they advertise SETTINGSMAXHEADERLISTSIZE of zero. That is because the default is 4096. We did fix this problem in QPACK, but HPACK had already shipped. OTOH, I have concerns regarding new text suggesting Dynamic Table Update Size be sent even when there is no change in the size.I agree with Willy, this is a really good clarification.