Re: HPACK encoder/decoder memory bounding

Okay, I was misunderstanding that, too! I think I'm clear on everything
now. In that case, I guess there's not a great need for negotiating that
parameter, then.

On Fri, Oct 25, 2013 at 11:31 AM, Mike Bishop
<Michael.Bishop@microsoft.com>wrote:

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