- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Fri, 23 Oct 2015 19:15:19 +0300
- To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Cc: Hervé Ruellan <herve.ruellan@crf.canon.fr>, Cory Benfield <cory@lukasa.co.uk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 <herve.ruellan@crf.canon.fr> > 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
Received on Friday, 23 October 2015 16:15:46 UTC