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:25:48 -0700
Message-ID: <CANUYc_QbCL4VFENxh3C+T2PG56jsqhR3ZDpHgaaTW1zYCOnreg@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>
On Fri, Oct 25, 2013 at 11:18 AM, Martin Thomson

> On 25 October 2013 11:11, Fred Akalin <akalin@google.com> wrote:
> > SETTINGS_HEADER_TABLE_SIZE is already special, since it requires an ack.
> It
> > doesn't seem that much more onerous to make it negotiable.
> All settings require an ACK.

I see, I must have misunderstood something somewhere.

> 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.
> An encoder is not forced to track the entire table.  It only needs to
> track the entries it wishes to use again.
> Unless it wants to use the static table, in which case it has to track
> the size of all the entries.  But it has a measure of control over
> that too, since it decides what is added to the table in the first
> place.

Right, if I get a SETTINGS_HEADER_TABLE_SIZE=4MB and I can only afford to
store 4k, I can choose to encode things in such a way as to avoid using
more than 4k, avoiding the static table, etc. However, once I ack that
setting, the other endpoint will presumably use the entire 4MB for its
encoding state, so I'm forced to use 4MB for my own decoding state. Which
seems like a problem.
Received on Friday, 25 October 2013 18:26:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC