Canon CRF

herve.ruellan@crf.canon.fr

Canon, Inc.

3-30-2 Shimomaruko Ohta-ku, Tokyo 146-8501 Japan fujisawa.jun@canon.co.jp

Canon CRF

romain.bellessort@crf.canon.fr

Canon CRF

youenn.fablet@crf.canon.fr

Applications HTTPbis Working Group HTTP Header This document describes modifications of the proposed HTTP/2.0 header compression mechanism for the definition of the reference set used to encode a set of headers.

In HTTP/2.0, HTTP headers are compressed according to the HTTP/2.0 Headers Compression draft. This compression format relies on the previous set of headers to improve compression. Two consecutive sets of headers often comprise a significant number of headers in common. Encoding the differences between those two sets is generally more efficient than encoding the set of headers itself. The messages exchanged between a client and a server (or between a server and a client) may however comprise different types of header sets: GET requests and POST requests may have more differences than similarities; "200 OK" responses and "304 Not Modified" responses may be very different. In those cases, allowing the encoder to select a specific reference set of headers allows reducing the size of encoded headers. A new mechanism is proposed in this draft to allow the encoder defining a reference set of headers directly from the header indexing table.

This proposal builds on HTTP/2.0 Header Compression to further improve the compactness of HTTP headers representation. It reuses the notion of header group as defined in Header Delta-Compression for HTTP/2.0 in a more limited way. First, NO additional indexing structure or storage requirement is added to the existing mechanisms defined in HTTP/2.0 Header Compression. Second, the impact on implementations, particularly on decoder side, should be as limited as possible. This proposal may also bring processing improvements. qdfsq

Using this proposal, when encoding a new set of headers, the encoder indicates whether it relies on the default reference set (i.e. the previous set of headers) or whether it defines a specific reference set. A specific reference set is represented as a start index SI and a length L; the reference set is defined as the L headers occurring from index SI in the header indexing table. Once this specific reference set is defined, it is used in place of the default reference set to encode the new set of headers: only the differences between this specific reference set and the new set of headers are represented.

A new flag, REFERENCE_SET, is defined for the HEADERS frame. This flag uses bit 5 (0x10) and determines whether the default reference set or another one is used for the given Header Block. The value of 0 indicates that the default reference set (i.e. the previous set of headers) is used and the header block contains the differences between the reference set and the set of headers represented. The value of 1 indicates that the header block starts by the definition of a specific reference set, which is then followed by the differences between this specitic reference set and the set of headers represented.

A header block is organized in two parts: An optional reference set definition. This definition is present only if the REFERENCE_SET flag is set. A list of difference between the reference set and the encoded set of headers. The difference is represented as defined in HTTP/2.0 Header Compression.

A reference set is described on 2 bytes.

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-------------------+-------------------------------------------+ | Length (5) | Start Index (11) | +-------------------+-------------------------------------------+

The fields defining a reference set are: The length of the reference set, encoded on 5 bits. This length is comprised between 0 and 31. The index of the first entry of the reference set in the header table. If the reference set length is strictly greater than zero, the start index is encoded on 11 bits. If the length is equal to zero, the start index value is zero and is encoded on 3 bits.

If the reference set length is equal to zero, the reference set is empty and the reference set definition is optimized to use only one byte.

0 1 2 3 4 5 6 7 +-------------------+-----------+ | 0 | 0 | +-------------------+-----------+

This special case may be useful in a number of applications. First, it can allow a more compact encoding of a header set. For instance, measurements have shown that using the empty as the reference set is, for a fair number of test samples, more efficient than using the default reference set for HTTP responses. Second, using the empty set allows reducing the coding complexity for the encoder. This can be useful for server or intermediaries under a heavy load. It could also be used by lightweight devices that prefer using static encoding strategies.

