draft-ietf-httpbis-header-compression-02.txt   draft-ietf-httpbis-header-compression-03.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: February 22, 2014 Canon CRF Expires: February 28, 2014 Canon CRF
August 21, 2013 August 27, 2013
HPACK HPACK - Header Compression for HTTP/2.0
draft-ietf-httpbis-header-compression-02 draft-ietf-httpbis-header-compression-03
Abstract Abstract
This document describes HPACK, a format adapted to efficiently This document describes HPACK, a format adapted to efficiently
represent 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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 February 22, 2014. This Internet-Draft will expire on February 28, 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
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Header Encoding . . . . . . . . . . . . . . . . . . . . . . . 4 3. Header Encoding . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Encoding Concepts . . . . . . . . . . . . . . . . . . . . 4 3.1. Encoding Concepts . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Encoding Context . . . . . . . . . . . . . . . . . . . 4 3.1.1. Encoding Context . . . . . . . . . . . . . . . . . . . 4
3.1.2. Header Table . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Header Table . . . . . . . . . . . . . . . . . . . . . 4
3.1.3. Reference Set . . . . . . . . . . . . . . . . . . . . 5 3.1.3. Reference Set . . . . . . . . . . . . . . . . . . . . 5
3.1.4. Header set . . . . . . . . . . . . . . . . . . . . . . 6 3.1.4. Header set . . . . . . . . . . . . . . . . . . . . . . 6
3.1.5. Header Representation . . . . . . . . . . . . . . . . 6 3.1.5. Header Representation . . . . . . . . . . . . . . . . 6
3.1.6. Header Emission . . . . . . . . . . . . . . . . . . . 6 3.1.6. Header Emission . . . . . . . . . . . . . . . . . . . 6
3.2. Header Set Processing . . . . . . . . . . . . . . . . . . 7 3.2. Header Set Processing . . . . . . . . . . . . . . . . . . 7
3.2.1. Header Representation Processing . . . . . . . . . . . 7 3.2.1. Header Representation Processing . . . . . . . . . . . 7
3.2.2. Reference Set Emission . . . . . . . . . . . . . . . . 8 3.2.2. Reference Set Emission . . . . . . . . . . . . . . . . 7
3.2.3. Header Set Completion . . . . . . . . . . . . . . . . 8 3.2.3. Header Set Completion . . . . . . . . . . . . . . . . 8
3.2.4. Header Table Management . . . . . . . . . . . . . . . 8 3.2.4. Header Table Management . . . . . . . . . . . . . . . 8
3.2.5. Specific Use Cases . . . . . . . . . . . . . . . . . . 8 4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 8
4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Low-level representations . . . . . . . . . . . . . . . . 8
4.1. Low-level representations . . . . . . . . . . . . . . . . 9 4.1.1. Integer representation . . . . . . . . . . . . . . . . 8
4.1.1. Integer representation . . . . . . . . . . . . . . . . 9 4.1.2. Header Name Representation . . . . . . . . . . . . . . 10
4.1.2. Header Name Representation . . . . . . . . . . . . . . 11
4.1.3. Header Value Representation . . . . . . . . . . . . . 11 4.1.3. Header Value Representation . . . . . . . . . . . . . 11
4.2. Indexed Header Representation . . . . . . . . . . . . . . 11 4.2. Indexed Header Representation . . . . . . . . . . . . . . 11
4.3. Literal Header Representation . . . . . . . . . . . . . . 12 4.3. Literal Header Representation . . . . . . . . . . . . . . 11
4.3.1. Literal Header without Indexing . . . . . . . . . . . 12 4.3.1. Literal Header without Indexing . . . . . . . . . . . 11
4.3.2. Literal Header with Incremental Indexing . . . . . . . 13 4.3.2. Literal Header with Incremental Indexing . . . . . . . 12
4.3.3. Literal Header with Substitution Indexing . . . . . . 14 4.3.3. Literal Header with Substitution Indexing . . . . . . 13
5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 15 5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication . . . . . . . . . . . . . . . . . . . . . 16 publication . . . . . . . . . . . . . . . . . . . . . 17
A.1. Since draft-ietf-httpbis-header-compression-01 . . . . . . 16 A.1. Since draft-ietf-httpbis-header-compression-01 . . . . . . 17
Appendix B. Initial Header Tables . . . . . . . . . . . . . . . . 17 A.2. Since draft-ietf-httpbis-header-compression-01 . . . . . . 17
B.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Initial Header Tables . . . . . . . . . . . . . . . . 18
B.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 18 B.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix C. Example . . . . . . . . . . . . . . . . . . . . . . . 19 B.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 19
C.1. First header set . . . . . . . . . . . . . . . . . . . . . 19 Appendix C. Example . . . . . . . . . . . . . . . . . . . . . . . 20
C.2. Second header set . . . . . . . . . . . . . . . . . . . . 21 C.1. First header set . . . . . . . . . . . . . . . . . . . . . 20
C.2. Second header set . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document describes HPACK, a format adapted to efficiently This document describes HPACK, a format adapted to efficiently
represent 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, headers are sent without any form of compression. As
the protocol, are transmitted with no transformations. web pages have grown to include dozens to hundreds of requests, the
Unfortunately, the amount of redundancy in both the keys and the redundant headers in these requests now pose a problem of measurable
values of these headers is high, and is the cause of increased latency and unnecessary bandwidth. 1 [PERF1] 2 [PERF2]
latency on lower bandwidth links. This indicates that an alternate
more compact encoding for headers would be beneficial to latency, and
that is what is proposed here.
As shown by SPDY [SPDY], Deflate compresses HTTP very effectively. SPDY [SPDY] initially addressed this redundancy by compressing
However, the use of a compression scheme which allows for arbitrary headers with Deflate, which proved very effective at eliminating the
matches against the previously encoded data (such as Deflate) exposes redundant headers. However, that aproach exposed a security risk as
users to security issues. In particular, the compression of demonstrated by the CRIME [CRIME].
sensitive data, together with other data controlled by an attacker,
may lead to leakage of that sensitive data, even when the resultant
bytes are transmitted over an encrypted channel.
Another consideration is that processing and memory costs of a In this document, we propose a new header compressor which eliminates
compressor such as Deflate may also be too high for some classes of the redundant headers, is not vulnerable to the CRIME style attack,
devices, for example when doing forward or reverse proxying. and which also has a bounded memory cost for use in small constrained
environments.
2.1. Outline 2.1. Outline
The HTTP header encoding described in this document is based on a The HTTP header encoding described in this document is based on a
header table that map (name, value) pairs to index values. This header table that map (name, value) pairs to index values. Header
scheme is believed to be safe for all known attacks against the tables are incrementally updated during the HTTP/2.0 session.
compression context today. Header tables are incrementally updated
during the HTTP/2.0 session.
The encoder is responsible for deciding which headers to insert as The encoder is responsible for deciding which headers to insert as
new entries in the header table. The decoder then does exactly what new entries in the header table. The decoder then does exactly what
the encoder prescribes, ending in a state that exactly matches the the encoder prescribes, ending in a state that exactly matches the
encoder's state. This enables decoders to remain simple and encoder's state. This enables decoders to remain simple and
understand a wide variety of encoders. understand a wide variety of encoders.
As two consecutive sets of headers often have headers in common, each As two consecutive sets of headers often have headers in common, each
set of headers is coded as a difference from the previous set of set of headers is coded as a difference from the previous set of
headers. The goal is to only encode the changes (headers present in headers. The goal is to only encode the changes (headers present in
skipping to change at page 4, line 29 skipping to change at page 4, line 22
Header Set: A header set (see Section 3.1.4) is a group 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 that are encoded jointly. A complete set of key-value pairs as
encoded in an HTTP request or response is a header set. encoded in an HTTP request or response is a header set.
Header Representation: A header can be represented in encoded form Header Representation: A header can be represented in encoded form
either as a literal or as an index (see Section 3.1.5). The either as a literal or as an index (see Section 3.1.5). The
indexed representation is based on the header table. indexed representation is based on the header table.
Header Emission: When decoding a set of headers, some operations Header Emission: When decoding a set of headers, some operations
emit a header (see Section 3.1.6). An emitted header is added to 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 that form the HTTP request or response. Once
the set of headers. emitted, a header can't be removed from the set of headers.
3.1.1. Encoding Context 3.1.1. Encoding Context
The set of components used to encode or decode a header set form an 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 encoding context: an encoding context contains a header table and a
reference set. reference set.
Using HTTP, messages are exchanged between a client and a server in Using HTTP, messages are exchanged between a client and a server in
both direction. To keep the encoding of headers in each direction both direction. To keep the encoding of headers in each direction
independent from the other direction, there is one encoding context independent from the other direction, there is one encoding context
skipping to change at page 5, line 5 skipping to change at page 4, line 46
The headers contained in a PUSH_PROMISE frame sent by a server to a 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 client are encoded within the same context as the headers contained
in the HEADERS frame corresponding to a response sent from the server in the HEADERS frame corresponding to a response sent from the server
to the client. to the client.
3.1.2. Header Table 3.1.2. Header Table
A header table consists of an ordered list of (name, value) pairs. A header table consists of an ordered list of (name, value) pairs.
The first entry of a header table is assigned the index 0. 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 A header can be represented by an entry from the header table.
match. A header and an entry match if both their name and their Rather than encoding a literal value for the header field name and
value match. A header name and an entry name match if they are equal value, the encoder can select an entry from the header table.
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. Literal header names MUST be translated to lowercase before encoding
However, implementations MUST be prepared to accept duplicates and transmission. This enables an encoder to perform direct bitwise
without signalling an error. comparisons on names and values when determining if an entry already
exists in the header table.
There is no need for the header table to contain duplicate entries.
However, duplicate entries MUST NOT be treated as an error by a
decoder.
Initially, a header table contains a list of common headers. Two Initially, a header table contains a list of common headers. Two
initial lists of header are provided in Appendix B. One list is for 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 headers transmitted from a client to a server, the other for the
reverse direction. reverse direction.
A header table is modified by either adding a new entry at the end of A header table is modified by either adding a new entry at the end of
the table, or by replacing an existing entry. the table, or by replacing an existing entry.
The encoder decides how to update the header table and as such can The encoder decides how to update the header table and as such can
control how much memory is used by the header table. To limit the control how much memory is used by the header table. To limit the
memory requirements on the decoder side, the header table size is memory requirements on the decoder side, the header table size is
bounded (see the SETTINGS_MAX_BUFFER_SIZE in Section 5). bounded (see the SETTINGS_HEADER_TABLE_SIZE in Section 5).
The size of an entry is the sum of its name's length in bytes (as 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 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 (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 the entry structure overhead. For example, an entry structure using
two 64-bits pointers to reference the name and the value and the 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 entry, and two 64-bits integer for counting the number of references
to these name and value would use 32 bytes. to these name and value would use 32 bytes.
The size of a header table is the sum of the size of its entries. The size of a header table is the sum of the size of its entries.
skipping to change at page 8, line 26 skipping to change at page 8, line 16
Once all of the header representations have been processed, and the Once all of the header representations have been processed, and the
remaining items in the reference set have been emitted, the header remaining items in the reference set have been emitted, the header
set is complete. set is complete.
3.2.4. Header Table Management 3.2.4. Header Table Management
The header table can be modified by either adding a new entry to it The header table can be modified by either adding a new entry to it
or by replacing an existing one. Before doing such a modification, 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 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 or equal to the SETTINGS_HEADER_TABLE_SIZE limit (see Section 5). To
achieve this, repeatedly, the first entry of the header table is achieve this, repeatedly, the first entry of the header table is
removed, until enough space is available for the modification. removed, until enough space is available for the modification.
A consequence of removing one or more entries at the beginning of the A consequence of removing one or more entries at the beginning of the
header table is that the remaining entries are renumbered. The first header table is that the remaining entries are renumbered. The first
entry of the header table is always associated to the index 0. entry of the header table is always associated to the index 0.
When the modification of the header table is the replacement of an When the modification of the header table is the replacement of an
existing entry, the replaced entry is the one indicated in the existing entry, the replaced entry is the one indicated in the
literal representation before any entry is removed from the header literal representation before any entry is removed from the header
table. If the entry to be replaced is removed from the header table table. If the entry to be replaced is removed from the header table
when performing the size adjustment, the replacement entry is when performing the size adjustment, the replacement entry is
inserted at the beginning of the header table. inserted at the beginning of the header table.
The addition of a new entry with a size greater than the The addition of a new entry with a size greater than the
SETTINGS_MAX_BUFFER_SIZE limit causes all the entries from the header SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the
table to be dropped and the new entry not to be added to the header header table to be dropped and the new entry not to be added to the
table. The replacement of an existing entry with a new entry with a header table. The replacement of an existing entry with a new entry
size greater than the SETTINGS_MAX_BUFFER_SIZE has the same with a size greater than the SETTINGS_HEADER_TABLE_SIZE has the same
consequences. consequences.
3.2.5. Specific Use Cases
Three occurrences of the same indexed representation, corresponding
to an entry not present in the reference set, emit the associated
header twice:
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. Detailed Format
4.1. Low-level representations 4.1. Low-level representations
4.1.1. Integer representation 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. To allow for optimized processing, an integer lengths. To allow for optimized processing, an integer
representation always finishes at the end of a byte. representation always finishes at the end of a byte.
skipping to change at page 9, line 46 skipping to change at page 9, line 16
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:
If I < 2^N - 1, encode I on N bits If I < 2^N - 1, encode I on N bits
Else Else
encode 2^N - 1 on N bits encode 2^N - 1 on N bits
I = I - (2^N - 1)
While I >= 128 While I >= 128
Encode (I % 128 + 128) on 8 bits Encode (I % 128 + 128) on 8 bits
I = I / 128 I = I / 128
encode (I) on 8 bits encode (I) on 8 bits
4.1.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
skipping to change at page 11, line 47 skipping to change at page 11, line 21
storage required to store the text, represented as a variable- storage required to store the text, represented as a variable-
length-quantity (Section 4.1.1). length-quantity (Section 4.1.1).
2. The specific sequence of octets representing the UTF-8 text. 2. The specific sequence of octets representing the UTF-8 text.
Invalid UTF-8 octet sequences, "over-long" UTF-8 encodings, and UTF-8 Invalid UTF-8 octet sequences, "over-long" UTF-8 encodings, and UTF-8
octets that represent invalid Unicode Codepoints MUST NOT be used. octets that represent invalid Unicode Codepoints MUST NOT be used.
4.2. Indexed Header Representation 4.2. Indexed Header Representation
An indexed header representation identifies an entry in the header
table. The entry is emitted and added to the reference set if it is
not currently in the reference set. The entry is removed from the
reference set if it is present in the reference set.
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.3. Literal Header Representation 4.3. Literal Header Representation
Literal header representations contain a literal header field value.
Header field names are either provided as a literal or by reference
to an existing header table entry.
Literal representations all result in the emission of a header when
decoded.
4.3.1. Literal Header without Indexing 4.3.1. Literal Header without Indexing
An literal header without indexing causes the emission of a header
without altering the header table.
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) |
+-------------------------------+ +-------------------------------+
Literal Header without Indexing - Indexed Name Literal Header without Indexing - Indexed Name
skipping to change at page 12, line 39 skipping to change at page 12, line 31
+-------------------------------+ +-------------------------------+
| Name String (Length octets) | | Name String (Length octets) |
+-------------------------------+ +-------------------------------+
| Value Length (8+) | | Value Length (8+) |
+-------------------------------+ +-------------------------------+
| Value String (Length octets) | | Value String (Length octets) |
+-------------------------------+ +-------------------------------+
Literal Header without Indexing - New Name Literal Header without Indexing - New Name
This representation, which does not involve updating the header This representation 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 (Section 4.1.2). represented on 5 bits followed by the header name (Section 4.1.2).
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.1.3. represented as a literal string as described in Section 4.1.3.
4.3.2. Literal Header with Incremental Indexing 4.3.2. Literal Header with Incremental Indexing
A literal header with incremental indexing adds a new entry to the
header table.
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 - Literal Header with Incremental Indexing -
skipping to change at page 14, line 7 skipping to change at page 13, line 48
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 (Section 4.1.2). represented on 5 bits followed by the header name (Section 4.1.2).
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.1.3. represented as a literal string as described in Section 4.1.3.
4.3.3. Literal Header with Substitution Indexing 4.3.3. Literal Header with Substitution Indexing
A literal header with substitution indexing replaces an existing
header table entry.
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) |
+-------------------------------+ +-------------------------------+
skipping to change at page 14, line 44 skipping to change at page 14, line 42
+-------------------------------+ +-------------------------------+
Literal Header with Substitution Indexing - Literal Header with Substitution Indexing -
New Name 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 63, 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 (Section 4.1.2). represented on 6 bits followed by the header name (Section 4.1.2).
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
skipping to change at page 15, line 21 skipping to change at page 15, line 18
string as described in Section 4.1.3. string as described in Section 4.1.3.
5. Parameter Negotiation 5. Parameter Negotiation
A few parameters can be used to accommodate client and server A few parameters can be used to accommodate client and server
processing and memory requirements. [[anchor3: These settings are processing and memory requirements. [[anchor3: These settings are
currently not supported as they have not been integrated in the main 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_HEADER_TABLE_SIZE (TBD): Allows the sender to inform the
endpoint of the maximum size it accepts for the header table. remote endpoint of the maximum size it accepts for the header
table.
The default value is 4096 bytes. The default value is 4096 bytes.
[[anchor4: Is this default value OK? Do we need a maximum size? [[anchor4: Is this default value OK? Do we need a maximum size?
Do we 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_HEADER_TABLE_SIZE setting with a value smaller than the
currently in use, it MUST send as soon as possible a HEADER frame one currently in use, it MUST send as soon as possible a HEADER
with a stream identifier of 0x0 containing a value smaller than or frame with a stream identifier of 0x0 containing a value smaller
equal to the received setting value. than or equal to the received setting value.
[[anchor5: This changes slightly the behaviour of the HEADERS [[anchor5: This changes slightly the behaviour of the HEADERS
frame, which 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
skipping to change at page 16, line 26 skipping to change at page 16, line 24
by considering overhead in the state size calculation. Implementors by considering overhead in the state size calculation. Implementors
must still be careful in the creation of APIs to an implementation of must still be careful in the creation of APIs to an implementation of
this compressor by ensuring that header keys and values are either this compressor by ensuring that header keys and values are either
emitted as a stream, or that the compression implementation have a emitted as a stream, or that the compression implementation have a
limit on the maximum size of a key or value. Failure to implement 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 these kinds of safeguards may still result in a scenario where the
local endpoint exhausts its memory. local endpoint exhausts its memory.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This document registers the SETTINGS_HEADER_TABLE_SIZE setting in the
"HTTP/2.0 Settings" registry established by [HTTP2]. The assigned
code for this setting is TBD.
8. Informative References 8. References
[SPDY] Belshe, M. and R. Peon, "SPDY Protocol", February 2012, 8.1. Normative References
<http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy>.
[HTTP2] Belshe, M., Peon, R., Thomson, M., and A. Melnikov,
"Hypertext Transfer Protocol version 2.0",
draft-ietf-httpbis-http2-06 (work in progress),
February 2013.
8.2. Informative References
[CRIME] Rizzo, J. and T. Duong, "The Crime Attack", September 2012,
<https://docs.google.com/a/twist.com/presentation/d/
11eBmGiHbYcHR9gL5nDyZChu_-lCa2GizeuOfaLU2HOU/
edit#slide=id.g1eb6c1b5_3_6>.
[PERF1] Belshe, M., "IETF83: SPDY and What to Consider for
HTTP/2.0", March 2012, <http://www.ietf.org/proceedings/83/
slides/slides-83-httpbis-3>.
[PERF2] McManus, P., "SPDY What I Like About You", September 2011, <
http://bitsup.blogspot.com/2011/09/
spdy-what-i-like-about-you.html>.
[SPDY] Belshe, M. and R. Peon, "SPDY Protocol", February 2012,
<http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy>.
URIs
[1] <http://en.wikipedia.org/wiki/Variable-length_quantity> [1] <http://en.wikipedia.org/wiki/Variable-length_quantity>
Appendix A. Change Log (to be removed by RFC Editor before publication Appendix A. Change Log (to be removed by RFC Editor before publication
A.1. Since draft-ietf-httpbis-header-compression-01 A.1. Since draft-ietf-httpbis-header-compression-01
o Refactored of Header Encoding Section: split definitions and o Refactored of Header Encoding Section: split definitions and
processing rule. processing rule.
skipping to change at page 17, line 13 skipping to change at page 17, line 37
o Added example of 32 bytes entry structure (issue #191). o Added example of 32 bytes entry structure (issue #191).
o Added Header Set Completion section. Reflowed some text. o Added Header Set Completion section. Reflowed some text.
Clarified some writing which was akward. Added text about Clarified some writing which was akward. Added text about
duplicate header entry encoding. Clarified some language w.r.t duplicate header entry encoding. Clarified some language w.r.t
Header Set. Changed x-my-header to mynewheader. Added text in the Header Set. Changed x-my-header to mynewheader. Added text in the
HeaderEmission section indicating that the application may also be HeaderEmission section indicating that the application may also be
able to free up memory more quickly. Added information in able to free up memory more quickly. Added information in
Security Considerations section. Security Considerations section.
A.2. Since draft-ietf-httpbis-header-compression-01
Fixed bug/omission in integer representation algorithm.
Changed the document title.
Header matching text rewritten.
Changed the definition of header emission.
Changed the name of the setting which dictates how much memory the
compression context should use.
Removed "specific use cases" section
Corrected erroneous statement about what index can be contained in
one byte
Added descriptions of opcodes
Removed security claims from introduction.
Appendix B. Initial Header Tables Appendix B. Initial Header Tables
[[anchor9: The tables in this section should be updated based on [[anchor11: The tables in this section should be updated based on
statistical analysis of header names frequency and specific HTTP 2.0 statistical analysis of header names frequency and specific HTTP 2.0
header rules (like removal of some headers).]] header rules (like removal of some headers).]]
[[anchor10: These tables are not adapted for headers contained in [[anchor12: These tables are not adapted for headers contained in
PUSH_PROMISE frames. Either the tables can be merged, or the table PUSH_PROMISE frames. Either the tables can be merged, or the table
for responses can be updated.]] for responses can be updated.]]
B.1. Requests 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.
+-------+---------------------+--------------+ +-------+---------------------+--------------+
skipping to change at page 19, line 45 skipping to change at page 20, line 45
| 27 | strict-transport-security | | | 27 | strict-transport-security | |
| 28 | transfer-encoding | | | 28 | transfer-encoding | |
| 29 | www-authenticate | | | 29 | www-authenticate | |
+-------+-----------------------------+--------------+ +-------+-----------------------------+--------------+
Table 2: Initial Header Table for Responses Table 2: Initial Header Table for Responses
Appendix C. Example 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. [[anchor13: This section needs to be updated to tables are updated. [[anchor15: This section needs to be updated to
better reflect the new processing of header fields, and include more better reflect the new processing of header fields, and include more
examples.]] examples.]]
C.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
mynewheader: first mynewheader: first
 End of changes. 37 change blocks. 
103 lines changed or deleted 146 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/