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

Re: HPACK encoder/decoder memory bounding

From: Hervé Ruellan <ruellan.crf@gmail.com>
Date: Fri, 25 Oct 2013 18:38:31 +0200
Message-ID: <CAAVj6kub_qnG7Jq0L=mmcxypVQTNzrGGCudxUNdcRgTrsS1g4g@mail.gmail.com>
To: Osama Mazahir <OSAMAM@microsoft.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Osama,

We discussed on this topic in the thread starting at:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0221.html.

Basically, an encoder can choose to keep only the first 4 KB of its table,
discarding the rest. It will just not make any reference to the entries in
the table above the first 4 KB.
It the encoder wants also to reference the static table, this is more
complex (see the referred to thread for more details). It will work if the
maximum table size is 8 KB, and the encoder keeps only 4 KB of it, it will
not really work if the encoder wants to only keep 4 KB of a 5MB table.

Hervé.


On Fri, Oct 25, 2013 at 4: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+)?****
>
> ** **
>
> Thanks,****
>
> --Osama.****
>
Received on Friday, 25 October 2013 16:38:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC