- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Thu, 24 Jul 2014 17:29:18 +0000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Martin Thomson <martin.thomson@gmail.com>
- CC: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, 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>
There's no opcode because it's the compressor who wants (wanted) to clear the reference set since they know that what they're encoding will be quicker if the set is gone, but it's the decompressor that wants to clear the dynamic set to reduce its memory commitment. (The compressor can partially discard the contents of the dynamic table any time it wants without need to notify the other side it has done so.) There are no HPACK opcodes sent from decompressor to compressor, unless you want to mix information across the two directions. That seems like even more of a complication to me. SETTINGS and the corresponding ACK are effectively the communication channel from decompressor back to the compressor. -----Original Message----- From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk] Sent: Thursday, July 24, 2014 7:35 AM To: Martin Thomson Cc: Tatsuhiro Tsujikawa; Mark Nottingham; David Krauss; Greg Wilkins; HTTP Working Group; Michael Sweet; Jason Greene; Roberto Peon; Ilari Liusvaara Subject: Re: Recovery from decompression failure (was: Re: Cost analysis: (was: Getting to Consensus: CONTINUATION-related issues)) In message <CABkgnnV82KWYVzHKNzFH7fXp4hZoC7vsqGsJcPDRep-O1qKuQQ@mail.gmail.com> , Martin Thomson writes: >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. The safest and by far most efficient approach is to have an oopcode for it. Why that was felt necessary for the reference set but not for the dynamic set is a good question. Resizing the dynamic set to zero and then back up invites the receivers to complicate their memory management because the most likely resize of the dynamic set isn't going to be one. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Thursday, 24 July 2014 17:29:48 UTC