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: Hi NAME I'll have to clone your repo and run the diff here by hand then because I can't figure in this horrible interface how to view the complete set of changes at once resulting from multiple subsequent changes. And it will be easier to reread Kazuho's proposal in context. Regarding "do we want" I didn't imply that we love this situation, just "do we want in order to support this interpretation of the protocol", given that the current text never explicitly states that (as Cory mentioned a while ago, the settings change is acked by a the settings ack) and that even the protocol's original co-author back then already stated that it wasn't meant to be interpreted that way ( URL ). Sure, the result is that we have what we have and we have to deal with it in the best way possible. In that spirit I think that Kazuho's proposal tries to be as closed as possible to the current state of deployment by indicating how some implementations behave vs what others expect and suggesting not to play in the gray area there.
Hervé's post there is quite useful, yes. That supports this overall view. I've cleaned up the comments on the diff view; let me know if what you see works. The diff overall is fairly clean (it's mostly additions).
I'm just a bit confused, where am I supposed to see the unified diff ? the only way I know is by clicking on each individual commit, which is the solution I find inconvenient :-/ Do I have to add a magic ".patch" in the URL bar somewhere ?
There's a "Files changed" tab toward the top of the page: ! Adding ".patch" to the URL is a neat hack for finding something you can download, but usually I find that pulling from the branch is nicer to work with.
Thanks for pointing that one, I always thought it only contained the original PR's changes, not the latest proposed ones :-) I'm seeing this part which remains confusing: "Any change to the maximum value set by the decoder takes effect when..." which I'm reading as "the decode first sets a size, then any change to this size ...", thus reinforces what most servers currently do. I think Kazuho's proposal to move the sentence about initial values solves this: "The dynamic table has a maximum size that is set by a decoder using the SETTINGSHEADERTABLESIZE setting; see XXX.