Re: Clarification of dynamic table size change

[Tatsuhiro Tsujikawa <[e-mail]>]

Hi,

On Fri, Oct 23, 2015 at 1:18 AM, Hervé Ruellan <[e-mail]>
wrote:

> I agree that the wording is ambiguous here.
>
> However, my reading is the same a Cory's: you don't have to send a dynamic
> table update if the *actual* value is not changed.
>
>
​I also found the discussion in this ML indicating you are right.  Thank
you for clarification.
I have to ask one more question: what is *actual* value? Is it the table
size both peer agreed before reading SETTINGS, or the value in
SETTINGS_HEADER_TABLE_SIZE decoder sent?

I think this is a good item to add in FAQ section..


Best regards,
Tatsuhiro Tsujikawa
​​




> Hervé
>
> On 19/10/15 19:15, Cory Benfield wrote:
>
>>
>> > On 19 Oct 2015, at 17:26, Tatsuhiro Tsujikawa <[e-mail]
>> > <mailto:[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
>>
>
>