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.  Each endpoint has an HPACK encoder context and an HPACK decoder context that are used for encoding and decoding all field blocks.  COMPRESSION defines the dynamic table, which is the primary state for each context. The dynamic table has a maximum size that is set by an HPACK decoder. An endpoint communicates the size chosen by its HPACK decoder context using the SETTINGS_HEADER_TABLE_SIZE setting; see SettingValues. When a connection is established, the dynamic table size for the HPACK decoder and encoder at both endpoints starts at 4,096 bytes, the initial value of the SETTINGS_HEADER_TABLE_SIZE setting. Any change to the maximum value set using SETTINGS_HEADER_TABLE_SIZE takes effect when the endpoint SettingsSync.  The HPACK encoder at that endpoint can set the dynamic table to any size up to the maximum value set by the decoder.  An HPACK encoder declares the size of the dynamic table with a Dynamic Table Size Update instruction (COMPRESSION). Once an endpoint acknowledges a change to SETTINGS_HEADER_TABLE_SIZE that reduces the maximum below the current size of the dynamic table, its HPACK encoder MUST start the next field block with a Dynamic Table Size Update instruction that sets the dynamic table to a size that is less than or equal to the reduced maximum; see COMPRESSION. An endpoint MUST treat a field block that follows an acknowledgment of the reduction to the maximum dynamic table size as a ConnectionErrorHandler of type COMPRESSION_ERROR if it does not start with an conformant Dynamic Table Size Update instruction. </ins> 5. A "stream" is an independent, bidirectional sequence of frames

Related discussion:
text: Text added by states: An encoder sends a Dynamic Table Size Update instruction after acknowledging a change of SETTINGSHEADERTABLESIZE 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. I am not sure if this correct interpretation of RFC 7541, and also am concerned that this text might cause new interoperability issues. states: A change in the maximum size of the dynamic table is signaled via a dynamic table size update (see Section 6.3). This dynamic table size update MUST occur at the beginning of the first header block following the change to the dynamic table size. In HTTP/2, this follows a settings acknowledgment (see Section 6.5.3 of [HTTP2]). As can be seen, this paragraph of RFC 7541 starts "a change." When an HTTP/2 endpoint is using an HPACK encoder with a dynamic table of size 4,096 (the default) and receives SETTINGSMAXHEADERLISTSIZE of 4096, it is not changing the size of the dynamic table. My interpretation of RFC 7541 would be that it does not require Dynamic Table Update Size to be sent when the table size remains the same. Interoperability-wise, do existing servers respond with a Dynamic Table Update Size instruction when the client sends SETTINGSMAXHEADERLIST_SIZE no less than 4096? It seems to me that this newly added text suggest such behavior is required, but I'm not sure if many servers behave as such. added text indicating that endpoints MAY error-close the connection when not seeing such behavior. Even if we are to agree that Dynamic Table Size Update MUST be sent in all cases, I'm concerned that we might see more interoperability issues by suggesting that endpoints can error-close.
Yup, I think this works well. Nice work NAME