Re: Header Compression Clarifications

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.

Amos

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