RE: SETTINGS_HEADER_TABLE_SIZE and ACK

The sender can use only a part of the header table.
For example, with a SETTINGS_HEADER_TABLE_SIZE of 4k, it may use only 2k for storing entries.
The receiver will have a 4k table, storing more entries than the sender. These entries stored only by the receiver are not a problem, as the sender will never refer to them, but only to those it has in its table.
There is a difficulty to access the entries from the static table: to know the index of the first entry in the static table, the sender needs to know how many entries are present in the whole table of the receiver. It can manage this by tracking the size of the entries in the part it doesn't use: this allows it to evict entries from the table as would the receiver, and therefore to know how many entries are in the header table.


Hervé.

> -----Original Message-----
> From: Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
> Sent: vendredi 18 octobre 2013 14:31
> To: ietf-http-wg@w3.org
> Subject: SETTINGS_HEADER_TABLE_SIZE and ACK
> 
> SETTINGS_HEADER_TABLE_SIZE is used to inform the size of header table to
> the other endpoint. Since the size of header table of the decoder side has to
> be matched to the one in the encoder side (otherwise, header table out-of-
> sync on eviction or out-of-bound index), the received peer may not want to
> accept the larger buffer size due to whatever reason (e.g., resource
> constraints or variable buffer size is not implemented, etc).
> 
> The HPACK-03 has a text to allow the receiver to choose smaller values in the
> acknowledgement, but now SETTINGS with ACK flags must not have any
> settings value, the peer is forced to accept the offer.
> 
> The SETTINGS_HEADER_TABLE_SIZE is special among the other settings. The
> others affect the receiver's capability, but it can regulate itself not to use
> more resources it wants (e.g., SETTINGS_MAX_CONCURRENT_STREAMS is
> informed as 500, but the receiver only uses 100). For
> SETTINGS_HEADER_TABLE_SIZE, there is no way but to just obey the
> informed value.
> 
> Best regards,
> Tatsuhiro Tsujikawa

Received on Friday, 18 October 2013 16:04:17 UTC