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

Re: HPACK encoder/decoder memory bounding

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Sat, 26 Oct 2013 01:37:22 +0900
Message-ID: <CAPyZ6=LEGc5hCMwUHHeg1e1S5pR+xj3jjBL4hrM9ATxj6Cq5-A@mail.gmail.com>
To: Osama Mazahir <OSAMAM@microsoft.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Oct 25, 2013 at 11:09 AM, Osama Mazahir <OSAMAM@microsoft.com>wrote:

>  Based on my understanding, the encoder and decoder have to have the
> exact same value for max-header-table-size so that the indices match.  So
> if the client advertises SETTINGS_HEADER_TABLE_SIZE=5MB then that means the
> client-decoder is using a header-table with maxsize=5MB.  Which means the
> server-encoder also has to use a header-table of maxsize=5MB.  But if the
> server only wants to use 4KB of encoder space then after storing 4KB worth
> of header name/values, it can only reuse from the initially stored 4KB or
> emit literals (either as-is or Huffman encoded).****
> ** **
> So it seems to bound its memory usage, the server (in the above example)
> has to be choosy in what it adds to the server-encoder header-table because
> once something is added it cannot be removed (unless it decides to expand
> to 5MB+)?****
> **

Not necessarily.
They cannot be removed but eventually evicted. The encoder only uses
entries within first 4KB and it can push new headers to index-0. One tricky
part is that encoder must drop the entry from the reference table by
emitting indexed repr when the entry is in the reference set and out of
first 4KB.

The relevant discussion is

Best regards,
Tatsuhiro Tsujikawa

> **
> Thanks,****
> --Osama.****
Received on Friday, 25 October 2013 16:38:10 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:38 UTC