draft-ietf-httpbis-header-compression-01.txt   draft-ietf-httpbis-header-compression-02.txt 
HTTPbis Working Group R. Peon HTTPbis Working Group R. Peon
Internet-Draft Google, Inc Internet-Draft Google, Inc
Intended status: Informational H. Ruellan Intended status: Informational H. Ruellan
Expires: January 10, 2014 Canon CRF Expires: February 22, 2014 Canon CRF
July 09, 2013 August 21, 2013
HTTP/2.0 Header Compression HPACK
draft-ietf-httpbis-header-compression-01 draft-ietf-httpbis-header-compression-02
Abstract Abstract
This document describes a format adapted to efficiently represent This document describes HPACK, a format adapted to efficiently
HTTP headers in the context of HTTP/2.0. represent HTTP headers in the context of HTTP/2.0.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 10, 2014. This Internet-Draft will expire on February 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Header Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Encoding Components . . . . . . . . . . . . . . . . . . . 3 3. Header Encoding . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Header Table . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Encoding Concepts . . . . . . . . . . . . . . . . . . . . 4
3.3. Header Representation . . . . . . . . . . . . . . . . . . 5 3.1.1. Encoding Context . . . . . . . . . . . . . . . . . . . 4
3.3.1. Literal Representation . . . . . . . . . . . . . . . 5 3.1.2. Header Table . . . . . . . . . . . . . . . . . . . . . 4
3.3.2. Indexed Representation . . . . . . . . . . . . . . . 6 3.1.3. Reference Set . . . . . . . . . . . . . . . . . . . . 5
3.4. Differential Coding . . . . . . . . . . . . . . . . . . . 6 3.1.4. Header set . . . . . . . . . . . . . . . . . . . . . . 6
4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.5. Header Representation . . . . . . . . . . . . . . . . 6
4.1. Header Blocks . . . . . . . . . . . . . . . . . . . . . . 7 3.1.6. Header Emission . . . . . . . . . . . . . . . . . . . 6
4.2. Low-level representations . . . . . . . . . . . . . . . . 7 3.2. Header Set Processing . . . . . . . . . . . . . . . . . . 7
4.2.1. Integer representation . . . . . . . . . . . . . . . 7 3.2.1. Header Representation Processing . . . . . . . . . . . 7
4.2.2. String literal representation . . . . . . . . . . . . 9 3.2.2. Reference Set Emission . . . . . . . . . . . . . . . . 8
4.3. Indexed Header Representation . . . . . . . . . . . . . . 9 3.2.3. Header Set Completion . . . . . . . . . . . . . . . . 8
4.4. Literal Header Representation . . . . . . . . . . . . . . 10 3.2.4. Header Table Management . . . . . . . . . . . . . . . 8
4.4.1. Literal Header without Indexing . . . . . . . . . . . 10 3.2.5. Specific Use Cases . . . . . . . . . . . . . . . . . . 8
4.4.2. Literal Header with Incremental Indexing . . . . . . 10 4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.3. Literal Header with Substitution Indexing . . . . . . 11 4.1. Low-level representations . . . . . . . . . . . . . . . . 9
5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Integer representation . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.1.2. Header Name Representation . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. Header Value Representation . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 13 4.2. Indexed Header Representation . . . . . . . . . . . . . . 11
Appendix A. Initial header names . . . . . . . . . . . . . . . . 13 4.3. Literal Header Representation . . . . . . . . . . . . . . 12
A.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.1. Literal Header without Indexing . . . . . . . . . . . 12
A.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.2. Literal Header with Incremental Indexing . . . . . . . 13
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 16 4.3.3. Literal Header with Substitution Indexing . . . . . . 14
B.1. First header set . . . . . . . . . . . . . . . . . . . . 16 5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 15
B.2. Second header set . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log (to be removed by RFC Editor before
publication . . . . . . . . . . . . . . . . . . . . . 16
A.1. Since draft-ietf-httpbis-header-compression-01 . . . . . . 16
Appendix B. Initial Header Tables . . . . . . . . . . . . . . . . 17
B.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17
B.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix C. Example . . . . . . . . . . . . . . . . . . . . . . . 19
C.1. First header set . . . . . . . . . . . . . . . . . . . . . 19
C.2. Second header set . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document describes a format adapted to efficiently represent This document describes HPACK, a format adapted to efficiently
HTTP headers in the context of HTTP/2.0. represent HTTP headers in the context of HTTP/2.0.
2. Overview 2. Overview
In HTTP/1.X, HTTP headers, which are necessary for the functioning of In HTTP/1.X, HTTP headers, which are necessary for the functioning of
the protocol, are transmitted with no transformations. the protocol, are transmitted with no transformations.
Unfortunately, the amount of redundancy in both the keys and the Unfortunately, the amount of redundancy in both the keys and the
values of these headers is astonishingly high, and is the cause of values of these headers is high, and is the cause of increased
increased latency on lower bandwidth links. This indicates that an latency on lower bandwidth links. This indicates that an alternate
alternate encoding for headers would be beneficial to latency, and more compact encoding for headers would be beneficial to latency, and
that is what is proposed here. As shown by SPDY [SPDY], Deflate that is what is proposed here.
compresses HTTP very effectively. However, the use of a compression
scheme which allows for arbitrary matches against the previously As shown by SPDY [SPDY], Deflate compresses HTTP very effectively.
encoded data (such as Deflate) exposes users to security issues. In However, the use of a compression scheme which allows for arbitrary
particular, the compression of sensitive data, together with other matches against the previously encoded data (such as Deflate) exposes
data controlled by an attacker, may lead to leakage of that sensitive users to security issues. In particular, the compression of
data, even when the resultant bytes are transmitted over an encrypted sensitive data, together with other data controlled by an attacker,
channel. Another consideration is that processing and memory costs may lead to leakage of that sensitive data, even when the resultant
of a compressor such as Deflate may also be too high for some classes bytes are transmitted over an encrypted channel.
of devices, for example when doing forward or reverse proxying.
Another consideration is that processing and memory costs of a
compressor such as Deflate may also be too high for some classes of
devices, for example when doing forward or reverse proxying.
2.1. Outline 2.1. Outline
The HTTP header representation described in this document is based on The HTTP header encoding described in this document is based on a
indexing tables that store (name, value) pairs, called header tables header table that map (name, value) pairs to index values. This
in the remainder of this document. This scheme is believed to be scheme is believed to be safe for all known attacks against the
safe for all known attacks against the compression context today. compression context today. Header tables are incrementally updated
Header tables are incrementally updated during the whole HTTP/2.0 during the HTTP/2.0 session.
session. Two independent header tables are used during a HTTP/2.0
session, one for HTTP request headers and one for HTTP response
headers.
The encoder is responsible for deciding which headers to insert as The encoder is responsible for deciding which headers to insert as
(name, value) pairs in the header table. The decoder then does new entries in the header table. The decoder then does exactly what
exactly what the encoder prescribes, ending in a state that exactly the encoder prescribes, ending in a state that exactly matches the
matches the encoder's state. This enables decoders to remain simple encoder's state. This enables decoders to remain simple and
and understand a wide variety of encoders. understand a wide variety of encoders.
A header may be represented as a literal or as an index. If As two consecutive sets of headers often have headers in common, each
represented as a literal, the representation specifies whether this set of headers is coded as a difference from the previous set of
header is used to update the indexing table. The different headers. The goal is to only encode the changes (headers present in
representations are described in Section 3.3. one of the set and not in the other) between the two sets of headers.
A set of headers is coded as a difference from the previous set of An example illustrating the use of these different mechanisms to
represent headers is available in Appendix C.
3. Header Encoding
3.1. Encoding Concepts
The encoding and decoding of headers relies on some components and
concepts. The set of components used form an encoding context.
Header Table: The header table (see Section 3.1.2) is a component
used to associate headers to index values.
Reference Set: The reference set (see Section 3.1.3) is a component
containing a group of headers used as a reference for the
differential encoding of a new set of headers.
Header Set: A header set (see Section 3.1.4) is a group of headers
that are encoded jointly. A complete set of key-value pairs as
encoded in an HTTP request or response is a header set.
Header Representation: A header can be represented in encoded form
either as a literal or as an index (see Section 3.1.5). The
indexed representation is based on the header table.
Header Emission: When decoding a set of headers, some operations
emit a header (see Section 3.1.6). An emitted header is added to
the set of headers. Once emitted, a header can't be removed from
the set of headers.
3.1.1. Encoding Context
The set of components used to encode or decode a header set form an
encoding context: an encoding context contains a header table and a
reference set.
Using HTTP, messages are exchanged between a client and a server in
both direction. To keep the encoding of headers in each direction
independent from the other direction, there is one encoding context
for each direction.
The headers contained in a PUSH_PROMISE frame sent by a server to a
client are encoded within the same context as the headers contained
in the HEADERS frame corresponding to a response sent from the server
to the client.
3.1.2. Header Table
A header table consists of an ordered list of (name, value) pairs.
The first entry of a header table is assigned the index 0.
A header can be represented by an entry of the header table if they
match. A header and an entry match if both their name and their
value match. A header name and an entry name match if they are equal
using a character-based, _case insensitive_ comparison (the case
insensitive comparison is used because HTTP header names are defined
in a case insensitive way). A header value and an entry value match
if they are equal using a character-based, _case sensitive_
comparison.
Generally, the header table will not contain duplicate entries.
However, implementations MUST be prepared to accept duplicates
without signalling an error.
Initially, a header table contains a list of common headers. Two
initial lists of header are provided in Appendix B. One list is for
headers transmitted from a client to a server, the other for the
reverse direction.
A header table is modified by either adding a new entry at the end of
the table, or by replacing an existing entry.
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
memory requirements on the decoder side, the header table size is
bounded (see the SETTINGS_MAX_BUFFER_SIZE in Section 5).
The size of an entry is the sum of its name's length in bytes (as
defined in Section 4.1.2), of its value's length in bytes
(Section 4.1.3) and of 32 bytes. The 32 bytes are an accounting for
the entry structure overhead. For example, an entry structure using
two 64-bits pointers to reference the name and the value and the
entry, and two 64-bits integer for counting the number of references
to these name and value would use 32 bytes.
The size of a header table is the sum of the size of its entries.
3.1.3. Reference Set
A reference set is defined as an unordered set of references to
entries of the header table.
The initial reference set is the empty set.
The reference set is updated during the processing of a set of
headers. headers.
An example illustrating the use these different mechanisms to Using the differential encoding, a header that is not present in the
represent headers is available in Appendix B. reference set can be encoded either with an indexed representation
(if the header is present in the header table), or with a literal
representation (if the header is not present in the header table).
3. Header Encoding A header that is to be removed from the reference set is encoded with
an indexed representation.
3.1. Encoding Components 3.1.4. Header set
The encoding and decoding of headers relies on a few components. A header set is a group of header fields that are encoded as a whole.
First, a header table (see Section 3.2) is used to associate headers Each header field is a (name, value) pair.
to index values. Second, a set of headers is encoded as a difference
from the previous reference set of headers (see Section 3.4).
As messages are exchanged in two directions, from client to server A header set is encoded using an ordered list of zero or more header
and from server to client, there are two sets of components: one for representations. All the header representations describing a header
each direction. All the headers sent in messages from the client to set a grouped into a header block.
the server are encoded (and decoded) using one set of components.
All the headers sent in messages from the server to the client
(including headers contained in PUSH_PROMISE frame) are encoded using
the other set of compotents.
3.2. Header Table 3.1.5. Header Representation
A header table consists of an ordered list of (name, value) pairs. A A header can be represented either as a literal or as an index.
pair is either inserted at the end of the table or replaces an
existing pair depending on the chosen representation. A pair can be
represented as an index which is its position in the table, starting
with 0 for the first entry.
An input header name matches the header name of a (name, value) pair Literal Representation: A literal representation defines a new
stored in the Header Table if they are equal using a character-based, header. The header name is represented either literally or as a
_case sensitive_ comparison. An input header value matches the reference to an entry of the header table. The header value is
header value of a (name, value) pair stored in the Header Table if represented literally.
they are equal using a character-based, _case sensitive_ comparison.
An input header (name, value) pair matches a pair in the Header Table
if both the name and value are matching as per above.
Generally, the header table will not contain duplicate header (name, Three different literal representations are provided:
value) entries. However, implementations MUST be prepared to accept
duplicates without signaling an error. If duplicates are added to
the table, they MUST be treated as distinct entries with their own
index positions.
The header table is progressively updated based on headers * A literal representation that does not add the header to the
represented as literal (as defined in Section 3.3.1). Two update header table (see Section 4.3.1).
mechanisms are defined:
o Incremental indexing: the represented header is inserted at the * A literal representation that adds the header at the end of the
end of the header table as a (name, value) pair. The inserted header table (see Section 4.3.2).
pair index is set to the next free index in the table: it is equal
to the number of headers in the table before its insertion.
o Substitution indexing: the represented header contains an index to * A literal representation that uses the header to replace an
an existing (name, value) pair. The existing pair value is existing entry of the header table (see Section 4.3.3).
replaced by the pair representing the new header.
Incremental and substitution indexing are optional. If none of them Indexed Representation: The indexed representation defines a header
is selected in a header representation, the header table is not as a reference in the header table (see Section 4.2).
updated. In particular, no update happens on the header table when
processing an indexed representation.
The header table size can be bounded so as to limit the memory 3.1.6. Header Emission
requirements (see the SETTINGS_MAX_BUFFER_SIZE in Section 5). The
header table size is defined as the sum of the size of each entry of
the table. The size of an entry is the sum of the length in bytes
(as defined in Section 4.2.2) of its name, of value's length in bytes
and of 32 bytes (for accounting for the entry structure overhead).
The header table size MUST NOT exceed this limit.
Before adding a new entry to the header table or changing an existing The emission of header is the process of adding a header to the
one, a check has to be performed to ensure that the change will not current set of headers. Once an header is emitted, it can't be
cause the table to grow in size beyond the SETTINGS_MAX_BUFFER_SIZE removed from the current set of headers.
limit. If necessary, one or more items from the beginning of the
table are removed until there is enough free space available to make
the modification. Dropping an entry from the beginning of the table
causes the index positions of the remaining entries in the table to
be decremented by 1. [[Feedback is needed on this automatic eviction
strategy. ]]
When using substitution indexing, it is possible that the existing The concept of header emission allows a decoder to know when it can
item being replaced might be one of the items removed when performing pass a header safely to a higher level on the receiver side. This
the necessary size adjustment. In such cases, the substituted value allows a decoder to be implemented in a streaming way, and as such to
being added to the header table is inserted at the beginning of the only keep in memory the header table and the reference set. With
header table (at index position #0) and the index positions of the such an implementation, the amount of memory used by the decoder is
other remaining entries in the table are incremented by 1. bounded, even in presence of a very large set of headers. The
management of memory for handling very large sets of headers can
therefore be deferred to the application, which may be able to emit
the header to the wire and thus free up memory quickly.
To optimize the representation of the headers exchanged at the 3.2. Header Set Processing
beginning of an HTTP/2.0 session, the header table is initialized
with common headers. Two lists of initial headers are provided in
Appendix A. One is for messages sent from a client to a server, the
other is for messages sent from a server to a client.
3.3. Header Representation The processing of an encoded header set to obtain a list of headers
is defined in this section. To ensure a correct decoding of a header
set, a decoder MUST obey the following rules.
3.3.1. Literal Representation 3.2.1. Header Representation Processing
The literal representation defines a new header. A literal header is All the header representations contained in a header block are
represented as: processed in the order in which they are presented, as specified
below.
o A header name, with two possible representations: An _indexed representation_ corresponding to an entry _not present_
in the reference set entails the following actions:
* A literal string, as described in Section 4.2.2. o The header corresponding to the entry is emitted.
* A index in the header table referencing the name of the o The entry is added to the reference set.
corresponding header. The index is represented as an integer,
as described in Section 4.2.1.
o The header value, represented as a literal string, as described in An _indexed representation_ corresponding to an entry _present_ in
Section 4.2.2. the reference set entails the following actions:
3.3.2. Indexed Representation o The entry is removed from the reference set.
The indexed representation defines a header as a match to a (name, A _literal representation_ that is _not added_ to the header table
value) pair in the header table. An indexed header is represented entails the following action:
as:
o An integer representing the index of the matching (name, value) o The header is emitted.
pair, as described in Section 4.2.1.
3.4. Differential Coding A _literal representation_ that is _added_ to the header table
entails the following actions:
A set of headers is encoded as a difference from the previous o The header is emitted.
reference set of headers. The initial reference set of headers is
the empty set.
An indexed representation toggles the presence of the header in the o The header is added to the header table, at the location defined
current set of headers. If the header corresponding to the indexed by the representation.
representation was not in the set, it is added to the set. If the
header index was in the set, it is removed from it.
A literal representation adds a header to the current set of headers. o The new entry is added to the reference set.
To ensure a correct decoding of a set of headers, the following steps 3.2.2. Reference Set Emission
or equivalent ones MUST be executed by the decoder.
First, upon starting the decoding of a new set of headers, the Once all the representations contained in a header block have been
reference set of headers is interpreted into the working set of processed, the headers that are in common with the previous header
headers: for each header in the reference set, an entry is added to set are emitted, during the reference set emission.
the working set, containing the header name, its value, and its
current index in the header table.
Then, the header representations are processed in their order of For the reference set emission, each header contained in the
occurrence in the frame. reference set that has not been emitted during the processing of the
header block is emitted.
For an indexed representation, the decoder checks whether the index 3.2.3. Header Set Completion
is present in the working set. If true, the corresponding entry is
removed from the working set. If several entries correspond to this
encoded index, all these entries are removed from the working set.
If the index is not present in the working set, it is used to
retrieve the corresponding header from the header table, and a new
entry is added to the working set representing this header.
For a literal representation, a new entry is added to the working set Once all of the header representations have been processed, and the
representing this header. If the literal representation specifies remaining items in the reference set have been emitted, the header
that the header is to be indexed, the header is added accordingly to set is complete.
the header table, and its index is included in the entry in the
working set. Otherwise, the entry in the working set contains an
undefined index.
When all the header representations have been processed, the working 3.2.4. Header Table Management
set contains all the headers of the set of headers.
The new reference set of headers is computed by removing from the The header table can be modified by either adding a new entry to it
working set all the headers that are not present in the header table. or by replacing an existing one. Before doing such a modification,
it has to be ensured that the header table size will stay lower than
or equal to the SETTINGS_MAX_BUFFER_SIZE limit (see Section 5). To
achieve this, repeatedly, the first entry of the header table is
removed, until enough space is available for the modification.
It should be noted that during the decoding of the header A consequence of removing one or more entries at the beginning of the
representations, the same index may be associated to different header table is that the remaining entries are renumbered. The first
headers in the working set and in the header table. entry of the header table is always associated to the index 0.
4. Detailed Format When the modification of the header table is the replacement of an
existing entry, the replaced entry is the one indicated in the
literal representation before any entry is removed from the header
table. If the entry to be replaced is removed from the header table
when performing the size adjustment, the replacement entry is
inserted at the beginning of the header table.
4.1. Header Blocks The addition of a new entry with a size greater than the
SETTINGS_MAX_BUFFER_SIZE limit causes all the entries from the header
table to be dropped and the new entry not to be added to the header
table. The replacement of an existing entry with a new entry with a
size greater than the SETTINGS_MAX_BUFFER_SIZE has the same
consequences.
A header block consists of a set of header fields, which are name- 3.2.5. Specific Use Cases
value pairs. Each header field is encoded using one of the header
representation.
4.2. Low-level representations Three occurrences of the same indexed representation, corresponding
to an entry not present in the reference set, emit the associated
header twice:
4.2.1. Integer representation o The first occurrence emits the header a first time and adds the
corresponding entry to the reference set.
o The second occurrence removes the header's entry from the
reference set.
o The third occurrence emits the header a second time and adds again
its entry to the reference set.
This allows for headers sets which include duplicate header entries
to be encoded efficiently and faithfully.
The first occurrence of the indexed representation can be replaced by
a literal representation creating an entry for the header.
4. Detailed Format
4.1. Low-level representations
4.1.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. The integer representation keeps byte-alignment as much as lengths. To allow for optimized processing, an integer
possible as this allows various processing optimizations as well as
efficient use of DEFLATE. For that purpose, an integer
representation always finishes at the end of a byte. representation always finishes at the end of a byte.
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 byte and an optional list of bytes that are used if the current byte and an optional list of bytes that are used if the
integer value does not fit in the prefix. The number of bits of the integer value does not fit in the prefix. The number of bits of the
prefix (called N) is a parameter of the integer representation. prefix (called N) is a parameter of the integer representation.
The N-bit prefix allows filling the current byte. If the value is The N-bit prefix allows filling the current byte. If the value is
small enough (strictly less than 2^N-1), it is encoded within the small enough (strictly less than 2^N-1), it is encoded within the
N-bit prefix. Otherwise all the bits of the prefix are set to 1 and N-bit prefix. Otherwise all the bits of the prefix are set to 1 and
the value is encoded using an unsigned variable length integer [1] the value is encoded using an unsigned variable length integer [1]
representation. representation.
The algorithm to represent an integer I is as follows: The algorithm to represent an integer I is as follows:
1. If I < 2^N - 1, encode I on N bits If I < 2^N - 1, encode I on N bits
Else
2. Else, encode 2^N - 1 on N bits and do the following steps: encode 2^N - 1 on N bits
While I >= 128
3. Encode (I % 128 + 128) on 8 bits
I = I / 128
1. Set I to (I - (2^N - 1)) and Q to 1 encode (I) on 8 bits
2. While Q > 0
3.
1. Compute Q and R, quotient and remainder of I divided by
2^7
2. If Q is strictly greater than 0, write one 1 bit;
otherwise, write one 0 bit
3. Encode R on the next 7 bits
4. I = Q
4.2.1.1. Example 1: Encoding 10 using a 5-bit prefix 4.1.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.
o 10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit o 10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit
prefix. prefix.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits | X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
4.2.1.2. Example 2: Encoding 1337 using a 5-bit prefix 4.1.1.2. Example 2: Encoding 1337 using a 5-bit prefix
The value I=1337 is to be encoded with a 5-bit prefix. The value I=1337 is to be encoded with a 5-bit prefix.
o 1337 is greater than 31 (= 2^5 - 1). 1337 is greater than 31 (= 2^5 - 1).
o The 5-bit prefix is filled with its max value (31).
* The 5-bit prefix is filled with its max value (31). I = 1337 - (2^5 - 1) = 1306.
o The value to represent on next bytes is I = 1337 - (2^5 - 1) = I (1306) is greater than or equal to 128, the while loop body
1306. executes:
o I % 128 == 26
* 1306 = 128*10 + 26, i.e. Q=10 and R=26. 26 + 128 == 154
* Q is greater than 1, bit 8 is set to 1. 154 is encoded in 8 bits as: 10011010
* The remainder R=26 is encoded on next 7 bits. I is set to 10 (1306 / 128 == 10)
* I is replaced by the quotient Q=10. I is no longer greater than or equal to 128, the while loop
terminates.
o The value to represent on next bytes is I = 10. I, now 10, is encoded on 8 bits as: 00001010
o The process ends.
* 10 = 128*0 + 10, i.e. Q=0 and R=10. 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
+---+---+---+---+---+---+---+---+
* Q is equal to 0, bit 16 is set to 0. 4.1.2. Header Name Representation
* The remainder R=10 is encoded on next 7 bits. Header names are sequences of ASCII characters that MUST conform to
the following header-name ABNF construction:
* I is replaced by the quotient Q=0. LOWERALPHA = %x61-7A
header-char = "!" / "#" / "$" / "%" / "&" / "'" /
"*" / "+" / "-" / "." / "^" / "_" /
"`" / "|" / "~" / DIGIT / LOWERALPHA
header-name = [":"] 1*header-char
o The process ends. They are encoded in two parts:
0 1 2 3 4 5 6 7 1. The length of the text, defined as the number of octets of
+---+---+---+---+---+---+---+---+ storage required to store the text, represented as a variable-
| X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31 length-quantity (Section 4.1.1).
| 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | Q>=1, R=26
| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | Q=0 , R=10
+---+---+---+---+---+---+---+---+
4.2.2. String literal representation 2. The specific sequence of ASCII octets
Literal strings can represent header names or header values. They 4.1.3. Header Value Representation
Header values are encoded as sequences of UTF-8 encoded text. They
are encoded in two parts: are encoded in two parts:
1. The string length, defined as the number of bytes needed to store 1. The length of the text, defined as the number of octets of
its UTF-8 representation, is represented as an integer with a storage required to store the text, represented as a variable-
zero bits prefix. If the string length is strictly less than length-quantity (Section 4.1.1).
128, it is represented as one byte.
2. The string value represented as a list of UTF-8 characters. 2. The specific sequence of octets representing the UTF-8 text.
4.3. Indexed Header Representation Invalid UTF-8 octet sequences, "over-long" UTF-8 encodings, and UTF-8
octets that represent invalid Unicode Codepoints MUST NOT be used.
4.2. Indexed Header Representation
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | Index (7+) | | 1 | Index (7+) |
+---+---------------------------+ +---+---------------------------+
Indexed Header Indexed Header
This representation starts with the '1' 1-bit pattern, followed by This representation starts with the '1' 1-bit pattern, followed by
the index of the matching pair, represented as an integer with a the index of the matching pair, represented as an integer with a
7-bit prefix. 7-bit prefix.
4.4. Literal Header Representation 4.3. Literal Header Representation
4.4.1. Literal Header without Indexing 4.3.1. Literal Header without Indexing
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | Index (5+) | | 0 | 1 | 1 | Index (5+) |
+---+---+---+-------------------+ +---+---+---+-------------------+
| Value Length (8+) | | Value Length (8+) |
+-------------------------------+ +-------------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
skipping to change at page 10, line 44 skipping to change at page 12, line 48
This representation, which does not involve updating the header This representation, which does not involve updating the header
table, starts with the '011' 3-bit pattern. table, starts with the '011' 3-bit pattern.
If the header name matches the header name of a (name, value) pair If the header name matches the header name of a (name, value) pair
stored in the Header Table, the index of the pair increased by one stored in the Header Table, the index of the pair increased by one
(index + 1) is represented as an integer with a 5-bit prefix. Note (index + 1) is represented as an integer with a 5-bit prefix. Note
that if the index is strictly below 31, one byte is used. that if the index is strictly below 31, one byte is used.
If the header name does not match a header name entry, the value 0 is If the header name does not match a header name entry, the value 0 is
represented on 5 bits followed by the header name, represented as a represented on 5 bits followed by the header name (Section 4.1.2).
literal string.
Header name representation is followed by the header value Header name representation is followed by the header value
represented as a literal string as described in Section 4.2.2. represented as a literal string as described in Section 4.1.3.
4.3.2. Literal Header with Incremental Indexing
4.4.2. Literal Header with Incremental Indexing
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | Index (5+) | | 0 | 1 | 0 | Index (5+) |
+---+---+---+-------------------+ +---+---+---+-------------------+
| Value Length (8+) | | Value Length (8+) |
+-------------------------------+ +-------------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header with Incremental Indexing - Indexed Name Literal Header with Incremental Indexing -
Indexed Name
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 | | 0 | 1 | 0 | 0 |
+---+---+---+-------------------+ +---+---+---+-------------------+
| Name Length (8+) | | Name Length (8+) |
+-------------------------------+ +-------------------------------+
| Name String (Length octets) | | Name String (Length octets) |
+-------------------------------+ +-------------------------------+
| Value Length (8+) | | Value Length (8+) |
+-------------------------------+ +-------------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header with Incremental Indexing - New Name Literal Header with Incremental Indexing -
New Name
This representation starts with the '010' 3-bit pattern. This representation starts with the '010' 3-bit pattern.
If the header name matches the header name of a (name, value) pair If the header name matches the header name of a (name, value) pair
stored in the Header Table, the index of the pair increased by one stored in the Header Table, the index of the pair increased by one
(index + 1) is represented as an integer with a 5-bit prefix. Note (index + 1) is represented as an integer with a 5-bit prefix. Note
that if the index is strictly below 31, one byte is used. that if the index is strictly below 31, one byte is used.
If the header name does not match a header name entry, the value 0 is If the header name does not match a header name entry, the value 0 is
represented on 5 bits followed by the header name, represented as a represented on 5 bits followed by the header name (Section 4.1.2).
literal string.
Header name representation is followed by the header value Header name representation is followed by the header value
represented as a literal string as described in Section 4.2.2. represented as a literal string as described in Section 4.1.3.
4.4.3. Literal Header with Substitution Indexing 4.3.3. Literal Header with Substitution Indexing
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | Index (6+) | | 0 | 0 | Index (6+) |
+---+---+-----------------------+ +---+---+-----------------------+
| Substituted Index (8+) | | Substituted Index (8+) |
+-------------------------------+ +-------------------------------+
| Value Length (8+) | | Value Length (8+) |
+-------------------------------+ +-------------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header with Substitution Indexing - Indexed Name Literal Header with Substitution Indexing -
Indexed Name
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | | 0 | 0 | 0 |
+---+---+-----------------------+ +---+---+-----------------------+
| Name Length (8+) | | Name Length (8+) |
+-------------------------------+ +-------------------------------+
| Name String (Length octets) | | Name String (Length octets) |
+-------------------------------+ +-------------------------------+
| Substituted Index (8+) | | Substituted Index (8+) |
+-------------------------------+ +-------------------------------+
| Value Length (8+) | | Value Length (8+) |
+-------------------------------+ +-------------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header with Substitution Indexing - New Name Literal Header with Substitution Indexing -
New Name
This representation starts with the '00' 2-bit pattern. This representation starts with the '00' 2-bit pattern.
If the header name matches the header name of a (name, value) pair If the header name matches the header name of a (name, value) pair
stored in the Header Table, the index of the pair increased by one stored in the Header Table, the index of the pair increased by one
(index + 1) is represented as an integer with a 6-bit prefix. Note (index + 1) is represented as an integer with a 6-bit prefix. Note
that if the index is strictly below 62, one byte is used. that if the index is strictly below 62, one byte is used.
If the header name does not match a header name entry, the value 0 is If the header name does not match a header name entry, the value 0 is
represented on 6 bits followed by the header name, represented as a represented on 6 bits followed by the header name (Section 4.1.2).
literal string.
The index of the substituted (name, value) pair is inserted after the The index of the substituted (name, value) pair is inserted after the
header name representation as a 0-bit prefix integer. header name representation as a 0-bit prefix integer.
The index of the substituted pair MUST correspond to a position in The index of the substituted pair MUST correspond to a position in
the header table containing a non-void entry. An index for the the header table containing a non-void entry. An index for the
substituted pair that corresponds to empty position in the header substituted pair that corresponds to empty position in the header
table MUST be treated as an error. table MUST be treated as an error.
This index is followed by the header value represented as a literal This index is followed by the header value represented as a literal
string as described in Section 4.2.2. string as described in Section 4.1.3.
5. Parameter Negotiation 5. Parameter Negotiation
A few parameters can be used to accomodate client and server
processing and memory requirements. [[These settings are currently A few parameters can be used to accommodate client and server
not supported as they have not been integrated in the main processing and memory requirements. [[anchor3: These settings are
currently not supported as they have not been integrated in the main
specification. Therefore, the maximum buffer size for the header specification. Therefore, the maximum buffer size for the header
table is fixed at 4096 bytes. ]] table is fixed at 4096 bytes.]]
SETTINGS_MAX_BUFFER_SIZE: Allows the sender to inform the remote SETTINGS_MAX_BUFFER_SIZE: Allows the sender to inform the remote
endpoint of the maximum size it accepts for the header table. endpoint of the maximum size it accepts for the header table.
The default value is 4096 bytes. The default value is 4096 bytes.
[[Is this default value OK? Do we need a maximum size? Do we [[anchor4: Is this default value OK? Do we need a maximum size?
want to allow infinite buffer?]] Do we want to allow infinite buffer?]]
When the remote endpoint receives a SETTINGS frame containing a When the remote endpoint receives a SETTINGS frame containing a
SETTINGS_MAX_BUFFER_SIZE setting with a value smaller than the one SETTINGS_MAX_BUFFER_SIZE setting with a value smaller than the one
currently in use, it MUST send as soon as possible a HEADER frame currently in use, it MUST send as soon as possible a HEADER frame
with a stream identifier of 0x0 containing a value smaller than or with a stream identifier of 0x0 containing a value smaller than or
equal to the received setting value. equal to the received setting value.
[[This changes slightly the behaviour of the HEADERS frame, which [[anchor5: This changes slightly the behaviour of the HEADERS
should be updated as follows: ]] frame, which should be updated as follows:]]
A HEADER frame with a stream identifier of 0x0 indicates that the A HEADER frame with a stream identifier of 0x0 indicates that the
sender has reduced the maximum size of the header table. The new sender has reduced the maximum size of the header table. The new
maximum size of the header table is encoded on 32-bit. The maximum size of the header table is encoded on 32-bit. The
decoder MUST reduce its own header table by dropping entries from decoder MUST reduce its own header table by dropping entries from
it until the size of the header table is lower than or equal to it until the size of the header table is lower than or equal to
the transmitted maximum size. the transmitted maximum size.
6. Security Considerations 6. Security Considerations
TODO? This compressor exists to solve security issues present in stream
compressors such as DEFLATE whereby the compression context can be
efficiently probed to reveal secrets. A conformant implementation of
this specification should be fairly safe against that kind of attack,
as the reaping of any information from the compression context
requires more work than guessing and verifying the plaintext data
directly with the server. As with any secret, however, the longer
the length of the secret, the more difficult the secret is to guess.
It is inadvisable to have short cookies that are relied upon to
remain secret for any duration of time.
A proper security-conscious implementation will also need to prevent
timing attacks by ensuring that the amount of time it takes to do
string comparisons is always a function of the total length of the
strings, and not a function of the number of matched characters.
Another common security problem is when the remote endpoint
successfully causes the local endpoint to exhaust its memory. This
compressor attempts to deal with the most obvious ways that this
could occur by limiting both the peak and the steady-state amount of
memory consumed in the compressor state, by providing ways for the
application to consume/flush the emitted headers in small chunks, and
by considering overhead in the state size calculation. Implementors
must still be careful in the creation of APIs to an implementation of
this compressor by ensuring that header keys and values are either
emitted as a stream, or that the compression implementation have a
limit on the maximum size of a key or value. Failure to implement
these kinds of safeguards may still result in a scenario where the
local endpoint exhausts its memory.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Informative References 8. Informative References
[SPDY] Belshe, M. and R. Peon, "SPDY Protocol", February 2012, [SPDY] Belshe, M. and R. Peon, "SPDY Protocol", February 2012,
<http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy>. <http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy>.
Appendix A. Initial header names [1] <http://en.wikipedia.org/wiki/Variable-length_quantity>
[[The tables in this section should be updated based on statistical Appendix A. Change Log (to be removed by RFC Editor before publication
analysis of header names frequency and specific HTTP 2.0 header rules
(like removal of some headers). ]]
[[These tables are not adapted for headers contained in PUSH_PROMISE
frames. Either the tables can be merged, or the table for responses
can be updated. ]]
A.1. Requests A.1. Since draft-ietf-httpbis-header-compression-01
o Refactored of Header Encoding Section: split definitions and
processing rule.
o Backward incompatible change: Updated reference set management as
per issue #214. This changes how the interaction between the
reference set and eviction works. This also changes the working
of the reference set in some specific cases.
o Backward incompatible change: modified initial header list, as per
issue #188.
o Added example of 32 bytes entry structure (issue #191).
o Added Header Set Completion section. Reflowed some text.
Clarified some writing which was akward. Added text about
duplicate header entry encoding. Clarified some language w.r.t
Header Set. Changed x-my-header to mynewheader. Added text in the
HeaderEmission section indicating that the application may also be
able to free up memory more quickly. Added information in
Security Considerations section.
Appendix B. Initial Header Tables
[[anchor9: The tables in this section should be updated based on
statistical analysis of header names frequency and specific HTTP 2.0
header rules (like removal of some headers).]]
[[anchor10: These tables are not adapted for headers contained in
PUSH_PROMISE frames. Either the tables can be merged, or the table
for responses can be updated.]]
B.1. Requests
The following table lists the pre-defined headers that make-up the The following table lists the pre-defined headers that make-up the
initial header table user to represent requests sent from a client to initial header table user to represent requests sent from a client to
a server. a server.
+-------+---------------------+--------------+ +-------+---------------------+--------------+
| Index | Header Name | Header Value | | Index | Header Name | Header Value |
+-------+---------------------+--------------+ +-------+---------------------+--------------+
| 0 | :scheme | http | | 0 | :scheme | http |
| 1 | :scheme | https | | 1 | :scheme | https |
| 2 | :host | | | 2 | :host | |
| 3 | :path | / | | 3 | :path | / |
| 4 | :method | GET | | 4 | :method | GET |
| 5 | accept | | | 5 | accept | |
| 6 | accept-charset | | | 6 | accept-charset | |
| 7 | accept-encoding | | | 7 | accept-encoding | |
| 8 | accept-language | | | 8 | accept-language | |
| 9 | cookie | | | 9 | cookie | |
| 10 | if-modified-since | | | 10 | if-modified-since | |
| 11 | keep-alive | | | 11 | user-agent | |
| 12 | user-agent | | | 12 | referer | |
| 13 | proxy-connection | | | 13 | authorization | |
| 14 | referer | | | 14 | allow | |
| 15 | accept-datetime | | | 15 | cache-control | |
| 16 | authorization | | | 16 | connection | |
| 17 | allow | | | 17 | content-length | |
| 18 | cache-control | | | 18 | content-type | |
| 19 | connection | | | 19 | date | |
| 20 | content-length | | | 20 | expect | |
| 21 | content-md5 | | | 21 | from | |
| 22 | content-type | | | 22 | if-match | |
| 23 | date | | | 23 | if-none-match | |
| 24 | expect | | | 24 | if-range | |
| 25 | from | | | 25 | if-unmodified-since | |
| 26 | if-match | | | 26 | max-forwards | |
| 27 | if-none-match | | | 27 | proxy-authorization | |
| 28 | if-range | | | 28 | range | |
| 29 | if-unmodified-since | | | 29 | via | |
| 30 | max-forwards | |
| 31 | pragma | |
| 32 | proxy-authorization | |
| 33 | range | |
| 34 | te | |
| 35 | upgrade | |
| 36 | via | |
| 37 | warning | |
+-------+---------------------+--------------+ +-------+---------------------+--------------+
Table 1
A.2. Responses Table 1: Initial Header Table for Requests
B.2. Responses
The following table lists the pre-defined headers that make-up the The following table lists the pre-defined headers that make-up the
initial header table used to represent responses sent from a server initial header table used to represent responses sent from a server
to a client. The same header table is also used to represent request to a client. The same header table is also used to represent request
headers sent from a server to a client in a PUSH_PROMISE frame. headers sent from a server to a client in a PUSH_PROMISE frame.
+-------+-----------------------------+--------------+ +-------+-----------------------------+--------------+
| Index | Header Name | Header Value | | Index | Header Name | Header Value |
+-------+-----------------------------+--------------+ +-------+-----------------------------+--------------+
| 0 | :status | 200 | | 0 | :status | 200 |
skipping to change at page 15, line 37 skipping to change at page 19, line 29
| 11 | vary | | | 11 | vary | |
| 12 | via | | | 12 | via | |
| 13 | access-control-allow-origin | | | 13 | access-control-allow-origin | |
| 14 | accept-ranges | | | 14 | accept-ranges | |
| 15 | allow | | | 15 | allow | |
| 16 | connection | | | 16 | connection | |
| 17 | content-disposition | | | 17 | content-disposition | |
| 18 | content-encoding | | | 18 | content-encoding | |
| 19 | content-language | | | 19 | content-language | |
| 20 | content-location | | | 20 | content-location | |
| 21 | content-md5 | | | 21 | content-range | |
| 22 | content-range | | | 22 | link | |
| 23 | link | | | 23 | location | |
| 24 | location | | | 24 | proxy-authenticate | |
| 25 | p3p | | | 25 | refresh | |
| 26 | pragma | | | 26 | retry-after | |
| 27 | proxy-authenticate | | | 27 | strict-transport-security | |
| 28 | refresh | | | 28 | transfer-encoding | |
| 29 | retry-after | | | 29 | www-authenticate | |
| 30 | strict-transport-security | |
| 31 | trailer | |
| 32 | transfer-encoding | |
| 33 | warning | |
| 34 | www-authenticate | |
+-------+-----------------------------+--------------+ +-------+-----------------------------+--------------+
Table 2
Appendix B. Example Table 2: Initial Header Table for Responses
Appendix C. Example
Here is an example that illustrates different representations and how Here is an example that illustrates different representations and how
tables are updated. [[This section needs to be updated to integrate tables are updated. [[anchor13: This section needs to be updated to
differential coding.]] better reflect the new processing of header fields, and include more
examples.]]
B.1. First header set C.1. First header set
The first header set to represent is the following: The first header set to represent is the following:
:path: /my-example/index.html :path: /my-example/index.html
user-agent: my-user-agent user-agent: my-user-agent
x-my-header: first mynewheader: first
The header table is empty, all headers are represented as literal The header table is empty, all headers are represented as literal
headers with indexing. The 'x-my-header' header name is not in the headers with indexing. The 'mynewheader' header name is not in the
header name table and is encoded literally. This gives the following header name table and is encoded literally. This gives the following
representation: representation:
0x44 (literal header with incremental indexing, name index = 3) 0x44 (literal header with incremental indexing, name index = 3)
0x16 (header value string length = 22) 0x16 (header value string length = 22)
/my-example/index.html /my-example/index.html
0x4D (literal header with incremental indexing, name index = 12) 0x4D (literal header with incremental indexing, name index = 12)
0x0D (header value string length = 13) 0x0D (header value string length = 13)
my-user-agent my-user-agent
0x40 (literal header with incremental indexing, new name) 0x40 (literal header with incremental indexing, new name)
0x0B (header name string length = 11) 0x0B (header name string length = 11)
x-my-header mynewheader
0x05 (header value string length = 5) 0x05 (header value string length = 5)
first first
The header table is as follows after the processing of these headers: The header table is as follows after the processing of these headers:
Header table Header table
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| Index | Header Name | Header Value | | Index | Header Name | Header Value |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 0 | :scheme | http | | 0 | :scheme | http |
skipping to change at page 17, line 9 skipping to change at page 20, line 44
| 1 | :scheme | https | | 1 | :scheme | https |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| ... | ... | ... | | ... | ... | ... |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 37 | warning | | | 37 | warning | |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 38 | :path | /my-example/index.html | added header | 38 | :path | /my-example/index.html | added header
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 39 | user-agent | my-user-agent | added header | 39 | user-agent | my-user-agent | added header
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 40 | x-my-header | first | added header | 40 | mynewheader | first | added header
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
As all the headers in the first header set are indexed in the header As all the headers in the first header set are indexed in the header
table, all are kept in the reference set of headers, which is: table, all are kept in the reference set of headers, which is:
Reference Set: Reference Set:
:path, /my-example/index.html :path, /my-example/index.html
user-agent, my-user-agent user-agent, my-user-agent
x-my-header, first mynewheader, first
B.2. Second header set C.2. Second header set
The second header set to represent is the following: The second header set to represent is the following:
:path: /my-example/resources/script.js :path: /my-example/resources/script.js
user-agent: my-user-agent user-agent: my-user-agent
x-my-header: second mynewheader: second
Comparing this second header set to the reference set, the first and Comparing this second header set to the reference set, the first and
third headers are from the reference set are not present in this third headers are from the reference set are not present in this
second header set and must be removed. In addition, in this new set, second header set and must be removed. In addition, in this new set,
the first and third headers have to be encoded. The path header is the first and third headers have to be encoded. The path header is
represented as a literal header with substitution indexing. The x represented as a literal header with substitution indexing. The
-my-header will be represented as a literal header with incremental mynewheader will be represented as a literal header with incremental
indexing. indexing.
0xa6 (indexed header, index = 38: removal from reference set) 0xa6 (indexed header, index = 38: removal from reference set)
0xa8 (indexed header, index = 40: removal from reference set) 0xa8 (indexed header, index = 40: removal from reference set)
0x04 (literal header, substitution indexing, name index = 3) 0x04 (literal header, substitution indexing, name index = 3)
0x26 (replaced entry index = 38) 0x26 (replaced entry index = 38)
0x1f (header value string length = 31) 0x1f (header value string length = 31)
/my-example/resources/script.js /my-example/resources/script.js
0x5f 0x0a (literal header, incremental indexing, name index = 40) 0x5f 0x0a (literal header, incremental indexing, name index = 40)
0x06 (header value string length = 6) 0x06 (header value string length = 6)
skipping to change at page 18, line 22 skipping to change at page 22, line 22
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| ... | ... | ... | | ... | ... | ... |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 37 | warning | | | 37 | warning | |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 38 | :path | /my-example/resources/ | replaced | 38 | :path | /my-example/resources/ | replaced
| | | script.js | header | | | script.js | header
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 39 | user-agent | my-user-agent | | 39 | user-agent | my-user-agent |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 40 | x-my-header | first | | 40 | mynewheader | first |
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
| 41 | x-my-header | second | added header | 41 | mynewheader | second | added header
+---------+----------------+---------------------------+ +---------+----------------+---------------------------+
All the headers in this second header set are indexed in the header All the headers in this second header set are indexed in the header
table, therefore, all are kept in the reference set of headers, which table, therefore, all are kept in the reference set of headers, which
becomes: becomes:
Reference Set: Reference Set:
:path, /my-example/resources/script.js :path, /my-example/resources/script.js
user-agent, my-user-agent user-agent, my-user-agent
x-my-header, second mynewheader, second
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
 End of changes. 123 change blocks. 
358 lines changed or deleted 492 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/