Network Working Group H. Ruellan Internet-Draft J. Fujisawa Expires: September 12, 2013 Canon, Inc. R. Bellessort Y. Fablet March 11, 2013 Header Diff: A compact HTTP header representation for HTTP/2.0 draft-ruellan-headerdiff-00 Abstract This document describes a format adapted to efficiently represent HTTP headers in the context of HTTP/2.0. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 12, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Ruellan, et al. Expires September 12, 2013 [Page 1] Documentation HTTP Header Diff March 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Design Principles . . . . . . . . . . . . . . . . . . . . 3 2.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Integration within HTTP/2.0 . . . . . . . . . . . . . . . 4 2.3.1. Deflate Usage . . . . . . . . . . . . . . . . . . . . 5 3. Indexing Strategies . . . . . . . . . . . . . . . . . . . . . 5 3.1. Indexing Tables . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Header Table . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Name Table . . . . . . . . . . . . . . . . . . . . . 6 3.2. Header Representation . . . . . . . . . . . . . . . . . . 7 3.2.1. Literal Representation . . . . . . . . . . . . . . . 7 3.2.2. Indexed Representation . . . . . . . . . . . . . . . 7 3.2.3. Delta Representation . . . . . . . . . . . . . . . . 7 4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Low-level representations . . . . . . . . . . . . . . . . 8 4.1.1. Integer representation . . . . . . . . . . . . . . . 8 4.1.2. String literal representation . . . . . . . . . . . . 10 4.2. Indexed Header Representation . . . . . . . . . . . . . . 10 4.2.1. Short Indexed Header . . . . . . . . . . . . . . . . 10 4.2.2. Long Indexed Header . . . . . . . . . . . . . . . . . 11 4.3. Literal Header Representation . . . . . . . . . . . . . . 11 4.3.1. Literal Header without Indexing . . . . . . . . . . . 11 4.3.2. Literal Header with Indexing . . . . . . . . . . . . 12 4.4. Delta Header Representation . . . . . . . . . . . . . . . 12 4.4.1. Delta Header without Indexing . . . . . . . . . . . . 12 4.4.2. Delta Header with Indexing . . . . . . . . . . . . . 13 5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 13 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Typed Codecs . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Specific header processing . . . . . . . . . . . . . . . 14 6.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 15 6.4. Deflate Partial Usage . . . . . . . . . . . . . . . . . . 15 6.5. Max length and entry numbers . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Initial header names . . . . . . . . . . . . . . . . 16 A.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 18 A.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.3.1. First header set . . . . . . . . . . . . . . . . . . 19 A.3.2. Second header set . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Ruellan, et al. Expires September 12, 2013 [Page 2] Documentation HTTP Header Diff March 2013 1. Introduction This document describes a format adapted to efficiently represent HTTP headers in the context of HTTP/2.0. 2. Overview 2.1. Design Principles HTTP headers can be represented in various ways. As shown by SPDY, Deflate compresses very well HTTP headers. But the use of Deflate has been found to cause security issues. In particular, the compression of sensitive data, together with other data controlled by an attacker, may lead to leakage of the sensitive data. The processing and memory costs may also be too high for some classes of devices. Having a lightweight compact HTTP header representation is therefore useful. To design this representation, the focus was put on the following points: o Simplicity: the representation should have a small number of options that allow handling any kind of headers; in particular, the use of dedicated codecs for each type of header value is not considered here. o Efficiency: the representation should provide good compression at a small encoding/decoding cost for both processing and memory. o Flexibility: the representation should be compatible with constrained devices, but also provide improved efficiency when more capable devices are used. o Deflate-friendly: Deflate has proven its efficiency for encoding HTTP headers. A good HTTP header representation should be efficient as a pre-compression step prior to applying Deflate. 2.2. Outline The HTTP header representation described in this document is based on indexing tables that store (name,value) pairs, called header tables in the remainder of this document. Header tables are incrementally updated during the whole HTTP/2.0 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 (name,value) pairs in the header table. The decoder follows exactly Ruellan, et al. Expires September 12, 2013 [Page 3] Documentation HTTP Header Diff March 2013 what the encoder prescribes. This enables decoders to remain simple and understand a wide variety of encoders. A header may be represented as a literal, an index or a delta. If represented as a literal or a delta, the representation specifies whether this header is used to update the indexing table. The different representations are described in Section 3.2. To improve literal headers representation compactness, header names are indexed in a specific name table. Two independent name tables are used during a HTTP/2.0 session, one for HTTP request headers and another for HTTP response headers. An example illustrating the use of the different tables to represent headers is available in Appendix A.3. Once a set of header is represented using the available representations, it can optionally be compressed with Deflate. 2.3. Integration within HTTP/2.0 The headers are inserted in the HTTP/2.0 frames at the same place as defined in SPDY (next chart was adapted from draft-ietf-httpbis- http2-00). +------------------------------------+ |1| version | 1 | +------------------------------------+ | Flags (8) | Length (24 bits) | +------------------------------------+ |X| Stream-ID (31bits) | +------------------------------------+ |X| Associated-To-Stream-ID (31bits) | +------------------------------------+ | Pri|Unused | Slot | | +-------------------+ | | Number of Name/Value pairs (int32) | +------------------------------------+ | Encoded name/value pair | <+ +------------------------------------+ | (*) | (repeats) | <+ (*) This section is the "Name/Value Header Block", and may be compressed. The modifications to SPDY are the following: Ruellan, et al. Expires September 12, 2013 [Page 4] Documentation HTTP Header Diff March 2013 o The headers are not represented as string tokens but using one of the possible representation described in Section 4. o The Deflate step is made optional. 2.3.1. Deflate Usage The header representation described in Section 4 is amenable to Deflate compression. The Deflate algorithm improves the compression at the expense of additional processing. At least two potential drawbacks have been identified when using Deflate. First, security issues may arise when using Deflate, like the CRIME attack [1]. Second, it may increase the workload of network intermediaries: they may need to uncompress and recompress the headers of all messages, even though they only need to process a few of them. The use of Deflate may still be envisioned if properly set up. Several approaches are available and should be studied: Restricting Deflate to Huffman-only coding is an option. This is supported by many Deflate implementations such as zlib. It may be used in the environments subject to CRIME attacks. This approach should be compared to the direct use of hand-tailored Huffman coding. The use of indexing mechanisms prior Deflate may solve some security issues. More precise analysis of the security impact of using indexing mechanisms prior Deflate should be studied as described in Section 6.3. Partial use of Deflate on a selected subset of headers may also be an option as described in Section 6.4. Restricting the use of Deflate to safe cases, such as controlled environments (widgets, native applications), anonymous connections and so on can be envisioned. For instance, restricting the use of Deflate to HTTP response headers should not enable CRIME-like attacks. 3. Indexing Strategies Ruellan, et al. Expires September 12, 2013 [Page 5] Documentation HTTP Header Diff March 2013 3.1. Indexing Tables 3.1.1. Header Table A header table consists in an ordered list of (name, value) pairs. Once a header pair is inserted in the header table, its index does not change until the pair gets removed. A pair is either inserted at the end of the table or replaces an existing pair depending on the chosen representation. Header names should be represented as lower-case strings. A header name is matching with a pair name if they are equal using a character-based, _case insensitive_ comparison. A header value is matching with a pair value if they are equal using a character-based, _case sensitive_ comparison. A header is matching with a (name,value) pair if both name and value are matching. The header table is progressively updated based on headers represented as literal (as defined in Section 3.2.1) or delta (as defined in Section 3.2.3). Two update mechanisms are defined: o Incremental indexing: the represented header is inserted at the end of the header table as a (name, value) pair. The inserted 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 an existing (name,value) pair. The existing pair value is replaced by the header value. Incremental and substitution indexing are optional. If none of them is selected in a header representation, the header table is not 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 requirements. The header table size is defined as the sum of the length (as defined in Section 4.1.2) of the values of all header table pairs. Header names are not counted in the header table size. 3.1.2. Name Table A name table is an ordered list of name entries that is used to efficiently represent header names. A header name is matching a name table entry if they are equal using a character-based, _case insensitive_ comparison. Ruellan, et al. Expires September 12, 2013 [Page 6] Documentation HTTP Header Diff March 2013 If a header name is matching a name table entry, it is represented as an integer based on the index of the entry, as described in Section 4.1.1. If a header name is not matching any of the name table entry, it is represented as a string, as described in Section 4.1.2. A new entry containing the name is then inserted at the end of the name table. Once inserted in the name table, a header name is never removed and its index is never changing. To optimize the representation of the headers exchanged at the beginning of the HTTP/2.0 session, the header name table is initally populated with common header names. The initial header names list is provided in Appendix A. 3.2. Header Representation 3.2.1. Literal Representation The literal representation defines a header independentently of the header table. A literal header is represented as: o A header name, represented using the name table, as described in Section 3.1.2. o The header value, represented as a literal string, as described in Section 4.1.2. 3.2.2. Indexed Representation The indexed representation defines a header as a match to a (name,value) pair in the header table. An indexed header is represented as: o An integer representing the index of the matching (name,value) pair, as described in Section 4.1.1. 3.2.3. Delta Representation The delta representation defines a header as a reference to a (name,value) pair contained in the header table. The names must match between the represented header and the reference pair. The values should start by a common substring between the represented header and the reference pair. A delta header is represented as: o An integer representing the index of the reference (name, value) pair, as described in Section 4.1.1. The pair name must match the name of the header. Ruellan, et al. Expires September 12, 2013 [Page 7] Documentation HTTP Header Diff March 2013 o An integer representing the length of the common prefix shared between the header value and the pair value, as described in Section 4.1.1. o A string representing the suffix value to append to the common prefix to obtain the header value, as defined in Section 4.1.2. 4. Detailed Format 4.1. Low-level representations 4.1.1. Integer representation Integers are used to represent name indexes, pair indexes or string lengths. The integer representation keeps byte-alignment as much as 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. 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 integer value does not fit in the prefix. The number of bits of the prefix (called N) is a parameter of the integer representation. 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 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 [2] representation. The algorithm to represent an integer I is as follows: 1. If I < 2^N - 1, encode I on N bits 2. Else, encode 2^N - 1 on N bits and do the following steps: 3. 1. Set I to (I - 2^N - 1) and Q to 1 2. While Q > 0 3. 1. Compute Q and R, quotient and remainder of I divided by 2^7 Ruellan, et al. Expires September 12, 2013 [Page 8] Documentation HTTP Header Diff March 2013 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.1.1.1. Example 1: Encoding 10 using a 5-bit prefix The value 10 is to be encoded with a 5-bit prefix. o 10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit prefix. +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-----+-----+-----+-----+-----+-----+-----+-----+ | X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits +-----+-----+-----+-----+-----+-----+-----+-----+ 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. o 1337 is greater than 31 (= 2^5 - 1). o * The 5-bit prefix is filled with its max value (31). o The value to represent on next bytes is I = 1337 - 2^5 = 1305. o * 1305 = 128*10 + 25, i.e. Q=10 and R=25. * Q is greater than 1, bit 8 is set to 1. * The remainder R=25 is encoded on next 7 bits. * I is replaced by the quotient Q=10. o The value to represent on next bytes is I = 10. o * 10 = 128*0 + 10, i.e. Q=0 and R=10. Ruellan, et al. Expires September 12, 2013 [Page 9] Documentation HTTP Header Diff March 2013 * Q is equal to 0, bit 16 is set to 0. * The remainder R=10 is encoded on next 7 bits. * I is replaced by the quotient Q=0. o The process ends. +----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-----+-----+-----+-----+-----+-----+-----+-----+ | X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | Q>=1, R=25 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | Q=0 , R=10 +-----+-----+-----+-----+-----+-----+-----+-----+ 4.1.2. String literal representation Literal strings can represent header names, header values or header values suffix in the case of delta coding. They are encoded in two parts: 1. The string length, defined as the number of bytes needed to store its UTF-8 representation, is represented as an integer with a zero bits prefix. If the string length is strictly less than 128, it is represented as one byte. 2. The string value represented as a list of UTF-8 characters. 4.2. Indexed Header Representation Indexed headers can be represented as short indexed header if the matching pair index is strictly below 64. Otherwise it is represented as a long indexed header. 4.2.1. Short Indexed Header +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-------+-------+-------+-------+-------+-------+-------+-------+ | 1 | 0 | 00 0000 - 11 1111 | | | | Matching pair index | | | | (if strictly lower than 64) | +-------+-------+-------+-------+-------+-------+-------+-------+ Ruellan, et al. Expires September 12, 2013 [Page 10] Documentation HTTP Header Diff March 2013 This representation starts with the '10' 2-bit pattern, followed by the index of the matching pair, represented on 6 bits. A short indexed header is always coded in one byte. 4.2.2. Long Indexed Header +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 2 | 3 | ... | ... | e | f | +-------+-------+-------+-------+-------+-------+-------+-------+ | 1 | 1 | 00 0000 0000 0000 - 11 1111 1111 1111 1111 | | | | Matching pair index | | | | (if equal to or greater than 64) | +-------+-------+-------+-------+-------+-------+-------+-------+ This representation starts with the '11' 2-bit pattern, followed by the value of the index of the matching pair minus 64, represented as an integer with a 14-bit prefix A long indexed header is coded in two bytes if the index minus 64 is strictly below 16383. 4.3. Literal Header Representation 4.3.1. Literal Header without Indexing +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-------+-------+-------+-------+-------+-------+-------+-------+ | | | | 0 0000 | | | | | New header name symbol | | 0 | 0 | 0 |---------------------------------------| | | | | 0 0001 - 1 1111 | | | | | Index of matching header name | +-------+-------+-------+-------+-------+-------+-------+-------+ This representation, which does not involve updating the header table, starts with the '000' 3-bit pattern. If the header name matches a header name entry whose index is IN, the value (IN+1) is represented as an integer with a 5-bit prefix. Note that if the index is strictly below 30, one byte is used. 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 literal string. Header name representation is followed by the header value represented as a literal string. Ruellan, et al. Expires September 12, 2013 [Page 11] Documentation HTTP Header Diff March 2013 4.3.2. Literal Header with Indexing +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-------+-------+-------+-------+-------+-------+-------+-------+ | | | | | 0000 | | | | |Indexing| New header name symbol | | 0 | 0 | 1 | |-------------------------------| | | | | Mode | 0001 - 1111 | | | | | | Index of matching header name | +-------+-------+-------+-------+-------+-------+-------+-------+ This representation starts with the '001' 3-bit pattern. The fourth bit sets the indexing mode: 0 for incremental indexing, 1 for substitution indexing. If the header name matches a header name entry whose index is IN, the value (IN+1) is represented as an integer with a 4-bit prefix. Note that if the index is strictly below 14, one byte is used. If the header name does not match a header name entry, the value 0 is represented on 4 bits followed by the header name, represented as a literal string. Header name representation is followed by the header value represented as a string as described in Section 4.1.2. In the case of substitution indexing, the substituted (name,value) pair index is inserted before the header value as a zero-bit prefix integer. The header value is represented as a literal string. 4.4. Delta Header Representation 4.4.1. Delta Header without Indexing +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 0 | 0 0000 - 1 1111 | | | | | Index of reference pair | +-------+-------+-------+-------+-------+-------+-------+-------+ This representation starts with the '010' 3-bit pattern. It continues with the index IR of the reference header pair. The value IR is represented as an integer with a 5-bit prefix. Note that if the index is strictly below 31, one byte is used. Ruellan, et al. Expires September 12, 2013 [Page 12] Documentation HTTP Header Diff March 2013 Index value is followed by: 1. the length of the common prefix shared between the header value and the pair value, represented as an integer with a zero-bit prefix. 2. the header value suffix represented as a literal string. 4.4.2. Delta Header with Indexing +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 1 | 1 |Indexing| 0000 - 1111 | | | | | Mode | Index of reference pair | +-------+-------+-------+-------+-------+-------+-------+-------+ This representation starts with the '011' 3-bit pattern. The fourth bit sets the indexing mode, 0 for incremental indexing and 1 for substitution indexing. It continues with the index IR of the reference header pair. The value IR is represented as an integer with a 4-bit prefix. Note that if the index is strictly below 15, one byte is used. Index value is followed by: 1. the length of the common prefix shared between the header value and the pair value, represented as an integer with a zero-bit prefix. 2. the header value suffix, represented as a literal string. 5. Parameter Negotiation Two parameters may be used to accomodate the client and server processing and memory requirements: o A parameter Nh that configures the size of the header table. The size can be computed as 2^Nh. Nh is exchanged as an unsigned integer. o A parameter Nd that configures the Deflate step. If Nd is equal to zero, no Deflate step is used. Otherwise, Deflate is used with a sliding window equal to 2^Nd. Huffman-only coding is advertised using the Deflate block initial bits. Nd is exchanged as an unsigned integer. Ruellan, et al. Expires September 12, 2013 [Page 13] Documentation HTTP Header Diff March 2013 This section should be further completed, including but not limited to the following points: o Define default values? o Define when negotiation happens: at the beginning only, any time during the session... o Define how are exchanged these parameters, probably using SETTINGS frames, through the definition of 4 settings (outgoing-Nd, outgoing-Nh, preferred-incomingNd, preferred-incoming-Nh). 6. Open Questions 6.1. Typed Codecs Typed codecs may be useful to represent header values, especially on response side. An additional typed header representation could be defined, adding support for a small number of codecs such as: o An Integer codec: may be useful for headers such as 'Age' and 'Content-Length'. o A Date codec: may be useful for headers such as 'Date', 'Expires', 'If-Modified-Since', 'Last-Modified'. 6.2. Specific header processing Some (name,value) pairs may be singled out to improve network nodes processing, such as: o The request line (verb, version and URL) for HTTP requests. o The response line (status and version) for HTTP responses. For those headers, the specification may define specific rules that can improve the processing cost, at the expense of some compression loss: o All those headers are placed as the first headers in the SYN_STREAM frame, with a predefined order. o Verb, version and status are represented as integers with zero-bit prefix. o Indexed, delta or literal representation may be used for URL values. In the case of delta and literal representation, only the substitution mode is used so that a processor only needs to store Ruellan, et al. Expires September 12, 2013 [Page 14] Documentation HTTP Header Diff March 2013 the URL of the previous message to compute the URL of the current message. 6.3. Security Issues Adequate use of delta and indexed representation before using of Deflate are supposed to solve security issues such as the CRIME attack. For instance, if cookie headers are represented as indexed headers as much as possible, attackers may be prevented from progressively learning its value. This point should be confirmed with deeper analysis. Additional study should also be done to evaluate whether the proposed indexed and delta representation create any new security issue. 6.4. Deflate Partial Usage To circumvent Deflate issues related to both security and network intermediaries, the header set of a given message can be split in two buckets. A first bucket would be sent without using Deflate, while the second bucket would be further compressed using Deflate. The decision would be done by the encoder. The specification could define a minimum set of headers that SHOULD never be compressed using Deflate, for instance URLs and cookies. Another possibility would be to define Deflate as a specific representation. The use of Deflate would then be decided on per- header basis. That would enable excluding any header that may contain sensitive data. The overall scheme would be less efficient though (padding bits and so on). Additional analysis of the complexity and benefit of these approaches would be needed to go further. For instance, these approaches should be compared to the use of Deflate restricted to Huffman-coding in terms of simplicity and compression benefits. 6.5. Max length and entry numbers The integer representation allows representation of unbounded values. If bounding the table entries number or string lengths, the integer encoding may be further optimized. o Decide whether to limit the length of strings to a max value and if so which value, 32768? o Decide whether to limit name table entries to 256? o Decide whether to limit header table entries to 16384? Ruellan, et al. Expires September 12, 2013 [Page 15] Documentation HTTP Header Diff March 2013 7. Security Considerations This section should be completed according the previous sections. 8. IANA Considerations This memo includes no request to IANA. 9. References Appendix A. Initial header names A.1. Requests Indexes strictly lower than 14 are always encoded on 1 byte. Hence, the 14 most frequent names should be set in the 14 first positions. This table may be updated based on statistical analysis of header names frequency and specific HTTP 2.0 header rules (like removal of 'proxy-connection', url being split or not...). +---------+------------------------------------+ | Index | Header Name | +---------+------------------------------------+ | 0 | accept | +---------+------------------------------------+ | 1 | accept-charset | +---------+------------------------------------+ | 2 | accept-encoding | +---------+------------------------------------+ | 3 | accept-language | +---------+------------------------------------+ | 4 | cookie | +---------+------------------------------------+ | 5 | method | +---------+------------------------------------+ | 6 | host | +---------+------------------------------------+ | 7 | if-modified-since | +---------+------------------------------------+ | 8 | keep-alive | +---------+------------------------------------+ | 9 | url | +---------+------------------------------------+ | 10 | user-agent | +---------+------------------------------------+ | 11 | version | +---------+------------------------------------+ | 12 | proxy-connection | Ruellan, et al. Expires September 12, 2013 [Page 16] Documentation HTTP Header Diff March 2013 +---------+------------------------------------+ | 13 | referer | +---------+------------------------------------+ | 14 | accept-datetime | +---------+------------------------------------+ | 15 | authorization | +---------+------------------------------------+ | 16 | allow | +---------+------------------------------------+ | 17 | cache-control | +---------+------------------------------------+ | 18 | connection | +---------+------------------------------------+ | 19 | content-length | +---------+------------------------------------+ | 20 | content-md5 | +---------+------------------------------------+ | 21 | content-type | +---------+------------------------------------+ | 22 | date | +---------+------------------------------------+ | 23 | expect | +---------+------------------------------------+ | 24 | from | +---------+------------------------------------+ | 25 | if-match | +---------+------------------------------------+ | 26 | if-none-match | +---------+------------------------------------+ | 27 | if-range | +---------+------------------------------------+ | 28 | if-unmodified-since | +---------+------------------------------------+ | 29 | max-forwards | +---------+------------------------------------+ | 30 | pragma | +---------+------------------------------------+ | 31 | proxy-authorization | +---------+------------------------------------+ | 32 | range | +---------+------------------------------------+ | 33 | te | +---------+------------------------------------+ | 34 | upgrade | +---------+------------------------------------+ | 35 | via | +---------+------------------------------------+ | 36 | warning | Ruellan, et al. Expires September 12, 2013 [Page 17] Documentation HTTP Header Diff March 2013 +---------+------------------------------------+ A.2. Responses Indexes strictly lower than 14 are always encoded on 1 byte. Hence, the 14 most frequent names should be set in the 14 first positions. This table may be updated based on statistical analysis of header names frequency and specific HTTP 2.0 header rules. +---------+------------------------------------+ | Index | Header Name | +---------+------------------------------------+ | 0 | age | +---------+------------------------------------+ | 1 | cache-control | +---------+------------------------------------+ | 2 | content-length | +---------+------------------------------------+ | 3 | content-type | +---------+------------------------------------+ | 4 | date | +---------+------------------------------------+ | 5 | etag | +---------+------------------------------------+ | 6 | expires | +---------+------------------------------------+ | 7 | last-modified | +---------+------------------------------------+ | 8 | server | +---------+------------------------------------+ | 9 | set-cookie | +---------+------------------------------------+ | 10 | status | +---------+------------------------------------+ | 11 | vary | +---------+------------------------------------+ | 12 | version | +---------+------------------------------------+ | 13 | via | +---------+------------------------------------+ | 14 | access-control-allow-origin | +---------+------------------------------------+ | 15 | accept-ranges | +---------+------------------------------------+ | 16 | allow | +---------+------------------------------------+ | 17 | connection | Ruellan, et al. Expires September 12, 2013 [Page 18] Documentation HTTP Header Diff March 2013 +---------+------------------------------------+ | 18 | content-disposition | +---------+------------------------------------+ | 19 | content-encoding | +---------+------------------------------------+ | 20 | content-language | +---------+------------------------------------+ | 21 | content-location | +---------+------------------------------------+ | 22 | content-md5 | +---------+------------------------------------+ | 23 | content-range | +---------+------------------------------------+ | 24 | link | +---------+------------------------------------+ | 25 | location | +---------+------------------------------------+ | 26 | p3p | +---------+------------------------------------+ | 27 | pragma | +---------+------------------------------------+ | 28 | proxy-authenticate | +---------+------------------------------------+ | 29 | refresh | +---------+------------------------------------+ | 30 | retry-after | +---------+------------------------------------+ | 31 | strict-transport-security | +---------+------------------------------------+ | 32 | trailer | +---------+------------------------------------+ | 33 | transfer-encoding | +---------+------------------------------------+ | 34 | warning | +---------+------------------------------------+ | 35 | www-authenticate | +---------+------------------------------------+ A.3. Example Here is an example that illustrates different representations and how tables are updated. A.3.1. First header set The first header set to represent is the following: Ruellan, et al. Expires September 12, 2013 [Page 19] Documentation HTTP Header Diff March 2013 url: http://www.example.org/my-example/index.html user-agent: my-user-agent x-my-header: first The header table is empty, all headers are represented as literal headers with indexing. The 'x-my-header' header name is not in the header name table and is encoded literally. This gives the following representation: 0x2A (literal header with indexing, name index = 9) 0x2C (header value string length = 44) http://www.example.org/my-example/index.html 0x2B (literal header with indexing, name index = 10) 0x0D (header value string length = 43) my-user-agent 0x20 (literal header with indexing, new name) 0x0B (header name string length = 11) x-my-header 0x05 (header value string length = 5) first The header tables are as follow after the processing of these headers: Name table +---------+---------------------------------------------+ | Index | Header Name | +---------+---------------------------------------------+ | 0 | accept | +---------+---------------------------------------------+ | 1 | accept-charset | +---------+---------------------------------------------+ | ... | ... | +---------+---------------------------------------------+ | 36 | warning | +---------+---------------------------------------------+ | 37 | x-my-header | added name +---------+---------------------------------------------+ Header table +----+-------------+------------------------------------+ | 0 | url | http://www.example.org/ | added pair | | | my-example/index.html | +----+-------------+------------------------------------+ | 1 | user-agent | my-user-agent | added pair Ruellan, et al. Expires September 12, 2013 [Page 20] Documentation HTTP Header Diff March 2013 +----+-------------+------------------------------------+ | 2 | x-my-header | first | added pair +----+-------------+------------------------------------+ A.3.2. Second header set The second header set to represent is the following: url: http://www.example.org/my-example/resources/script.js user-agent: my-user-agent x-my-header: second The url header is represented as a delta header with substitution. The user-agent header will be represented as a short header. The x -my-header will be represented as a literal header with indexing. 0x70 (delta header with substitution, header index = 0) 0x22 (common prefix length = 32) 0x13 (suffix value length = 19) resources/script.js 0x81 (indexed header, index = 1) 0x2f 0x17 (literal header with indexing, name index = 37) 0x05 (header value string length = 5) second The name table remains unchanged. The header table is updated as follow: +----+-------------+------------------------------------+ | 0 | url | http://www.example.org/ | substituted | | | my-example/resources/script.js | pair +----+-------------+------------------------------------+ | 1 | user-agent | my-user-agent | +----+-------------+------------------------------------+ | 2 | x-my-header | first | +----+-------------+------------------------------------+ | 3 | x-my-header | second | added pair +----+-------------+------------------------------------+ Ruellan, et al. Expires September 12, 2013 [Page 21] Documentation HTTP Header Diff March 2013 Authors' Addresses Herve Ruellan Email: herve.ruellan@crf.canon.fr Jun Fujisawa Canon, Inc. 3-30-2 Shimomaruko Ohta-ku, Tokyo 146-8501 Japan Email: fujisawa.jun@canon.co.jp Romain Bellessort Email: romain.bellessort@crf.canon.fr Youenn Fablet Email: youenn.fablet@crf.canon.fr Ruellan, et al. Expires September 12, 2013 [Page 22]