Re: HPACK encoder/decoder memory bounding

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

> 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.