Module httlib_hpack::table

Provides an implementation of the HPACK indexing tables.

Indexing table is a list, to which the HPACK saves the commonly used headers. Each entity indexes headers per connection, separately for incoming (decoding) and for outgoing (encoding) data.

The numbering of entries starts with index ‘1’ and the first 61 headers are static items, keeping their position in the table. These are specific headers, provided by the HPACK specification, based on their statistical relevance, and therefore deserve their permanent position in the table.

Other headers are listed in the table from position 62 onwards and are called dynamic headers. Header entries are ordered as FIFO (first-in, first-out) and duplicated entries are allowed. Dynamic headers are always inserted at index 62, which shifts all indexes of the existing custom headers one step lower. For the dynamic part of the table, we need to set a limit of how many bytes of the dynamic headers the table is allowed to store. When, while adding a header, this limit is crossed, the headers are evicted from the back of the table, so the table never exceeds the limit.

This specific functioning is addressed in the HPACk specification as two separate tables, to which it refers as the static and the dynamic table. However, we are dealing with a single list, where two tables are combined into a single address space for defining index values.

The illustration below shows the structure of the indexing table.

<---------- Index Address Space --------->
<    Static Table   ><   Dynamic Table   >
+--+-------------+--++--+-------------+--+
|01|     ...     |61||62|     ...     |XX|
+--+-------------+--++II+-------------+DD+
 
II = Insertion point
DD = Dropping point

Let's see how such a table is used by entities. When a client sends the request, it can indicate in the header block that a particular header and potentially also its value, should be indexed. The table for outgoing headers on the client's side would thus look something like this:

Index	Name	Value
01	:authority
02	:method	GET
..	...	...
62	name1	value1
63	value2	value2

On the server’s side, when it reads the headers it would create a table that would look exactly the same. If the next client request would send the same headers, it could simply send a header block including only header indexes:

62 63 64

The server will then look up and expand into the full headers what those indexes represent. This essentially explains the whole concept. The mechanism is innovative and highly efficient. I guess no added discussion on its effects on the performance is necessary since there are plenty of benchmarks, proving its efficacy available online.

Structs

Table	A table representing a single index address space for headers where the static and the dynamic table are combined.
TableIter	Represents an iterator through all the entries in the table.