- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 8 Jul 2014 10:43:45 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, Jason Greene <jason.greene@redhat.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Johnny Graettinger <jgraettinger@chromium.org>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 7 July 2014 22:36, Greg Wilkins <gregw@intalio.com> wrote: > but I have pointed out in the past that the encoder header size is a > reasonable indication of additional memory requirements represented by the > header block. The highly compressed fields within a header block are the > indexed ones, and they reference memory in the header set that is already > constrained by a setting. Not really. The math is pretty simple: uncompressed_size[max] = compressed_size * header_table_size / 2 So yes, constrained, but not really reasonable.
Received on Tuesday, 8 July 2014 17:44:15 UTC