Re: Clarification of dynamic table size change

[Ilari Liusvaara <[e-mail]>]

On Sat, Oct 24, 2015 at 12:45:49AM +0900, Tatsuhiro Tsujikawa wrote:
> 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..

The way negotiation works:
- Decoder side sets the upper bound via SETTINGS_HEADER_TABLE_SIZE.
- Encoder side sets the actual size via dynamic table updates (inside
  HPACK bitstream) within limits set by decoder.
- If between headers decoder reduces the limit below size signaled by
  encoder, the encoder must first reduce the table size to the minimum
  it was between the frames or less (it can then increase it up to
  current limit).

As example of the last point:
[4k dynamic table size in use]
--> HEADERS
<-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=4k)
<-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=2k)
<-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=4k)
<-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=8k)
<-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=6k)
--> HEADERS

The second HEADERS must first reduce the dynamic table to at most
2k. It can then increase dynamic table size to up to 6k.


-Ilari