idnits 2.17.1 draft-ietf-httpbis-header-compression-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 187: '...ral header names MUST be translated to...' RFC 2119 keyword, line 193: '...uplicate entries MUST NOT be treated a...' RFC 2119 keyword, line 289: '... set, a decoder MUST obey the followi...' RFC 2119 keyword, line 448: '... ASCII characters that MUST conform to...' RFC 2119 keyword, line 477: '...d Unicode Codepoints MUST NOT be used....' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2013) is 3894 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Peon 3 Internet-Draft Google, Inc 4 Intended status: Informational H. Ruellan 5 Expires: February 28, 2014 Canon CRF 6 August 27, 2013 8 HPACK - Header Compression for HTTP/2.0 9 draft-ietf-httpbis-header-compression-03 11 Abstract 13 This document describes HPACK, a format adapted to efficiently 14 represent HTTP headers in the context of HTTP/2.0. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on February 28, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Header Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Encoding Concepts . . . . . . . . . . . . . . . . . . . . 3 55 3.1.1. Encoding Context . . . . . . . . . . . . . . . . . . . 4 56 3.1.2. Header Table . . . . . . . . . . . . . . . . . . . . . 4 57 3.1.3. Reference Set . . . . . . . . . . . . . . . . . . . . 5 58 3.1.4. Header set . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1.5. Header Representation . . . . . . . . . . . . . . . . 6 60 3.1.6. Header Emission . . . . . . . . . . . . . . . . . . . 6 61 3.2. Header Set Processing . . . . . . . . . . . . . . . . . . 7 62 3.2.1. Header Representation Processing . . . . . . . . . . . 7 63 3.2.2. Reference Set Emission . . . . . . . . . . . . . . . . 7 64 3.2.3. Header Set Completion . . . . . . . . . . . . . . . . 8 65 3.2.4. Header Table Management . . . . . . . . . . . . . . . 8 66 4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Low-level representations . . . . . . . . . . . . . . . . 8 68 4.1.1. Integer representation . . . . . . . . . . . . . . . . 8 69 4.1.2. Header Name Representation . . . . . . . . . . . . . . 10 70 4.1.3. Header Value Representation . . . . . . . . . . . . . 11 71 4.2. Indexed Header Representation . . . . . . . . . . . . . . 11 72 4.3. Literal Header Representation . . . . . . . . . . . . . . 11 73 4.3.1. Literal Header without Indexing . . . . . . . . . . . 11 74 4.3.2. Literal Header with Incremental Indexing . . . . . . . 12 75 4.3.3. Literal Header with Substitution Indexing . . . . . . 13 76 5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 15 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 82 Appendix A. Change Log (to be removed by RFC Editor before 83 publication . . . . . . . . . . . . . . . . . . . . . 17 84 A.1. Since draft-ietf-httpbis-header-compression-01 . . . . . . 17 85 A.2. Since draft-ietf-httpbis-header-compression-01 . . . . . . 17 86 Appendix B. Initial Header Tables . . . . . . . . . . . . . . . . 18 87 B.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 B.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 19 89 Appendix C. Example . . . . . . . . . . . . . . . . . . . . . . . 20 90 C.1. First header set . . . . . . . . . . . . . . . . . . . . . 20 91 C.2. Second header set . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 This document describes HPACK, a format adapted to efficiently 96 represent HTTP headers in the context of HTTP/2.0. 98 2. Overview 100 In HTTP/1.X, headers are sent without any form of compression. As 101 web pages have grown to include dozens to hundreds of requests, the 102 redundant headers in these requests now pose a problem of measurable 103 latency and unnecessary bandwidth. 1 [PERF1] 2 [PERF2] 105 SPDY [SPDY] initially addressed this redundancy by compressing 106 headers with Deflate, which proved very effective at eliminating the 107 redundant headers. However, that aproach exposed a security risk as 108 demonstrated by the CRIME [CRIME]. 110 In this document, we propose a new header compressor which eliminates 111 the redundant headers, is not vulnerable to the CRIME style attack, 112 and which also has a bounded memory cost for use in small constrained 113 environments. 115 2.1. Outline 117 The HTTP header encoding described in this document is based on a 118 header table that map (name, value) pairs to index values. Header 119 tables are incrementally updated during the HTTP/2.0 session. 121 The encoder is responsible for deciding which headers to insert as 122 new entries in the header table. The decoder then does exactly what 123 the encoder prescribes, ending in a state that exactly matches the 124 encoder's state. This enables decoders to remain simple and 125 understand a wide variety of encoders. 127 As two consecutive sets of headers often have headers in common, each 128 set of headers is coded as a difference from the previous set of 129 headers. The goal is to only encode the changes (headers present in 130 one of the set and not in the other) between the two sets of headers. 132 An example illustrating the use of these different mechanisms to 133 represent headers is available in Appendix C. 135 3. Header Encoding 137 3.1. Encoding Concepts 139 The encoding and decoding of headers relies on some components and 140 concepts. The set of components used form an encoding context. 142 Header Table: The header table (see Section 3.1.2) is a component 143 used to associate headers to index values. 145 Reference Set: The reference set (see Section 3.1.3) is a component 146 containing a group of headers used as a reference for the 147 differential encoding of a new set of headers. 149 Header Set: A header set (see Section 3.1.4) is a group of headers 150 that are encoded jointly. A complete set of key-value pairs as 151 encoded in an HTTP request or response is a header set. 153 Header Representation: A header can be represented in encoded form 154 either as a literal or as an index (see Section 3.1.5). The 155 indexed representation is based on the header table. 157 Header Emission: When decoding a set of headers, some operations 158 emit a header (see Section 3.1.6). An emitted header is added to 159 the set of headers that form the HTTP request or response. Once 160 emitted, a header can't be removed from the set of headers. 162 3.1.1. Encoding Context 164 The set of components used to encode or decode a header set form an 165 encoding context: an encoding context contains a header table and a 166 reference set. 168 Using HTTP, messages are exchanged between a client and a server in 169 both direction. To keep the encoding of headers in each direction 170 independent from the other direction, there is one encoding context 171 for each direction. 173 The headers contained in a PUSH_PROMISE frame sent by a server to a 174 client are encoded within the same context as the headers contained 175 in the HEADERS frame corresponding to a response sent from the server 176 to the client. 178 3.1.2. Header Table 180 A header table consists of an ordered list of (name, value) pairs. 181 The first entry of a header table is assigned the index 0. 183 A header can be represented by an entry from the header table. 184 Rather than encoding a literal value for the header field name and 185 value, the encoder can select an entry from the header table. 187 Literal header names MUST be translated to lowercase before encoding 188 and transmission. This enables an encoder to perform direct bitwise 189 comparisons on names and values when determining if an entry already 190 exists in the header table. 192 There is no need for the header table to contain duplicate entries. 193 However, duplicate entries MUST NOT be treated as an error by a 194 decoder. 196 Initially, a header table contains a list of common headers. Two 197 initial lists of header are provided in Appendix B. One list is for 198 headers transmitted from a client to a server, the other for the 199 reverse direction. 201 A header table is modified by either adding a new entry at the end of 202 the table, or by replacing an existing entry. 204 The encoder decides how to update the header table and as such can 205 control how much memory is used by the header table. To limit the 206 memory requirements on the decoder side, the header table size is 207 bounded (see the SETTINGS_HEADER_TABLE_SIZE in Section 5). 209 The size of an entry is the sum of its name's length in bytes (as 210 defined in Section 4.1.2), of its value's length in bytes 211 (Section 4.1.3) and of 32 bytes. The 32 bytes are an accounting for 212 the entry structure overhead. For example, an entry structure using 213 two 64-bits pointers to reference the name and the value and the 214 entry, and two 64-bits integer for counting the number of references 215 to these name and value would use 32 bytes. 217 The size of a header table is the sum of the size of its entries. 219 3.1.3. Reference Set 221 A reference set is defined as an unordered set of references to 222 entries of the header table. 224 The initial reference set is the empty set. 226 The reference set is updated during the processing of a set of 227 headers. 229 Using the differential encoding, a header that is not present in the 230 reference set can be encoded either with an indexed representation 231 (if the header is present in the header table), or with a literal 232 representation (if the header is not present in the header table). 234 A header that is to be removed from the reference set is encoded with 235 an indexed representation. 237 3.1.4. Header set 239 A header set is a group of header fields that are encoded as a whole. 240 Each header field is a (name, value) pair. 242 A header set is encoded using an ordered list of zero or more header 243 representations. All the header representations describing a header 244 set a grouped into a header block. 246 3.1.5. Header Representation 248 A header can be represented either as a literal or as an index. 250 Literal Representation: A literal representation defines a new 251 header. The header name is represented either literally or as a 252 reference to an entry of the header table. The header value is 253 represented literally. 255 Three different literal representations are provided: 257 * A literal representation that does not add the header to the 258 header table (see Section 4.3.1). 260 * A literal representation that adds the header at the end of the 261 header table (see Section 4.3.2). 263 * A literal representation that uses the header to replace an 264 existing entry of the header table (see Section 4.3.3). 266 Indexed Representation: The indexed representation defines a header 267 as a reference in the header table (see Section 4.2). 269 3.1.6. Header Emission 271 The emission of header is the process of adding a header to the 272 current set of headers. Once an header is emitted, it can't be 273 removed from the current set of headers. 275 The concept of header emission allows a decoder to know when it can 276 pass a header safely to a higher level on the receiver side. This 277 allows a decoder to be implemented in a streaming way, and as such to 278 only keep in memory the header table and the reference set. With 279 such an implementation, the amount of memory used by the decoder is 280 bounded, even in presence of a very large set of headers. The 281 management of memory for handling very large sets of headers can 282 therefore be deferred to the application, which may be able to emit 283 the header to the wire and thus free up memory quickly. 285 3.2. Header Set Processing 287 The processing of an encoded header set to obtain a list of headers 288 is defined in this section. To ensure a correct decoding of a header 289 set, a decoder MUST obey the following rules. 291 3.2.1. Header Representation Processing 293 All the header representations contained in a header block are 294 processed in the order in which they are presented, as specified 295 below. 297 An _indexed representation_ corresponding to an entry _not present_ 298 in the reference set entails the following actions: 300 o The header corresponding to the entry is emitted. 302 o The entry is added to the reference set. 304 An _indexed representation_ corresponding to an entry _present_ in 305 the reference set entails the following actions: 307 o The entry is removed from the reference set. 309 A _literal representation_ that is _not added_ to the header table 310 entails the following action: 312 o The header is emitted. 314 A _literal representation_ that is _added_ to the header table 315 entails the following actions: 317 o The header is emitted. 319 o The header is added to the header table, at the location defined 320 by the representation. 322 o The new entry is added to the reference set. 324 3.2.2. Reference Set Emission 326 Once all the representations contained in a header block have been 327 processed, the headers that are in common with the previous header 328 set are emitted, during the reference set emission. 330 For the reference set emission, each header contained in the 331 reference set that has not been emitted during the processing of the 332 header block is emitted. 334 3.2.3. Header Set Completion 336 Once all of the header representations have been processed, and the 337 remaining items in the reference set have been emitted, the header 338 set is complete. 340 3.2.4. Header Table Management 342 The header table can be modified by either adding a new entry to it 343 or by replacing an existing one. Before doing such a modification, 344 it has to be ensured that the header table size will stay lower than 345 or equal to the SETTINGS_HEADER_TABLE_SIZE limit (see Section 5). To 346 achieve this, repeatedly, the first entry of the header table is 347 removed, until enough space is available for the modification. 349 A consequence of removing one or more entries at the beginning of the 350 header table is that the remaining entries are renumbered. The first 351 entry of the header table is always associated to the index 0. 353 When the modification of the header table is the replacement of an 354 existing entry, the replaced entry is the one indicated in the 355 literal representation before any entry is removed from the header 356 table. If the entry to be replaced is removed from the header table 357 when performing the size adjustment, the replacement entry is 358 inserted at the beginning of the header table. 360 The addition of a new entry with a size greater than the 361 SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the 362 header table to be dropped and the new entry not to be added to the 363 header table. The replacement of an existing entry with a new entry 364 with a size greater than the SETTINGS_HEADER_TABLE_SIZE has the same 365 consequences. 367 4. Detailed Format 369 4.1. Low-level representations 371 4.1.1. Integer representation 373 Integers are used to represent name indexes, pair indexes or string 374 lengths. To allow for optimized processing, an integer 375 representation always finishes at the end of a byte. 377 An integer is represented in two parts: a prefix that fills the 378 current byte and an optional list of bytes that are used if the 379 integer value does not fit in the prefix. The number of bits of the 380 prefix (called N) is a parameter of the integer representation. 382 The N-bit prefix allows filling the current byte. If the value is 383 small enough (strictly less than 2^N-1), it is encoded within the 384 N-bit prefix. Otherwise all the bits of the prefix are set to 1 and 385 the value is encoded using an unsigned variable length integer [1] 386 representation. 388 The algorithm to represent an integer I is as follows: 390 If I < 2^N - 1, encode I on N bits 391 Else 392 encode 2^N - 1 on N bits 393 I = I - (2^N - 1) 394 While I >= 128 395 Encode (I % 128 + 128) on 8 bits 396 I = I / 128 397 encode (I) on 8 bits 399 4.1.1.1. Example 1: Encoding 10 using a 5-bit prefix 401 The value 10 is to be encoded with a 5-bit prefix. 403 o 10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit 404 prefix. 406 0 1 2 3 4 5 6 7 407 +---+---+---+---+---+---+---+---+ 408 | X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits 409 +---+---+---+---+---+---+---+---+ 411 4.1.1.2. Example 2: Encoding 1337 using a 5-bit prefix 413 The value I=1337 is to be encoded with a 5-bit prefix. 415 1337 is greater than 31 (= 2^5 - 1). 417 The 5-bit prefix is filled with its max value (31). 419 I = 1337 - (2^5 - 1) = 1306. 421 I (1306) is greater than or equal to 128, the while loop body 422 executes: 424 I % 128 == 26 426 26 + 128 == 154 428 154 is encoded in 8 bits as: 10011010 430 I is set to 10 (1306 / 128 == 10) 432 I is no longer greater than or equal to 128, the while loop 433 terminates. 435 I, now 10, is encoded on 8 bits as: 00001010 437 The process ends. 439 0 1 2 3 4 5 6 7 440 +---+---+---+---+---+---+---+---+ 441 | X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31, I = 1306 442 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1306>=128, encode(154), I = 1306/128 443 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 10<128, encode(10), done 444 +---+---+---+---+---+---+---+---+ 446 4.1.2. Header Name Representation 448 Header names are sequences of ASCII characters that MUST conform to 449 the following header-name ABNF construction: 451 LOWERALPHA = %x61-7A 452 header-char = "!" / "#" / "$" / "%" / "&" / "'" / 453 "*" / "+" / "-" / "." / "^" / "_" / 454 "`" / "|" / "~" / DIGIT / LOWERALPHA 455 header-name = [":"] 1*header-char 457 They are encoded in two parts: 459 1. The length of the text, defined as the number of octets of 460 storage required to store the text, represented as a variable- 461 length-quantity (Section 4.1.1). 463 2. The specific sequence of ASCII octets 465 4.1.3. Header Value Representation 467 Header values are encoded as sequences of UTF-8 encoded text. They 468 are encoded in two parts: 470 1. The length of the text, defined as the number of octets of 471 storage required to store the text, represented as a variable- 472 length-quantity (Section 4.1.1). 474 2. The specific sequence of octets representing the UTF-8 text. 476 Invalid UTF-8 octet sequences, "over-long" UTF-8 encodings, and UTF-8 477 octets that represent invalid Unicode Codepoints MUST NOT be used. 479 4.2. Indexed Header Representation 481 An indexed header representation identifies an entry in the header 482 table. The entry is emitted and added to the reference set if it is 483 not currently in the reference set. The entry is removed from the 484 reference set if it is present in the reference set. 486 0 1 2 3 4 5 6 7 487 +---+---+---+---+---+---+---+---+ 488 | 1 | Index (7+) | 489 +---+---------------------------+ 491 Indexed Header 493 This representation starts with the '1' 1-bit pattern, followed by 494 the index of the matching pair, represented as an integer with a 495 7-bit prefix. 497 4.3. Literal Header Representation 499 Literal header representations contain a literal header field value. 500 Header field names are either provided as a literal or by reference 501 to an existing header table entry. 503 Literal representations all result in the emission of a header when 504 decoded. 506 4.3.1. Literal Header without Indexing 508 An literal header without indexing causes the emission of a header 509 without altering the header table. 511 0 1 2 3 4 5 6 7 512 +---+---+---+---+---+---+---+---+ 513 | 0 | 1 | 1 | Index (5+) | 514 +---+---+---+-------------------+ 515 | Value Length (8+) | 516 +-------------------------------+ 517 | Value String (Length octets) | 518 +-------------------------------+ 520 Literal Header without Indexing - Indexed Name 522 0 1 2 3 4 5 6 7 523 +---+---+---+---+---+---+---+---+ 524 | 0 | 1 | 1 | 0 | 525 +---+---+---+-------------------+ 526 | Name Length (8+) | 527 +-------------------------------+ 528 | Name String (Length octets) | 529 +-------------------------------+ 530 | Value Length (8+) | 531 +-------------------------------+ 532 | Value String (Length octets) | 533 +-------------------------------+ 535 Literal Header without Indexing - New Name 537 This representation starts with the '011' 3-bit pattern. 539 If the header name matches the header name of a (name, value) pair 540 stored in the Header Table, the index of the pair increased by one 541 (index + 1) is represented as an integer with a 5-bit prefix. Note 542 that if the index is strictly below 31, one byte is used. 544 If the header name does not match a header name entry, the value 0 is 545 represented on 5 bits followed by the header name (Section 4.1.2). 547 Header name representation is followed by the header value 548 represented as a literal string as described in Section 4.1.3. 550 4.3.2. Literal Header with Incremental Indexing 552 A literal header with incremental indexing adds a new entry to the 553 header table. 555 0 1 2 3 4 5 6 7 556 +---+---+---+---+---+---+---+---+ 557 | 0 | 1 | 0 | Index (5+) | 558 +---+---+---+-------------------+ 559 | Value Length (8+) | 560 +-------------------------------+ 561 | Value String (Length octets) | 562 +-------------------------------+ 564 Literal Header with Incremental Indexing - 565 Indexed Name 567 0 1 2 3 4 5 6 7 568 +---+---+---+---+---+---+---+---+ 569 | 0 | 1 | 0 | 0 | 570 +---+---+---+-------------------+ 571 | Name Length (8+) | 572 +-------------------------------+ 573 | Name String (Length octets) | 574 +-------------------------------+ 575 | Value Length (8+) | 576 +-------------------------------+ 577 | Value String (Length octets) | 578 +-------------------------------+ 580 Literal Header with Incremental Indexing - 581 New Name 583 This representation starts with the '010' 3-bit pattern. 585 If the header name matches the header name of a (name, value) pair 586 stored in the Header Table, the index of the pair increased by one 587 (index + 1) is represented as an integer with a 5-bit prefix. Note 588 that if the index is strictly below 31, one byte is used. 590 If the header name does not match a header name entry, the value 0 is 591 represented on 5 bits followed by the header name (Section 4.1.2). 593 Header name representation is followed by the header value 594 represented as a literal string as described in Section 4.1.3. 596 4.3.3. Literal Header with Substitution Indexing 598 A literal header with substitution indexing replaces an existing 599 header table entry. 601 0 1 2 3 4 5 6 7 602 +---+---+---+---+---+---+---+---+ 603 | 0 | 0 | Index (6+) | 604 +---+---+-----------------------+ 605 | Substituted Index (8+) | 606 +-------------------------------+ 607 | Value Length (8+) | 608 +-------------------------------+ 609 | Value String (Length octets) | 610 +-------------------------------+ 612 Literal Header with Substitution Indexing - 613 Indexed Name 615 0 1 2 3 4 5 6 7 616 +---+---+---+---+---+---+---+---+ 617 | 0 | 0 | 0 | 618 +---+---+-----------------------+ 619 | Name Length (8+) | 620 +-------------------------------+ 621 | Name String (Length octets) | 622 +-------------------------------+ 623 | Substituted Index (8+) | 624 +-------------------------------+ 625 | Value Length (8+) | 626 +-------------------------------+ 627 | Value String (Length octets) | 628 +-------------------------------+ 630 Literal Header with Substitution Indexing - 631 New Name 633 This representation starts with the '00' 2-bit pattern. 635 If the header name matches the header name of a (name, value) pair 636 stored in the Header Table, the index of the pair increased by one 637 (index + 1) is represented as an integer with a 6-bit prefix. Note 638 that if the index is strictly below 63, one byte is used. 640 If the header name does not match a header name entry, the value 0 is 641 represented on 6 bits followed by the header name (Section 4.1.2). 643 The index of the substituted (name, value) pair is inserted after the 644 header name representation as a 0-bit prefix integer. 646 The index of the substituted pair MUST correspond to a position in 647 the header table containing a non-void entry. An index for the 648 substituted pair that corresponds to empty position in the header 649 table MUST be treated as an error. 651 This index is followed by the header value represented as a literal 652 string as described in Section 4.1.3. 654 5. Parameter Negotiation 656 A few parameters can be used to accommodate client and server 657 processing and memory requirements. [[anchor3: These settings are 658 currently not supported as they have not been integrated in the main 659 specification. Therefore, the maximum buffer size for the header 660 table is fixed at 4096 bytes.]] 662 SETTINGS_HEADER_TABLE_SIZE (TBD): Allows the sender to inform the 663 remote endpoint of the maximum size it accepts for the header 664 table. 665 The default value is 4096 bytes. 666 [[anchor4: Is this default value OK? Do we need a maximum size? 667 Do we want to allow infinite buffer?]] 668 When the remote endpoint receives a SETTINGS frame containing a 669 SETTINGS_HEADER_TABLE_SIZE setting with a value smaller than the 670 one currently in use, it MUST send as soon as possible a HEADER 671 frame with a stream identifier of 0x0 containing a value smaller 672 than or equal to the received setting value. 673 [[anchor5: This changes slightly the behaviour of the HEADERS 674 frame, which should be updated as follows:]] 675 A HEADER frame with a stream identifier of 0x0 indicates that the 676 sender has reduced the maximum size of the header table. The new 677 maximum size of the header table is encoded on 32-bit. The 678 decoder MUST reduce its own header table by dropping entries from 679 it until the size of the header table is lower than or equal to 680 the transmitted maximum size. 682 6. Security Considerations 684 This compressor exists to solve security issues present in stream 685 compressors such as DEFLATE whereby the compression context can be 686 efficiently probed to reveal secrets. A conformant implementation of 687 this specification should be fairly safe against that kind of attack, 688 as the reaping of any information from the compression context 689 requires more work than guessing and verifying the plaintext data 690 directly with the server. As with any secret, however, the longer 691 the length of the secret, the more difficult the secret is to guess. 692 It is inadvisable to have short cookies that are relied upon to 693 remain secret for any duration of time. 695 A proper security-conscious implementation will also need to prevent 696 timing attacks by ensuring that the amount of time it takes to do 697 string comparisons is always a function of the total length of the 698 strings, and not a function of the number of matched characters. 700 Another common security problem is when the remote endpoint 701 successfully causes the local endpoint to exhaust its memory. This 702 compressor attempts to deal with the most obvious ways that this 703 could occur by limiting both the peak and the steady-state amount of 704 memory consumed in the compressor state, by providing ways for the 705 application to consume/flush the emitted headers in small chunks, and 706 by considering overhead in the state size calculation. Implementors 707 must still be careful in the creation of APIs to an implementation of 708 this compressor by ensuring that header keys and values are either 709 emitted as a stream, or that the compression implementation have a 710 limit on the maximum size of a key or value. Failure to implement 711 these kinds of safeguards may still result in a scenario where the 712 local endpoint exhausts its memory. 714 7. IANA Considerations 716 This document registers the SETTINGS_HEADER_TABLE_SIZE setting in the 717 "HTTP/2.0 Settings" registry established by [HTTP2]. The assigned 718 code for this setting is TBD. 720 8. References 722 8.1. Normative References 724 [HTTP2] Belshe, M., Peon, R., Thomson, M., and A. Melnikov, 725 "Hypertext Transfer Protocol version 2.0", 726 draft-ietf-httpbis-http2-06 (work in progress), 727 February 2013. 729 8.2. Informative References 731 [CRIME] Rizzo, J. and T. Duong, "The Crime Attack", September 2012, 732 . 736 [PERF1] Belshe, M., "IETF83: SPDY and What to Consider for 737 HTTP/2.0", March 2012, . 740 [PERF2] McManus, P., "SPDY What I Like About You", September 2011, < 741 http://bitsup.blogspot.com/2011/09/ 742 spdy-what-i-like-about-you.html>. 744 [SPDY] Belshe, M. and R. Peon, "SPDY Protocol", February 2012, 745 . 747 URIs 749 [1] 751 Appendix A. Change Log (to be removed by RFC Editor before publication 753 A.1. Since draft-ietf-httpbis-header-compression-01 755 o Refactored of Header Encoding Section: split definitions and 756 processing rule. 758 o Backward incompatible change: Updated reference set management as 759 per issue #214. This changes how the interaction between the 760 reference set and eviction works. This also changes the working 761 of the reference set in some specific cases. 763 o Backward incompatible change: modified initial header list, as per 764 issue #188. 766 o Added example of 32 bytes entry structure (issue #191). 768 o Added Header Set Completion section. Reflowed some text. 769 Clarified some writing which was akward. Added text about 770 duplicate header entry encoding. Clarified some language w.r.t 771 Header Set. Changed x-my-header to mynewheader. Added text in the 772 HeaderEmission section indicating that the application may also be 773 able to free up memory more quickly. Added information in 774 Security Considerations section. 776 A.2. Since draft-ietf-httpbis-header-compression-01 778 Fixed bug/omission in integer representation algorithm. 780 Changed the document title. 782 Header matching text rewritten. 784 Changed the definition of header emission. 786 Changed the name of the setting which dictates how much memory the 787 compression context should use. 789 Removed "specific use cases" section 790 Corrected erroneous statement about what index can be contained in 791 one byte 793 Added descriptions of opcodes 795 Removed security claims from introduction. 797 Appendix B. Initial Header Tables 799 [[anchor11: The tables in this section should be updated based on 800 statistical analysis of header names frequency and specific HTTP 2.0 801 header rules (like removal of some headers).]] 802 [[anchor12: These tables are not adapted for headers contained in 803 PUSH_PROMISE frames. Either the tables can be merged, or the table 804 for responses can be updated.]] 806 B.1. Requests 808 The following table lists the pre-defined headers that make-up the 809 initial header table user to represent requests sent from a client to 810 a server. 812 +-------+---------------------+--------------+ 813 | Index | Header Name | Header Value | 814 +-------+---------------------+--------------+ 815 | 0 | :scheme | http | 816 | 1 | :scheme | https | 817 | 2 | :host | | 818 | 3 | :path | / | 819 | 4 | :method | GET | 820 | 5 | accept | | 821 | 6 | accept-charset | | 822 | 7 | accept-encoding | | 823 | 8 | accept-language | | 824 | 9 | cookie | | 825 | 10 | if-modified-since | | 826 | 11 | user-agent | | 827 | 12 | referer | | 828 | 13 | authorization | | 829 | 14 | allow | | 830 | 15 | cache-control | | 831 | 16 | connection | | 832 | 17 | content-length | | 833 | 18 | content-type | | 834 | 19 | date | | 835 | 20 | expect | | 836 | 21 | from | | 837 | 22 | if-match | | 838 | 23 | if-none-match | | 839 | 24 | if-range | | 840 | 25 | if-unmodified-since | | 841 | 26 | max-forwards | | 842 | 27 | proxy-authorization | | 843 | 28 | range | | 844 | 29 | via | | 845 +-------+---------------------+--------------+ 847 Table 1: Initial Header Table for Requests 849 B.2. Responses 851 The following table lists the pre-defined headers that make-up the 852 initial header table used to represent responses sent from a server 853 to a client. The same header table is also used to represent request 854 headers sent from a server to a client in a PUSH_PROMISE frame. 856 +-------+-----------------------------+--------------+ 857 | Index | Header Name | Header Value | 858 +-------+-----------------------------+--------------+ 859 | 0 | :status | 200 | 860 | 1 | age | | 861 | 2 | cache-control | | 862 | 3 | content-length | | 863 | 4 | content-type | | 864 | 5 | date | | 865 | 6 | etag | | 866 | 7 | expires | | 867 | 8 | last-modified | | 868 | 9 | server | | 869 | 10 | set-cookie | | 870 | 11 | vary | | 871 | 12 | via | | 872 | 13 | access-control-allow-origin | | 873 | 14 | accept-ranges | | 874 | 15 | allow | | 875 | 16 | connection | | 876 | 17 | content-disposition | | 877 | 18 | content-encoding | | 878 | 19 | content-language | | 879 | 20 | content-location | | 880 | 21 | content-range | | 881 | 22 | link | | 882 | 23 | location | | 883 | 24 | proxy-authenticate | | 884 | 25 | refresh | | 885 | 26 | retry-after | | 886 | 27 | strict-transport-security | | 887 | 28 | transfer-encoding | | 888 | 29 | www-authenticate | | 889 +-------+-----------------------------+--------------+ 891 Table 2: Initial Header Table for Responses 893 Appendix C. Example 895 Here is an example that illustrates different representations and how 896 tables are updated. [[anchor15: This section needs to be updated to 897 better reflect the new processing of header fields, and include more 898 examples.]] 900 C.1. First header set 902 The first header set to represent is the following: 904 :path: /my-example/index.html 905 user-agent: my-user-agent 906 mynewheader: first 908 The header table is empty, all headers are represented as literal 909 headers with indexing. The 'mynewheader' header name is not in the 910 header name table and is encoded literally. This gives the following 911 representation: 913 0x44 (literal header with incremental indexing, name index = 3) 914 0x16 (header value string length = 22) 915 /my-example/index.html 916 0x4D (literal header with incremental indexing, name index = 12) 917 0x0D (header value string length = 13) 918 my-user-agent 919 0x40 (literal header with incremental indexing, new name) 920 0x0B (header name string length = 11) 921 mynewheader 922 0x05 (header value string length = 5) 923 first 925 The header table is as follows after the processing of these headers: 927 Header table 928 +---------+----------------+---------------------------+ 929 | Index | Header Name | Header Value | 930 +---------+----------------+---------------------------+ 931 | 0 | :scheme | http | 932 +---------+----------------+---------------------------+ 933 | 1 | :scheme | https | 934 +---------+----------------+---------------------------+ 935 | ... | ... | ... | 936 +---------+----------------+---------------------------+ 937 | 37 | warning | | 938 +---------+----------------+---------------------------+ 939 | 38 | :path | /my-example/index.html | added header 940 +---------+----------------+---------------------------+ 941 | 39 | user-agent | my-user-agent | added header 942 +---------+----------------+---------------------------+ 943 | 40 | mynewheader | first | added header 944 +---------+----------------+---------------------------+ 946 As all the headers in the first header set are indexed in the header 947 table, all are kept in the reference set of headers, which is: 949 Reference Set: 950 :path, /my-example/index.html 951 user-agent, my-user-agent 952 mynewheader, first 954 C.2. Second header set 956 The second header set to represent is the following: 958 :path: /my-example/resources/script.js 959 user-agent: my-user-agent 960 mynewheader: second 962 Comparing this second header set to the reference set, the first and 963 third headers are from the reference set are not present in this 964 second header set and must be removed. In addition, in this new set, 965 the first and third headers have to be encoded. The path header is 966 represented as a literal header with substitution indexing. The 967 mynewheader will be represented as a literal header with incremental 968 indexing. 970 0xa6 (indexed header, index = 38: removal from reference set) 971 0xa8 (indexed header, index = 40: removal from reference set) 972 0x04 (literal header, substitution indexing, name index = 3) 973 0x26 (replaced entry index = 38) 974 0x1f (header value string length = 31) 975 /my-example/resources/script.js 976 0x5f 0x0a (literal header, incremental indexing, name index = 40) 977 0x06 (header value string length = 6) 978 second 980 The header table is updated as follow: 982 Header table 983 +---------+----------------+---------------------------+ 984 | Index | Header Name | Header Value | 985 +---------+----------------+---------------------------+ 986 | 0 | :scheme | http | 987 +---------+----------------+---------------------------+ 988 | 1 | :scheme | https | 989 +---------+----------------+---------------------------+ 990 | ... | ... | ... | 991 +---------+----------------+---------------------------+ 992 | 37 | warning | | 993 +---------+----------------+---------------------------+ 994 | 38 | :path | /my-example/resources/ | replaced 995 | | | script.js | header 996 +---------+----------------+---------------------------+ 997 | 39 | user-agent | my-user-agent | 998 +---------+----------------+---------------------------+ 999 | 40 | mynewheader | first | 1000 +---------+----------------+---------------------------+ 1001 | 41 | mynewheader | second | added header 1002 +---------+----------------+---------------------------+ 1004 All the headers in this second header set are indexed in the header 1005 table, therefore, all are kept in the reference set of headers, which 1006 becomes: 1008 Reference Set: 1009 :path, /my-example/resources/script.js 1010 user-agent, my-user-agent 1011 mynewheader, second 1013 Authors' Addresses 1015 Roberto Peon 1016 Google, Inc 1018 EMail: fenix@google.com 1020 Herve Ruellan 1021 Canon CRF 1023 EMail: herve.ruellan@crf.canon.fr