- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 24 Jul 2014 06:12:18 -0700
- To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, David Krauss <potswa@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>, Jason Greene <jason.greene@redhat.com>, Roberto Peon <grmocg@gmail.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
On 23 July 2014 17:55, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote: > So decoder changes table size only when it sees encodong context update? It > works, but it has a disadvantage because decoder has to retain header table > size unchanged until HEADERS/PP are received, which might never arrive. > On the other hand, SETTINGS ACK is guaranteed to arrive (and we have a > timeout for it). If decoder changes header table size, including eviction to > the lowest value it advertised when it received SETTINGS ACK, encoder only > sends its selected value based on the last seen value in SETTINGS decoder > sent. This is because decoder already performed eviction based on the lowest > value and encoding context update comes after SETTINGS ACK. Yes, I would use SETTINGS ACK as the marker to use for trimming the header table down, but still require the next header block after that to include a context update. That might mean two rounds of eviction if the encoder chooses to use a smaller table size, but that's the safest approach.
Received on Thursday, 24 July 2014 13:12:46 UTC