Re: Header Compression Overview

Minor correction with regards to substitution indexing for literal headers...

You can use substitution to change both the name and value of existing
header positions, making it fairly simple to reuse existing memory
slots.

Generally speaking, an intelligent implementation is likely going to
want to make smart use of substitution indexing as much as possible,
in order to keep the compression context from filling up and incurring
more frequent eviction operations.

On Mon, Jul 1, 2013 at 11:32 AM, James M Snell <jasnell@gmail.com> wrote:
[snip]
>
> We have an index position for the header field foo1 but not the full
> name+value pair "foo1=bar". Remember when I briefly mentioned
> Incremental Indexing vs. Substitution indexing? We need to make a
> decision. When Incremental Indexing, I can add "foo1 = new" as an
> entirely new entry in the dynamic table (#2) or I can replace the
> value of the existing "foo1 = bar" entry sitting at index #3. The
> choice is entirely up to the sender and can be based on a number of
> factors... the most important of which is basic memory management. For
> now, let's keep things simple and use Incremental Indexing. We want to
> minimize the amount of data we're going to send, however, so instead
> of sending the header field name as a length prefixed string, we're
> going to reference the existing index position and send along a new
> value ( 0x43 0x03 0x6E 0x65 0x77 ).
>
...
>
> Another consideration that must be carefully weighed is the choice
> between Incremental and Substitution indexing. If an implementation
> always chooses to use Incremental Indexing, Eviction will become the
> only reliable means of memory management. Long lived connections will
> build up full compression contexts that tie up a potentially
> significant amount of memory. This could be dangerous, especially
> since there is no explicit mechanism for deleting items from the
> dynamic table.
>
...
>
> Substitution Indexing provides only a partial solution to this problem
> by making it possible to reuse existing index positions so long as the
> header field name remain the same. There still exists the possibility
> of tying up memory, however, if there are a large number of different
> header names.
>[snip]

Received on Monday, 1 July 2013 20:32:52 UTC