RE: HPACK encoder/decoder memory bounding

No, the settings are one-way.  If the other side’s decoder is advertising 4MB, you’re allowed to encode against that 4MB space.  However, you’re free to encode using less if you want.  What the encoder MUST track is:
•             The size of each entry before the section it wishes to use (but not the contents)
•             The section of the header table it wishes to use, entirely at its discretion
•             The size of each entry beyond the section it wishes to use (but not the contents), only if it wishes to reference the static table

In reality, the first is likely to be an empty set (the server will probably be using most recent entries first), the second is entirely under the server’s control; the third should be manageably small (a few hundred bytes at most) and can be discarded in extreme need.

However, the fact that the remote decoder advertises 4MB is independent of your own decode – you can advertise as small a decoder window as you want, and the other side’s encoder must obey.

From: Fred Akalin [mailto:akalin@google.com]
Sent: Friday, October 25, 2013 11:26 AM
To: Martin Thomson
Cc: Tatsuhiro Tsujikawa; Hervé Ruellan; Osama Mazahir; HTTP Working Group
Subject: Re: HPACK encoder/decoder memory bounding

On Fri, Oct 25, 2013 at 11:18 AM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 25 October 2013 11:11, Fred Akalin <akalin@google.com<mailto: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.