- From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Date: Sat, 26 Oct 2013 01:37:22 +0900
- To: Osama Mazahir <OSAMAM@microsoft.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAPyZ6=LEGc5hCMwUHHeg1e1S5pR+xj3jjBL4hrM9ATxj6Cq5-A@mail.gmail.com>
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 http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0222.html Best regards, Tatsuhiro Tsujikawa > ** > > Thanks,**** > > --Osama.**** >
Received on Friday, 25 October 2013 16:38:10 UTC