Capping Header Compression Index Values

[jasnell]

When using Literal Representations with Incremental Indexing as defined by the current Header Compression draft, a long lived connection could potentially end up with rather large table index values... Specifically, every Literal-with-Incremental causes the table index to increment by one monotonically without limit. Index positions are represented using a variable length integer syntax that has no upper limit, as the index position increases, the number of bytes necessary to represent the index on the wire increases. The result is that as the number of Literal-with-Incremental operations increase, the efficiency of our compression will slowly but certainly decrease.

The solution, of course, is to favor substitution indexing as much as possible within long running connections.

One possible strategy is to use incremental indexing only until a fixed range of index positions have been used (1...n). After that range has been exhausted, use substitution indexing starting back from the initial position in the range... Where this strategy might become unworkable, however, is when items within that fixed range are evicted. It is currently not clear in the header compression draft whether a Literal-with-Substitution-Indexing is allowed to reuse an index position that has previously been evicted.