The definition of a specific reference set is based on a contiguous set of header entries in the header indexing table. Removing a header from the set is typically encoded using one or two bytes. It may be beneficial to optimize the removal of a header in the case of a specific reference set which would be constituted of several contiguous sets of headers separated by a few other headers not belonging to the set of headers to encode. For instance, for a sixteen headers reference set, two bytes are needed to define all the removals as an array of booleans. Two bytes is also the cost for encoding one or two removals using HTTP/2.0 Header Compression. Once a reference set of sixteen headers contains more than two headers that should be removed, using an array of booleans is more efficient. Early experiments show that this approach allows selecting larger reference sets and brings noticeable compaction benefits. Additional investigation should be done to understand how optimized indexing table building would decrease the benefits. Encoding the removals as an array of booleans has also the advantage of making decoder implementations simpler. As removals are not encoded in the same way as indexed values, there is no problem of handling possible discrepancies between the index values in the reference set and the index values in the header table. Optimized encoding of the header removal could also be envisioned for the default reference set. In such a case, an ordering of the default reference set headers should be defined. Such an ordering could be based on the indexes of the headers. Additional study should be conducted to evaluate whether this feature should be a mandatory part of the specific reference set definition or an option. Several ways to switch on/off this feature may be envisioned: using a specific HEADERS frame flag; using a specific bit within the reference set definition. Using a specific HEADERS frame flag would be appropriate if using deletions for the default reference set is envisioned.

Rules to handle incremental indexing and batch entry removal in case of buffer overflow are defined in HTTP/2.0 Header Compression. New rules may be defined when specific reference sets are used. Incrementally indexed entries could be inserted just after the last entry in the header indexing table that is part of the specific reference set. If entry removal is needed, removal could start with the first entry after the last incrementally indexed header or just after the last entry that is part of the specific reference set. Additional study of the processing cost of these rules should be envisioned.

A single representation of the reference header set is currently specified. This representation generally requires 2 bytes to be encoded. Tests involving a single byte representation have been made and have shown a small benefit. Based on additional tests, a more optimized representation could be defined.

If the same header happens in several reference sets, it may be beneficial to insert such header at several places in the header indexing table. While it makes the header indexing table size bigger, it may further improve future reference set definitions. This approach is already feasible by encoding a header literally several times. It may be optimized by enabling to insert at a new place a header that is already represented as an indexed header.

TBD.

This memo includes no request to IANA.

After the transmission of a "200 OK" and "304 Not Modified" responses, the header indexing table is as follows:

+---------+----------------+---------------------------+ | Index | Header Name | Header Value | +---------+----------------+---------------------------+ | 0 | :status | 200 | +---------+----------------+---------------------------+ | 1 | cache-control | public | +---------+----------------+---------------------------+ | 2 | content-type | text/html | +---------+----------------+---------------------------+ | 3 | content-length | 32 | +---------+----------------+---------------------------+ | 4 | expires | 01 Apr 2014 00:00:00 GMT | +---------+----------------+---------------------------+ | 5 | :status | 304 | +---------+----------------+---------------------------+ | 6 | expires | 01 Apr 2015 00:00:00 GMT | +---------+----------------+---------------------------+

The current reference set is:

5 :status: 304 6 expires: 01 Apr 2015 00:00:00 GMT

The next response is a "200 OK" response. The following headers have to be encoded:

:status: 200 cache-control: public content-type: text/html content-length: 1034 expires: 01 Apr 2016 00:00:00 GMT

The following stream illustrates the "200 OK" response header set encoded as reference to the previous message:

0x85 (Indexed header, index = 5, removal) 0x86 (Indexed header, index = 6, removal) 0x80 (Indexed header, index = 0) 0x81 (Indexed header, index = 1) 0x82 (Indexed header, index = 2) 0x44 (Literal header with incremental indexing, name index = 3) 0x04 (Header value string length = 4) 1034 0x45 (Literal header with incremental indexing, name index = 4) 0x18 (Header value string length = 24) 01 Apr 2016 00:00:00 GMT

The size of the encoded header set is 37 bytes.

The following stream illustrates the "200 OK" response header set encoded as reference to an empty reference set:

0x00 (Empty reference set) 0x80 (Indexed header, index = 0) 0x81 (indexed header, index = 1) 0x82 (indexed header, index = 2) 0x44 (Literal header with incremental indexing, name index = 3) 0x04 (Header value string length = 4) 1034 0x45 (Literal header with incremental indexing, name index = 4) 0x18 (Header value string length = 24) 01 Apr 2016 00:00:00 GMT

The size of the encoded header set is 36 bytes.

The following stream illustrates the "200 OK" response header set encoded as reference to a specific reference set (Length = 3, Start Index = 0):

0x18 0x00 (specific reference set, length = 3, start index = 0) 0x44 (Literal header with incremental indexing, name index = 3) 0x04 (Header value string length = 4) 1034 0x45 (Literal header with incremental indexing, name index = 4) 0x18 (Header value string length = 24) 01 Apr 2016 00:00:00 GMT

The size of the encoded header set is 34 bytes.