summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7541.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7541.txt')
-rw-r--r--doc/rfc/rfc7541.txt3083
1 files changed, 3083 insertions, 0 deletions
diff --git a/doc/rfc/rfc7541.txt b/doc/rfc/rfc7541.txt
new file mode 100644
index 0000000..4c9c202
--- /dev/null
+++ b/doc/rfc/rfc7541.txt
@@ -0,0 +1,3083 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Peon
+Request for Comments: 7541 Google, Inc
+Category: Standards Track H. Ruellan
+ISSN: 2070-1721 Canon CRF
+ May 2015
+
+
+ HPACK: Header Compression for HTTP/2
+
+Abstract
+
+ This specification defines HPACK, a compression format for
+ efficiently representing HTTP header fields, to be used in HTTP/2.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7541.
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 1]
+
+RFC 7541 HPACK May 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Overview ...................................................4
+ 1.2. Conventions ................................................5
+ 1.3. Terminology ................................................5
+ 2. Compression Process Overview ....................................6
+ 2.1. Header List Ordering .......................................6
+ 2.2. Encoding and Decoding Contexts .............................6
+ 2.3. Indexing Tables ............................................6
+ 2.3.1. Static Table ........................................6
+ 2.3.2. Dynamic Table .......................................6
+ 2.3.3. Index Address Space .................................7
+ 2.4. Header Field Representation ................................8
+ 3. Header Block Decoding ...........................................8
+ 3.1. Header Block Processing ....................................8
+ 3.2. Header Field Representation Processing .....................9
+ 4. Dynamic Table Management ........................................9
+ 4.1. Calculating Table Size ....................................10
+ 4.2. Maximum Table Size ........................................10
+ 4.3. Entry Eviction When Dynamic Table Size Changes ............11
+ 4.4. Entry Eviction When Adding New Entries ....................11
+ 5. Primitive Type Representations .................................11
+ 5.1. Integer Representation ....................................11
+ 5.2. String Literal Representation .............................13
+ 6. Binary Format ..................................................14
+ 6.1. Indexed Header Field Representation .......................14
+ 6.2. Literal Header Field Representation .......................15
+ 6.2.1. Literal Header Field with Incremental Indexing .....15
+ 6.2.2. Literal Header Field without Indexing ..............16
+ 6.2.3. Literal Header Field Never Indexed .................17
+ 6.3. Dynamic Table Size Update .................................18
+ 7. Security Considerations ........................................19
+ 7.1. Probing Dynamic Table State ...............................19
+ 7.1.1. Applicability to HPACK and HTTP ....................20
+ 7.1.2. Mitigation .........................................20
+ 7.1.3. Never-Indexed Literals .............................21
+ 7.2. Static Huffman Encoding ...................................22
+ 7.3. Memory Consumption ........................................22
+ 7.4. Implementation Limits .....................................23
+ 8. References .....................................................23
+ 8.1. Normative References ......................................23
+ 8.2. Informative References ....................................24
+ Appendix A. Static Table Definition ...............................25
+ Appendix B. Huffman Code ..........................................27
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 2]
+
+RFC 7541 HPACK May 2015
+
+
+ Appendix C. Examples ..............................................33
+ C.1. Integer Representation Examples ............................33
+ C.1.1. Example 1: Encoding 10 Using a 5-Bit Prefix ............33
+ C.1.2. Example 2: Encoding 1337 Using a 5-Bit Prefix ..........33
+ C.1.3. Example 3: Encoding 42 Starting at an Octet Boundary ...34
+ C.2. Header Field Representation Examples .......................34
+ C.2.1. Literal Header Field with Indexing .....................34
+ C.2.2. Literal Header Field without Indexing ..................35
+ C.2.3. Literal Header Field Never Indexed .....................36
+ C.2.4. Indexed Header Field ...................................37
+ C.3. Request Examples without Huffman Coding ....................37
+ C.3.1. First Request ..........................................37
+ C.3.2. Second Request .........................................38
+ C.3.3. Third Request ..........................................39
+ C.4. Request Examples with Huffman Coding .......................41
+ C.4.1. First Request ..........................................41
+ C.4.2. Second Request .........................................42
+ C.4.3. Third Request ..........................................43
+ C.5. Response Examples without Huffman Coding ...................45
+ C.5.1. First Response .........................................45
+ C.5.2. Second Response ........................................46
+ C.5.3. Third Response .........................................47
+ C.6. Response Examples with Huffman Coding ......................49
+ C.6.1. First Response .........................................49
+ C.6.2. Second Response ........................................51
+ C.6.3. Third Response .........................................52
+ Acknowledgments ...................................................55
+ Authors' Addresses ................................................55
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 3]
+
+RFC 7541 HPACK May 2015
+
+
+1. Introduction
+
+ In HTTP/1.1 (see [RFC7230]), header fields are not compressed. As
+ web pages have grown to require dozens to hundreds of requests, the
+ redundant header fields in these requests unnecessarily consume
+ bandwidth, measurably increasing latency.
+
+ SPDY [SPDY] initially addressed this redundancy by compressing header
+ fields using the DEFLATE [DEFLATE] format, which proved very
+ effective at efficiently representing the redundant header fields.
+ However, that approach exposed a security risk as demonstrated by the
+ CRIME (Compression Ratio Info-leak Made Easy) attack (see [CRIME]).
+
+ This specification defines HPACK, a new compressor that eliminates
+ redundant header fields, limits vulnerability to known security
+ attacks, and has a bounded memory requirement for use in constrained
+ environments. Potential security concerns for HPACK are described in
+ Section 7.
+
+ The HPACK format is intentionally simple and inflexible. Both
+ characteristics reduce the risk of interoperability or security
+ issues due to implementation error. No extensibility mechanisms are
+ defined; changes to the format are only possible by defining a
+ complete replacement.
+
+1.1. Overview
+
+ The format defined in this specification treats a list of header
+ fields as an ordered collection of name-value pairs that can include
+ duplicate pairs. Names and values are considered to be opaque
+ sequences of octets, and the order of header fields is preserved
+ after being compressed and decompressed.
+
+ Encoding is informed by header field tables that map header fields to
+ indexed values. These header field tables can be incrementally
+ updated as new header fields are encoded or decoded.
+
+ In the encoded form, a header field is represented either literally
+ or as a reference to a header field in one of the header field
+ tables. Therefore, a list of header fields can be encoded using a
+ mixture of references and literal values.
+
+ Literal values are either encoded directly or use a static Huffman
+ code.
+
+ The encoder is responsible for deciding which header fields to insert
+ as new entries in the header field tables. The decoder executes the
+ modifications to the header field tables prescribed by the encoder,
+
+
+
+Peon & Ruellan Standards Track [Page 4]
+
+RFC 7541 HPACK May 2015
+
+
+ reconstructing the list of header fields in the process. This
+ enables decoders to remain simple and interoperate with a wide
+ variety of encoders.
+
+ Examples illustrating the use of these different mechanisms to
+ represent header fields are available in Appendix C.
+
+1.2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ All numeric values are in network byte order. Values are unsigned
+ unless otherwise indicated. Literal values are provided in decimal
+ or hexadecimal as appropriate.
+
+1.3. Terminology
+
+ This specification uses the following terms:
+
+ Header Field: A name-value pair. Both the name and value are
+ treated as opaque sequences of octets.
+
+ Dynamic Table: The dynamic table (see Section 2.3.2) is a table that
+ associates stored header fields with index values. This table is
+ dynamic and specific to an encoding or decoding context.
+
+ Static Table: The static table (see Section 2.3.1) is a table that
+ statically associates header fields that occur frequently with
+ index values. This table is ordered, read-only, always
+ accessible, and it may be shared amongst all encoding or decoding
+ contexts.
+
+ Header List: A header list is an ordered collection of header fields
+ that are encoded jointly and can contain duplicate header fields.
+ A complete list of header fields contained in an HTTP/2 header
+ block is a header list.
+
+ Header Field Representation: A header field can be represented in
+ encoded form either as a literal or as an index (see Section 2.4).
+
+ Header Block: An ordered list of header field representations,
+ which, when decoded, yields a complete header list.
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 5]
+
+RFC 7541 HPACK May 2015
+
+
+2. Compression Process Overview
+
+ This specification does not describe a specific algorithm for an
+ encoder. Instead, it defines precisely how a decoder is expected to
+ operate, allowing encoders to produce any encoding that this
+ definition permits.
+
+2.1. Header List Ordering
+
+ HPACK preserves the ordering of header fields inside the header list.
+ An encoder MUST order header field representations in the header
+ block according to their ordering in the original header list. A
+ decoder MUST order header fields in the decoded header list according
+ to their ordering in the header block.
+
+2.2. Encoding and Decoding Contexts
+
+ To decompress header blocks, a decoder only needs to maintain a
+ dynamic table (see Section 2.3.2) as a decoding context. No other
+ dynamic state is needed.
+
+ When used for bidirectional communication, such as in HTTP, the
+ encoding and decoding dynamic tables maintained by an endpoint are
+ completely independent, i.e., the request and response dynamic tables
+ are separate.
+
+2.3. Indexing Tables
+
+ HPACK uses two tables for associating header fields to indexes. The
+ static table (see Section 2.3.1) is predefined and contains common
+ header fields (most of them with an empty value). The dynamic table
+ (see Section 2.3.2) is dynamic and can be used by the encoder to
+ index header fields repeated in the encoded header lists.
+
+ These two tables are combined into a single address space for
+ defining index values (see Section 2.3.3).
+
+2.3.1. Static Table
+
+ The static table consists of a predefined static list of header
+ fields. Its entries are defined in Appendix A.
+
+2.3.2. Dynamic Table
+
+ The dynamic table consists of a list of header fields maintained in
+ first-in, first-out order. The first and newest entry in a dynamic
+ table is at the lowest index, and the oldest entry of a dynamic table
+ is at the highest index.
+
+
+
+Peon & Ruellan Standards Track [Page 6]
+
+RFC 7541 HPACK May 2015
+
+
+ The dynamic table is initially empty. Entries are added as each
+ header block is decompressed.
+
+ The dynamic table can contain duplicate entries (i.e., entries with
+ the same name and same value). Therefore, duplicate entries MUST NOT
+ be treated as an error by a decoder.
+
+ The encoder decides how to update the dynamic table and as such can
+ control how much memory is used by the dynamic table. To limit the
+ memory requirements of the decoder, the dynamic table size is
+ strictly bounded (see Section 4.2).
+
+ The decoder updates the dynamic table during the processing of a list
+ of header field representations (see Section 3.2).
+
+2.3.3. Index Address Space
+
+ The static table and the dynamic table are combined into a single
+ index address space.
+
+ Indices between 1 and the length of the static table (inclusive)
+ refer to elements in the static table (see Section 2.3.1).
+
+ Indices strictly greater than the length of the static table refer to
+ elements in the dynamic table (see Section 2.3.2). The length of the
+ static table is subtracted to find the index into the dynamic table.
+
+ Indices strictly greater than the sum of the lengths of both tables
+ MUST be treated as a decoding error.
+
+ For a static table size of s and a dynamic table size of k, the
+ following diagram shows the entire valid index address space.
+
+ <---------- Index Address Space ---------->
+ <-- Static Table --> <-- Dynamic Table -->
+ +---+-----------+---+ +---+-----------+---+
+ | 1 | ... | s | |s+1| ... |s+k|
+ +---+-----------+---+ +---+-----------+---+
+ ^ |
+ | V
+ Insertion Point Dropping Point
+
+ Figure 1: Index Address Space
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 7]
+
+RFC 7541 HPACK May 2015
+
+
+2.4. Header Field Representation
+
+ An encoded header field can be represented either as an index or as a
+ literal.
+
+ An indexed representation defines a header field as a reference to an
+ entry in either the static table or the dynamic table (see
+ Section 6.1).
+
+ A literal representation defines a header field by specifying its
+ name and value. The header field name can be represented literally
+ or as a reference to an entry in either the static table or the
+ dynamic table. The header field value is represented literally.
+
+ Three different literal representations are defined:
+
+ o A literal representation that adds the header field as a new entry
+ at the beginning of the dynamic table (see Section 6.2.1).
+
+ o A literal representation that does not add the header field to the
+ dynamic table (see Section 6.2.2).
+
+ o A literal representation that does not add the header field to the
+ dynamic table, with the additional stipulation that this header
+ field always use a literal representation, in particular when re-
+ encoded by an intermediary (see Section 6.2.3). This
+ representation is intended for protecting header field values that
+ are not to be put at risk by compressing them (see Section 7.1.3
+ for more details).
+
+ The selection of one of these literal representations can be guided
+ by security considerations, in order to protect sensitive header
+ field values (see Section 7.1).
+
+ The literal representation of a header field name or of a header
+ field value can encode the sequence of octets either directly or
+ using a static Huffman code (see Section 5.2).
+
+3. Header Block Decoding
+
+3.1. Header Block Processing
+
+ A decoder processes a header block sequentially to reconstruct the
+ original header list.
+
+ A header block is the concatenation of header field representations.
+ The different possible header field representations are described in
+ Section 6.
+
+
+
+Peon & Ruellan Standards Track [Page 8]
+
+RFC 7541 HPACK May 2015
+
+
+ Once a header field is decoded and added to the reconstructed header
+ list, the header field cannot be removed. A header field added to
+ the header list can be safely passed to the application.
+
+ By passing the resulting header fields to the application, a decoder
+ can be implemented with minimal transitory memory commitment in
+ addition to the memory required for the dynamic table.
+
+3.2. 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
+ processed in the order in which they appear, as specified below.
+ Details on the formatting of the various header field representations
+ and some additional processing instructions are found in Section 6.
+
+ An _indexed representation_ entails the following actions:
+
+ o The header field corresponding to the referenced entry in either
+ the static table or dynamic table is appended to the decoded
+ header list.
+
+ A _literal representation_ that is _not added_ to the dynamic table
+ entails the following action:
+
+ o The header field is appended to the decoded header list.
+
+ A _literal representation_ that is _added_ to the dynamic table
+ entails the following actions:
+
+ o The header field is appended to the decoded header list.
+
+ o The header field is inserted at the beginning of the dynamic
+ table. This insertion could result in the eviction of previous
+ entries in the dynamic table (see Section 4.4).
+
+4. Dynamic Table Management
+
+ To limit the memory requirements on the decoder side, the dynamic
+ table is constrained in size.
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 9]
+
+RFC 7541 HPACK May 2015
+
+
+4.1. Calculating Table Size
+
+ The size of the dynamic 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
+ defined in Section 5.2), its value's length in octets, and 32.
+
+ The size of an entry is calculated using the length of its name and
+ value without any Huffman encoding applied.
+
+ Note: The additional 32 octets account for an estimated overhead
+ associated with an 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 integers for counting the number of
+ references to the name and value would have 32 octets of overhead.
+
+4.2. Maximum Table Size
+
+ Protocols that use HPACK determine the maximum size that the encoder
+ is permitted to use for the dynamic table. In HTTP/2, this value is
+ determined by the SETTINGS_HEADER_TABLE_SIZE setting (see
+ Section 6.5.2 of [HTTP2]).
+
+ An encoder can choose to use less capacity than this maximum size
+ (see Section 6.3), but the chosen size MUST stay lower than or equal
+ to the maximum set by the protocol.
+
+ A change in the maximum size of the dynamic table is signaled via a
+ dynamic table size update (see Section 6.3). This dynamic table size
+ update MUST occur at the beginning of the first header block
+ following the change to the dynamic table size. In HTTP/2, this
+ follows a settings acknowledgment (see Section 6.5.3 of [HTTP2]).
+
+ Multiple updates to the maximum table size can occur between the
+ transmission of two header blocks. In the case that this size is
+ changed more than once in this interval, the smallest maximum table
+ size that occurs in that interval MUST be signaled in a dynamic table
+ size update. The final maximum size is always signaled, resulting in
+ at most two dynamic table size updates. This ensures that the
+ decoder is able to perform eviction based on reductions in dynamic
+ table size (see Section 4.3).
+
+ This mechanism can be used to completely clear entries from the
+ dynamic table by setting a maximum size of 0, which can subsequently
+ be restored.
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 10]
+
+RFC 7541 HPACK May 2015
+
+
+4.3. Entry Eviction When Dynamic Table Size Changes
+
+ Whenever the maximum size for the dynamic table is reduced, entries
+ are evicted from the end of the dynamic table until the size of the
+ dynamic table is less than or equal to the maximum size.
+
+4.4. Entry Eviction When Adding New Entries
+
+ Before a new entry is added to the dynamic table, entries are evicted
+ from the end of the dynamic table until the size of the dynamic table
+ is less than or equal to (maximum size - new entry size) or until the
+ table is empty.
+
+ 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
+ attempt to add an entry that is larger than the maximum size; an
+ attempt to add an entry larger than the maximum size causes the table
+ to be emptied of all existing entries and results in an empty table.
+
+ A new entry can reference the name of an entry in the dynamic table
+ that will be evicted when adding this new entry into the dynamic
+ table. Implementations are cautioned to avoid deleting the
+ referenced name if the referenced entry is evicted from the dynamic
+ table prior to inserting the new entry.
+
+5. Primitive Type Representations
+
+ HPACK encoding uses two primitive types: unsigned variable-length
+ integers and strings of octets.
+
+5.1. Integer Representation
+
+ Integers are used to represent name indexes, header field indexes, or
+ string lengths. An integer representation can start anywhere within
+ an octet. To allow for optimized processing, an integer
+ representation always finishes at the end of an octet.
+
+ 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
+ integer value does not fit within the prefix. The number of bits of
+ the prefix (called N) is a parameter of the integer representation.
+
+ If the integer value is small enough, i.e., strictly less than 2^N-1,
+ it is encoded within the N-bit prefix.
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 11]
+
+RFC 7541 HPACK May 2015
+
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | ? | ? | ? | Value |
+ +---+---+---+-------------------+
+
+ Figure 2: Integer Value Encoded within the Prefix (Shown for N = 5)
+
+ Otherwise, all the bits of the prefix are set to 1, and the value,
+ decreased by 2^N-1, is encoded using a list of one or more octets.
+ The most significant bit of each octet is used as a continuation
+ flag: its value is set to 1 except for the last octet in the list.
+ The remaining bits of the octets are used to encode the decreased
+ value.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | ? | ? | ? | 1 1 1 1 1 |
+ +---+---+---+-------------------+
+ | 1 | Value-(2^N-1) LSB |
+ +---+---------------------------+
+ ...
+ +---+---------------------------+
+ | 0 | Value-(2^N-1) MSB |
+ +---+---------------------------+
+
+ Figure 3: Integer Value Encoded after the Prefix (Shown for N = 5)
+
+ Decoding the integer value from the list of octets starts by
+ reversing the order of the octets in the list. Then, for each octet,
+ its most significant bit is removed. The remaining bits of the
+ octets are concatenated, and the resulting value is increased by
+ 2^N-1 to obtain the integer value.
+
+ The prefix size, N, is always between 1 and 8 bits. An integer
+ starting at an octet boundary will have an 8-bit prefix.
+
+ Pseudocode to represent an integer I is as follows:
+
+ if I < 2^N - 1, encode I on N bits
+ else
+ encode (2^N - 1) on N bits
+ I = I - (2^N - 1)
+ while I >= 128
+ encode (I % 128 + 128) on 8 bits
+ I = I / 128
+ encode I on 8 bits
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 12]
+
+RFC 7541 HPACK May 2015
+
+
+ Pseudocode to decode an integer I is as follows:
+
+ decode I from the next N bits
+ if I < 2^N - 1, return I
+ else
+ M = 0
+ repeat
+ B = next octet
+ I = I + (B & 127) * 2^M
+ M = M + 7
+ while B & 128 == 128
+ return I
+
+ Examples illustrating the encoding of integers are available in
+ Appendix C.1.
+
+ This integer representation allows for values of indefinite size. It
+ is also possible for an encoder to send a large number of zero
+ values, which can waste octets and could be used to overflow integer
+ values. Integer encodings that exceed implementation limits -- in
+ value or octet length -- MUST be treated as decoding errors.
+ Different limits can be set for each of the different uses of
+ integers, based on implementation constraints.
+
+5.2. String Literal Representation
+
+ Header field names and header field values can be represented as
+ string literals. A string literal is encoded as a sequence of
+ octets, either by directly encoding the string literal's octets or by
+ using a Huffman code (see [HUFFMAN]).
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | H | String Length (7+) |
+ +---+---------------------------+
+ | String Data (Length octets) |
+ +-------------------------------+
+
+ Figure 4: String Literal Representation
+
+ A string literal representation contains the following fields:
+
+ H: A one-bit flag, H, indicating whether or not the octets of the
+ string are Huffman encoded.
+
+ String Length: The number of octets used to encode the string
+ literal, encoded as an integer with a 7-bit prefix (see
+ Section 5.1).
+
+
+
+Peon & Ruellan Standards Track [Page 13]
+
+RFC 7541 HPACK May 2015
+
+
+ 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
+ H is '1', then the encoded data is the Huffman encoding of the
+ string literal.
+
+ String literals that use Huffman encoding are encoded with the
+ Huffman code defined in Appendix B (see examples for requests in
+ Appendix C.4 and for responses in Appendix C.6). The encoded data is
+ the bitwise concatenation of the codes corresponding to each octet of
+ the string literal.
+
+ 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
+ prevent this padding from being misinterpreted as part of the string
+ literal, the most significant bits of the code corresponding to the
+ EOS (end-of-string) symbol are used.
+
+ Upon decoding, an incomplete code at the end of the encoded data is
+ to be considered as padding and discarded. A padding strictly longer
+ 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
+ symbol MUST be treated as a decoding error. A Huffman-encoded string
+ literal containing the EOS symbol MUST be treated as a decoding
+ error.
+
+6. Binary Format
+
+ This section describes the detailed format of each of the different
+ header field representations and the dynamic table size update
+ instruction.
+
+6.1. Indexed Header Field Representation
+
+ An indexed header field representation identifies an entry in either
+ the static table or the dynamic table (see Section 2.3).
+
+ An indexed header field representation causes a header field to be
+ added to the decoded header list, as described in Section 3.2.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 1 | Index (7+) |
+ +---+---------------------------+
+
+ Figure 5: Indexed Header Field
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 14]
+
+RFC 7541 HPACK May 2015
+
+
+ An indexed header field starts with the '1' 1-bit pattern, followed
+ by the index of the matching header field, represented as an integer
+ with a 7-bit prefix (see Section 5.1).
+
+ The index value of 0 is not used. It MUST be treated as a decoding
+ error if found in an indexed header field representation.
+
+6.2. Literal Header Field Representation
+
+ A literal header field representation contains a literal header field
+ value. Header field names are provided either as a literal or by
+ reference to an existing table entry, either from the static table or
+ the dynamic table (see Section 2.3).
+
+ This specification defines three forms of literal header field
+ representations: with indexing, without indexing, and never indexed.
+
+6.2.1. Literal Header Field with Incremental Indexing
+
+ A literal header field with incremental indexing representation
+ results in appending a header field to the decoded header list and
+ inserting it as a new entry into the dynamic table.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 1 | Index (6+) |
+ +---+---+-----------------------+
+ | H | Value Length (7+) |
+ +---+---------------------------+
+ | Value String (Length octets) |
+ +-------------------------------+
+
+ Figure 6: Literal Header Field with Incremental Indexing -- Indexed
+ Name
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 15]
+
+RFC 7541 HPACK May 2015
+
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 1 | 0 |
+ +---+---+-----------------------+
+ | H | Name Length (7+) |
+ +---+---------------------------+
+ | Name String (Length octets) |
+ +---+---------------------------+
+ | H | Value Length (7+) |
+ +---+---------------------------+
+ | Value String (Length octets) |
+ +-------------------------------+
+
+ Figure 7: Literal Header Field with Incremental Indexing -- New Name
+
+ A literal header field with incremental indexing representation
+ starts with the '01' 2-bit pattern.
+
+ If the header field name matches the header field name of an entry
+ stored in the static table or the dynamic table, the header field
+ name 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 (see Section 5.1). This value is always non-zero.
+
+ Otherwise, the header field name is represented as a string literal
+ (see Section 5.2). A value 0 is used in place of the 6-bit index,
+ followed by the header field name.
+
+ Either form of header field name representation is followed by the
+ header field value represented as a string literal (see Section 5.2).
+
+6.2.2. Literal Header Field without Indexing
+
+ A literal header field without indexing representation results in
+ appending a header field to the decoded header list without altering
+ the dynamic table.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 0 | 0 | 0 | Index (4+) |
+ +---+---+-----------------------+
+ | H | Value Length (7+) |
+ +---+---------------------------+
+ | Value String (Length octets) |
+ +-------------------------------+
+
+ Figure 8: Literal Header Field without Indexing -- Indexed Name
+
+
+
+
+Peon & Ruellan Standards Track [Page 16]
+
+RFC 7541 HPACK May 2015
+
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 0 | 0 | 0 | 0 |
+ +---+---+-----------------------+
+ | H | Name Length (7+) |
+ +---+---------------------------+
+ | Name String (Length octets) |
+ +---+---------------------------+
+ | H | Value Length (7+) |
+ +---+---------------------------+
+ | Value String (Length octets) |
+ +-------------------------------+
+
+ Figure 9: Literal Header Field without Indexing -- New Name
+
+ A literal header field without indexing representation starts with
+ the '0000' 4-bit pattern.
+
+ If the header field name matches the header field name of an entry
+ stored in the static table or the dynamic table, the header field
+ name 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 (see Section 5.1). This value is always non-zero.
+
+ Otherwise, the header field name is represented as a string literal
+ (see Section 5.2). A value 0 is used in place of the 4-bit index,
+ followed by the header field name.
+
+ Either form of header field name representation is followed by the
+ header field value represented as a string literal (see Section 5.2).
+
+6.2.3. Literal Header Field Never Indexed
+
+ A literal header field never-indexed representation results in
+ appending a header field to the decoded header list without altering
+ the dynamic table. Intermediaries MUST use the same representation
+ for encoding this header field.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 0 | 0 | 1 | Index (4+) |
+ +---+---+-----------------------+
+ | H | Value Length (7+) |
+ +---+---------------------------+
+ | Value String (Length octets) |
+ +-------------------------------+
+
+ Figure 10: Literal Header Field Never Indexed -- Indexed Name
+
+
+
+Peon & Ruellan Standards Track [Page 17]
+
+RFC 7541 HPACK May 2015
+
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 0 | 0 | 1 | 0 |
+ +---+---+-----------------------+
+ | H | Name Length (7+) |
+ +---+---------------------------+
+ | Name String (Length octets) |
+ +---+---------------------------+
+ | H | Value Length (7+) |
+ +---+---------------------------+
+ | Value String (Length octets) |
+ +-------------------------------+
+
+ Figure 11: Literal Header Field Never Indexed -- New Name
+
+ A literal header field never-indexed representation starts with the
+ '0001' 4-bit pattern.
+
+ When a header field is represented as a literal header field never
+ indexed, it MUST always be encoded with this specific literal
+ representation. In particular, when a peer sends a header field that
+ it received represented as a literal header field never indexed, it
+ MUST use the same representation to forward this header field.
+
+ This representation is intended for protecting header field values
+ that are not to be put at risk by compressing them (see Section 7.1
+ for more details).
+
+ The encoding of the representation is identical to the literal header
+ field without indexing (see Section 6.2.2).
+
+6.3. Dynamic Table Size Update
+
+ A dynamic table size update signals a change to the size of the
+ dynamic table.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 0 | 1 | Max size (5+) |
+ +---+---------------------------+
+
+ Figure 12: Maximum Dynamic Table Size Change
+
+ A dynamic table size update starts with the '001' 3-bit pattern,
+ followed by the new maximum size, represented as an integer with a
+ 5-bit prefix (see Section 5.1).
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 18]
+
+RFC 7541 HPACK May 2015
+
+
+ The new maximum size MUST be lower than or equal to the limit
+ determined by the protocol using HPACK. A value that exceeds this
+ limit MUST be treated as a decoding error. In HTTP/2, this limit is
+ the last value of 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 dynamic table can cause entries to
+ be evicted (see Section 4.3).
+
+7. Security Considerations
+
+ This section describes potential areas of security concern with
+ HPACK:
+
+ o Use of compression as a length-based oracle for verifying guesses
+ about secrets that are compressed into a shared compression
+ context.
+
+ o Denial of service resulting from exhausting processing or memory
+ capacity at a decoder.
+
+7.1. Probing Dynamic Table State
+
+ HPACK reduces the length of header field encodings by exploiting the
+ redundancy inherent in protocols like HTTP. The ultimate goal of
+ this is to reduce the amount of data that is required to send HTTP
+ requests or responses.
+
+ The compression context used to encode header fields can be probed by
+ an attacker who can both define header fields to be encoded and
+ transmitted and observe the length of those fields once they are
+ encoded. When an attacker can do both, they can adaptively modify
+ requests in order to confirm guesses about the dynamic table state.
+ If a guess is compressed into a shorter length, the attacker can
+ observe the encoded length and infer that the guess was correct.
+
+ This is possible even over the Transport Layer Security (TLS)
+ protocol (see [TLS12]), because while TLS provides confidentiality
+ protection for content, it only provides a limited amount of
+ protection for the length of that content.
+
+ Note: Padding schemes only provide limited protection against an
+ attacker with these capabilities, potentially only forcing an
+ increased number of guesses to learn the length associated with a
+ given guess. Padding schemes also work directly against
+ compression by increasing the number of bits that are transmitted.
+
+
+
+
+Peon & Ruellan Standards Track [Page 19]
+
+RFC 7541 HPACK May 2015
+
+
+ Attacks like CRIME [CRIME] demonstrated the existence of these
+ general attacker capabilities. The specific attack exploited the
+ fact that DEFLATE [DEFLATE] removes redundancy based on prefix
+ matching. This permitted the attacker to confirm guesses a character
+ at a time, reducing an exponential-time attack into a linear-time
+ attack.
+
+7.1.1. Applicability to HPACK and HTTP
+
+ HPACK mitigates but does not completely prevent attacks modeled on
+ CRIME [CRIME] by forcing a guess to match an entire header field
+ value rather than individual characters. Attackers can only learn
+ whether a guess is correct or not, so they are reduced to brute-force
+ guesses for the header field values.
+
+ The viability of recovering specific header field values therefore
+ depends on the entropy of values. As a result, values with high
+ entropy are unlikely to be recovered successfully. However, values
+ with low entropy remain vulnerable.
+
+ Attacks of this nature are possible any time that two mutually
+ distrustful entities control requests or responses that are placed
+ onto a single HTTP/2 connection. If the shared HPACK compressor
+ permits one entity to add entries to the dynamic table and the other
+ to access those entries, then the state of the table can be learned.
+
+ Having requests or responses from mutually distrustful entities
+ occurs when an intermediary either:
+
+ o sends requests from multiple clients on a single connection toward
+ an origin server, or
+
+ o takes responses from multiple origin servers and places them on a
+ shared connection toward a client.
+
+ Web browsers also need to assume that requests made on the same
+ connection by different web origins [ORIGIN] are made by mutually
+ distrustful entities.
+
+7.1.2. Mitigation
+
+ Users of HTTP that require confidentiality for header fields can use
+ values with entropy sufficient to make guessing infeasible. However,
+ this is impractical as a general solution because it forces all users
+ of HTTP to take steps to mitigate attacks. It would impose new
+ constraints on how HTTP is used.
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 20]
+
+RFC 7541 HPACK May 2015
+
+
+ Rather than impose constraints on users of HTTP, an implementation of
+ HPACK can instead constrain how compression is applied in order to
+ limit the potential for dynamic table probing.
+
+ An ideal solution segregates access to the dynamic table based on the
+ entity that is constructing header fields. Header field values that
+ are added to the table are attributed to an entity, and only the
+ entity that created a particular value can extract that value.
+
+ To improve compression performance of this option, certain entries
+ might be tagged as being public. For example, a web browser might
+ make the values of the Accept-Encoding header field available in all
+ requests.
+
+ An encoder without good knowledge of the provenance of header fields
+ might instead introduce a penalty for a header field with many
+ different values, such that a large number of attempts to guess a
+ header field value results in the header field no longer being
+ compared to the dynamic table entries in future messages, effectively
+ preventing further guesses.
+
+ Note: Simply removing entries corresponding to the header field
+ from the dynamic table can be ineffectual if the attacker has a
+ reliable way of causing values to be reinstalled. For example, a
+ request to load an image in a web browser typically includes the
+ Cookie header field (a potentially highly valued target for this
+ sort of attack), and web sites can easily force an image to be
+ loaded, thereby refreshing the entry in the dynamic table.
+
+ This response might be made inversely proportional to the length of
+ the header field value. Marking a header field as not using the
+ dynamic table anymore might occur for shorter values more quickly or
+ with higher probability than for longer values.
+
+7.1.3. Never-Indexed Literals
+
+ Implementations can also choose to protect sensitive header fields by
+ not compressing them and instead encoding their value as literals.
+
+ Refusing to generate an indexed representation for a header field is
+ only effective if compression is avoided on all hops. The never-
+ indexed literal (see Section 6.2.3) can be used to signal to
+ intermediaries that a particular value was intentionally sent as a
+ literal.
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 21]
+
+RFC 7541 HPACK May 2015
+
+
+ An intermediary MUST NOT re-encode a value that uses the never-
+ indexed literal representation with another representation that would
+ index it. If HPACK is used for re-encoding, the never-indexed
+ literal representation MUST be used.
+
+ The choice to use a never-indexed literal representation for a header
+ field depends on several factors. Since HPACK doesn't protect
+ against guessing an entire header field value, short or low-entropy
+ values are more readily recovered by an adversary. Therefore, an
+ encoder might choose not to index values with low entropy.
+
+ An encoder might also choose not to index values for header fields
+ that are considered to be highly valuable or sensitive to recovery,
+ such as the Cookie or Authorization header fields.
+
+ On the contrary, an encoder might prefer indexing values for header
+ fields that have little or no value if they were exposed. For
+ instance, a User-Agent header field does not commonly vary between
+ requests and is sent to any server. In that case, confirmation that
+ a particular User-Agent value has been used provides little value.
+
+ Note that these criteria for deciding to use a never-indexed literal
+ representation will evolve over time as new attacks are discovered.
+
+7.2. Static Huffman Encoding
+
+ There is no currently known attack against a static Huffman encoding.
+ A study has shown that using a static Huffman encoding table created
+ an information leakage; however, this same study concluded that an
+ attacker could not take advantage of this information leakage to
+ recover any meaningful amount of information (see [PETAL]).
+
+7.3. Memory Consumption
+
+ 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
+ allocated by an endpoint.
+
+ The amount of memory used by the compressor is limited by the
+ protocol using HPACK through the definition of the maximum size of
+ the dynamic table. In HTTP/2, this value is controlled by the
+ decoder through the setting parameter 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 dynamic table, plus a small allowance
+ for overhead.
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 22]
+
+RFC 7541 HPACK May 2015
+
+
+ A decoder can limit the amount of state memory used by setting an
+ appropriate value for the maximum size of the dynamic table. In
+ HTTP/2, this is realized by setting an appropriate value for the
+ SETTINGS_HEADER_TABLE_SIZE parameter. An encoder can limit the
+ amount of state memory it uses by signaling a lower dynamic table
+ size than the decoder allows (see Section 6.3).
+
+ The amount of temporary memory consumed by an encoder or decoder can
+ be limited by processing header fields sequentially. An
+ implementation does not need to retain a complete list of header
+ fields. Note, however, that it might be necessary for an application
+ to retain a complete header list for other reasons; even though HPACK
+ does not force this to occur, application constraints might make this
+ necessary.
+
+7.4. Implementation Limits
+
+ An implementation of HPACK needs to ensure that large values for
+ integers, long encoding for integers, or long string literals do not
+ create security weaknesses.
+
+ An implementation has to set a limit for the values it accepts for
+ integers, as well as for the encoded length (see Section 5.1). In
+ the same way, it has to set a limit to the length it accepts for
+ string literals (see Section 5.2).
+
+8. References
+
+8.1. Normative References
+
+ [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+ Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+ DOI 10.17487/RFC7540, May 2015,
+ <http://www.rfc-editor.org/info/rfc7540>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
+ Transfer Protocol (HTTP/1.1): Message Syntax and
+ Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,
+ <http://www.rfc-editor.org/info/rfc7230>.
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 23]
+
+RFC 7541 HPACK May 2015
+
+
+8.2. Informative References
+
+ [CANONICAL] Schwartz, E. and B. Kallick, "Generating a canonical
+ prefix encoding", Communications of the ACM, Volume 7
+ Issue 3, pp. 166-169, March 1964, <https://dl.acm.org/
+ citation.cfm?id=363991>.
+
+ [CRIME] Wikipedia, "CRIME", May 2015, <http://en.wikipedia.org/w/
+ index.php?title=CRIME&oldid=660948120>.
+
+ [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
+ Specification version 1.3", RFC 1951,
+ DOI 10.17487/RFC1951, May 1996,
+ <http://www.rfc-editor.org/info/rfc1951>.
+
+ [HUFFMAN] Huffman, D., "A Method for the Construction of Minimum-
+ Redundancy Codes", Proceedings of the Institute of Radio
+ Engineers, Volume 40, Number 9, pp. 1098-1101, September
+ 1952, <http://ieeexplore.ieee.org/xpl/
+ articleDetails.jsp?arnumber=4051119>.
+
+ [ORIGIN] Barth, A., "The Web Origin Concept", RFC 6454,
+ DOI 10.17487/RFC6454, December 2011,
+ <http://www.rfc-editor.org/info/rfc6454>.
+
+ [PETAL] Tan, J. and J. Nahata, "PETAL: Preset Encoding
+ Table Information Leakage", April 2013,
+ <http://www.pdl.cmu.edu/PDL-FTP/associated/
+ CMU-PDL-13-106.pdf>.
+
+ [SPDY] Belshe, M. and R. Peon, "SPDY Protocol", Work in
+ Progress, draft-mbelshe-httpbis-spdy-00, February 2012.
+
+ [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <http://www.rfc-editor.org/info/rfc5246>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 24]
+
+RFC 7541 HPACK May 2015
+
+
+Appendix A. Static Table Definition
+
+ The static table (see Section 2.3.1) consists in a predefined and
+ unchangeable list of header fields.
+
+ The static table was created from the most frequent header fields
+ used by popular web sites, with the addition of HTTP/2-specific
+ pseudo-header fields (see Section 8.1.2.1 of [HTTP2]). 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 added
+ with an empty value.
+
+ Table 1 lists the predefined header fields that make up the static
+ table and gives the index of each entry.
+
+ +-------+-----------------------------+---------------+
+ | Index | Header Name | Header Value |
+ +-------+-----------------------------+---------------+
+ | 1 | :authority | |
+ | 2 | :method | GET |
+ | 3 | :method | POST |
+ | 4 | :path | / |
+ | 5 | :path | /index.html |
+ | 6 | :scheme | http |
+ | 7 | :scheme | https |
+ | 8 | :status | 200 |
+ | 9 | :status | 204 |
+ | 10 | :status | 206 |
+ | 11 | :status | 304 |
+ | 12 | :status | 400 |
+ | 13 | :status | 404 |
+ | 14 | :status | 500 |
+ | 15 | accept-charset | |
+ | 16 | accept-encoding | gzip, deflate |
+ | 17 | accept-language | |
+ | 18 | accept-ranges | |
+ | 19 | accept | |
+ | 20 | access-control-allow-origin | |
+ | 21 | age | |
+ | 22 | allow | |
+ | 23 | authorization | |
+ | 24 | cache-control | |
+ | 25 | content-disposition | |
+ | 26 | content-encoding | |
+ | 27 | content-language | |
+ | 28 | content-length | |
+ | 29 | content-location | |
+ | 30 | content-range | |
+
+
+
+Peon & Ruellan Standards Track [Page 25]
+
+RFC 7541 HPACK May 2015
+
+
+ | 31 | content-type | |
+ | 32 | cookie | |
+ | 33 | date | |
+ | 34 | etag | |
+ | 35 | expect | |
+ | 36 | expires | |
+ | 37 | from | |
+ | 38 | host | |
+ | 39 | if-match | |
+ | 40 | if-modified-since | |
+ | 41 | if-none-match | |
+ | 42 | if-range | |
+ | 43 | if-unmodified-since | |
+ | 44 | last-modified | |
+ | 45 | link | |
+ | 46 | location | |
+ | 47 | max-forwards | |
+ | 48 | proxy-authenticate | |
+ | 49 | proxy-authorization | |
+ | 50 | range | |
+ | 51 | referer | |
+ | 52 | refresh | |
+ | 53 | retry-after | |
+ | 54 | server | |
+ | 55 | set-cookie | |
+ | 56 | strict-transport-security | |
+ | 57 | transfer-encoding | |
+ | 58 | user-agent | |
+ | 59 | vary | |
+ | 60 | via | |
+ | 61 | www-authenticate | |
+ +-------+-----------------------------+---------------+
+
+ Table 1: Static Table Entries
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 26]
+
+RFC 7541 HPACK May 2015
+
+
+Appendix B. Huffman Code
+
+ The following Huffman code is used when encoding string literals with
+ a Huffman coding (see Section 5.2).
+
+ This Huffman code was generated from statistics obtained on a large
+ sample of HTTP headers. It is a canonical Huffman code (see
+ [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:
+
+ sym: The symbol to be represented. It is the decimal value of an
+ octet, possibly prepended with its ASCII representation. A
+ specific symbol, "EOS", is used to indicate the end of a string
+ literal.
+
+ code as bits: The Huffman code for the symbol represented as a
+ base-2 integer, aligned on the most significant bit (MSB).
+
+ code as hex: The Huffman code for the symbol, represented as a
+ hexadecimal integer, aligned on the least significant bit (LSB).
+
+ len: The number of bits for the code representing the symbol.
+
+ 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".
+ This corresponds to the value 0x18 (in hexadecimal) encoded in 6
+ bits.
+
+ code
+ code as bits as hex len
+ sym aligned to MSB aligned in
+ to LSB bits
+ ( 0) |11111111|11000 1ff8 [13]
+ ( 1) |11111111|11111111|1011000 7fffd8 [23]
+ ( 2) |11111111|11111111|11111110|0010 fffffe2 [28]
+ ( 3) |11111111|11111111|11111110|0011 fffffe3 [28]
+ ( 4) |11111111|11111111|11111110|0100 fffffe4 [28]
+ ( 5) |11111111|11111111|11111110|0101 fffffe5 [28]
+ ( 6) |11111111|11111111|11111110|0110 fffffe6 [28]
+ ( 7) |11111111|11111111|11111110|0111 fffffe7 [28]
+ ( 8) |11111111|11111111|11111110|1000 fffffe8 [28]
+ ( 9) |11111111|11111111|11101010 ffffea [24]
+ ( 10) |11111111|11111111|11111111|111100 3ffffffc [30]
+ ( 11) |11111111|11111111|11111110|1001 fffffe9 [28]
+ ( 12) |11111111|11111111|11111110|1010 fffffea [28]
+ ( 13) |11111111|11111111|11111111|111101 3ffffffd [30]
+
+
+
+Peon & Ruellan Standards Track [Page 27]
+
+RFC 7541 HPACK May 2015
+
+
+ ( 14) |11111111|11111111|11111110|1011 fffffeb [28]
+ ( 15) |11111111|11111111|11111110|1100 fffffec [28]
+ ( 16) |11111111|11111111|11111110|1101 fffffed [28]
+ ( 17) |11111111|11111111|11111110|1110 fffffee [28]
+ ( 18) |11111111|11111111|11111110|1111 fffffef [28]
+ ( 19) |11111111|11111111|11111111|0000 ffffff0 [28]
+ ( 20) |11111111|11111111|11111111|0001 ffffff1 [28]
+ ( 21) |11111111|11111111|11111111|0010 ffffff2 [28]
+ ( 22) |11111111|11111111|11111111|111110 3ffffffe [30]
+ ( 23) |11111111|11111111|11111111|0011 ffffff3 [28]
+ ( 24) |11111111|11111111|11111111|0100 ffffff4 [28]
+ ( 25) |11111111|11111111|11111111|0101 ffffff5 [28]
+ ( 26) |11111111|11111111|11111111|0110 ffffff6 [28]
+ ( 27) |11111111|11111111|11111111|0111 ffffff7 [28]
+ ( 28) |11111111|11111111|11111111|1000 ffffff8 [28]
+ ( 29) |11111111|11111111|11111111|1001 ffffff9 [28]
+ ( 30) |11111111|11111111|11111111|1010 ffffffa [28]
+ ( 31) |11111111|11111111|11111111|1011 ffffffb [28]
+ ' ' ( 32) |010100 14 [ 6]
+ '!' ( 33) |11111110|00 3f8 [10]
+ '"' ( 34) |11111110|01 3f9 [10]
+ '#' ( 35) |11111111|1010 ffa [12]
+ '$' ( 36) |11111111|11001 1ff9 [13]
+ '%' ( 37) |010101 15 [ 6]
+ '&' ( 38) |11111000 f8 [ 8]
+ ''' ( 39) |11111111|010 7fa [11]
+ '(' ( 40) |11111110|10 3fa [10]
+ ')' ( 41) |11111110|11 3fb [10]
+ '*' ( 42) |11111001 f9 [ 8]
+ '+' ( 43) |11111111|011 7fb [11]
+ ',' ( 44) |11111010 fa [ 8]
+ '-' ( 45) |010110 16 [ 6]
+ '.' ( 46) |010111 17 [ 6]
+ '/' ( 47) |011000 18 [ 6]
+ '0' ( 48) |00000 0 [ 5]
+ '1' ( 49) |00001 1 [ 5]
+ '2' ( 50) |00010 2 [ 5]
+ '3' ( 51) |011001 19 [ 6]
+ '4' ( 52) |011010 1a [ 6]
+ '5' ( 53) |011011 1b [ 6]
+ '6' ( 54) |011100 1c [ 6]
+ '7' ( 55) |011101 1d [ 6]
+ '8' ( 56) |011110 1e [ 6]
+ '9' ( 57) |011111 1f [ 6]
+ ':' ( 58) |1011100 5c [ 7]
+ ';' ( 59) |11111011 fb [ 8]
+ '<' ( 60) |11111111|1111100 7ffc [15]
+ '=' ( 61) |100000 20 [ 6]
+
+
+
+Peon & Ruellan Standards Track [Page 28]
+
+RFC 7541 HPACK May 2015
+
+
+ '>' ( 62) |11111111|1011 ffb [12]
+ '?' ( 63) |11111111|00 3fc [10]
+ '@' ( 64) |11111111|11010 1ffa [13]
+ 'A' ( 65) |100001 21 [ 6]
+ 'B' ( 66) |1011101 5d [ 7]
+ 'C' ( 67) |1011110 5e [ 7]
+ 'D' ( 68) |1011111 5f [ 7]
+ 'E' ( 69) |1100000 60 [ 7]
+ 'F' ( 70) |1100001 61 [ 7]
+ 'G' ( 71) |1100010 62 [ 7]
+ 'H' ( 72) |1100011 63 [ 7]
+ 'I' ( 73) |1100100 64 [ 7]
+ 'J' ( 74) |1100101 65 [ 7]
+ 'K' ( 75) |1100110 66 [ 7]
+ 'L' ( 76) |1100111 67 [ 7]
+ 'M' ( 77) |1101000 68 [ 7]
+ 'N' ( 78) |1101001 69 [ 7]
+ 'O' ( 79) |1101010 6a [ 7]
+ 'P' ( 80) |1101011 6b [ 7]
+ 'Q' ( 81) |1101100 6c [ 7]
+ 'R' ( 82) |1101101 6d [ 7]
+ 'S' ( 83) |1101110 6e [ 7]
+ 'T' ( 84) |1101111 6f [ 7]
+ 'U' ( 85) |1110000 70 [ 7]
+ 'V' ( 86) |1110001 71 [ 7]
+ 'W' ( 87) |1110010 72 [ 7]
+ 'X' ( 88) |11111100 fc [ 8]
+ 'Y' ( 89) |1110011 73 [ 7]
+ 'Z' ( 90) |11111101 fd [ 8]
+ '[' ( 91) |11111111|11011 1ffb [13]
+ '\' ( 92) |11111111|11111110|000 7fff0 [19]
+ ']' ( 93) |11111111|11100 1ffc [13]
+ '^' ( 94) |11111111|111100 3ffc [14]
+ '_' ( 95) |100010 22 [ 6]
+ '`' ( 96) |11111111|1111101 7ffd [15]
+ 'a' ( 97) |00011 3 [ 5]
+ 'b' ( 98) |100011 23 [ 6]
+ 'c' ( 99) |00100 4 [ 5]
+ 'd' (100) |100100 24 [ 6]
+ 'e' (101) |00101 5 [ 5]
+ 'f' (102) |100101 25 [ 6]
+ 'g' (103) |100110 26 [ 6]
+ 'h' (104) |100111 27 [ 6]
+ 'i' (105) |00110 6 [ 5]
+ 'j' (106) |1110100 74 [ 7]
+ 'k' (107) |1110101 75 [ 7]
+ 'l' (108) |101000 28 [ 6]
+ 'm' (109) |101001 29 [ 6]
+
+
+
+Peon & Ruellan Standards Track [Page 29]
+
+RFC 7541 HPACK May 2015
+
+
+ 'n' (110) |101010 2a [ 6]
+ 'o' (111) |00111 7 [ 5]
+ 'p' (112) |101011 2b [ 6]
+ 'q' (113) |1110110 76 [ 7]
+ 'r' (114) |101100 2c [ 6]
+ 's' (115) |01000 8 [ 5]
+ 't' (116) |01001 9 [ 5]
+ 'u' (117) |101101 2d [ 6]
+ 'v' (118) |1110111 77 [ 7]
+ 'w' (119) |1111000 78 [ 7]
+ 'x' (120) |1111001 79 [ 7]
+ 'y' (121) |1111010 7a [ 7]
+ 'z' (122) |1111011 7b [ 7]
+ '{' (123) |11111111|1111110 7ffe [15]
+ '|' (124) |11111111|100 7fc [11]
+ '}' (125) |11111111|111101 3ffd [14]
+ '~' (126) |11111111|11101 1ffd [13]
+ (127) |11111111|11111111|11111111|1100 ffffffc [28]
+ (128) |11111111|11111110|0110 fffe6 [20]
+ (129) |11111111|11111111|010010 3fffd2 [22]
+ (130) |11111111|11111110|0111 fffe7 [20]
+ (131) |11111111|11111110|1000 fffe8 [20]
+ (132) |11111111|11111111|010011 3fffd3 [22]
+ (133) |11111111|11111111|010100 3fffd4 [22]
+ (134) |11111111|11111111|010101 3fffd5 [22]
+ (135) |11111111|11111111|1011001 7fffd9 [23]
+ (136) |11111111|11111111|010110 3fffd6 [22]
+ (137) |11111111|11111111|1011010 7fffda [23]
+ (138) |11111111|11111111|1011011 7fffdb [23]
+ (139) |11111111|11111111|1011100 7fffdc [23]
+ (140) |11111111|11111111|1011101 7fffdd [23]
+ (141) |11111111|11111111|1011110 7fffde [23]
+ (142) |11111111|11111111|11101011 ffffeb [24]
+ (143) |11111111|11111111|1011111 7fffdf [23]
+ (144) |11111111|11111111|11101100 ffffec [24]
+ (145) |11111111|11111111|11101101 ffffed [24]
+ (146) |11111111|11111111|010111 3fffd7 [22]
+ (147) |11111111|11111111|1100000 7fffe0 [23]
+ (148) |11111111|11111111|11101110 ffffee [24]
+ (149) |11111111|11111111|1100001 7fffe1 [23]
+ (150) |11111111|11111111|1100010 7fffe2 [23]
+ (151) |11111111|11111111|1100011 7fffe3 [23]
+ (152) |11111111|11111111|1100100 7fffe4 [23]
+ (153) |11111111|11111110|11100 1fffdc [21]
+ (154) |11111111|11111111|011000 3fffd8 [22]
+ (155) |11111111|11111111|1100101 7fffe5 [23]
+ (156) |11111111|11111111|011001 3fffd9 [22]
+ (157) |11111111|11111111|1100110 7fffe6 [23]
+
+
+
+Peon & Ruellan Standards Track [Page 30]
+
+RFC 7541 HPACK May 2015
+
+
+ (158) |11111111|11111111|1100111 7fffe7 [23]
+ (159) |11111111|11111111|11101111 ffffef [24]
+ (160) |11111111|11111111|011010 3fffda [22]
+ (161) |11111111|11111110|11101 1fffdd [21]
+ (162) |11111111|11111110|1001 fffe9 [20]
+ (163) |11111111|11111111|011011 3fffdb [22]
+ (164) |11111111|11111111|011100 3fffdc [22]
+ (165) |11111111|11111111|1101000 7fffe8 [23]
+ (166) |11111111|11111111|1101001 7fffe9 [23]
+ (167) |11111111|11111110|11110 1fffde [21]
+ (168) |11111111|11111111|1101010 7fffea [23]
+ (169) |11111111|11111111|011101 3fffdd [22]
+ (170) |11111111|11111111|011110 3fffde [22]
+ (171) |11111111|11111111|11110000 fffff0 [24]
+ (172) |11111111|11111110|11111 1fffdf [21]
+ (173) |11111111|11111111|011111 3fffdf [22]
+ (174) |11111111|11111111|1101011 7fffeb [23]
+ (175) |11111111|11111111|1101100 7fffec [23]
+ (176) |11111111|11111111|00000 1fffe0 [21]
+ (177) |11111111|11111111|00001 1fffe1 [21]
+ (178) |11111111|11111111|100000 3fffe0 [22]
+ (179) |11111111|11111111|00010 1fffe2 [21]
+ (180) |11111111|11111111|1101101 7fffed [23]
+ (181) |11111111|11111111|100001 3fffe1 [22]
+ (182) |11111111|11111111|1101110 7fffee [23]
+ (183) |11111111|11111111|1101111 7fffef [23]
+ (184) |11111111|11111110|1010 fffea [20]
+ (185) |11111111|11111111|100010 3fffe2 [22]
+ (186) |11111111|11111111|100011 3fffe3 [22]
+ (187) |11111111|11111111|100100 3fffe4 [22]
+ (188) |11111111|11111111|1110000 7ffff0 [23]
+ (189) |11111111|11111111|100101 3fffe5 [22]
+ (190) |11111111|11111111|100110 3fffe6 [22]
+ (191) |11111111|11111111|1110001 7ffff1 [23]
+ (192) |11111111|11111111|11111000|00 3ffffe0 [26]
+ (193) |11111111|11111111|11111000|01 3ffffe1 [26]
+ (194) |11111111|11111110|1011 fffeb [20]
+ (195) |11111111|11111110|001 7fff1 [19]
+ (196) |11111111|11111111|100111 3fffe7 [22]
+ (197) |11111111|11111111|1110010 7ffff2 [23]
+ (198) |11111111|11111111|101000 3fffe8 [22]
+ (199) |11111111|11111111|11110110|0 1ffffec [25]
+ (200) |11111111|11111111|11111000|10 3ffffe2 [26]
+ (201) |11111111|11111111|11111000|11 3ffffe3 [26]
+ (202) |11111111|11111111|11111001|00 3ffffe4 [26]
+ (203) |11111111|11111111|11111011|110 7ffffde [27]
+ (204) |11111111|11111111|11111011|111 7ffffdf [27]
+ (205) |11111111|11111111|11111001|01 3ffffe5 [26]
+
+
+
+Peon & Ruellan Standards Track [Page 31]
+
+RFC 7541 HPACK May 2015
+
+
+ (206) |11111111|11111111|11110001 fffff1 [24]
+ (207) |11111111|11111111|11110110|1 1ffffed [25]
+ (208) |11111111|11111110|010 7fff2 [19]
+ (209) |11111111|11111111|00011 1fffe3 [21]
+ (210) |11111111|11111111|11111001|10 3ffffe6 [26]
+ (211) |11111111|11111111|11111100|000 7ffffe0 [27]
+ (212) |11111111|11111111|11111100|001 7ffffe1 [27]
+ (213) |11111111|11111111|11111001|11 3ffffe7 [26]
+ (214) |11111111|11111111|11111100|010 7ffffe2 [27]
+ (215) |11111111|11111111|11110010 fffff2 [24]
+ (216) |11111111|11111111|00100 1fffe4 [21]
+ (217) |11111111|11111111|00101 1fffe5 [21]
+ (218) |11111111|11111111|11111010|00 3ffffe8 [26]
+ (219) |11111111|11111111|11111010|01 3ffffe9 [26]
+ (220) |11111111|11111111|11111111|1101 ffffffd [28]
+ (221) |11111111|11111111|11111100|011 7ffffe3 [27]
+ (222) |11111111|11111111|11111100|100 7ffffe4 [27]
+ (223) |11111111|11111111|11111100|101 7ffffe5 [27]
+ (224) |11111111|11111110|1100 fffec [20]
+ (225) |11111111|11111111|11110011 fffff3 [24]
+ (226) |11111111|11111110|1101 fffed [20]
+ (227) |11111111|11111111|00110 1fffe6 [21]
+ (228) |11111111|11111111|101001 3fffe9 [22]
+ (229) |11111111|11111111|00111 1fffe7 [21]
+ (230) |11111111|11111111|01000 1fffe8 [21]
+ (231) |11111111|11111111|1110011 7ffff3 [23]
+ (232) |11111111|11111111|101010 3fffea [22]
+ (233) |11111111|11111111|101011 3fffeb [22]
+ (234) |11111111|11111111|11110111|0 1ffffee [25]
+ (235) |11111111|11111111|11110111|1 1ffffef [25]
+ (236) |11111111|11111111|11110100 fffff4 [24]
+ (237) |11111111|11111111|11110101 fffff5 [24]
+ (238) |11111111|11111111|11111010|10 3ffffea [26]
+ (239) |11111111|11111111|1110100 7ffff4 [23]
+ (240) |11111111|11111111|11111010|11 3ffffeb [26]
+ (241) |11111111|11111111|11111100|110 7ffffe6 [27]
+ (242) |11111111|11111111|11111011|00 3ffffec [26]
+ (243) |11111111|11111111|11111011|01 3ffffed [26]
+ (244) |11111111|11111111|11111100|111 7ffffe7 [27]
+ (245) |11111111|11111111|11111101|000 7ffffe8 [27]
+ (246) |11111111|11111111|11111101|001 7ffffe9 [27]
+ (247) |11111111|11111111|11111101|010 7ffffea [27]
+ (248) |11111111|11111111|11111101|011 7ffffeb [27]
+ (249) |11111111|11111111|11111111|1110 ffffffe [28]
+ (250) |11111111|11111111|11111101|100 7ffffec [27]
+ (251) |11111111|11111111|11111101|101 7ffffed [27]
+ (252) |11111111|11111111|11111101|110 7ffffee [27]
+ (253) |11111111|11111111|11111101|111 7ffffef [27]
+
+
+
+Peon & Ruellan Standards Track [Page 32]
+
+RFC 7541 HPACK May 2015
+
+
+ (254) |11111111|11111111|11111110|000 7fffff0 [27]
+ (255) |11111111|11111111|11111011|10 3ffffee [26]
+ EOS (256) |11111111|11111111|11111111|111111 3fffffff [30]
+
+Appendix C. Examples
+
+ This appendix contains examples covering integer encoding, header
+ field representation, and the encoding of whole lists of header
+ fields for both requests and responses, with and without Huffman
+ coding.
+
+C.1. Integer Representation Examples
+
+ This section shows the representation of integer values in detail
+ (see Section 5.1).
+
+C.1.1. Example 1: Encoding 10 Using a 5-Bit Prefix
+
+ The value 10 is to be encoded with a 5-bit prefix.
+
+ o 10 is less than 31 (2^5 - 1) and is represented using the 5-bit
+ prefix.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits
+ +---+---+---+---+---+---+---+---+
+
+C.1.2. Example 2: Encoding 1337 Using a 5-Bit Prefix
+
+ The value I=1337 is to be encoded with a 5-bit prefix.
+
+ 1337 is greater than 31 (2^5 - 1).
+
+ The 5-bit prefix is filled with its max value (31).
+
+ I = 1337 - (2^5 - 1) = 1306.
+
+ I (1306) is greater than or equal to 128, so the while loop
+ body executes:
+
+ I % 128 == 26
+
+ 26 + 128 == 154
+
+ 154 is encoded in 8 bits as: 10011010
+
+ I is set to 10 (1306 / 128 == 10)
+
+
+
+Peon & Ruellan Standards Track [Page 33]
+
+RFC 7541 HPACK May 2015
+
+
+ I is no longer greater than or equal to 128, so the while
+ loop terminates.
+
+ I, now 10, is encoded in 8 bits as: 00001010.
+
+ The process ends.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31, I = 1306
+ | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1306>=128, encode(154), I=1306/128
+ | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 10<128, encode(10), done
+ +---+---+---+---+---+---+---+---+
+
+C.1.3. Example 3: Encoding 42 Starting at an Octet Boundary
+
+ The value 42 is to be encoded starting at an octet boundary. This
+ implies that a 8-bit prefix is used.
+
+ o 42 is less than 255 (2^8 - 1) and is represented using the 8-bit
+ prefix.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 42 stored on 8 bits
+ +---+---+---+---+---+---+---+---+
+
+C.2. Header Field Representation Examples
+
+ This section shows several independent representation examples.
+
+C.2.1. Literal Header Field with Indexing
+
+ The header field representation uses a literal name and a literal
+ value. The header field is added to the dynamic table.
+
+ Header list to encode:
+
+ custom-key: custom-header
+
+ Hex dump of encoded data:
+
+ 400a 6375 7374 6f6d 2d6b 6579 0d63 7573 | @.custom-key.cus
+ 746f 6d2d 6865 6164 6572 | tom-header
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 34]
+
+RFC 7541 HPACK May 2015
+
+
+ Decoding process:
+
+ 40 | == Literal indexed ==
+ 0a | Literal name (len = 10)
+ 6375 7374 6f6d 2d6b 6579 | custom-key
+ 0d | Literal value (len = 13)
+ 6375 7374 6f6d 2d68 6561 6465 72 | custom-header
+ | -> custom-key:
+ | custom-header
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 55) custom-key: custom-header
+ Table size: 55
+
+ Decoded header list:
+
+ custom-key: custom-header
+
+C.2.2. Literal Header Field without Indexing
+
+ The header field representation uses an indexed name and a literal
+ value. The header field is not added to the dynamic table.
+
+ Header list to encode:
+
+ :path: /sample/path
+
+ Hex dump of encoded data:
+
+ 040c 2f73 616d 706c 652f 7061 7468 | ../sample/path
+
+ Decoding process:
+
+ 04 | == Literal not indexed ==
+ | Indexed name (idx = 4)
+ | :path
+ 0c | Literal value (len = 12)
+ 2f73 616d 706c 652f 7061 7468 | /sample/path
+ | -> :path: /sample/path
+
+ Dynamic table (after decoding): empty.
+
+ Decoded header list:
+
+ :path: /sample/path
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 35]
+
+RFC 7541 HPACK May 2015
+
+
+C.2.3. Literal Header Field Never Indexed
+
+ The header field representation uses a literal name and a literal
+ value. The header field is not added to the dynamic table and must
+ use the same representation if re-encoded by an intermediary.
+
+ Header list to encode:
+
+ password: secret
+
+ Hex dump of encoded data:
+
+ 1008 7061 7373 776f 7264 0673 6563 7265 | ..password.secre
+ 74 | t
+
+ Decoding process:
+
+ 10 | == Literal never indexed ==
+ 08 | Literal name (len = 8)
+ 7061 7373 776f 7264 | password
+ 06 | Literal value (len = 6)
+ 7365 6372 6574 | secret
+ | -> password: secret
+
+ Dynamic table (after decoding): empty.
+
+ Decoded header list:
+
+ password: secret
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 36]
+
+RFC 7541 HPACK May 2015
+
+
+C.2.4. Indexed Header Field
+
+ The header field representation uses an indexed header field from the
+ static table.
+
+ Header list to encode:
+
+ :method: GET
+
+ Hex dump of encoded data:
+
+ 82 | .
+
+ Decoding process:
+
+ 82 | == Indexed - Add ==
+ | idx = 2
+ | -> :method: GET
+
+ Dynamic table (after decoding): empty.
+
+ Decoded header list:
+
+ :method: GET
+
+C.3. Request Examples without Huffman Coding
+
+ This section shows several consecutive header lists, corresponding to
+ HTTP requests, on the same connection.
+
+C.3.1. First Request
+
+ Header list to encode:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+
+ Hex dump of encoded data:
+
+ 8286 8441 0f77 7777 2e65 7861 6d70 6c65 | ...A.www.example
+ 2e63 6f6d | .com
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 37]
+
+RFC 7541 HPACK May 2015
+
+
+ Decoding process:
+
+ 82 | == Indexed - Add ==
+ | idx = 2
+ | -> :method: GET
+ 86 | == Indexed - Add ==
+ | idx = 6
+ | -> :scheme: http
+ 84 | == Indexed - Add ==
+ | idx = 4
+ | -> :path: /
+ 41 | == Literal indexed ==
+ | Indexed name (idx = 1)
+ | :authority
+ 0f | Literal value (len = 15)
+ 7777 772e 6578 616d 706c 652e 636f 6d | www.example.com
+ | -> :authority:
+ | www.example.com
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 57) :authority: www.example.com
+ Table size: 57
+
+ Decoded header list:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+
+C.3.2. Second Request
+
+ Header list to encode:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+ cache-control: no-cache
+
+ Hex dump of encoded data:
+
+ 8286 84be 5808 6e6f 2d63 6163 6865 | ....X.no-cache
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 38]
+
+RFC 7541 HPACK May 2015
+
+
+ Decoding process:
+
+ 82 | == Indexed - Add ==
+ | 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
+ 08 | Literal value (len = 8)
+ 6e6f 2d63 6163 6865 | no-cache
+ | -> cache-control: no-cache
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 53) cache-control: no-cache
+ [ 2] (s = 57) :authority: www.example.com
+ Table size: 110
+
+ Decoded header list:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+ cache-control: no-cache
+
+C.3.3. Third Request
+
+ Header list to encode:
+
+ :method: GET
+ :scheme: https
+ :path: /index.html
+ :authority: www.example.com
+ custom-key: custom-value
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 39]
+
+RFC 7541 HPACK May 2015
+
+
+ Hex dump of encoded data:
+
+ 8287 85bf 400a 6375 7374 6f6d 2d6b 6579 | ....@.custom-key
+ 0c63 7573 746f 6d2d 7661 6c75 65 | .custom-value
+
+ Decoding process:
+
+ 82 | == Indexed - Add ==
+ | idx = 2
+ | -> :method: GET
+ 87 | == Indexed - Add ==
+ | idx = 7
+ | -> :scheme: https
+ 85 | == Indexed - Add ==
+ | idx = 5
+ | -> :path: /index.html
+ bf | == Indexed - Add ==
+ | idx = 63
+ | -> :authority:
+ | www.example.com
+ 40 | == Literal indexed ==
+ 0a | Literal name (len = 10)
+ 6375 7374 6f6d 2d6b 6579 | custom-key
+ 0c | Literal value (len = 12)
+ 6375 7374 6f6d 2d76 616c 7565 | custom-value
+ | -> custom-key:
+ | custom-value
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 54) custom-key: custom-value
+ [ 2] (s = 53) cache-control: no-cache
+ [ 3] (s = 57) :authority: www.example.com
+ Table size: 164
+
+ Decoded header list:
+
+ :method: GET
+ :scheme: https
+ :path: /index.html
+ :authority: www.example.com
+ custom-key: custom-value
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 40]
+
+RFC 7541 HPACK May 2015
+
+
+C.4. Request Examples with Huffman Coding
+
+ This section shows the same examples as the previous section but uses
+ Huffman encoding for the literal values.
+
+C.4.1. First Request
+
+ Header list to encode:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+
+ Hex dump of encoded data:
+
+ 8286 8441 8cf1 e3c2 e5f2 3a6b a0ab 90f4 | ...A......:k....
+ ff | .
+
+ Decoding process:
+
+ 82 | == Indexed - Add ==
+ | idx = 2
+ | -> :method: GET
+ 86 | == Indexed - Add ==
+ | idx = 6
+ | -> :scheme: http
+ 84 | == Indexed - Add ==
+ | idx = 4
+ | -> :path: /
+ 41 | == Literal indexed ==
+ | Indexed name (idx = 1)
+ | :authority
+ 8c | Literal value (len = 12)
+ | Huffman encoded:
+ f1e3 c2e5 f23a 6ba0 ab90 f4ff | .....:k.....
+ | Decoded:
+ | www.example.com
+ | -> :authority:
+ | www.example.com
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 57) :authority: www.example.com
+ Table size: 57
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 41]
+
+RFC 7541 HPACK May 2015
+
+
+ Decoded header list:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+
+C.4.2. Second Request
+
+ Header list to encode:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+ cache-control: no-cache
+
+ Hex dump of encoded data:
+
+ 8286 84be 5886 a8eb 1064 9cbf | ....X....d..
+
+ Decoding process:
+
+ 82 | == Indexed - Add ==
+ | 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
+ 86 | Literal value (len = 6)
+ | Huffman encoded:
+ a8eb 1064 9cbf | ...d..
+ | Decoded:
+ | no-cache
+ | -> cache-control: no-cache
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 42]
+
+RFC 7541 HPACK May 2015
+
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 53) cache-control: no-cache
+ [ 2] (s = 57) :authority: www.example.com
+ Table size: 110
+
+ Decoded header list:
+
+ :method: GET
+ :scheme: http
+ :path: /
+ :authority: www.example.com
+ cache-control: no-cache
+
+C.4.3. Third Request
+
+ Header list to encode:
+
+ :method: GET
+ :scheme: https
+ :path: /index.html
+ :authority: www.example.com
+ custom-key: custom-value
+
+ Hex dump of encoded data:
+
+ 8287 85bf 4088 25a8 49e9 5ba9 7d7f 8925 | ....@.%.I.[.}..%
+ a849 e95b b8e8 b4bf | .I.[....
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 43]
+
+RFC 7541 HPACK May 2015
+
+
+ Decoding process:
+
+ 82 | == Indexed - Add ==
+ | idx = 2
+ | -> :method: GET
+ 87 | == Indexed - Add ==
+ | idx = 7
+ | -> :scheme: https
+ 85 | == Indexed - Add ==
+ | idx = 5
+ | -> :path: /index.html
+ bf | == Indexed - Add ==
+ | idx = 63
+ | -> :authority:
+ | www.example.com
+ 40 | == Literal indexed ==
+ 88 | Literal name (len = 8)
+ | Huffman encoded:
+ 25a8 49e9 5ba9 7d7f | %.I.[.}.
+ | Decoded:
+ | custom-key
+ 89 | Literal value (len = 9)
+ | Huffman encoded:
+ 25a8 49e9 5bb8 e8b4 bf | %.I.[....
+ | Decoded:
+ | custom-value
+ | -> custom-key:
+ | custom-value
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 54) custom-key: custom-value
+ [ 2] (s = 53) cache-control: no-cache
+ [ 3] (s = 57) :authority: www.example.com
+ Table size: 164
+
+ Decoded header list:
+
+ :method: GET
+ :scheme: https
+ :path: /index.html
+ :authority: www.example.com
+ custom-key: custom-value
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 44]
+
+RFC 7541 HPACK May 2015
+
+
+C.5. Response Examples without Huffman Coding
+
+ This section shows several consecutive header lists, corresponding to
+ HTTP responses, on the same connection. The HTTP/2 setting parameter
+ SETTINGS_HEADER_TABLE_SIZE is set to the value of 256 octets, causing
+ some evictions to occur.
+
+C.5.1. First Response
+
+ Header list to encode:
+
+ :status: 302
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+ Hex dump of encoded data:
+
+ 4803 3330 3258 0770 7269 7661 7465 611d | H.302X.privatea.
+ 4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013
+ 2032 303a 3133 3a32 3120 474d 546e 1768 | 20:13:21 GMTn.h
+ 7474 7073 3a2f 2f77 7777 2e65 7861 6d70 | ttps://www.examp
+ 6c65 2e63 6f6d | le.com
+
+ Decoding process:
+
+ 48 | == Literal indexed ==
+ | Indexed name (idx = 8)
+ | :status
+ 03 | Literal value (len = 3)
+ 3330 32 | 302
+ | -> :status: 302
+ 58 | == Literal indexed ==
+ | Indexed name (idx = 24)
+ | cache-control
+ 07 | Literal value (len = 7)
+ 7072 6976 6174 65 | private
+ | -> cache-control: private
+ 61 | == Literal indexed ==
+ | Indexed name (idx = 33)
+ | date
+ 1d | Literal value (len = 29)
+ 4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013
+ 2032 303a 3133 3a32 3120 474d 54 | 20:13:21 GMT
+ | -> date: Mon, 21 Oct 2013
+ | 20:13:21 GMT
+ 6e | == Literal indexed ==
+ | Indexed name (idx = 46)
+
+
+
+Peon & Ruellan Standards Track [Page 45]
+
+RFC 7541 HPACK May 2015
+
+
+ | location
+ 17 | Literal value (len = 23)
+ 6874 7470 733a 2f2f 7777 772e 6578 616d | https://www.exam
+ 706c 652e 636f 6d | ple.com
+ | -> location:
+ | https://www.example.com
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 63) location: https://www.example.com
+ [ 2] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
+ [ 3] (s = 52) cache-control: private
+ [ 4] (s = 42) :status: 302
+ Table size: 222
+
+ Decoded header list:
+
+ :status: 302
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+C.5.2. Second Response
+
+ The (":status", "302") header field is evicted from the dynamic table
+ to free space to allow adding the (":status", "307") header field.
+
+ Header list to encode:
+
+ :status: 307
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+ Hex dump of encoded data:
+
+ 4803 3330 37c1 c0bf | H.307...
+
+ Decoding process:
+
+ 48 | == Literal indexed ==
+ | Indexed name (idx = 8)
+ | :status
+ 03 | Literal value (len = 3)
+ 3330 37 | 307
+ | - evict: :status: 302
+ | -> :status: 307
+ c1 | == Indexed - Add ==
+
+
+
+Peon & Ruellan Standards Track [Page 46]
+
+RFC 7541 HPACK May 2015
+
+
+ | 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.example.com
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 42) :status: 307
+ [ 2] (s = 63) location: https://www.example.com
+ [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
+ [ 4] (s = 52) cache-control: private
+ Table size: 222
+
+ Decoded header list:
+
+ :status: 307
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+C.5.3. Third Response
+
+ Several header fields are evicted from the dynamic table during the
+ processing of this header list.
+
+ Header list to encode:
+
+ :status: 200
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:22 GMT
+ location: https://www.example.com
+ content-encoding: gzip
+ set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 47]
+
+RFC 7541 HPACK May 2015
+
+
+ Hex dump of encoded data:
+
+ 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
+ 54c0 5a04 677a 6970 7738 666f 6f3d 4153 | T.Z.gzipw8foo=AS
+ 444a 4b48 514b 425a 584f 5157 454f 5049 | DJKHQKBZXOQWEOPI
+ 5541 5851 5745 4f49 553b 206d 6178 2d61 | UAXQWEOIU; max-a
+ 6765 3d33 3630 303b 2076 6572 7369 6f6e | ge=3600; version
+ 3d31 | =1
+
+ Decoding process:
+
+ 88 | == Indexed - Add ==
+ | idx = 8
+ | -> :status: 200
+ c1 | == Indexed - Add ==
+ | idx = 65
+ | -> cache-control: private
+ 61 | == Literal indexed ==
+ | Indexed name (idx = 33)
+ | date
+ 1d | Literal value (len = 29)
+ 4d6f 6e2c 2032 3120 4f63 7420 3230 3133 | Mon, 21 Oct 2013
+ 2032 303a 3133 3a32 3220 474d 54 | 20:13:22 GMT
+ | - evict: cache-control:
+ | private
+ | -> date: Mon, 21 Oct 2013
+ | 20:13:22 GMT
+ c0 | == Indexed - Add ==
+ | idx = 64
+ | -> location:
+ | https://www.example.com
+ 5a | == Literal indexed ==
+ | Indexed name (idx = 26)
+ | content-encoding
+ 04 | Literal value (len = 4)
+ 677a 6970 | gzip
+ | - evict: date: Mon, 21 Oct
+ | 2013 20:13:21 GMT
+ | -> content-encoding: gzip
+ 77 | == Literal indexed ==
+ | Indexed name (idx = 55)
+ | set-cookie
+ 38 | Literal value (len = 56)
+ 666f 6f3d 4153 444a 4b48 514b 425a 584f | foo=ASDJKHQKBZXO
+ 5157 454f 5049 5541 5851 5745 4f49 553b | QWEOPIUAXQWEOIU;
+ 206d 6178 2d61 6765 3d33 3630 303b 2076 | max-age=3600; v
+ 6572 7369 6f6e 3d31 | ersion=1
+
+
+
+Peon & Ruellan Standards Track [Page 48]
+
+RFC 7541 HPACK May 2015
+
+
+ | - evict: location:
+ | https://www.example.com
+ | - evict: :status: 307
+ | -> set-cookie: foo=ASDJKHQ
+ | KBZXOQWEOPIUAXQWEOIU; ma
+ | x-age=3600; version=1
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 98) set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU;
+ max-age=3600; version=1
+ [ 2] (s = 52) content-encoding: gzip
+ [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:22 GMT
+ Table size: 215
+
+ Decoded header list:
+
+ :status: 200
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:22 GMT
+ location: https://www.example.com
+ content-encoding: gzip
+ set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
+
+C.6. Response Examples with Huffman Coding
+
+ This section shows the same examples as the previous section but uses
+ Huffman encoding for the literal values. The HTTP/2 setting
+ parameter SETTINGS_HEADER_TABLE_SIZE is set to the value of 256
+ octets, causing some evictions to occur. The eviction mechanism uses
+ the length of the decoded literal values, so the same evictions occur
+ as in the previous section.
+
+C.6.1. First Response
+
+ Header list to encode:
+
+ :status: 302
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+ Hex dump of encoded data:
+
+ 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...
+ 2d1b ff6e 919d 29ad 1718 63c7 8f0b 97c8 | -..n..)...c.....
+ e9ae 82ae 43d3 | ....C.
+
+
+
+Peon & Ruellan Standards Track [Page 49]
+
+RFC 7541 HPACK May 2015
+
+
+ Decoding process:
+
+ 48 | == Literal indexed ==
+ | Indexed name (idx = 8)
+ | :status
+ 82 | Literal value (len = 2)
+ | Huffman encoded:
+ 6402 | d.
+ | Decoded:
+ | 302
+ | -> :status: 302
+ 58 | == Literal indexed ==
+ | Indexed name (idx = 24)
+ | cache-control
+ 85 | Literal value (len = 5)
+ | Huffman encoded:
+ aec3 771a 4b | ..w.K
+ | Decoded:
+ | private
+ | -> cache-control: private
+ 61 | == Literal indexed ==
+ | Indexed name (idx = 33)
+ | date
+ 96 | Literal value (len = 22)
+ | Huffman encoded:
+ d07a be94 1054 d444 a820 0595 040b 8166 | .z...T.D. .....f
+ e082 a62d 1bff | ...-..
+ | Decoded:
+ | Mon, 21 Oct 2013 20:13:21
+ | GMT
+ | -> date: Mon, 21 Oct 2013
+ | 20:13:21 GMT
+ 6e | == Literal indexed ==
+ | Indexed name (idx = 46)
+ | location
+ 91 | Literal value (len = 17)
+ | Huffman encoded:
+ 9d29 ad17 1863 c78f 0b97 c8e9 ae82 ae43 | .)...c.........C
+ d3 | .
+ | Decoded:
+ | https://www.example.com
+ | -> location:
+ | https://www.example.com
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 50]
+
+RFC 7541 HPACK May 2015
+
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 63) location: https://www.example.com
+ [ 2] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
+ [ 3] (s = 52) cache-control: private
+ [ 4] (s = 42) :status: 302
+ Table size: 222
+
+ Decoded header list:
+
+ :status: 302
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+C.6.2. Second Response
+
+ The (":status", "302") header field is evicted from the dynamic table
+ to free space to allow adding the (":status", "307") header field.
+
+ Header list to encode:
+
+ :status: 307
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+ Hex dump of encoded data:
+
+ 4883 640e ffc1 c0bf | H.d.....
+
+ Decoding process:
+
+ 48 | == Literal indexed ==
+ | Indexed name (idx = 8)
+ | :status
+ 83 | Literal value (len = 3)
+ | Huffman encoded:
+ 640e ff | d..
+ | Decoded:
+ | 307
+ | - evict: :status: 302
+ | -> :status: 307
+ c1 | == Indexed - Add ==
+ | idx = 65
+ | -> cache-control: private
+ c0 | == Indexed - Add ==
+ | idx = 64
+
+
+
+Peon & Ruellan Standards Track [Page 51]
+
+RFC 7541 HPACK May 2015
+
+
+ | -> date: Mon, 21 Oct 2013
+ | 20:13:21 GMT
+ bf | == Indexed - Add ==
+ | idx = 63
+ | -> location:
+ | https://www.example.com
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 42) :status: 307
+ [ 2] (s = 63) location: https://www.example.com
+ [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:21 GMT
+ [ 4] (s = 52) cache-control: private
+ Table size: 222
+
+ Decoded header list:
+
+ :status: 307
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:21 GMT
+ location: https://www.example.com
+
+C.6.3. Third Response
+
+ Several header fields are evicted from the dynamic table during the
+ processing of this header list.
+
+ Header list to encode:
+
+ :status: 200
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:22 GMT
+ location: https://www.example.com
+ content-encoding: gzip
+ set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
+
+ Hex dump of encoded data:
+
+ 88c1 6196 d07a be94 1054 d444 a820 0595 | ..a..z...T.D. ..
+ 040b 8166 e084 a62d 1bff c05a 839b d9ab | ...f...-...Z....
+ 77ad 94e7 821d d7f2 e6c7 b335 dfdf cd5b | w..........5...[
+ 3960 d5af 2708 7f36 72c1 ab27 0fb5 291f | 9`..'..6r..'..).
+ 9587 3160 65c0 03ed 4ee5 b106 3d50 07 | ..1`e...N...=P.
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 52]
+
+RFC 7541 HPACK May 2015
+
+
+ Decoding process:
+
+ 88 | == Indexed - Add ==
+ | idx = 8
+ | -> :status: 200
+ c1 | == Indexed - Add ==
+ | idx = 65
+ | -> cache-control: private
+ 61 | == Literal indexed ==
+ | Indexed name (idx = 33)
+ | date
+ 96 | Literal value (len = 22)
+ | Huffman encoded:
+ d07a be94 1054 d444 a820 0595 040b 8166 | .z...T.D. .....f
+ e084 a62d 1bff | ...-..
+ | Decoded:
+ | Mon, 21 Oct 2013 20:13:22
+ | GMT
+ | - evict: cache-control:
+ | private
+ | -> date: Mon, 21 Oct 2013
+ | 20:13:22 GMT
+ c0 | == Indexed - Add ==
+ | idx = 64
+ | -> location:
+ | https://www.example.com
+ 5a | == Literal indexed ==
+ | Indexed name (idx = 26)
+ | content-encoding
+ 83 | Literal value (len = 3)
+ | Huffman encoded:
+ 9bd9 ab | ...
+ | Decoded:
+ | gzip
+ | - evict: date: Mon, 21 Oct
+ | 2013 20:13:21 GMT
+ | -> content-encoding: gzip
+ 77 | == Literal indexed ==
+ | Indexed name (idx = 55)
+ | set-cookie
+ ad | Literal value (len = 45)
+ | Huffman encoded:
+ 94e7 821d d7f2 e6c7 b335 dfdf cd5b 3960 | .........5...[9`
+ d5af 2708 7f36 72c1 ab27 0fb5 291f 9587 | ..'..6r..'..)...
+ 3160 65c0 03ed 4ee5 b106 3d50 07 | 1`e...N...=P.
+ | Decoded:
+ | foo=ASDJKHQKBZXOQWEOPIUAXQ
+ | WEOIU; max-age=3600; versi
+
+
+
+Peon & Ruellan Standards Track [Page 53]
+
+RFC 7541 HPACK May 2015
+
+
+ | on=1
+ | - evict: location:
+ | https://www.example.com
+ | - evict: :status: 307
+ | -> set-cookie: foo=ASDJKHQ
+ | KBZXOQWEOPIUAXQWEOIU; ma
+ | x-age=3600; version=1
+
+ Dynamic Table (after decoding):
+
+ [ 1] (s = 98) set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU;
+ max-age=3600; version=1
+ [ 2] (s = 52) content-encoding: gzip
+ [ 3] (s = 65) date: Mon, 21 Oct 2013 20:13:22 GMT
+ Table size: 215
+
+ Decoded header list:
+
+ :status: 200
+ cache-control: private
+ date: Mon, 21 Oct 2013 20:13:22 GMT
+ location: https://www.example.com
+ content-encoding: gzip
+ set-cookie: foo=ASDJKHQKBZXOQWEOPIUAXQWEOIU; max-age=3600; version=1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 54]
+
+RFC 7541 HPACK May 2015
+
+
+Acknowledgments
+
+ This specification includes substantial input from the following
+ individuals:
+
+ o Mike Bishop, Jeff Pinner, Julian Reschke, and Martin Thomson
+ (substantial editorial contributions).
+
+ o Johnny Graettinger (Huffman code statistics).
+
+Authors' Addresses
+
+ Roberto Peon
+ Google, Inc
+
+ EMail: fenix@google.com
+
+
+ Herve Ruellan
+ Canon CRF
+
+ EMail: herve.ruellan@crf.canon.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peon & Ruellan Standards Track [Page 55]
+