W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: HPACK encoder/decoder memory bounding

From: Fred Akalin <akalin@google.com>
Date: Fri, 25 Oct 2013 11:11:09 -0700
Message-ID: <CANUYc_SW0zuw=H7syN90wgMM4JquvU3+1VEKakHWeDHcveN-qQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Hervé Ruellan <ruellan.crf@gmail.com>, Osama Mazahir <OSAMAM@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Filed https://github.com/http2/http2-spec/issues/300

On Fri, Oct 25, 2013 at 10:46 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 25 October 2013 10:37, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
> wrote:
> > This greatly simplifies the things.
>
> It does not simplify things.  Primarily because settings become
> negotiable, which is a significant complication.  Is this the only
> setting that is negotiable?  How do we signal that settings are
> negotiable?
>

SETTINGS_HEADER_TABLE_SIZE is already special, since it requires an ack. It
doesn't seem that much more onerous to make it negotiable.

At worst, the cost to an encoder of an increased header table size
> setting is an inability to use the static header table.  That means,
> worst case, the encoder has to send a few more literals on the wire.
> This is not significantly worse than sending
> SETTINGS_HEADER_TABLE_SIZE=0.  In some respects, it's actually better.
>

Remember that the setting applies to both contexts, so the other endpoint
is forced to keep a full-size context for the decoding state, or close the
connection. That doesn't seem good.
Received on Friday, 25 October 2013 18:11:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC