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

Issue #155: Capping header compression index values

From: James M Snell <jasnell@gmail.com>
Date: Mon, 1 Jul 2013 13:58:21 -0700
Message-ID: <CABP7RbeJ-sxWn_KZV9jeN9ysZeSM7K0KwfOhy1PNPDLVJ+bm7w@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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

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