Issue #155: Capping header compression index values

https://github.com/http2/http2-spec/issues/155

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.

Received on Monday, 1 July 2013 20:59:08 UTC