draft-ietf-httpbis-header-compression-08.txt   draft-ietf-httpbis-header-compression-09.txt 
HTTPbis Working Group R. Peon HTTPbis Working Group R. Peon
Internet-Draft Google, Inc Internet-Draft Google, Inc
Intended status: Standards Track H. Ruellan Intended status: Standards Track H. Ruellan
Expires: December 19, 2014 Canon CRF Expires: February 01, 2015 Canon CRF
June 17, 2014 July 31, 2014
HPACK - Header Compression for HTTP/2 HPACK - Header Compression for HTTP/2
draft-ietf-httpbis-header-compression-08 draft-ietf-httpbis-header-compression-09
Abstract Abstract
This specification defines HPACK, a compression format for This specification defines HPACK, a compression format for
efficiently representing HTTP header fields in the context of HTTP/2. efficiently representing HTTP header fields in the context of HTTP/2.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at <https:// mailing list (ietf-http-wg@w3.org), which is archived at <https://
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2014. This Internet-Draft will expire on February 01, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. HPACK Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2. HPACK Overview . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Decoding Process Overview . . . . . . . . . . . . . . . . . . 6 3. Compression Process Overview . . . . . . . . . . . . . . . . 5
3.1. Encoding and Decoding Contexts . . . . . . . . . . . . . 6 3.1. Header List Ordering . . . . . . . . . . . . . . . . . . 6
3.2. Header Table . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Encoding and Decoding Contexts . . . . . . . . . . . . . 6
3.3. Reference Set . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Indexing Tables . . . . . . . . . . . . . . . . . . . . . 6
3.4. Header Field Representation . . . . . . . . . . . . . . . 7 3.3.1. Static Table . . . . . . . . . . . . . . . . . . . . 7
3.5. Header Field Emission . . . . . . . . . . . . . . . . . . 9 3.3.2. Header Table . . . . . . . . . . . . . . . . . . . . 7
4. Header Block Decoding . . . . . . . . . . . . . . . . . . . . 9 3.3.3. Index Address Space . . . . . . . . . . . . . . . . . 7
4.1. Header Field Representation Processing . . . . . . . . . 9 3.4. Header Field Representation . . . . . . . . . . . . . . . 8
4.2. Reference Set Emission . . . . . . . . . . . . . . . . . 10 4. Header Block Decoding . . . . . . . . . . . . . . . . . . . . 8
5. Header Table Management . . . . . . . . . . . . . . . . . . . 10 4.1. Header Block Processing . . . . . . . . . . . . . . . . . 8
5.1. Maximum Table Size . . . . . . . . . . . . . . . . . . . 10 4.2. Header Field Representation Processing . . . . . . . . . 9
5.2. Entry Eviction When Header Table Size Changes . . . . . . 11 5. Header Table Management . . . . . . . . . . . . . . . . . . . 9
5.3. Entry Eviction when Adding New Entries . . . . . . . . . 12 5.1. Maximum Table Size . . . . . . . . . . . . . . . . . . . 9
6. Primitive Type Representations . . . . . . . . . . . . . . . 12 5.2. Entry Eviction when Header Table Size Changes . . . . . . 10
6.1. Integer representation . . . . . . . . . . . . . . . . . 12 5.3. Entry Eviction when Adding New Entries . . . . . . . . . 11
6.2. String Literal Representation . . . . . . . . . . . . . . 13 6. Primitive Type Representations . . . . . . . . . . . . . . . 11
7. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Integer Representation . . . . . . . . . . . . . . . . . 11
7.1. Indexed Header Field Representation . . . . . . . . . . . 14 6.2. String Literal Representation . . . . . . . . . . . . . . 12
7.2. Literal Header Field Representation . . . . . . . . . . . 15 7. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1. Literal Header Field with Incremental Indexing . . . 15 7.1. Indexed Header Field Representation . . . . . . . . . . . 13
7.2.2. Literal Header Field without Indexing . . . . . . . . 16 7.2. Literal Header Field Representation . . . . . . . . . . . 14
7.2.3. Literal Header Field Never Indexed . . . . . . . . . 17 7.2.1. Literal Header Field with Incremental Indexing . . . 14
7.3. Encoding Context Update . . . . . . . . . . . . . . . . . 18 7.2.2. Literal Header Field without Indexing . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.2.3. Literal Header Field never Indexed . . . . . . . . . 16
8.1. Probing Header Table State . . . . . . . . . . . . . . . 20 7.3. Header Table Size Update . . . . . . . . . . . . . . . . 17
8.1.1. Applicability to HPACK and HTTP . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1.2. Mitigation . . . . . . . . . . . . . . . . . . . . . 21 8.1. Probing Header Table State . . . . . . . . . . . . . . . 18
8.1.3. Never Indexed Literals . . . . . . . . . . . . . . . 22 8.1.1. Applicability to HPACK and HTTP . . . . . . . . . . . 19
8.2. Static Huffman Encoding . . . . . . . . . . . . . . . . . 22 8.1.2. Mitigation . . . . . . . . . . . . . . . . . . . . . 19
8.3. Memory Consumption . . . . . . . . . . . . . . . . . . . 22 8.1.3. Never Indexed Literals . . . . . . . . . . . . . . . 20
8.4. Implementation Limits . . . . . . . . . . . . . . . . . . 23 8.2. Static Huffman Encoding . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8.3. Memory Consumption . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.4. Implementation Limits . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication . . . . . . . . . . . . . . . . . . . . 24 publication) . . . . . . . . . . . . . . . . . . . . 23
A.1. Since draft-ietf-httpbis-header-compression-07 . . . . . 25 A.1. Since draft-ietf-httpbis-header-compression-08 . . . . . 23
A.2. Since draft-ietf-httpbis-header-compression-06 . . . . . 25 A.2. Since draft-ietf-httpbis-header-compression-07 . . . . . 23
A.3. Since draft-ietf-httpbis-header-compression-05 . . . . . 25 A.3. Since draft-ietf-httpbis-header-compression-06 . . . . . 24
A.4. Since draft-ietf-httpbis-header-compression-04 . . . . . 26 A.4. Since draft-ietf-httpbis-header-compression-05 . . . . . 24
A.5. Since draft-ietf-httpbis-header-compression-03 . . . . . 26 A.5. Since draft-ietf-httpbis-header-compression-04 . . . . . 24
A.6. Since draft-ietf-httpbis-header-compression-02 . . . . . 26 A.6. Since draft-ietf-httpbis-header-compression-03 . . . . . 25
A.7. Since draft-ietf-httpbis-header-compression-01 . . . . . 26 A.7. Since draft-ietf-httpbis-header-compression-02 . . . . . 25
A.8. Since draft-ietf-httpbis-header-compression-00 . . . . . 27 A.8. Since draft-ietf-httpbis-header-compression-01 . . . . . 25
Appendix B. Static Table . . . . . . . . . . . . . . . . . . . . 27 A.9. Since draft-ietf-httpbis-header-compression-00 . . . . . 25
Appendix C. Huffman Code . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Static Table Definition . . . . . . . . . . . . . . 26
Appendix D. Examples . . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Huffman Code . . . . . . . . . . . . . . . . . . . . 28
D.1. Integer Representation Examples . . . . . . . . . . . . . 35 Appendix D. Examples . . . . . . . . . . . . . . . . . . . . . . 34
D.1.1. Example 1: Encoding 10 Using a 5-bit Prefix . . . . . 35 D.1. Integer Representation Examples . . . . . . . . . . . . . 34
D.1.2. Example 2: Encoding 1337 Using a 5-bit Prefix . . . . 36 D.1.1. Example 1: Encoding 10 Using a 5-bit Prefix . . . . . 34
D.1.3. Example 3: Encoding 42 Starting at an Octet Boundary 37 D.1.2. Example 2: Encoding 1337 Using a 5-bit Prefix . . . . 34
D.2. Header Field Representation Examples . . . . . . . . . . 37 D.1.3. Example 3: Encoding 42 Starting at an Octet Boundary 35
D.2.1. Literal Header Field with Indexing . . . . . . . . . 37 D.2. Header Field Representation Examples . . . . . . . . . . 35
D.2.2. Literal Header Field without Indexing . . . . . . . . 38 D.2.1. Literal Header Field with Indexing . . . . . . . . . 35
D.2.3. Literal Header Field never Indexed . . . . . . . . . 38 D.2.2. Literal Header Field without Indexing . . . . . . . . 36
D.2.4. Indexed Header Field . . . . . . . . . . . . . . . . 39 D.2.3. Literal Header Field never Indexed . . . . . . . . . 37
D.2.5. Indexed Header Field from Static Table . . . . . . . 40 D.2.4. Indexed Header Field . . . . . . . . . . . . . . . . 38
D.3. Request Examples without Huffman Coding . . . . . . . . . 41 D.3. Request Examples without Huffman Coding . . . . . . . . . 38
D.3.1. First Request . . . . . . . . . . . . . . . . . . . . 41 D.3.1. First Request . . . . . . . . . . . . . . . . . . . . 38
D.3.2. Second Request . . . . . . . . . . . . . . . . . . . 42 D.3.2. Second Request . . . . . . . . . . . . . . . . . . . 39
D.3.3. Third Request . . . . . . . . . . . . . . . . . . . . 44 D.3.3. Third Request . . . . . . . . . . . . . . . . . . . . 41
D.4. Request Examples with Huffman Coding . . . . . . . . . . 46 D.4. Request Examples with Huffman Coding . . . . . . . . . . 42
D.4.1. First Request . . . . . . . . . . . . . . . . . . . . 46 D.4.1. First Request . . . . . . . . . . . . . . . . . . . . 42
D.4.2. Second Request . . . . . . . . . . . . . . . . . . . 47 D.4.2. Second Request . . . . . . . . . . . . . . . . . . . 43
D.4.3. Third Request . . . . . . . . . . . . . . . . . . . . 48 D.4.3. Third Request . . . . . . . . . . . . . . . . . . . . 44
D.5. Response Examples without Huffman Coding . . . . . . . . 50 D.5. Response Examples without Huffman Coding . . . . . . . . 46
D.5.1. First Response . . . . . . . . . . . . . . . . . . . 50 D.5.1. First Response . . . . . . . . . . . . . . . . . . . 46
D.5.2. Second Response . . . . . . . . . . . . . . . . . . . 52 D.5.2. Second Response . . . . . . . . . . . . . . . . . . . 48
D.5.3. Third Response . . . . . . . . . . . . . . . . . . . 53 D.5.3. Third Response . . . . . . . . . . . . . . . . . . . 49
D.6. Response Examples with Huffman Coding . . . . . . . . . . 55 D.6. Response Examples with Huffman Coding . . . . . . . . . . 51
D.6.1. First Response . . . . . . . . . . . . . . . . . . . 55 D.6.1. First Response . . . . . . . . . . . . . . . . . . . 51
D.6.2. Second Response . . . . . . . . . . . . . . . . . . . 58 D.6.2. Second Response . . . . . . . . . . . . . . . . . . . 53
D.6.3. Third Response . . . . . . . . . . . . . . . . . . . 59 D.6.3. Third Response . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
This specification defines HPACK, a compression format for This specification defines HPACK, a compression format for
efficiently representing HTTP header fields in the context of HTTP/2 efficiently representing HTTP header fields in the context of HTTP/2
(see [HTTP2]). [HTTP2].
2. HPACK Overview 2. HPACK Overview
In HTTP/1.1 (see [RFC7230]), header fields are encoded without any In HTTP/1.1 (see [RFC7230]), header fields are encoded without any
form of compression. As web pages have grown to include dozens to form of compression. As web pages have grown to include dozens to
hundreds of requests, the redundant header fields in these requests hundreds of requests, the redundant header fields in these requests
now measurably increase latency and unnecessarily consume bandwidth now measurably increase latency and unnecessarily consume bandwidth
(see [SPDY-DESC-1] and [SPDY-DESC-2]). (see [SPDY-DESC-1] and [SPDY-DESC-2]).
SPDY [SPDY] initially addressed this redundancy by compressing header SPDY [SPDY] initially addressed this redundancy by compressing header
fields using the DEFLATE format [DEFLATE], which proved very fields using the DEFLATE [DEFLATE] format, which proved very
effective at efficiently representing the redundant header fields. effective at efficiently representing the redundant header fields.
However, that approach exposed a security risk as demonstrated by the However, that approach exposed a security risk as demonstrated by the
CRIME attack (see [CRIME]). CRIME attack (see [CRIME]).
This document describes HPACK, a new compressor for header fields This document describes HPACK, a new compressor for header fields
which eliminates redundant header fields, limits vulnerability to which eliminates redundant header fields, limits vulnerability to
known security attacks, and which has a bounded memory requirement known security attacks, and which has a bounded memory requirement
for use in constrained environments. for use in constrained environments.
2.1. Outline 2.1. Outline
The HTTP header field encoding defined in this document is based on a The HTTP header field encoding defined in this document is based on a
header table that maps name-value pairs to index values. The header header table that maps name-value pairs to index values. The header
table is incrementally updated as new values are encoded or decoded. table is incrementally updated as new values are encoded or decoded.
A set of header fields is treated as an unordered collection of name- A list of header fields is treated as an ordered collection of name-
value pairs that can include duplicates. Names and values are value pairs that can include duplicates. Names and values are
considered to be opaque sequences of octets. The order of header considered to be opaque sequences of octets. The order of header
fields is not guaranteed to be preserved after being compressed and fields is preserved after being compressed and decompressed.
decompressed.
In the encoded form, a header field is represented either literally In the encoded form, a header field is represented either literally
or as a reference to a name-value pair in a header table. A set of or as a reference to a name-value pair in a header table. A list of
header fields can therefore be encoded using a mixture of references header fields can therefore be encoded using a mixture of references
and literal values. and literal values.
As two consecutive sets of header fields often have header fields in
common, each set is coded as a difference from the previous set. The
goal is to only encode the changes between the two sets of header
fields (that is, header fields that are present in only one of the
sets) and eliminate redundancy (header fields present in both sets).
A subset of the header fields that are encoded as references to the
header table are maintained in a reference set that is used as the
initial set of header fields for the next encoding.
The encoder is responsible for deciding which header fields to insert The encoder is responsible for deciding which header fields to insert
as new entries in the header table. The decoder executes the as new entries in the header table. The decoder executes the
modifications to the header table and reference set prescribed by the modifications to the header table prescribed by the encoder,
encoder, reconstructing the set of header fields in the process. reconstructing the list of header fields in the process. This
This enables decoders to remain simple and understand a wide variety enables decoders to remain simple and understand a wide variety of
of encoders. encoders.
Examples illustrating the use of these different mechanisms to Examples illustrating the use of these different mechanisms to
represent header fields are available in Appendix D. represent header fields are available in Appendix D.
2.2. Conventions 2.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 5, line 37 skipping to change at page 5, line 28
or hexadecimal as appropriate. Hexadecimal literals are prefixed or hexadecimal as appropriate. Hexadecimal literals are prefixed
with "0x" to distinguish them from decimal literals. with "0x" to distinguish them from decimal literals.
2.3. Terminology 2.3. Terminology
This document uses the following terms: This document uses the following terms:
Header Field: A name-value pair. Both the name and value are Header Field: A name-value pair. Both the name and value are
treated as opaque sequences of octets. treated as opaque sequences of octets.
Header Table: The header table (see Section 3.2) is a component used Header Table: The header table (see Section 3.3.2) is used to
to associate stored header fields to index values. associate stored header fields to index values. This table is
dynamic and specific to an encoding or decoding context.
Static Table: The static table (see Appendix B) is a component used Static Table: The static table (see Section 3.3.1) is used to
to associate static header fields to index values. This data is associate static header fields to index values. This table is
ordered, read-only, always accessible, and may be shared amongst ordered, read-only, always accessible, and may be shared amongst
all encoding contexts. all encoding or decoding contexts.
Header Set: A header set is an unordered group of header fields that
are encoded jointly. It can contain duplicate header fields. A
complete set of key-value pairs contained in a HTTP request or
response is a header set.
Reference Set: The reference set (see Section 3.3) is a component Header List: A header list is an ordered collection of header fields
containing an unordered set of references to entries in the header that are encoded jointly. It can contain duplicate header fields.
table. It doesn't contain duplicate references. The reference A complete list of key-value pairs contained in a HTTP request or
set is used for the differential encoding of a new header set. response is a header list.
Header Field Representation: A header field can be represented in Header Field Representation: A header field can be represented in
encoded form either as a literal or as an index (see Section 3.4). encoded form either as a literal or as an index (see Section 3.4).
Header Block: The entire set of encoded header field representations Header Block: An ordered list of header field representations which,
which, when decoded, yield a complete header set. when decoded, yields a complete header list.
Header Field Emission: When decoding a set of header field
representations, some operations emit a header field (see
Section 3.5). Emitted header fields are added to the output
header set and cannot be removed.
3. Decoding Process Overview 3. Compression Process Overview
This specification does not describe a specific algorithm for an This specification does not describe a specific algorithm for an
encoder. Instead, it defines precisely how a decoder is expected to encoder. Instead, it defines precisely how a decoder is expected to
operate, allowing encoders to produce any encoding that this operate, allowing encoders to produce any encoding that this
definition permits. definition permits.
3.1. Encoding and Decoding Contexts 3.1. Header List Ordering
HPACK requires that a decoder maintains both a header table and a The compression and decompression process preserve the ordering of
reference set. No other state information is needed to decode header fields inside the header list. An encoder SHOULD order header
messages. An encoder that wishes to reference entries in the header field representations in the header block according to their ordering
table, reference set, or static table needs to maintain a copy of the in the original header list. A decoder SHOULD order header fields in
information a decoder holds. the decoded header list according to their ordering in the header
block.
In particular, representations for pseudo-header fields (see
Section 8.1.2.1 of [HTTP2]) MUST appear before representations for
regular header fields in a header block. In a decoded header list,
pseudo-header fields MUST appear before regular header fields.
3.2. Encoding and Decoding Contexts
To decompress header blocks, a decoder only needs to maintain a
header table (see Section 3.3.2) as a decoding context. No other
state information is needed.
An encoder that wishes to reference entries in the header table needs
to maintain a copy of the header table used by the decoder.
When used for bidirectional communication, such as in HTTP, the When used for bidirectional communication, such as in HTTP, the
encoding and decoding contexts maintained by an endpoint are encoding and decoding header tables maintained by an endpoint are
completely independent. Header fields are encoded without any completely independent. Header fields are encoded without any
reference to the local decoding state; and header fields are decoded reference to the local decoding header table; and header fields are
without reference to the encoding state. decoded without reference to the local encoding header table.
Each endpoint maintains a header table and a reference set in order 3.3. Indexing Tables
to decode header blocks, and optionally a copy of the information
maintained by their peer.
3.2. Header Table HPACK uses two tables for associating header fields to indexes. The
static table (see Section 3.3.1) is predefined and contains common
header fields (most of them with an empty value). The header table
(see Section 3.3.2) is dynamic and can be used by the encoder to
index header fields repeated in the encoded header lists.
A header table consists of a list of header fields maintained in These two tables are combined into a single address space for
defining index values (see Section 3.3.3).
3.3.1. Static Table
The static table consists of a predefined static list of header
fields. Its entries are defined in Appendix B.
3.3.2. Header Table
The header table consists of a list of header fields maintained in
first-in, first-out order. The first and newest entry in a header first-in, first-out order. The first and newest entry in a header
table is always at index 1, and the oldest entry of a header table is table is always at index 1, and the oldest entry of a header table is
at the index corresponding to the number of entries in the header at the index corresponding to the number of entries in the header
table. table.
The header table is initially empty. The header table is initially empty.
The header table can contain duplicate entries. Therefore, duplicate The header table can contain duplicate entries. Therefore, duplicate
entries MUST NOT be treated as an error by a decoder. entries MUST NOT be treated as an error by a decoder.
The encoder decides how to update the header table and as such can The encoder decides how to update the header table and as such can
control how much memory is used by the header table. To limit the control how much memory is used by the header table. To limit the
memory requirements of the decoder, the header table size is strictly memory requirements of the decoder, the header table size is strictly
bounded (see Section 5.1). bounded (see Section 5.1).
The header table is updated during the processing of a set of header The header table is updated during the processing of a list of header
field representations (see Section 4.1). field representations (see Section 4.2).
3.3. Reference Set 3.3.3. Index Address Space
A reference set is an unordered set of references to entries of the The static table and the header table are combined into a single
header table. It never contains duplicate references. index address space.
The reference set is initially empty. Indices between 1 and the length of the static table (inclusive)
refer to elements in the static table (see Section 3.3.1).
The reference set is updated during the processing of a set of header Indices strictly greater than the length of the static table refer to
field representations (see Section 4.1). elements in the header table (see Section 3.3.2). The length of the
static table is subtracted to find the index into the header table.
The reference set enables differential encoding, where only Indices strictly greater than the sum of the lengths of both tables
differences between the previous header set and the current header MUST be treated as a decoding error.
set need to be encoded. The use of differential encoding is optional
for any header set.
When an entry is evicted from the header table, if it was referenced For a static table size of s and a header table size of k, the
from the reference set, its reference is removed from the reference following diagram shows the entire valid index address space.
set.
To limit the memory requirements on the decoder side for handling the <---------- Index Address Space ---------->
reference set, only entries within the header table can be contained <-- Static Table --> <-- Header Table -->
in the reference set. To still allow entries from the static table +---+-----------+---+ +---+-----------+---+
to take advantage of the differential encoding, when a header field | 1 | ... | s | |s+1| ... |s+k|
is represented as a reference to an entry of the static table, this +---+-----------+---+ +---+-----------+---+
entry is inserted into the header table (see Section 4.1). ^ |
| V
Insertion Point Dropping Point
Index Address Space
3.4. Header Field Representation 3.4. Header Field Representation
An encoded header field can be represented either as a literal or as An encoded header field can be represented either as a literal or as
an index. an index.
A literal representation defines a new header field. The header A literal representation defines a header field by specifying its
field name can be represented literally or as a reference to an entry name and value. The header field name can be represented literally
of the header table. The header field value is represented or as a reference to an entry in either the static table or the
literally. header table. The header field value is represented literally.
Three different literal representations are provided: Three different literal representations are provided:
o A literal representation that does not add the header field to the o A literal representation that does not add the header field to the
header table (see Section 7.2.2). header table (see Section 7.2.2).
o A literal representation that does not add the header field to the o A literal representation that does not add the header field to the
header table, with the additional stipulation that this header header table, with the additional stipulation that this header
field always use a literal representation, in particular when re- field always use a literal representation, in particular when re-
encoded by an intermediary (see Section 7.2.3). encoded by an intermediary (see Section 7.2.3).
o A literal representation that adds the header field as a new entry o A literal representation that adds the header field as a new entry
at the beginning of the header table (see Section 7.2.1). at the beginning of the header table (see Section 7.2.1).
An indexed representation defines a header field as a reference to an An indexed representation defines a header field as a reference to an
entry in either the header table or the static table (see entry in either the static table or the header table (see
Section 7.1). Section 7.1).
Indices between 1 and the length of the header table (inclusive) 4. Header Block Decoding
refer to elements in the header table, with index 1 referring to the
beginning of the table.
Indices between one higher than the length of the header table
represent indexes into the static table. The length of the header
table is subtracted to find the index into the static table.
Indices that are greater than the sum of the lengths of both tables
MUST be treated as a decoding error.
An indexed representation using an entry of the static table induces
a copy of this entry into the header table (see Section 4.1) for
bounding memory requirements on the decoder side (see Section 5.1).
For this reason, the header table is accessed more frequently than
the static table and has the lower indices.
For a header table size of k and a static table size of s, the
following diagram shows the entire valid index address space.
<---------- Index Address Space ---------->
<-- Header Table --> <-- Static Table -->
+---+-----------+---+ +---+-----------+---+
| 1 | ... | k | |k+1| ... |k+s|
+---+-----------+---+ +---+-----------+---+
^ |
| V
Insertion Point Dropping Point
Index Address Space
3.5. Header Field Emission
A decoder processes an encoded header block sequentially. As 4.1. Header Block Processing
different instructions are processed, some might specify that a
header field is emitted.
The emission of a header field is the process of marking a header A decoder processes an encoded header block sequentially to
field as belonging to the output header set. Once a header has been reconstruct the original header list.
emitted, it cannot be removed or retracted from the decoder output.
An emitted header field can be safely passed to the upper processing Once a header field is decoded and added to the reconstructed header
layer as part of the current header set. The decoder can pass list, it cannot be removed from it. A header field added to the
emitted header fields to the upper processing layer in any order. header list can be safely passed to the upper processing layer.
By emitting header fields instead of emitting header sets, a decoder By passing decoded header fields to the upper processing layer, a
can be implemented with minimal memory commitment in addition to the decoder can be implemented with minimal transitory memory commitment
header table and the reference set. The management of memory for in addition to the header table. The management of memory for
handling very large sets of header fields can therefore be deferred handling very large lists of header fields can therefore be deferred
to the upper processing layers. to the upper processing layers.
4. Header Block Decoding 4.2. Header Field Representation Processing
The processing of a header block to obtain a header set is defined in
this section. To ensure that the decoding will successfully produce
a header set, a decoder MUST obey the following rules.
4.1. Header Field Representation Processing The processing of a header block to obtain a header list is defined
in this section. To ensure that the decoding will successfully
produce a header list, a decoder MUST obey the following rules.
All the header field representations contained in a header block are All the header field representations contained in a header block are
processed in the order in which they appear, as specified below. processed in the order in which they appear, as specified below.
Details on the formatting of the various header field Details on the formatting of the various header field
representations, and some additional processing instructions are representations, and some additional processing instructions are
found in Section 7. found in Section 7.
An _indexed representation_ corresponding to an entry _present_ in An _indexed representation_ entails the following actions:
the reference set entails the following actions:
o The entry is removed from the reference set.
An _indexed representation_ corresponding to an entry _not present_
in the reference set entails the following actions:
o If referencing an element of the static table:
* The header field corresponding to the referenced entry is
emitted.
* The referenced static entry is inserted at the beginning of the
header table.
* A reference to this new header table entry is added to the
reference set, unless this new entry didn't fit in the header
table.
o If referencing an element of the header table:
* The header field corresponding to the referenced entry is
emitted.
* The referenced header table entry is added to the reference o The header field corresponding to the referenced entry in either
set. the static table or header table is added to the decoded header
list.
A _literal representation_ that is _not added_ to the header table A _literal representation_ that is _not added_ to the header table
entails the following action: entails the following action:
o The header field is emitted. o The header field is added to the decoded header list.
A _literal representation_ that is _added_ to the header table A _literal representation_ that is _added_ to the header table
entails the following actions: entails the following actions:
o The header field is emitted. o The header field is added to the decoded header list.
o The header field is inserted at the beginning of the header table. o The header field is inserted at the beginning of the header table.
o A reference to the new entry is added to the reference set, unless
this new entry didn't fit in the header table.
4.2. Reference Set Emission
Once all the representations contained in a header block have been
processed, any header fields included in the reference set that have
not previously been emitted during the processing of this header
block are emitted.
After the emission of these remaining header fields, the header set
is complete.
5. Header Table Management 5. Header Table Management
5.1. Maximum Table Size 5.1. Maximum Table Size
To limit the memory requirements on the decoder side, the mutable To limit the memory requirements on the decoder side, the header
structures used in an encoding context are constrained in size. table is constrained in size.
These mutable structures are the header table and the reference set.
The size of the header table is bounded by a maximum size defined by The size of the header table is bounded by a maximum size defined by
the decoder. The size of the header table MUST always be lower than the encoder. The size of the header table MUST always be lower than
or equal to this maximum size. or equal to this maximum size.
The reference set can only contain references to entries of the
header table, and can't contain references to entries of the static
table. In addition, it can't contain duplicate references.
Therefore, its maximum size is bounded by the size of the header
table.
By default, the maximum size of the header table is equal to the By default, the maximum size of the header table is equal to the
value of the HTTP/2 setting SETTINGS_HEADER_TABLE_SIZE defined by the value of the HTTP/2 setting parameter SETTINGS_HEADER_TABLE_SIZE
decoder (see Section 6.5.2 of [HTTP2]). The encoder can change this defined by the decoder (see Section 6.5.2 of [HTTP2]). The encoder
maximum size (see Section 7.3), but it MUST stay lower than or equal can change this maximum size (see Section 7.3), but it MUST stay
to the value of SETTINGS_HEADER_TABLE_SIZE. lower than or equal to the value of SETTINGS_HEADER_TABLE_SIZE.
After applying an updated value of the HTTP/2 setting After applying an updated value of the SETTINGS_HEADER_TABLE_SIZE
SETTINGS_HEADER_TABLE_SIZE that changes the maximum size of the parameter that changes the maximum size of the header table used by
header table used by the encoder, the encoder MUST signal this change the encoder, the encoder MUST signal this change via an encoding
via an encoding context update (see Section 7.3). This encoding context update (see Section 7.3). This encoding context update MUST
context update MUST occur at the beginning of the first header block occur at the beginning of the first header block following the
following the SETTINGS frame sent to acknowledge the application of SETTINGS frame sent to acknowledge the application of the updated
the updated settings. settings (see Section 6.5.3 of [HTTP2]).
Several updates to the value of the SETTINGS_HEADER_TABLE_SIZE
parameter can occur between the sending of two header blocks. In the
case that the value of this parameter is changed more that once, if
one of its value is smaller than the new maximum size, the smallest
value for the parameter MUST be sent before the new maximum size,
using two encoding context updates. This ensures that the decoder is
able to perform eviction based on the decoder table size (see
Section 5.2).
This mechanism can be used with a SETTINGS_HEADER_TABLE_SIZE
parameter value of 0 to completely clear entries from the header
table.
The size of the header table is the sum of the size of its entries. The size of the header table is the sum of the size of its entries.
The size of an entry is the sum of its name's length in octets (as The size of an entry is the sum of its name's length in octets (as
defined in Section 6.2), its value's length in octets (Section 6.2), defined in Section 6.2), its value's length in octets (see
plus 32. Section 6.2), plus 32.
The size of an entry is calculated using the length of the name and The size of an entry is calculated using the length of the name and
value without any Huffman encoding applied. value without any Huffman encoding applied.
The additional 32 octets account for overhead associated with an The additional 32 octets account for the overhead associated with an
entry. For example, an entry structure using two 64-bit pointers to entry. For example, an entry structure using two 64-bit pointers to
reference the name and the value of the entry, and two 64-bit reference the name and the value of the entry, and two 64-bit
integers for counting the number of references to the name and value integers for counting the number of references to the name and value
would have 32 octets of overhead. would have 32 octets of overhead.
5.2. Entry Eviction When Header Table Size Changes 5.2. Entry Eviction when Header Table Size Changes
Whenever the maximum size for the header table is reduced, entries Whenever the maximum size for the header table is reduced, entries
are evicted from the end of the header table until the size of the are evicted from the end of the header table until the size of the
header table is less than or equal to the maximum size. header table is less than or equal to the maximum size.
Whenever an entry is evicted from the header table, any reference to
that entry from the reference set is removed.
The eviction of an entry from the header table causes the index of
the entries in the static table to be reduced by one.
5.3. Entry Eviction when Adding New Entries 5.3. Entry Eviction when Adding New Entries
Whenever a new entry is to be added to the header table entries are Whenever a new entry is to be added to the header table, entries are
evicted from the end of the header table until the size of the header evicted from the end of the header table until the size of the header
table is less than or equal to (maximum size - new entry size), or table is less than or equal to (maximum size - new entry size), or
until the table is empty. until the table is empty.
If the representation of the added entry references the name of an If the representation of the added entry references the name of an
entry in the header table, the referenced name is cached prior to entry in the header table, the referenced name is cached prior to
performing eviction to avoid having the name inadvertently evicted. performing eviction to avoid having the name inadvertently evicted.
If the size of the new entry is less than or equal to the maximum If the size of the new entry is less than or equal to the maximum
size, that entry is added to the table. It is not an error to size, that entry is added to the table. It is not an error to
attempt to add an entry that is larger than the maximum size; an attempt to add an entry that is larger than the maximum size; an
attempt to add an entry larger than the entire table causes the table attempt to add an entry larger than the entire table causes the table
to be emptied of all existing entries. to be emptied of all existing entries.
6. Primitive Type Representations 6. Primitive Type Representations
HPACK encoding uses two primitive types: unsigned variable length HPACK encoding uses two primitive types: unsigned variable length
integers, and strings of octets. integers, and strings of octets.
6.1. Integer representation 6.1. Integer Representation
Integers are used to represent name indexes, pair indexes or string Integers are used to represent name indexes, pair indexes or string
lengths. To allow for optimized processing, an integer lengths. To allow for optimized processing, an integer
representation always finishes at the end of an octet. representation always finishes at the end of an octet.
An integer is represented in two parts: a prefix that fills the An integer is represented in two parts: a prefix that fills the
current octet and an optional list of octets that are used if the current octet and an optional list of octets that are used if the
integer value does not fit within the prefix. The number of bits of integer value does not fit within the prefix. The number of bits of
the prefix (called N) is a parameter of the integer representation. the prefix (called N) is a parameter of the integer representation.
skipping to change at page 13, line 44 skipping to change at page 12, line 44
values. Excessively large integer encodings - in value or octet values. Excessively large integer encodings - in value or octet
length - MUST be treated as a decoding error. Different limits can length - MUST be treated as a decoding error. Different limits can
be set for each of the different uses of integers, based on be set for each of the different uses of integers, based on
implementation constraints. implementation constraints.
6.2. String Literal Representation 6.2. String Literal Representation
Header field names and header field values can be represented as Header field names and header field values can be represented as
literal string. A literal string is encoded as a sequence of octets, literal string. A literal string is encoded as a sequence of octets,
either by directly encoding the literal string's octets, or by using either by directly encoding the literal string's octets, or by using
a Huffman code [HUFFMAN]. a Huffman code (see [HUFFMAN]).
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| H | String Length (7+) | | H | String Length (7+) |
+---+---------------------------+ +---+---------------------------+
| String Data (Length octets) | | String Data (Length octets) |
+-------------------------------+ +-------------------------------+
String Literal Representation String Literal Representation
skipping to change at page 14, line 23 skipping to change at page 13, line 23
String Length: The number of octets used to encode the string String Length: The number of octets used to encode the string
literal, encoded as an integer with 7-bit prefix (see literal, encoded as an integer with 7-bit prefix (see
Section 6.1). Section 6.1).
String Data: The encoded data of the string literal. If H is '0', String Data: The encoded data of the string literal. If H is '0',
then the encoded data is the raw octets of the string literal. If then the encoded data is the raw octets of the string literal. If
H is '1', then the encoded data is the Huffman encoding of the H is '1', then the encoded data is the Huffman encoding of the
string literal. string literal.
String literals which use Huffman encoding are encoded with the String literals which use Huffman encoding are encoded with the
Huffman code defined in Appendix C (see examples in Request Examples Huffman code defined in Appendix C (see examples for requests in
with Huffman Coding (Appendix D.4) and in Response Examples with Appendix D.4 and for responses in Appendix D.6). The encoded data is
Huffman Coding (Appendix D.6)). The encoded data is the bitwise the bitwise concatenation of the codes corresponding to each octet of
concatenation of the codes corresponding to each octet of the string the string literal.
literal.
As the Huffman encoded data doesn't always end at an octet boundary, As the Huffman encoded data doesn't always end at an octet boundary,
some padding is inserted after it up to the next octet boundary. To some padding is inserted after it, up to the next octet boundary. To
prevent this padding to be misinterpreted as part of the string prevent this padding to be misinterpreted as part of the string
literal, the most significant bits of code corresponding to the EOS literal, the most significant bits of the code corresponding to the
(end-of-string) symbol are used. EOS (end-of-string) symbol are used.
Upon decoding, an incomplete code at the end of the encoded data is Upon decoding, an incomplete code at the end of the encoded data is
to be considered as padding and discarded. A padding strictly longer to be considered as padding and discarded. A padding strictly longer
than 7 bits MUST be treated as a decoding error. A padding not than 7 bits MUST be treated as a decoding error. A padding not
corresponding to the most significant bits of the code for the EOS corresponding to the most significant bits of the code for the EOS
symbol MUST be treated as a decoding error. A Huffman encoded string symbol MUST be treated as a decoding error. A Huffman encoded string
literal containing the EOS symbol MUST be treated as a decoding literal containing the EOS symbol MUST be treated as a decoding
error. error.
7. Binary Format 7. Binary Format
skipping to change at page 15, line 4 skipping to change at page 13, line 49
literal containing the EOS symbol MUST be treated as a decoding literal containing the EOS symbol MUST be treated as a decoding
error. error.
7. Binary Format 7. Binary Format
This section describes the detailed format of each of the different This section describes the detailed format of each of the different
header field representations, plus the encoding context update header field representations, plus the encoding context update
instruction. instruction.
7.1. Indexed Header Field Representation 7.1. Indexed Header Field Representation
An indexed header field representation identifies an entry in either An indexed header field representation identifies an entry in either
the header table or the static table. the static table or the header table (see Section 3.3).
An indexed header field representation can either causes a header An indexed header field representation causes a header field to be
field to be emitted or to be removed from the reference set, as added to the decoded header list, as described in Section 4.2.
described in Section 4.1.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | Index (7+) | | 1 | Index (7+) |
+---+---------------------------+ +---+---------------------------+
Indexed Header Field Indexed Header Field
An indexed header field starts with the '1' 1-bit pattern, followed An indexed header field starts with the '1' 1-bit pattern, followed
by the index of the matching pair, represented as an integer with a by the index of the matching pair, represented as an integer with a
7-bit prefix. 7-bit prefix (see Section 6.1).
The index value of 0 is not used. It MUST be treated as a decoding The index value of 0 is not used. It MUST be treated as a decoding
error if found in an indexed header field representation. error if found in an indexed header field representation.
7.2. Literal Header Field Representation 7.2. Literal Header Field Representation
A literal header field representation contains a literal header field A literal header field representation contains a literal header field
value. Header field names are either provided as a literal or by value. Header field names are either provided as a literal or by
reference to an existing table entry, either from the header table or reference to an existing table entry, either from the static table or
the static table. the header table (see Section 3.3).
A literal representation always result in the emission of a header A literal representation causes a header field to be added to the
field when decoded. decoded header list, as described in Section 4.2.
7.2.1. Literal Header Field with Incremental Indexing 7.2.1. Literal Header Field with Incremental Indexing
A literal header field with incremental indexing representation A literal header field with incremental indexing representation
causes the emission of a header field, adding it as a new entry to results in adding a header field to the decoded header list and
the header table. inserting it as a new entry into the header table.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 1 | Index (6+) | | 0 | 1 | Index (6+) |
+---+---+-----------------------+ +---+---+-----------------------+
| H | Value Length (7+) | | H | Value Length (7+) |
+---+---------------------------+ +---+---------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
skipping to change at page 16, line 24 skipping to change at page 15, line 19
+---+---------------------------+ +---+---------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header Field with Incremental Indexing - New Name Literal Header Field with Incremental Indexing - New Name
A literal header field with incremental indexing representation A literal header field with incremental indexing representation
starts with the '01' 2-bit pattern. starts with the '01' 2-bit pattern.
If the header field name matches the header field name of an entry If the header field name matches the header field name of an entry
stored in the header table or the static table, the header field name stored in the static table or the header table, the header field name
can be represented using the index of that entry. In this case, the can be represented using the index of that entry. In this case, the
index of the entry is represented as an integer with a 6-bit prefix index of the entry is represented as an integer with a 6-bit prefix
(see Section 6.1). This value is always non-zero. (see Section 6.1). This value is always non-zero.
Otherwise, the header field name is represented as a literal. A Otherwise, the header field name is represented as a literal string
value 0 is used in place of the 6-bit index, followed by the header (see Section 6.2). A value 0 is used in place of the 6-bit index,
field name (see Section 6.2). followed by the header field name.
Either form of header field name representation is followed by the Either form of header field name representation is followed by the
header field value represented as a literal string as described in header field value represented as a literal string (see Section 6.2).
Section 6.2.
7.2.2. Literal Header Field without Indexing 7.2.2. Literal Header Field without Indexing
A literal header field without indexing representation causes the A literal header field without indexing representation results in
emission of a header field without altering the header table. adding a header field to the decoded header list without altering the
header table.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | Index (4+) | | 0 | 0 | 0 | 0 | Index (4+) |
+---+---+-----------------------+ +---+---+-----------------------+
| H | Value Length (7+) | | H | Value Length (7+) |
+---+---------------------------+ +---+---------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
skipping to change at page 17, line 24 skipping to change at page 16, line 19
+---+---------------------------+ +---+---------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header Field without Indexing - New Name Literal Header Field without Indexing - New Name
A literal header field without indexing representation starts with A literal header field without indexing representation starts with
the '0000' 4-bit pattern. the '0000' 4-bit pattern.
If the header field name matches the header field name of an entry If the header field name matches the header field name of an entry
stored in the header table or the static table, the header field name stored in the static table or the header table, the header field name
can be represented using the index of that entry. In this case, the can be represented using the index of that entry. In this case, the
index of the entry is represented as an integer with a 4-bit prefix index of the entry is represented as an integer with a 4-bit prefix
(see Section 6.1). This value is always non-zero. (see Section 6.1). This value is always non-zero.
Otherwise, the header field name is represented as a literal. A Otherwise, the header field name is represented as a literal string
value 0 is used in place of the 4-bit index, followed by the header (see Section 6.2). A value 0 is used in place of the 4-bit index,
field name (see Section 6.2). followed by the header field name.
Either form of header field name representation is followed by the Either form of header field name representation is followed by the
header field value represented as a literal string as described in header field value represented as a literal string (see Section 6.2).
Section 6.2.
7.2.3. Literal Header Field Never Indexed 7.2.3. Literal Header Field never Indexed
A literal header field never indexed representation causes the A literal header field never indexed representation results in adding
emission of a header field without altering the header table. a header field to the decoded header list without altering the header
Intermediaries MUST use the same representation for encoding this table. Intermediaries MUST use the same representation for encoding
header field. this header field.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | Index (4+) | | 0 | 0 | 0 | 1 | Index (4+) |
+---+---+-----------------------+ +---+---+-----------------------+
| H | Value Length (7+) | | H | Value Length (7+) |
+---+---------------------------+ +---+---------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header Field Never Indexed - Indexed Name Literal Header Field never Indexed - Indexed Name
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 0 | | 0 | 0 | 0 | 1 | 0 |
+---+---+-----------------------+ +---+---+-----------------------+
| H | Name Length (7+) | | H | Name Length (7+) |
+---+---------------------------+ +---+---------------------------+
| Name String (Length octets) | | Name String (Length octets) |
+---+---------------------------+ +---+---------------------------+
| H | Value Length (7+) | | H | Value Length (7+) |
+---+---------------------------+ +---+---------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header Field Never Indexed - New Name Literal Header Field never Indexed - New Name
A literal header field never indexed representation starts with the A literal header field never indexed representation starts with the
'0001' 4-bit pattern. '0001' 4-bit pattern.
When a header field is represented as a literal header field never When a header field is represented as a literal header field never
indexed, it MUST always be encoded with this specific literal indexed, it MUST always be encoded with this specific literal
representation. In particular, when a peer sends a header field that representation. In particular, when a peer sends a header field that
it received represented as a literal header field never indexed, it it received represented as a literal header field never indexed, it
MUST use the same representation to forward this header field. MUST use the same representation to forward this header field.
This representation is intended for protecting header field values This representation is intended for protecting header field values
that are not to be put at risk by compressing them (see Section 8.1 that are not to be put at risk by compressing them (see Section 8.1
for more details). for more details).
The encoding of the representation is identical to the literal header The encoding of the representation is identical to the literal header
field without indexing (see Section 7.2.2). field without indexing (see Section 7.2.2).
7.3. Encoding Context Update 7.3. Header Table Size Update
An encoding context update causes the immediate application of a
change to the encoding context.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | F | ... |
+---+---------------------------+
Context Update
An encoding context update starts with the '001' 3-bit pattern.
It is followed by a flag specifying the type of the change, and by
any data necessary to describe the change itself.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 1 | 0 |
+---+---------------------------+
Reference Set Emptying
The flag bit being set to '1' signals that the reference set is A header table size update signals a change to the size of the header
emptied. The remaining bits MUST be set to '0', non-zero values MUST table.
be treated as a decoding error.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 0 | Max size (4+) | | 0 | 0 | 1 | Max size (5+) |
+---+---------------------------+ +---+---------------------------+
Maximum Header Table Size Change Maximum Header Table Size Change
The flag bit being set to '0' signals that a change to the maximum A header table size update starts with the '001' 3-bit pattern,
size of the header table. This new maximum size MUST be lower than followed by the new maximum size, represented as an integer with a
or equal to the maximum set by the decoder. That is, the value of 5-bit prefix (see Section 6.1).
the HTTP/2 setting SETTINGS_HEADER_TABLE_SIZE, defined in
Section 6.5.2 of [HTTP2].
The new maximum size is encoded as an integer with a 4-bit prefix The new maximum size MUST be lower than or equal to the last value of
(see Section 6.1). the SETTINGS_HEADER_TABLE_SIZE parameter (see Section 6.5.2 of
[HTTP2]) received from the decoder and acknowledged by the encoder
(see Section 6.5.3 of [HTTP2]).
Reducing the maximum size of the header table causes entries to be Reducing the maximum size of the header table can cause entries to be
evicted (see Section 5.2). evicted (see Section 5.2).
8. Security Considerations 8. Security Considerations
This section describes potential areas of security concern with This section describes potential areas of security concern with
HPACK: HPACK:
o Use of compression as a length-based oracle for verifying guesses o Use of compression as a length-based oracle for verifying guesses
about secrets that are compressed into a shared compression about secrets that are compressed into a shared compression
context. context.
skipping to change at page 20, line 38 skipping to change at page 18, line 46
This is possible because while TLS provides confidentiality This is possible because while TLS provides confidentiality
protection for content, it only provides a limited amount of protection for content, it only provides a limited amount of
protection for the length of that content. protection for the length of that content.
Note: Padding schemes only provide limited protection against an Note: Padding schemes only provide limited protection against an
attacker with these capabilities, potentially only forcing an attacker with these capabilities, potentially only forcing an
increased number of guesses to learn the length associated with a increased number of guesses to learn the length associated with a
given guess. Padding schemes also work directly against given guess. Padding schemes also work directly against
compression by increasing the number of bits that are transmitted. compression by increasing the number of bits that are transmitted.
Attacks like [CRIME] demonstrated the existence of these general Attacks like CRIME [CRIME] demonstrated the existence of these
attacker capabilities. The specific attack exploited the fact that general attacker capabilities. The specific attack exploited the
[DEFLATE] removes redundancy based on prefix matching. This fact that DEFLATE [DEFLATE] removes redundancy based on prefix
permitted the attacker to confirm guesses a character at a time, matching. This permitted the attacker to confirm guesses a character
reducing an exponential-time attack into a constant time attack. at a time, reducing an exponential-time attack into a linear-time
attack.
8.1.1. Applicability to HPACK and HTTP 8.1.1. Applicability to HPACK and HTTP
HPACK mitigates but does not completely prevent attacks modelled on HPACK mitigates but does not completely prevent attacks modelled on
[CRIME] by forcing a guess to match an entire header field value, CRIME [CRIME] by forcing a guess to match an entire header field
rather than individual characters. An attacker can only learn value, rather than individual characters. An attacker can only learn
whether a guess is correct or not, so is reduced to a brute force whether a guess is correct or not, so is reduced to a brute force
guess for the header field values. guess for the header field values.
The viability of recovering specific header field values therefore The viability of recovering specific header field values therefore
depends on the entropy of values. As a result, values with high depends on the entropy of values. As a result, values with high
entropy are unlikely to be recovered successfully. However, values entropy are unlikely to be recovered successfully. However, values
with low entropy remain vulnerable. with low entropy remain vulnerable.
Attacks of this nature are possible any time that two mutually Attacks of this nature are possible any time that two mutually
distrustful entities control requests or responses that are placed distrustful entities control requests or responses that are placed
skipping to change at page 22, line 29 skipping to change at page 20, line 37
values. values.
Implementations might also choose to protect certain header fields Implementations might also choose to protect certain header fields
that are known to be highly valued, such as the Authorization or that are known to be highly valued, such as the Authorization or
Cookie header fields, by disabling or further limiting compression. Cookie header fields, by disabling or further limiting compression.
8.1.3. Never Indexed Literals 8.1.3. Never Indexed Literals
Refusing to generate an indexed representation for a header field is Refusing to generate an indexed representation for a header field is
only effective if compression is avoided on all hops. The never only effective if compression is avoided on all hops. The never
indexed literal (Section 7.2.3) can be used to signal to indexed literal (see Section 7.2.3) can be used to signal to
intermediaries that a particular value was intentionally sent as a intermediaries that a particular value was intentionally sent as a
literal. An intermediary MUST NOT re-encode a value that uses the literal. An intermediary MUST NOT re-encode a value that uses the
never indexed literal as an indexed representation. never indexed literal with a representation that would index it.
8.2. Static Huffman Encoding 8.2. Static Huffman Encoding
There is currently no known threat taking advantage of the use of a There is currently no known threat taking advantage of the use of a
fixed Huffman encoding. A study has shown that using a fixed Huffman fixed Huffman encoding. A study has shown that using a fixed Huffman
encoding table created an information leakage, however this same encoding table created an information leakage, however this same
study concluded that an attacker could not take advantage of this study concluded that an attacker could not take advantage of this
information leakage to recover any meaningful amount of information information leakage to recover any meaningful amount of information
(see [PETAL]). (see [PETAL]).
skipping to change at page 22, line 44 skipping to change at page 21, line 4
8.2. Static Huffman Encoding 8.2. Static Huffman Encoding
There is currently no known threat taking advantage of the use of a There is currently no known threat taking advantage of the use of a
fixed Huffman encoding. A study has shown that using a fixed Huffman fixed Huffman encoding. A study has shown that using a fixed Huffman
encoding table created an information leakage, however this same encoding table created an information leakage, however this same
study concluded that an attacker could not take advantage of this study concluded that an attacker could not take advantage of this
information leakage to recover any meaningful amount of information information leakage to recover any meaningful amount of information
(see [PETAL]). (see [PETAL]).
8.3. Memory Consumption 8.3. Memory Consumption
An attacker can try to cause an endpoint to exhaust its memory. An attacker can try to cause an endpoint to exhaust its memory.
HPACK is designed to limit both the peak and state amounts of memory HPACK is designed to limit both the peak and state amounts of memory
allocated by an endpoint. allocated by an endpoint.
The amount of memory used by the compressor state is limited by the The amount of memory used by the compressor state is limited by the
decoder using the value of the HTTP/2 setting decoder using the value of the HTTP/2 setting parameter
SETTINGS_HEADER_TABLE_SIZE (see Section 6.5.2 of [HTTP2]). This SETTINGS_HEADER_TABLE_SIZE (see Section 6.5.2 of [HTTP2]). This
limit takes into account both the size of the data stored in the limit takes into account both the size of the data stored in the
header table, plus a small allowance for overhead. header table, plus a small allowance for overhead.
A decoder can limit the amount of state memory used by setting an A decoder can limit the amount of state memory used by setting an
appropriate value for the setting SETTINGS_HEADER_TABLE_SIZE. An appropriate value for the SETTINGS_HEADER_TABLE_SIZE parameter. An
encoder can limit the amount of state memory it uses by signaling encoder can limit the amount of state memory it uses by signalling
lower header table size than the decoder allows (see Section 7.3). lower header table size than the decoder allows (see Section 7.3).
The amount of temporary memory consumed by an encoder or decoder can The amount of temporary memory consumed by an encoder or decoder can
be limited by processing header fields sequentially. An be limited by processing header fields sequentially. An
implementation does not need to retain a complete set of header implementation does not need to retain a complete list of header
fields. Note however that it might be necessary for an application fields. Note however that it might be necessary for an application
to retain a complete header set for other reasons; even though HPACK to retain a complete header list for other reasons; even though HPACK
does not force this to occur, application constraints might make this does not force this to occur, application constraints might make this
necessary. necessary.
8.4. Implementation Limits 8.4. Implementation Limits
An implementation of HPACK needs to ensure that large values for An implementation of HPACK needs to ensure that large values for
integers, long encoding for integers, or long string literals do not integers, long encoding for integers, or long string literals do not
create security weaknesses. create security weaknesses.
An implementation has to set a limit for the values it accepts for An implementation has to set a limit for the values it accepts for
skipping to change at page 23, line 46 skipping to change at page 22, line 6
o Mike Bishop, Jeff Pinner, Julian Reschke, Martin Thomson o Mike Bishop, Jeff Pinner, Julian Reschke, Martin Thomson
(substantial editorial contributions). (substantial editorial contributions).
o Johnny Graettinger (Huffman code statistics). o Johnny Graettinger (Huffman code statistics).
10. References 10. References
10.1. Normative References 10.1. Normative References
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol version 2", draft-ietf-httpbis-http2-13 Transfer Protocol version 2", draft-ietf-httpbis-http2-14
(work in progress), June 2014. (work in progress), July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels ", BCP 14, RFC 2119, March 1997. Requirement Levels ", BCP 14, RFC 2119, March 1997.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing ", RFC Protocol (HTTP/1.1): Message Syntax and Routing ", RFC
7230, June 2014. 7230, June 2014.
10.2. Informative References 10.2. Informative References
skipping to change at page 24, line 51 skipping to change at page 23, line 11
slides/slides-83-httpbis-3>. slides/slides-83-httpbis-3>.
[SPDY-DESC-2] [SPDY-DESC-2]
McManus, P., "SPDY: What I Like About You", September McManus, P., "SPDY: What I Like About You", September
2011, <https://bitsup.blogspot.com/2011/09/spdy-what-i 2011, <https://bitsup.blogspot.com/2011/09/spdy-what-i
-like-about-you.html>. -like-about-you.html>.
[SPDY] Belshe, M. and R. Peon, "SPDY Protocol", draft-mbelshe- [SPDY] Belshe, M. and R. Peon, "SPDY Protocol", draft-mbelshe-
httpbis-spdy-00 (work in progress), February 2012. httpbis-spdy-00 (work in progress), February 2012.
Appendix A. Change Log (to be removed by RFC Editor before publication Appendix A. Change Log (to be removed by RFC Editor before publication)
A.1. Since draft-ietf-httpbis-header-compression-07
A.1. Since draft-ietf-httpbis-header-compression-08
o Removed the reference set.
o Removed header emission.
o Explicit handling of several SETTINGS_HEADER_TABLE_SIZE parameter
changes.
o Changed header set to header list, and forced ordering.
o Updated examples.
o Exchanged header and static table positions.
A.2. Since draft-ietf-httpbis-header-compression-07
o Removed old text on index value of 0. o Removed old text on index value of 0.
o Added clarification for signalling of maximum table size after a o Added clarification for signalling of maximum table size after a
SETTINGS_HEADER_TABLE_SIZE update. SETTINGS_HEADER_TABLE_SIZE update.
o Rewrote security considerations. o Rewrote security considerations.
o Many editorial clarifications or improvements. o Many editorial clarifications or improvements.
o Added convention section. o Added convention section.
o Reworked document's outline. o Reworked document's outline.
o Updated static table. Entry 16 has now "gzip, deflate" for value. o Updated static table. Entry 16 has now "gzip, deflate" for value.
o Updated Huffman table, using data set provided by Google. o Updated Huffman table, using data set provided by Google.
A.2. Since draft-ietf-httpbis-header-compression-06 A.3. Since draft-ietf-httpbis-header-compression-06
o Updated format to include literal headers that must never be o Updated format to include literal headers that must never be
compressed. compressed.
o Updated security considerations. o Updated security considerations.
o Moved integer encoding examples to the appendix. o Moved integer encoding examples to the appendix.
o Updated Huffman table. o Updated Huffman table.
o Updated static header table (adding and removing status values). o Updated static header table (adding and removing status values).
o Updated examples. o Updated examples.
A.3. Since draft-ietf-httpbis-header-compression-05 A.4. Since draft-ietf-httpbis-header-compression-05
o Regenerated examples. o Regenerated examples.
o Only one Huffman table for requests and responses. o Only one Huffman table for requests and responses.
o Added maximum size for header table, independent of o Added maximum size for header table, independent of
SETTINGS_HEADER_TABLE_SIZE. SETTINGS_HEADER_TABLE_SIZE.
o Added pseudo-code for integer decoding. o Added pseudo-code for integer decoding.
o Improved examples (removing unnecessary removals). o Improved examples (removing unnecessary removals).
A.4. Since draft-ietf-httpbis-header-compression-04 A.5. Since draft-ietf-httpbis-header-compression-04
o Updated examples: take into account changes in the spec, and show o Updated examples: take into account changes in the spec, and show
more features. more features.
o Use 'octet' everywhere instead of having both 'byte' and 'octet'. o Use 'octet' everywhere instead of having both 'byte' and 'octet'.
o Added reference set emptying. o Added reference set emptying.
o Editorial changes and clarifications. o Editorial changes and clarifications.
o Added "host" header to the static table. o Added "host" header to the static table.
o Ordering for list of values (either NULL- or comma-separated). o Ordering for list of values (either NULL- or comma-separated).
A.5. Since draft-ietf-httpbis-header-compression-03 A.6. Since draft-ietf-httpbis-header-compression-03
o A large number of editorial changes; changed the description of o A large number of editorial changes; changed the description of
evicting/adding new entries. evicting/adding new entries.
o Removed substitution indexing o Removed substitution indexing
o Changed 'initial headers' to 'static headers', as per issue #258 o Changed 'initial headers' to 'static headers', as per issue #258
o Merged 'request' and 'response' static headers, as per issue #259 o Merged 'request' and 'response' static headers, as per issue #259
o Changed text to indicate that new headers are added at index 0 and o Changed text to indicate that new headers are added at index 0 and
expire from the largest index, as per issue #233 expire from the largest index, as per issue #233
A.6. Since draft-ietf-httpbis-header-compression-02 A.7. Since draft-ietf-httpbis-header-compression-02
o Corrected error in integer encoding pseudocode. o Corrected error in integer encoding pseudocode.
A.7. Since draft-ietf-httpbis-header-compression-01 A.8. Since draft-ietf-httpbis-header-compression-01
o Refactored of Header Encoding Section: split definitions and o Refactored of Header Encoding Section: split definitions and
processing rule. processing rule.
o Backward incompatible change: Updated reference set management as o Backward incompatible change: Updated reference set management as
per issue #214. This changes how the interaction between the per issue #214. This changes how the interaction between the
reference set and eviction works. This also changes the working reference set and eviction works. This also changes the working
of the reference set in some specific cases. of the reference set in some specific cases.
o Backward incompatible change: modified initial header list, as per o Backward incompatible change: modified initial header list, as per
skipping to change at page 27, line 13 skipping to change at page 25, line 46
o Added example of 32 octets entry structure (issue #191). o Added example of 32 octets entry structure (issue #191).
o Added Header Set Completion section. Reflowed some text. o Added Header Set Completion section. Reflowed some text.
Clarified some writing which was akward. Added text about Clarified some writing which was akward. Added text about
duplicate header entry encoding. Clarified some language w.r.t duplicate header entry encoding. Clarified some language w.r.t
Header Set. Changed x-my-header to mynewheader. Added text in Header Set. Changed x-my-header to mynewheader. Added text in
the HeaderEmission section indicating that the application may the HeaderEmission section indicating that the application may
also be able to free up memory more quickly. Added information in also be able to free up memory more quickly. Added information in
Security Considerations section. Security Considerations section.
A.8. Since draft-ietf-httpbis-header-compression-00 A.9. Since draft-ietf-httpbis-header-compression-00
Fixed bug/omission in integer representation algorithm. Fixed bug/omission in integer representation algorithm.
Changed the document title. Changed the document title.
Header matching text rewritten. Header matching text rewritten.
Changed the definition of header emission. Changed the definition of header emission.
Changed the name of the setting which dictates how much memory the Changed the name of the setting which dictates how much memory the
skipping to change at page 27, line 35 skipping to change at page 26, line 19
Removed "specific use cases" section Removed "specific use cases" section
Corrected erroneous statement about what index can be contained in Corrected erroneous statement about what index can be contained in
one octet one octet
Added descriptions of opcodes Added descriptions of opcodes
Removed security claims from introduction. Removed security claims from introduction.
Appendix B. Static Table Appendix B. Static Table Definition
The static table consists of an unchangeable ordered list of (name, The static table (see Section 3.3.1) consists of a predefined and
value) pairs. The first entry in the table is always represented by unchangeable list of header fields.
the index len(header table) + 1, and the last entry in the table is
represented by the index len(header table) + len(static table).
The static table was created by listing the most common header fields The static table was created by listing the most common header fields
that are valid for messages exchanged inside a HTTP/2 connection. that are valid for messages exchanged inside a HTTP/2 connection.
For header fields with a few frequent values, an entry was added for For header fields with a few frequent values, an entry was added for
each of these frequent values. For other header fields, an entry was each of these frequent values. For other header fields, an entry was
added with an empty value. added with an empty value.
The following table lists the pre-defined header fields that make-up The following table lists the pre-defined header fields that make-up
the static table. the static table.
skipping to change at page 29, line 22 skipping to change at page 28, line 5
| 56 | strict-transport-security | | | 56 | strict-transport-security | |
| 57 | transfer-encoding | | | 57 | transfer-encoding | |
| 58 | user-agent | | | 58 | user-agent | |
| 59 | vary | | | 59 | vary | |
| 60 | via | | | 60 | via | |
| 61 | www-authenticate | | | 61 | www-authenticate | |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 1: Static Table Entries Table 1: Static Table Entries
Table 1 gives the index of each entry in the static table. The full Table 1 gives the index of each entry in the static table.
index of each entry, to be used for encoding a reference to this
entry, is computed by adding the number of entries in the header
table to this index.
Appendix C. Huffman Code Appendix C. Huffman Code
The following Huffman code is used when encoding string literals with The following Huffman code is used when encoding string literals with
a Huffman coding (see Section 6.2). a Huffman coding (see Section 6.2).
This Huffman code was generated from statistics obtained on a large This Huffman code was generated from statistics obtained on a large
sample of HTTP headers. It is a canonical Huffman code [CANONICAL] sample of HTTP headers. It is a canonical Huffman code (see
with some tweaking to ensure that no symbol has a unique code length. [CANONICAL]) with some tweaking to ensure that no symbol has a unique
code length.
Each row in the table defines the code used to represent a symbol: Each row in the table defines the code used to represent a symbol:
sym: The symbol to be represented. It is the decimal value of an sym: The symbol to be represented. It is the decimal value of an
octet, possibly prepended with its ASCII representation. A octet, possibly prepended with its ASCII representation. A
specific symbol, "EOS", is used to indicate the end of a string specific symbol, "EOS", is used to indicate the end of a string
literal. literal.
code as bits: The Huffman code for the symbol represented as a code as bits: The Huffman code for the symbol represented as a
base-2 integer, aligned on the most significant bit (MSB). base-2 integer, aligned on the most significant bit (MSB).
skipping to change at page 30, line 10 skipping to change at page 28, line 37
code as hex: The Huffman code for the symbol, represented as a code as hex: The Huffman code for the symbol, represented as a
hexadecimal integer, aligned on the least significant bit (LSB). hexadecimal integer, aligned on the least significant bit (LSB).
len: The number of bits for the code representing the symbol. len: The number of bits for the code representing the symbol.
As an example, the code for the symbol 47 (corresponding to the ASCII As an example, the code for the symbol 47 (corresponding to the ASCII
character "/") consists in the 6 bits "0", "1", "1", "0", "0", "0". character "/") consists in the 6 bits "0", "1", "1", "0", "0", "0".
This corresponds to the value 0x18 (in hexadecimal) encoded on 6 This corresponds to the value 0x18 (in hexadecimal) encoded on 6
bits. bits.
code code
code as bits as hex len code as bits as hex len
sym aligned to MSB aligned in sym aligned to MSB aligned in
to LSB bits to LSB bits
( 0) |11111111|11000 1ff8 [13] ( 0) |11111111|11000 1ff8 [13]
( 1) |11111111|11111111|1011000 7fffd8 [23] ( 1) |11111111|11111111|1011000 7fffd8 [23]
( 2) |11111111|11111111|11111110|0010 fffffe2 [28] ( 2) |11111111|11111111|11111110|0010 fffffe2 [28]
( 3) |11111111|11111111|11111110|0011 fffffe3 [28] ( 3) |11111111|11111111|11111110|0011 fffffe3 [28]
( 4) |11111111|11111111|11111110|0100 fffffe4 [28] ( 4) |11111111|11111111|11111110|0100 fffffe4 [28]
( 5) |11111111|11111111|11111110|0101 fffffe5 [28] ( 5) |11111111|11111111|11111110|0101 fffffe5 [28]
( 6) |11111111|11111111|11111110|0110 fffffe6 [28] ( 6) |11111111|11111111|11111110|0110 fffffe6 [28]
( 7) |11111111|11111111|11111110|0111 fffffe7 [28] ( 7) |11111111|11111111|11111110|0111 fffffe7 [28]
( 8) |11111111|11111111|11111110|1000 fffffe8 [28] ( 8) |11111111|11111111|11111110|1000 fffffe8 [28]
( 9) |11111111|11111111|11101010 ffffea [24] ( 9) |11111111|11111111|11101010 ffffea [24]
skipping to change at page 35, line 34 skipping to change at page 34, line 13
(251) |11111111|11111111|11111101|101 7ffffed [27] (251) |11111111|11111111|11111101|101 7ffffed [27]
(252) |11111111|11111111|11111101|110 7ffffee [27] (252) |11111111|11111111|11111101|110 7ffffee [27]
(253) |11111111|11111111|11111101|111 7ffffef [27] (253) |11111111|11111111|11111101|111 7ffffef [27]
(254) |11111111|11111111|11111110|000 7fffff0 [27] (254) |11111111|11111111|11111110|000 7fffff0 [27]
(255) |11111111|11111111|11111011|10 3ffffee [26] (255) |11111111|11111111|11111011|10 3ffffee [26]
EOS (256) |11111111|11111111|11111111|111111 3fffffff [30] EOS (256) |11111111|11111111|11111111|111111 3fffffff [30]
Appendix D. Examples Appendix D. Examples
A number of examples are worked through here, covering integer A number of examples are worked through here, covering integer
encoding, header field representation, and the encoding of whole sets encoding, header field representation, and the encoding of whole
of header fields, for both requests and responses, and with and lists of header fields, for both requests and responses, and with and
without Huffman coding. without Huffman coding.
D.1. Integer Representation Examples D.1. Integer Representation Examples
This section shows the representation of integer values in details This section shows the representation of integer values in details
(see Section 6.1). (see Section 6.1).
D.1.1. Example 1: Encoding 10 Using a 5-bit Prefix D.1.1. Example 1: Encoding 10 Using a 5-bit Prefix
The value 10 is to be encoded with a 5-bit prefix. The value 10 is to be encoded with a 5-bit prefix.
skipping to change at page 37, line 27 skipping to change at page 35, line 49
D.2. Header Field Representation Examples D.2. Header Field Representation Examples
This section shows several independent representation examples. This section shows several independent representation examples.
D.2.1. Literal Header Field with Indexing D.2.1. Literal Header Field with Indexing
The header field representation uses a literal name and a literal The header field representation uses a literal name and a literal
value. The header field is added to the header table. value. The header field is added to the header table.
Header set to encode: Header list to encode:
custom-key: custom-header custom-key: custom-header
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
400a 6375 7374 6f6d 2d6b 6579 0d63 7573 | @.custom-key.cus 400a 6375 7374 6f6d 2d6b 6579 0d63 7573 | @.custom-key.cus
746f 6d2d 6865 6164 6572 | tom-header 746f 6d2d 6865 6164 6572 | tom-header
Decoding process: Decoding process:
40 | == Literal indexed == 40 | == Literal indexed ==
0a | Literal name (len = 10) 0a | Literal name (len = 10)
6375 7374 6f6d 2d6b 6579 | custom-key 6375 7374 6f6d 2d6b 6579 | custom-key
0d | Literal value (len = 13) 0d | Literal value (len = 13)
6375 7374 6f6d 2d68 6561 6465 72 | custom-header 6375 7374 6f6d 2d68 6561 6465 72 | custom-header
| -> custom-key: custom-head\ | -> custom-key: custom-head\
| er | er
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 55) custom-key: custom-header [ 1] (s = 55) custom-key: custom-header
Table size: 55 Table size: 55
Decoded header set: Decoded header list:
custom-key: custom-header custom-key: custom-header
D.2.2. Literal Header Field without Indexing D.2.2. Literal Header Field without Indexing
The header field representation uses an indexed name and a literal The header field representation uses an indexed name and a literal
value. The header field is not added to the header table. value. The header field is not added to the header table.
Header set to encode: Header list to encode:
:path: /sample/path :path: /sample/path
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
040c 2f73 616d 706c 652f 7061 7468 | ../sample/path 040c 2f73 616d 706c 652f 7061 7468 | ../sample/path
Decoding process: Decoding process:
04 | == Literal not indexed == 04 | == Literal not indexed ==
| Indexed name (idx = 4) | Indexed name (idx = 4)
| :path | :path
0c | Literal value (len = 12) 0c | Literal value (len = 12)
2f73 616d 706c 652f 7061 7468 | /sample/path 2f73 616d 706c 652f 7061 7468 | /sample/path
| -> :path: /sample/path | -> :path: /sample/path
Header table (after decoding): empty. Header table (after decoding): empty.
Decoded header set: Decoded header list:
:path: /sample/path :path: /sample/path
D.2.3. Literal Header Field never Indexed D.2.3. Literal Header Field never Indexed
The header field representation uses a literal name and a literal The header field representation uses a literal name and a literal
value. The header field is not added to the header table, and must value. The header field is not added to the header table, and must
use the same representation if re-encoded by an intermediary. use the same representation if re-encoded by an intermediary.
Header set to encode: Header list to encode:
password: secret password: secret
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
1008 7061 7373 776f 7264 0673 6563 7265 | ..password.secre 1008 7061 7373 776f 7264 0673 6563 7265 | ..password.secre
74 | t 74 | t
Decoding process: Decoding process:
10 | == Literal never indexed == 10 | == Literal never indexed ==
08 | Literal name (len = 8) 08 | Literal name (len = 8)
7061 7373 776f 7264 | password 7061 7373 776f 7264 | password
06 | Literal value (len = 6) 06 | Literal value (len = 6)
7365 6372 6574 | secret 7365 6372 6574 | secret
| -> password: secret | -> password: secret
Header table (after decoding): empty. Header table (after decoding): empty.
Decoded header set: Decoded header list:
password: secret password: secret
D.2.4. Indexed Header Field D.2.4. Indexed Header Field
The header field representation uses an indexed header field, from The header field representation uses an indexed header field, from
the static table. Upon using it, the static table entry is copied the static table.
into the header table.
Header set to encode:
:method: GET
Reference set: empty.
Hex dump of encoded data:
82 | .
Decoding process:
82 | == Indexed - Add ==
| idx = 2
| -> :method: GET
Header Table (after decoding):
[ 1] (s = 42) :method: GET
Table size: 42
Decoded header set:
:method: GET
D.2.5. Indexed Header Field from Static Table
The header field representation uses an indexed header field, from
the static table. In this example, the HTTP/2 setting
SETTINGS_HEADER_TABLE_SIZE is set to 0, therefore, the entry is not
copied into the header table.
Header set to encode: Header list to encode:
:method: GET :method: GET
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
82 | . 82 | .
Decoding process: Decoding process:
82 | == Indexed - Add == 82 | == Indexed - Add ==
| idx = 2 | idx = 2
| -> :method: GET | -> :method: GET
Header table (after decoding): empty. Header table (after decoding): empty.
Decoded header set: Decoded header list:
:method: GET :method: GET
D.3. Request Examples without Huffman Coding D.3. Request Examples without Huffman Coding
This section shows several consecutive header sets, corresponding to This section shows several consecutive header lists, corresponding to
HTTP requests, on the same connection. HTTP requests, on the same connection.
D.3.1. First Request D.3.1. First Request
Header set to encode: Header list to encode:
:method: GET :method: GET
:scheme: http :scheme: http
:path: / :path: /
:authority: www.example.com :authority: www.example.com
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
8287 8644 0f77 7777 2e65 7861 6d70 6c65 | ...D.www.example 8286 8441 0f77 7777 2e65 7861 6d70 6c65 | ...A.www.example
2e63 6f6d | .com 2e63 6f6d | .com
Decoding process: Decoding process:
82 | == Indexed - Add == 82 | == Indexed - Add ==
| idx = 2 | idx = 2
| -> :method: GET | -> :method: GET
87 | == Indexed - Add ==
| idx = 7
| -> :scheme: http
86 | == Indexed - Add == 86 | == Indexed - Add ==
| idx = 6 | idx = 6
| -> :scheme: http
84 | == Indexed - Add ==
| idx = 4
| -> :path: / | -> :path: /
44 | == Literal indexed == 41 | == Literal indexed ==
| Indexed name (idx = 4) | Indexed name (idx = 1)
| :authority | :authority
0f | Literal value (len = 15) 0f | Literal value (len = 15)
7777 772e 6578 616d 706c 652e 636f 6d | www.example.com 7777 772e 6578 616d 706c 652e 636f 6d | www.example.com
| -> :authority: www.example\ | -> :authority: www.example\
| .com | .com
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 57) :authority: www.example.com [ 1] (s = 57) :authority: www.example.com
[ 2] (s = 38) :path: / Table size: 57
[ 3] (s = 43) :scheme: http
[ 4] (s = 42) :method: GET
Table size: 180
Decoded header set: Decoded header list:
:method: GET :method: GET
:scheme: http :scheme: http
:path: / :path: /
:authority: www.example.com :authority: www.example.com
D.3.2. Second Request D.3.2. Second Request
This request takes advantage of the differential encoding of header Header list to encode:
sets.
Header set to encode:
:method: GET :method: GET
:scheme: http :scheme: http
:path: / :path: /
:authority: www.example.com :authority: www.example.com
cache-control: no-cache cache-control: no-cache
Reference set:
[ 1] :authority: www.example.com
[ 2] :path: /
[ 3] :scheme: http
[ 4] :method: GET
Hex dump of encoded data: Hex dump of encoded data:
5c08 6e6f 2d63 6163 6865 | \.no-cache 8286 84be 5808 6e6f 2d63 6163 6865 | ....X.no-cache
Decoding process: Decoding process:
5c | == Literal indexed == 82 | == Indexed - Add ==
| Indexed name (idx = 28) | idx = 2
| -> :method: GET
86 | == Indexed - Add ==
| idx = 6
| -> :scheme: http
84 | == Indexed - Add ==
| idx = 4
| -> :path: /
be | == Indexed - Add ==
| idx = 62
| -> :authority: www.example\
| .com
58 | == Literal indexed ==
| Indexed name (idx = 24)
| cache-control | cache-control
08 | Literal value (len = 8) 08 | Literal value (len = 8)
6e6f 2d63 6163 6865 | no-cache 6e6f 2d63 6163 6865 | no-cache
| -> cache-control: no-cache | -> cache-control: no-cache
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 53) cache-control: no-cache [ 1] (s = 53) cache-control: no-cache
[ 2] (s = 57) :authority: www.example.com [ 2] (s = 57) :authority: www.example.com
[ 3] (s = 38) :path: / Table size: 110
[ 4] (s = 43) :scheme: http
[ 5] (s = 42) :method: GET
Table size: 233
Decoded header set: Decoded header list:
cache-control: no-cache
:authority: www.example.com
:path: /
:scheme: http
:method: GET :method: GET
:scheme: http
:path: /
:authority: www.example.com
cache-control: no-cache
D.3.3. Third Request D.3.3. Third Request
This request has not enough headers in common with the previous Header list to encode:
request to take advantage of the differential encoding. Therefore,
the reference set is emptied before encoding the header fields.
Header set to encode:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /index.html :path: /index.html
:authority: www.example.com :authority: www.example.com
custom-key: custom-value custom-key: custom-value
Reference set:
[ 1] cache-control: no-cache
[ 2] :authority: www.example.com
[ 3] :path: /
[ 4] :scheme: http
[ 5] :method: GET
Hex dump of encoded data: Hex dump of encoded data:
3085 8c8b 8440 0a63 7573 746f 6d2d 6b65 | 0....@.custom-ke 8287 85bf 400a 6375 7374 6f6d 2d6b 6579 | ....@.custom-key
790c 6375 7374 6f6d 2d76 616c 7565 | y.custom-value 0c63 7573 746f 6d2d 7661 6c75 65 | .custom-value
Decoding process: Decoding process:
30 | == Empty reference set == 82 | == Indexed - Add ==
| idx = 0 | idx = 2
| flag = 1
85 | == Indexed - Add ==
| idx = 5
| -> :method: GET | -> :method: GET
8c | == Indexed - Add == 87 | == Indexed - Add ==
| idx = 12 | idx = 7
| -> :scheme: https | -> :scheme: https
8b | == Indexed - Add == 85 | == Indexed - Add ==
| idx = 11 | idx = 5
| -> :path: /index.html | -> :path: /index.html
84 | == Indexed - Add == bf | == Indexed - Add ==
| idx = 4 | idx = 63
| -> :authority: www.example\ | -> :authority: www.example\
| .com | .com
40 | == Literal indexed == 40 | == Literal indexed ==
0a | Literal name (len = 10) 0a | Literal name (len = 10)
6375 7374 6f6d 2d6b 6579 | custom-key 6375 7374 6f6d 2d6b 6579 | custom-key
0c | Literal value (len = 12) 0c | Literal value (len = 12)
6375 7374 6f6d 2d76 616c 7565 | custom-value 6375 7374 6f6d 2d76 616c 7565 | custom-value
| -> custom-key: custom-valu\ | -> custom-key: custom-valu\
| e | e
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 54) custom-key: custom-value [ 1] (s = 54) custom-key: custom-value
[ 2] (s = 48) :path: /index.html [ 2] (s = 53) cache-control: no-cache
[ 3] (s = 44) :scheme: https [ 3] (s = 57) :authority: www.example.com
[ 4] (s = 53) cache-control: no-cache Table size: 164
[ 5] (s = 57) :authority: www.example.com
[ 6] (s = 38) :path: /
[ 7] (s = 43) :scheme: http
[ 8] (s = 42) :method: GET
Table size: 379
Decoded header set: Decoded header list:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /index.html :path: /index.html
:authority: www.example.com :authority: www.example.com
custom-key: custom-value custom-key: custom-value
D.4. Request Examples with Huffman Coding D.4. Request Examples with Huffman Coding
This section shows the same examples as the previous section, but This section shows the same examples as the previous section, but
using Huffman encoding for the literal values. using Huffman encoding for the literal values.
D.4.1. First Request D.4.1. First Request
Header set to encode: Header list to encode:
:method: GET :method: GET
:scheme: http :scheme: http
:path: / :path: /
:authority: www.example.com :authority: www.example.com
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
8287 8644 8cf1 e3c2 e5f2 3a6b a0ab 90f4 | ...D......:k.... 8286 8441 8cf1 e3c2 e5f2 3a6b a0ab 90f4 | ...A......:k....
ff | . ff | .
Decoding process: Decoding process:
82 | == Indexed - Add == 82 | == Indexed - Add ==
| idx = 2 | idx = 2
| -> :method: GET | -> :method: GET
87 | == Indexed - Add ==
| idx = 7
| -> :scheme: http
86 | == Indexed - Add == 86 | == Indexed - Add ==
| idx = 6 | idx = 6
| -> :scheme: http
84 | == Indexed - Add ==
| idx = 4
| -> :path: / | -> :path: /
44 | == Literal indexed == 41 | == Literal indexed ==
| Indexed name (idx = 4) | Indexed name (idx = 1)
| :authority | :authority
8c | Literal value (len = 15) 8c | Literal value (len = 12)
| Huffman encoded: | Huffman encoded:
f1e3 c2e5 f23a 6ba0 ab90 f4ff | .....:k..... f1e3 c2e5 f23a 6ba0 ab90 f4ff | .....:k.....
| Decoded: | Decoded:
| www.example.com | www.example.com
| -> :authority: www.example\ | -> :authority: www.example\
| .com | .com
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 57) :authority: www.example.com [ 1] (s = 57) :authority: www.example.com
[ 2] (s = 38) :path: / Table size: 57
[ 3] (s = 43) :scheme: http
[ 4] (s = 42) :method: GET
Table size: 180
Decoded header set: Decoded header list:
:method: GET :method: GET
:scheme: http :scheme: http
:path: / :path: /
:authority: www.example.com :authority: www.example.com
D.4.2. Second Request D.4.2. Second Request
This request takes advantage of the differential encoding of header Header list to encode:
sets.
Header set to encode:
:method: GET :method: GET
:scheme: http :scheme: http
:path: / :path: /
:authority: www.example.com :authority: www.example.com
cache-control: no-cache cache-control: no-cache
Reference set:
[ 1] :authority: www.example.com
[ 2] :path: /
[ 3] :scheme: http
[ 4] :method: GET
Hex dump of encoded data: Hex dump of encoded data:
5c86 a8eb 1064 9cbf | \....d.. 8286 84be 5886 a8eb 1064 9cbf | ....X....d..
Decoding process: Decoding process:
5c | == Literal indexed == 82 | == Indexed - Add ==
| Indexed name (idx = 28) | idx = 2
| -> :method: GET
86 | == Indexed - Add ==
| idx = 6
| -> :scheme: http
84 | == Indexed - Add ==
| idx = 4
| -> :path: /
be | == Indexed - Add ==
| idx = 62
| -> :authority: www.example\
| .com
58 | == Literal indexed ==
| Indexed name (idx = 24)
| cache-control | cache-control
86 | Literal value (len = 8) 86 | Literal value (len = 6)
| Huffman encoded: | Huffman encoded:
a8eb 1064 9cbf | ...d.. a8eb 1064 9cbf | ...d..
| Decoded: | Decoded:
| no-cache | no-cache
| -> cache-control: no-cache | -> cache-control: no-cache
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 53) cache-control: no-cache [ 1] (s = 53) cache-control: no-cache
[ 2] (s = 57) :authority: www.example.com [ 2] (s = 57) :authority: www.example.com
[ 3] (s = 38) :path: / Table size: 110
[ 4] (s = 43) :scheme: http
[ 5] (s = 42) :method: GET
Table size: 233
Decoded header set: Decoded header list:
cache-control: no-cache
:authority: www.example.com
:path: /
:scheme: http
:method: GET :method: GET
:scheme: http
:path: /
:authority: www.example.com
cache-control: no-cache
D.4.3. Third Request D.4.3. Third Request
Header list to encode:
This request has not enough headers in common with the previous
request to take advantage of the differential encoding. Therefore,
the reference set is emptied before encoding the header fields.
Header set to encode:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /index.html :path: /index.html
:authority: www.example.com :authority: www.example.com
custom-key: custom-value custom-key: custom-value
Reference set:
[ 1] cache-control: no-cache
[ 2] :authority: www.example.com
[ 3] :path: /
[ 4] :scheme: http
[ 5] :method: GET
Hex dump of encoded data: Hex dump of encoded data:
3085 8c8b 8440 8825 a849 e95b a97d 7f89 | 0....@.%.I.[.}.. 8287 85bf 4088 25a8 49e9 5ba9 7d7f 8925 | ....@.%.I.[.}..%
25a8 49e9 5bb8 e8b4 bf | %.I.[.... a849 e95b b8e8 b4bf | .I.[....
Decoding process: Decoding process:
30 | == Empty reference set == 82 | == Indexed - Add ==
| idx = 0 | idx = 2
| flag = 1
85 | == Indexed - Add ==
| idx = 5
| -> :method: GET | -> :method: GET
8c | == Indexed - Add == 87 | == Indexed - Add ==
| idx = 12 | idx = 7
| -> :scheme: https | -> :scheme: https
8b | == Indexed - Add == 85 | == Indexed - Add ==
| idx = 11 | idx = 5
| -> :path: /index.html | -> :path: /index.html
84 | == Indexed - Add == bf | == Indexed - Add ==
| idx = 4 | idx = 63
| -> :authority: www.example\ | -> :authority: www.example\
| .com | .com
40 | == Literal indexed == 40 | == Literal indexed ==
88 | Literal name (len = 10) 88 | Literal name (len = 8)
| Huffman encoded: | Huffman encoded:
25a8 49e9 5ba9 7d7f | %.I.[.}. 25a8 49e9 5ba9 7d7f | %.I.[.}.
| Decoded: | Decoded:
| custom-key | custom-key
89 | Literal value (len = 12) 89 | Literal value (len = 9)
| Huffman encoded: | Huffman encoded:
25a8 49e9 5bb8 e8b4 bf | %.I.[.... 25a8 49e9 5bb8 e8b4 bf | %.I.[....
| Decoded: | Decoded:
| custom-value | custom-value
| -> custom-key: custom-valu\ | -> custom-key: custom-valu\
| e | e
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 54) custom-key: custom-value [ 1] (s = 54) custom-key: custom-value
[ 2] (s = 48) :path: /index.html [ 2] (s = 53) cache-control: no-cache
[ 3] (s = 44) :scheme: https [ 3] (s = 57) :authority: www.example.com
[ 4] (s = 53) cache-control: no-cache Table size: 164
[ 5] (s = 57) :authority: www.example.com
[ 6] (s = 38) :path: /
[ 7] (s = 43) :scheme: http
[ 8] (s = 42) :method: GET
Table size: 379
Decoded header set: Decoded header list:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /index.html :path: /index.html
:authority: www.example.com :authority: www.example.com
custom-key: custom-value custom-key: custom-value
D.5. Response Examples without Huffman Coding D.5. Response Examples without Huffman Coding
This section shows several consecutive header sets, corresponding to This section shows several consecutive header lists, corresponding to
HTTP responses, on the same connection. The HTTP/2 setting HTTP responses, on the same connection. The HTTP/2 setting parameter
SETTINGS_HEADER_TABLE_SIZE is set to the value of 256 octets, causing SETTINGS_HEADER_TABLE_SIZE is set to the value of 256 octets, causing
some evictions to occur. some evictions to occur.
D.5.1. First Response D.5.1. First Response
Header set to encode: Header list to encode:
:status: 302 :status: 302
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com location: https://www.example.com
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
4803 3330 3259 0770 7269 7661 7465 631d | H.302Y.privatec. 4803 3330 3258 0770 7269 7661 7465 611d | H.302X.privatea.
4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013 4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013
2032 303a 3133 3a32 3120 474d 5471 1768 | 20:13:21 GMTq.h 2032 303a 3133 3a32 3120 474d 546e 1768 | 20:13:21 GMTn.h
7474 7073 3a2f 2f77 7777 2e65 7861 6d70 | ttps://www.examp 7474 7073 3a2f 2f77 7777 2e65 7861 6d70 | ttps://www.examp
6c65 2e63 6f6d | le.com 6c65 2e63 6f6d | le.com
Decoding process: Decoding process:
48 | == Literal indexed == 48 | == Literal indexed ==
| Indexed name (idx = 8) | Indexed name (idx = 8)
| :status | :status
03 | Literal value (len = 3) 03 | Literal value (len = 3)
3330 32 | 302 3330 32 | 302
| -> :status: 302 | -> :status: 302
59 | == Literal indexed == 58 | == Literal indexed ==
| Indexed name (idx = 25) | Indexed name (idx = 24)
| cache-control | cache-control
07 | Literal value (len = 7) 07 | Literal value (len = 7)
7072 6976 6174 65 | private 7072 6976 6174 65 | private
| -> cache-control: private | -> cache-control: private
63 | == Literal indexed == 61 | == Literal indexed ==
| Indexed name (idx = 35) | Indexed name (idx = 33)
| date | date
1d | Literal value (len = 29) 1d | Literal value (len = 29)
4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013 4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013
2032 303a 3133 3a32 3120 474d 54 | 20:13:21 GMT 2032 303a 3133 3a32 3120 474d 54 | 20:13:21 GMT
| -> date: Mon, 21 Oct 2013 \ | -> date: Mon, 21 Oct 2013 \
| 20:13:21 GMT | 20:13:21 GMT
71 | == Literal indexed == 6e | == Literal indexed ==
| Indexed name (idx = 49) | Indexed name (idx = 46)
| location | location
17 | Literal value (len = 23) 17 | Literal value (len = 23)
6874 7470 733a 2f2f 7777 772e 6578 616d | https://www.exam 6874 7470 733a 2f2f 7777 772e 6578 616d | https://www.exam
706c 652e 636f 6d | ple.com 706c 652e 636f 6d | ple.com
| -> location: https://www.e\ | -> location: https://www.e\
| xample.com | xample.com
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 63) location: https://www.example.com [ 1] (s = 63) location: https://www.example.com
[ 2] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT [ 2] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
[ 3] (s = 52) cache-control: private [ 3] (s = 52) cache-control: private
[ 4] (s = 42) :status: 302 [ 4] (s = 42) :status: 302
Table size: 222 Table size: 222
Decoded header set: Decoded header list:
:status: 302 :status: 302
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com location: https://www.example.com
D.5.2. Second Response D.5.2. Second Response
The (":status", "302") header field is evicted from the header table The (":status", "302") header field is evicted from the header table
to free space to allow adding the (":status", "200") header field, to free space to allow adding the (":status", "307") header field.
copied from the static table into the header table. The (":status",
"302") header field doesn't need to be removed from the reference set
as it is evicted from the header table.
Header set to encode: Header list to encode:
:status: 200 :status: 307
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com location: https://www.example.com
Reference set:
[ 1] location: https://www.example.com
[ 2] date: Mon, 21 Oct 2013 20:13:21 GMT
[ 3] cache-control: private
[ 4] :status: 302
Hex dump of encoded data: Hex dump of encoded data:
8c | . 4803 3330 37c1 c0bf | H.307...
Decoding process: Decoding process:
8c | == Indexed - Add == 48 | == Literal indexed ==
| idx = 12 | Indexed name (idx = 8)
| :status
03 | Literal value (len = 3)
3330 37 | 307
| - evict: :status: 302 | - evict: :status: 302
| -> :status: 200 | -> :status: 307
c1 | == Indexed - Add ==
| idx = 65
| -> cache-control: private
c0 | == Indexed - Add ==
| idx = 64
| -> date: Mon, 21 Oct 2013 \
| 20:13:21 GMT
bf | == Indexed - Add ==
| idx = 63
| -> location: https://www.e\
| xample.com
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 42) :status: 200 [ 1] (s = 42) :status: 307
[ 2] (s = 63) location: https://www.example.com [ 2] (s = 63) location: https://www.example.com
[ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
[ 4] (s = 52) cache-control: private [ 4] (s = 52) cache-control: private
Table size: 222 Table size: 222
Decoded header set: Decoded header list:
:status: 200 :status: 307
location: https://www.example.com
date: Mon, 21 Oct 2013 20:13:21 GMT
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com
D.5.3. Third Response D.5.3. Third Response
Several header fields are evicted from the header table during the Several header fields are evicted from the header table during the
processing of this header set. Before evicting a header belonging to processing of this header list.
the reference set, it is emitted, by coding it twice as an Indexed
Representation. The first representation removes the header field
from the reference set, the second one adds it again to the reference
set, also emitting it.
Header set to encode: Header list to encode:
:status: 200 :status: 200
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:22 GMT date: Mon, 21 Oct 2013 20:13:22 GMT
location: https://www.example.com location: https://www.example.com
content-encoding: gzip content-encoding: gzip
set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1 set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
Reference set:
[ 1] :status: 200
[ 2] location: https://www.example.com
[ 3] date: Mon, 21 Oct 2013 20:13:21 GMT
[ 4] cache-control: private
Hex dump of encoded data: Hex dump of encoded data:
8484 431d 4d6f 6e2c 2032 3120 4f63 7420 | ..C.Mon, 21 Oct 88c1 611d 4d6f 6e2c 2032 3120 4f63 7420 | ..a.Mon, 21 Oct
3230 3133 2032 303a 3133 3a32 3220 474d | 2013 20:13:22 GM 3230 3133 2032 303a 3133 3a32 3220 474d | 2013 20:13:22 GM
545e 0467 7a69 7084 8483 837b 3866 6f6f | T^.gzip....{8foo 54c0 5a04 677a 6970 7738 666f 6f3d 4153 | T.Z.gzipw8foo=AS
3d41 5344 4a4b 4851 4b42 5a58 4f51 5745 | =ASDJKHQKBZXOQWE 444a 4b48 514b 425a 584f 5157 454f 5049 | DJKHQKBZXOQWEOPI
4f50 4955 4158 5157 454f 4955 3b20 6d61 | OPIUAXQWEOIU; ma 5541 5851 5745 4f49 553b 206d 6178 2d61 | UAXQWEOIU; max-a
782d 6167 653d 3336 3030 3b20 7665 7273 | x-age=3600; vers 6765 3d33 3630 303b 2076 6572 7369 6f6e | ge=3600; version
696f 6e3d 31 | ion=1 3d31 | =1
Decoding process: Decoding process:
84 | == Indexed - Remove == 88 | == Indexed - Add ==
| idx = 4 | idx = 8
| -> cache-control: private | -> :status: 200
84 | == Indexed - Add == c1 | == Indexed - Add ==
| idx = 4 | idx = 65
| -> cache-control: private | -> cache-control: private
43 | == Literal indexed == 61 | == Literal indexed ==
| Indexed name (idx = 3) | Indexed name (idx = 33)
| date | date
1d | Literal value (len = 29) 1d | Literal value (len = 29)
4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013 4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013
2032 303a 3133 3a32 3220 474d 54 | 20:13:22 GMT 2032 303a 3133 3a32 3220 474d 54 | 20:13:22 GMT
| - evict: cache-control: pr\ | - evict: cache-control: pr\
| ivate | ivate
| -> date: Mon, 21 Oct 2013 \ | -> date: Mon, 21 Oct 2013 \
| 20:13:22 GMT | 20:13:22 GMT
5e | == Literal indexed == c0 | == Indexed - Add ==
| Indexed name (idx = 30) | idx = 64
| -> location: https://www.e\
| xample.com
5a | == Literal indexed ==
| Indexed name (idx = 26)
| content-encoding | content-encoding
04 | Literal value (len = 4) 04 | Literal value (len = 4)
677a 6970 | gzip 677a 6970 | gzip
| - evict: date: Mon, 21 Oct\ | - evict: date: Mon, 21 Oct\
| 2013 20:13:21 GMT | 2013 20:13:21 GMT
| -> content-encoding: gzip | -> content-encoding: gzip
84 | == Indexed - Remove == 77 | == Literal indexed ==
| idx = 4 | Indexed name (idx = 55)
| -> location: https://www.e\
| xample.com
84 | == Indexed - Add ==
| idx = 4
| -> location: https://www.e\
| xample.com
83 | == Indexed - Remove ==
| idx = 3
| -> :status: 200
83 | == Indexed - Add ==
| idx = 3
| -> :status: 200
7b | == Literal indexed ==
| Indexed name (idx = 59)
| set-cookie | set-cookie
38 | Literal value (len = 56) 38 | Literal value (len = 56)
666f 6f3d 4153 444a 4b48 514b 425a 584f | foo=ASDJKHQKBZXO 666f 6f3d 4153 444a 4b48 514b 425a 584f | foo=ASDJKHQKBZXO
5157 454f 5049 5541 5851 5745 4f49 553b | QWEOPIUAXQWEOIU; 5157 454f 5049 5541 5851 5745 4f49 553b | QWEOPIUAXQWEOIU;
206d 6178 2d61 6765 3d33 3630 303b 2076 | max-age=3600; v 206d 6178 2d61 6765 3d33 3630 303b 2076 | max-age=3600; v
6572 7369 6f6e 3d31 | ersion=1 6572 7369 6f6e 3d31 | ersion=1
| - evict: location: https:/\ | - evict: location: https:/\
| /www.example.com | /www.example.com
| - evict: :status: 200 | - evict: :status: 307
| -> set-cookie: foo=ASDJKHQ\ | -> set-cookie: foo=ASDJKHQ\
| KBZXOQWEOPIUAXQWEOIU; ma\ | KBZXOQWEOPIUAXQWEOIU; ma\
| x-age=3600; version=1 | x-age=3600; version=1
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 98) set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age\ [ 1] (s = 98) set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age\
=3600; version=1 =3600; version=1
[ 2] (s = 52) content-encoding: gzip [ 2] (s = 52) content-encoding: gzip
[ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:22 GMT [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:22 GMT
Table size: 215 Table size: 215
Decoded header set: Decoded header list:
:status: 200
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:22 GMT date: Mon, 21 Oct 2013 20:13:22 GMT
content-encoding: gzip
location: https://www.example.com location: https://www.example.com
:status: 200 content-encoding: gzip
set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1 set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
D.6. Response Examples with Huffman Coding D.6. Response Examples with Huffman Coding
This section shows the same examples as the previous section, but This section shows the same examples as the previous section, but
using Huffman encoding for the literal values. The HTTP/2 setting using Huffman encoding for the literal values. The HTTP/2 setting
SETTINGS_HEADER_TABLE_SIZE is set to the value of 256 octets, causing parameter SETTINGS_HEADER_TABLE_SIZE is set to the value of 256
some evictions to occur. The eviction mechanism uses the length of octets, causing some evictions to occur. The eviction mechanism uses
the decoded literal values, so the same evictions occurs as in the the length of the decoded literal values, so the same evictions
previous section. occurs as in the previous section.
D.6.1. First Response D.6.1. First Response
Header set to encode: Header list to encode:
:status: 302 :status: 302
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com location: https://www.example.com
Reference set: empty.
Hex dump of encoded data: Hex dump of encoded data:
4882 6402 5985 aec3 771a 4b63 96d0 7abe | H.d.Y...w.Kc..z. 4882 6402 5885 aec3 771a 4b61 96d0 7abe | H.d.X...w.Ka..z.
9410 54d4 44a8 2005 9504 0b81 66e0 82a6 | ..T.D. .....f... 9410 54d4 44a8 2005 9504 0b81 66e0 82a6 | ..T.D. .....f...
2d1b ff71 919d 29ad 1718 63c7 8f0b 97c8 | -..q..)...c..... 2d1b ff6e 919d 29ad 1718 63c7 8f0b 97c8 | -..n..)...c.....
e9ae 82ae 43d3 | ....C. e9ae 82ae 43d3 | ....C.
Decoding process: Decoding process:
48 | == Literal indexed == 48 | == Literal indexed ==
| Indexed name (idx = 8) | Indexed name (idx = 8)
| :status | :status
82 | Literal value (len = 3) 82 | Literal value (len = 2)
| Huffman encoded: | Huffman encoded:
6402 | d. 6402 | d.
| Decoded: | Decoded:
| 302 | 302
| -> :status: 302 | -> :status: 302
59 | == Literal indexed == 58 | == Literal indexed ==
| Indexed name (idx = 25) | Indexed name (idx = 24)
| cache-control | cache-control
85 | Literal value (len = 7) 85 | Literal value (len = 5)
| Huffman encoded: | Huffman encoded:
aec3 771a 4b | ..w.K aec3 771a 4b | ..w.K
| Decoded: | Decoded:
| private | private
| -> cache-control: private | -> cache-control: private
63 | == Literal indexed == 61 | == Literal indexed ==
| Indexed name (idx = 35) | Indexed name (idx = 33)
| date | date
96 | Literal value (len = 29) 96 | Literal value (len = 22)
| Huffman encoded: | Huffman encoded:
d07a be94 1054 d444 a820 0595 040b 8166 | .z...T.D. .....f d07a be94 1054 d444 a820 0595 040b 8166 | .z...T.D. .....f
e082 a62d 1bff | ...-.. e082 a62d 1bff | ...-..
| Decoded: | Decoded:
| Mon, 21 Oct 2013 20:13:21 \ | Mon, 21 Oct 2013 20:13:21 \
| GMT | GMT
| -> date: Mon, 21 Oct 2013 \ | -> date: Mon, 21 Oct 2013 \
| 20:13:21 GMT | 20:13:21 GMT
71 | == Literal indexed == 6e | == Literal indexed ==
| Indexed name (idx = 49) | Indexed name (idx = 46)
| location | location
91 | Literal value (len = 23) 91 | Literal value (len = 17)
| Huffman encoded: | Huffman encoded:
9d29 ad17 1863 c78f 0b97 c8e9 ae82 ae43 | .)...c.........C 9d29 ad17 1863 c78f 0b97 c8e9 ae82 ae43 | .)...c.........C
d3 | . d3 | .
| Decoded: | Decoded:
| https://www.example.com | https://www.example.com
| -> location: https://www.e\ | -> location: https://www.e\
| xample.com | xample.com
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 63) location: https://www.example.com [ 1] (s = 63) location: https://www.example.com
[ 2] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT [ 2] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
[ 3] (s = 52) cache-control: private [ 3] (s = 52) cache-control: private
[ 4] (s = 42) :status: 302 [ 4] (s = 42) :status: 302
Table size: 222 Table size: 222
Decoded header set: Decoded header list:
:status: 302 :status: 302
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com location: https://www.example.com
D.6.2. Second Response D.6.2. Second Response
The (":status", "302") header field is evicted from the header table The (":status", "302") header field is evicted from the header table
to free space to allow adding the (":status", "200") header field, to free space to allow adding the (":status", "307") header field.
copied from the static table into the header table. The (":status",
"302") header field doesn't need to be removed from the reference set
as it is evicted from the header table.
Header set to encode: Header list to encode:
:status: 200 :status: 307
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com location: https://www.example.com
Reference set:
[ 1] location: https://www.example.com
[ 2] date: Mon, 21 Oct 2013 20:13:21 GMT
[ 3] cache-control: private
[ 4] :status: 302
Hex dump of encoded data: Hex dump of encoded data:
8c | . 4883 640e ffc1 c0bf | H.d.....
Decoding process: Decoding process:
8c | == Indexed - Add == 48 | == Literal indexed ==
| idx = 12 | Indexed name (idx = 8)
| :status
83 | Literal value (len = 3)
| Huffman encoded:
640e ff | d..
| Decoded:
| 307
| - evict: :status: 302 | - evict: :status: 302
| -> :status: 200 | -> :status: 307
c1 | == Indexed - Add ==
| idx = 65
| -> cache-control: private
c0 | == Indexed - Add ==
| idx = 64
| -> date: Mon, 21 Oct 2013 \
| 20:13:21 GMT
bf | == Indexed - Add ==
| idx = 63
| -> location: https://www.e\
| xample.com
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 42) :status: 200 [ 1] (s = 42) :status: 307
[ 2] (s = 63) location: https://www.example.com [ 2] (s = 63) location: https://www.example.com
[ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
[ 4] (s = 52) cache-control: private [ 4] (s = 52) cache-control: private
Table size: 222 Table size: 222
Decoded header set: Decoded header list:
:status: 200 :status: 307
location: https://www.example.com
date: Mon, 21 Oct 2013 20:13:21 GMT
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:21 GMT
location: https://www.example.com
D.6.3. Third Response D.6.3. Third Response
Several header fields are evicted from the header table during the Several header fields are evicted from the header table during the
processing of this header set. Before evicting a header belonging to processing of this header list.
the reference set, it is emitted, by coding it twice as an Indexed
Representation. The first representation removes the header field
from the reference set, the second one adds it again to the reference
set, also emitting it.
Header set to encode: Header list to encode:
:status: 200 :status: 200
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:22 GMT date: Mon, 21 Oct 2013 20:13:22 GMT
location: https://www.example.com location: https://www.example.com
content-encoding: gzip content-encoding: gzip
set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1 set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
Reference set:
[ 1] :status: 200
[ 2] location: https://www.example.com
[ 3] date: Mon, 21 Oct 2013 20:13:21 GMT
[ 4] cache-control: private
Hex dump of encoded data: Hex dump of encoded data:
8484 4396 d07a be94 1054 d444 a820 0595 | ..C..z...T.D. .. 88c1 6196 d07a be94 1054 d444 a820 0595 | ..a..z...T.D. ..
040b 8166 e084 a62d 1bff 5e83 9bd9 ab84 | ...f...-..^..... 040b 8166 e084 a62d 1bff c05a 839b d9ab | ...f...-...Z....
8483 837b ad94 e782 1dd7 f2e6 c7b3 35df | ...{..........5. 77ad 94e7 821d d7f2 e6c7 b335 dfdf cd5b | w..........5...[
dfcd 5b39 60d5 af27 087f 3672 c1ab 270f | ..[9`..'..6r..'. 3960 d5af 2708 7f36 72c1 ab27 0fb5 291f | 9`..'..6r..'..).
b529 1f95 8731 6065 c003 ed4e e5b1 063d | .)...1`e...N...= 9587 3160 65c0 03ed 4ee5 b106 3d50 07 | ..1`e...N...=P.
5007 | P.
Decoding process: Decoding process:
84 | == Indexed - Remove == 88 | == Indexed - Add ==
| idx = 4 | idx = 8
| -> cache-control: private | -> :status: 200
84 | == Indexed - Add == c1 | == Indexed - Add ==
| idx = 4 | idx = 65
| -> cache-control: private | -> cache-control: private
43 | == Literal indexed == 61 | == Literal indexed ==
| Indexed name (idx = 3) | Indexed name (idx = 33)
| date | date
96 | Literal value (len = 29) 96 | Literal value (len = 22)
| Huffman encoded: | Huffman encoded:
d07a be94 1054 d444 a820 0595 040b 8166 | .z...T.D. .....f d07a be94 1054 d444 a820 0595 040b 8166 | .z...T.D. .....f
e084 a62d 1bff | ...-.. e084 a62d 1bff | ...-..
| Decoded: | Decoded:
| Mon, 21 Oct 2013 20:13:22 \ | Mon, 21 Oct 2013 20:13:22 \
| GMT | GMT
| - evict: cache-control: pr\ | - evict: cache-control: pr\
| ivate | ivate
| -> date: Mon, 21 Oct 2013 \ | -> date: Mon, 21 Oct 2013 \
| 20:13:22 GMT | 20:13:22 GMT
5e | == Literal indexed == c0 | == Indexed - Add ==
| Indexed name (idx = 30) | idx = 64
| -> location: https://www.e\
| xample.com
5a | == Literal indexed ==
| Indexed name (idx = 26)
| content-encoding | content-encoding
83 | Literal value (len = 4) 83 | Literal value (len = 3)
| Huffman encoded: | Huffman encoded:
9bd9 ab | ... 9bd9 ab | ...
| Decoded: | Decoded:
| gzip | gzip
| - evict: date: Mon, 21 Oct\ | - evict: date: Mon, 21 Oct\
| 2013 20:13:21 GMT | 2013 20:13:21 GMT
| -> content-encoding: gzip | -> content-encoding: gzip
84 | == Indexed - Remove == 77 | == Literal indexed ==
| idx = 4 | Indexed name (idx = 55)
| -> location: https://www.e\
| xample.com
84 | == Indexed - Add ==
| idx = 4
| -> location: https://www.e\
| xample.com
83 | == Indexed - Remove ==
| idx = 3
| -> :status: 200
83 | == Indexed - Add ==
| idx = 3
| -> :status: 200
7b | == Literal indexed ==
| Indexed name (idx = 59)
| set-cookie | set-cookie
ad | Literal value (len = 56) ad | Literal value (len = 45)
| Huffman encoded: | Huffman encoded:
94e7 821d d7f2 e6c7 b335 dfdf cd5b 3960 | .........5...[9` 94e7 821d d7f2 e6c7 b335 dfdf cd5b 3960 | .........5...[9`
d5af 2708 7f36 72c1 ab27 0fb5 291f 9587 | ..'..6r..'..)... d5af 2708 7f36 72c1 ab27 0fb5 291f 9587 | ..'..6r..'..)...
3160 65c0 03ed 4ee5 b106 3d50 07 | 1`e...N...=P. 3160 65c0 03ed 4ee5 b106 3d50 07 | 1`e...N...=P.
| Decoded: | Decoded:
| foo=ASDJKHQKBZXOQWEOPIUAXQ\ | foo=ASDJKHQKBZXOQWEOPIUAXQ\
| WEOIU; max-age=3600; versi\ | WEOIU; max-age=3600; versi\
| on=1 | on=1
| - evict: location: https:/\ | - evict: location: https:/\
| /www.example.com | /www.example.com
| - evict: :status: 200 | - evict: :status: 307
| -> set-cookie: foo=ASDJKHQ\ | -> set-cookie: foo=ASDJKHQ\
| KBZXOQWEOPIUAXQWEOIU; ma\ | KBZXOQWEOPIUAXQWEOIU; ma\
| x-age=3600; version=1 | x-age=3600; version=1
Header Table (after decoding): Header Table (after decoding):
[ 1] (s = 98) set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age\ [ 1] (s = 98) set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age\
=3600; version=1 =3600; version=1
[ 2] (s = 52) content-encoding: gzip [ 2] (s = 52) content-encoding: gzip
[ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:22 GMT [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:22 GMT
Table size: 215 Table size: 215
Decoded header set: Decoded header list:
:status: 200
cache-control: private cache-control: private
date: Mon, 21 Oct 2013 20:13:22 GMT date: Mon, 21 Oct 2013 20:13:22 GMT
content-encoding: gzip
location: https://www.example.com location: https://www.example.com
:status: 200 content-encoding: gzip
set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1 set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
Authors' Addresses Authors' Addresses
Roberto Peon Roberto Peon
Google, Inc Google, Inc
EMail: fenix@google.com EMail: fenix@google.com
Herve Ruellan Herve Ruellan
Canon CRF Canon CRF
EMail: herve.ruellan@crf.canon.fr EMail: herve.ruellan@crf.canon.fr
 End of changes. 257 change blocks. 
781 lines changed or deleted 584 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/