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

Re: Header Compression Clarifications

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 05 Jul 2013 03:34:08 +1200
Message-ID: <51D595F0.2020400@treenet.co.nz>
To: ietf-http-wg@w3.org
On 5/07/2013 2:47 a.m., Michael Sweet wrote:
> Hervé,
> On Jul 4, 2013, at 10:06 AM, RUELLAN Herve wrote:
>> I'm not sure I understand correctly your comment.
>> One of the goal of the eviction mechanism is to provide a solution to the possible problem of header table fragmentation over long-lasting connections: if the header table is full of very small entries, then substituting a long entry to one of these small entries will make the header table grow over its maximum allowed size. The eviction mechanism enable to allow for such a substitution while still keeping the header table under its maximum allowed size.
> Right, I am just addressing the "I want to add a name/value pair that is 100 bytes long but the header table size is 50 bytes." - what happens if you try substitution/incremental indexing with a name/value pair that is larger than the header table?
> We *could* just say that doing so empties the header table and doesn't add the pair to it (because it won't fit), but I don't think that is particularly useful.
> Instead I am suggesting that such name/value pairs must always use the Literal Header without Indexing representation - that allows for header name reuse (e.g. cookie) and otherwise preserves the header table.  Otherwise I see certain headers (e.g. cookie) effectively killing any benefits of the header compression scheme.

+1. This sounds like a useful and clean solution to that particular 
class of edge case.

Received on Thursday, 4 July 2013 15:34:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC