Re: Clarification of dynamic table size change

[Cory Benfield <[e-mail]>]

> On 19 Oct 2015, at 17:26, Tatsuhiro Tsujikawa <[e-mail]> wrote:
> ​Could be.  But I don't think we mixed HTTP/2 layer and HPACK layer.  More specifically, we input the max header table size to HPACK, and see what it react to it in this case.  It is specific to HPACK implementation behaviour.
> 
> In general, we choose simpler path in HTTP/2​, I mean single execution path rather than "do this if we have x otherwise do that".  For example, we require client preface even if we negotiated HTTP/2 over ALPN.
> We send HTTP2-Settings in HTTP Upgrade request, but still we need to send SETTINGS frame in client preface.
> Taking into account of this split, it is more natural to always send header table size update as acknowledgement for SETTINGS_HEADER_TABLE_SIZE.  We can do more strict validation about the peer; it might forget to implement it anyway.

I don’t know that I buy that. The acknowledgement for SETTINGS_HEADER_TABLE_SIZE is a SETTINGS frame with the ACK flag set. Why is further acknowledgement required? As far as I can see it, there are two (slightly different) values here:

- SETTINGS_HEADER_TABLE_SIZE is the *maximum* value the encoder may use.
- Whatever is sent by the HPACK encoder in a dynamic table size update is the *actual* value being used.

You may be able to change the first without affecting the second (e.g. if you raise or leave unchanged the value of SETTINGS_HEADER_TABLE_SIZE). In the case that the second is not affected, it seems like unnecessary noise for the encoder to be forced to emit a dynamic table size update that has no change.

I don’t strongly object to adding an erratum to RFC 7541 that requires that a dynamic table update be emitted for any change to SETTINGS_HEADER_TABLE_SIZE, even if that change does not actually affect the size of the table the encoder will use, but my current reading of the specification does not require that such an update be emitted.

Cory