idnits 2.17.1 draft-ruellan-headerdiff-00.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 679: '... of headers that SHOULD never be compr...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2013) is 4063 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 203 looks like a reference -- Missing reference section? '2' on line 355 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Ruellan 3 Internet-Draft J. Fujisawa 4 Expires: September 12, 2013 Canon, Inc. 5 R. Bellessort 6 Y. Fablet 7 March 11, 2013 9 Header Diff: A compact HTTP header representation for HTTP/2.0 10 draft-ruellan-headerdiff-00 12 Abstract 14 This document describes a format adapted to efficiently represent 15 HTTP headers in the context of HTTP/2.0. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 12, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Design Principles . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Integration within HTTP/2.0 . . . . . . . . . . . . . . . 4 56 2.3.1. Deflate Usage . . . . . . . . . . . . . . . . . . . . 5 57 3. Indexing Strategies . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Indexing Tables . . . . . . . . . . . . . . . . . . . . . 6 59 3.1.1. Header Table . . . . . . . . . . . . . . . . . . . . 6 60 3.1.2. Name Table . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Header Representation . . . . . . . . . . . . . . . . . . 7 62 3.2.1. Literal Representation . . . . . . . . . . . . . . . 7 63 3.2.2. Indexed Representation . . . . . . . . . . . . . . . 7 64 3.2.3. Delta Representation . . . . . . . . . . . . . . . . 7 65 4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Low-level representations . . . . . . . . . . . . . . . . 8 67 4.1.1. Integer representation . . . . . . . . . . . . . . . 8 68 4.1.2. String literal representation . . . . . . . . . . . . 10 69 4.2. Indexed Header Representation . . . . . . . . . . . . . . 10 70 4.2.1. Short Indexed Header . . . . . . . . . . . . . . . . 10 71 4.2.2. Long Indexed Header . . . . . . . . . . . . . . . . . 11 72 4.3. Literal Header Representation . . . . . . . . . . . . . . 11 73 4.3.1. Literal Header without Indexing . . . . . . . . . . . 11 74 4.3.2. Literal Header with Indexing . . . . . . . . . . . . 12 75 4.4. Delta Header Representation . . . . . . . . . . . . . . . 12 76 4.4.1. Delta Header without Indexing . . . . . . . . . . . . 12 77 4.4.2. Delta Header with Indexing . . . . . . . . . . . . . 13 78 5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 13 79 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.1. Typed Codecs . . . . . . . . . . . . . . . . . . . . . . 14 81 6.2. Specific header processing . . . . . . . . . . . . . . . 14 82 6.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 15 83 6.4. Deflate Partial Usage . . . . . . . . . . . . . . . . . . 15 84 6.5. Max length and entry numbers . . . . . . . . . . . . . . 15 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 Appendix A. Initial header names . . . . . . . . . . . . . . . . 16 89 A.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 16 90 A.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 18 91 A.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 A.3.1. First header set . . . . . . . . . . . . . . . . . . 19 93 A.3.2. Second header set . . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 This document describes a format adapted to efficiently represent 99 HTTP headers in the context of HTTP/2.0. 101 2. Overview 103 2.1. Design Principles 105 HTTP headers can be represented in various ways. As shown by SPDY, 106 Deflate compresses very well HTTP headers. But the use of Deflate 107 has been found to cause security issues. In particular, the 108 compression of sensitive data, together with other data controlled by 109 an attacker, may lead to leakage of the sensitive data. The 110 processing and memory costs may also be too high for some classes of 111 devices. 113 Having a lightweight compact HTTP header representation is therefore 114 useful. To design this representation, the focus was put on the 115 following points: 117 o Simplicity: the representation should have a small number of 118 options that allow handling any kind of headers; in particular, 119 the use of dedicated codecs for each type of header value is not 120 considered here. 122 o Efficiency: the representation should provide good compression at 123 a small encoding/decoding cost for both processing and memory. 125 o Flexibility: the representation should be compatible with 126 constrained devices, but also provide improved efficiency when 127 more capable devices are used. 129 o Deflate-friendly: Deflate has proven its efficiency for encoding 130 HTTP headers. A good HTTP header representation should be 131 efficient as a pre-compression step prior to applying Deflate. 133 2.2. Outline 135 The HTTP header representation described in this document is based on 136 indexing tables that store (name,value) pairs, called header tables 137 in the remainder of this document. Header tables are incrementally 138 updated during the whole HTTP/2.0 session. Two independent header 139 tables are used during a HTTP/2.0 session, one for HTTP request 140 headers and one for HTTP response headers. 142 The encoder is responsible for deciding which headers to insert as 143 (name,value) pairs in the header table. The decoder follows exactly 144 what the encoder prescribes. This enables decoders to remain simple 145 and understand a wide variety of encoders. 147 A header may be represented as a literal, an index or a delta. If 148 represented as a literal or a delta, the representation specifies 149 whether this header is used to update the indexing table. The 150 different representations are described in Section 3.2. 152 To improve literal headers representation compactness, header names 153 are indexed in a specific name table. Two independent name tables 154 are used during a HTTP/2.0 session, one for HTTP request headers and 155 another for HTTP response headers. 157 An example illustrating the use of the different tables to represent 158 headers is available in Appendix A.3. Once a set of header is 159 represented using the available representations, it can optionally be 160 compressed with Deflate. 162 2.3. Integration within HTTP/2.0 164 The headers are inserted in the HTTP/2.0 frames at the same place as 165 defined in SPDY (next chart was adapted from draft-ietf-httpbis- 166 http2-00). 168 +------------------------------------+ 169 |1| version | 1 | 170 +------------------------------------+ 171 | Flags (8) | Length (24 bits) | 172 +------------------------------------+ 173 |X| Stream-ID (31bits) | 174 +------------------------------------+ 175 |X| Associated-To-Stream-ID (31bits) | 176 +------------------------------------+ 177 | Pri|Unused | Slot | | 178 +-------------------+ | 179 | Number of Name/Value pairs (int32) | 180 +------------------------------------+ 181 | Encoded name/value pair | <+ 182 +------------------------------------+ | (*) 183 | (repeats) | <+ 185 (*) This section is the "Name/Value Header Block", 186 and may be compressed. 188 The modifications to SPDY are the following: 190 o The headers are not represented as string tokens but using one of 191 the possible representation described in Section 4. 193 o The Deflate step is made optional. 195 2.3.1. Deflate Usage 197 The header representation described in Section 4 is amenable to 198 Deflate compression. The Deflate algorithm improves the compression 199 at the expense of additional processing. 201 At least two potential drawbacks have been identified when using 202 Deflate. First, security issues may arise when using Deflate, like 203 the CRIME attack [1]. Second, it may increase the workload of 204 network intermediaries: they may need to uncompress and recompress 205 the headers of all messages, even though they only need to process a 206 few of them. 208 The use of Deflate may still be envisioned if properly set up. 209 Several approaches are available and should be studied: 211 Restricting Deflate to Huffman-only coding is an option. This is 212 supported by many Deflate implementations such as zlib. It may be 213 used in the environments subject to CRIME attacks. This approach 214 should be compared to the direct use of hand-tailored Huffman 215 coding. 217 The use of indexing mechanisms prior Deflate may solve some 218 security issues. More precise analysis of the security impact of 219 using indexing mechanisms prior Deflate should be studied as 220 described in Section 6.3. 222 Partial use of Deflate on a selected subset of headers may also be 223 an option as described in Section 6.4. 225 Restricting the use of Deflate to safe cases, such as controlled 226 environments (widgets, native applications), anonymous connections 227 and so on can be envisioned. For instance, restricting the use of 228 Deflate to HTTP response headers should not enable CRIME-like 229 attacks. 231 3. Indexing Strategies 232 3.1. Indexing Tables 234 3.1.1. Header Table 236 A header table consists in an ordered list of (name, value) pairs. 237 Once a header pair is inserted in the header table, its index does 238 not change until the pair gets removed. A pair is either inserted at 239 the end of the table or replaces an existing pair depending on the 240 chosen representation. 242 Header names should be represented as lower-case strings. A header 243 name is matching with a pair name if they are equal using a 244 character-based, _case insensitive_ comparison. A header value is 245 matching with a pair value if they are equal using a character-based, 246 _case sensitive_ comparison. A header is matching with a 247 (name,value) pair if both name and value are matching. 249 The header table is progressively updated based on headers 250 represented as literal (as defined in Section 3.2.1) or delta (as 251 defined in Section 3.2.3). Two update mechanisms are defined: 253 o Incremental indexing: the represented header is inserted at the 254 end of the header table as a (name, value) pair. The inserted 255 pair index is set to the next free index in the table: it is equal 256 to the number of headers in the table before its insertion. 258 o Substitution indexing: the represented header contains an index to 259 an existing (name,value) pair. The existing pair value is 260 replaced by the header value. 262 Incremental and substitution indexing are optional. If none of them 263 is selected in a header representation, the header table is not 264 updated. In particular, no update happens on the header table when 265 processing an indexed representation. 267 The header table size can be bounded so as to limit the memory 268 requirements. The header table size is defined as the sum of the 269 length (as defined in Section 4.1.2) of the values of all header 270 table pairs. Header names are not counted in the header table size. 272 3.1.2. Name Table 274 A name table is an ordered list of name entries that is used to 275 efficiently represent header names. A header name is matching a name 276 table entry if they are equal using a character-based, _case 277 insensitive_ comparison. 279 If a header name is matching a name table entry, it is represented as 280 an integer based on the index of the entry, as described in 281 Section 4.1.1. If a header name is not matching any of the name 282 table entry, it is represented as a string, as described in 283 Section 4.1.2. A new entry containing the name is then inserted at 284 the end of the name table. Once inserted in the name table, a header 285 name is never removed and its index is never changing. 287 To optimize the representation of the headers exchanged at the 288 beginning of the HTTP/2.0 session, the header name table is initally 289 populated with common header names. The initial header names list is 290 provided in Appendix A. 292 3.2. Header Representation 294 3.2.1. Literal Representation 296 The literal representation defines a header independentently of the 297 header table. A literal header is represented as: 299 o A header name, represented using the name table, as described in 300 Section 3.1.2. 302 o The header value, represented as a literal string, as described in 303 Section 4.1.2. 305 3.2.2. Indexed Representation 307 The indexed representation defines a header as a match to a 308 (name,value) pair in the header table. An indexed header is 309 represented as: 311 o An integer representing the index of the matching (name,value) 312 pair, as described in Section 4.1.1. 314 3.2.3. Delta Representation 316 The delta representation defines a header as a reference to a 317 (name,value) pair contained in the header table. The names must 318 match between the represented header and the reference pair. The 319 values should start by a common substring between the represented 320 header and the reference pair. 322 A delta header is represented as: 324 o An integer representing the index of the reference (name, value) 325 pair, as described in Section 4.1.1. The pair name must match the 326 name of the header. 328 o An integer representing the length of the common prefix shared 329 between the header value and the pair value, as described in 330 Section 4.1.1. 332 o A string representing the suffix value to append to the common 333 prefix to obtain the header value, as defined in Section 4.1.2. 335 4. Detailed Format 337 4.1. Low-level representations 339 4.1.1. Integer representation 341 Integers are used to represent name indexes, pair indexes or string 342 lengths. The integer representation keeps byte-alignment as much as 343 possible as this allows various processing optimizations as well as 344 efficient use of DEFLATE. For that purpose, an integer 345 representation always finishes at the end of a byte. 347 An integer is represented in two parts: a prefix that fills the 348 current byte and an optional list of bytes that are used if the 349 integer value does not fit in the prefix. The number of bits of the 350 prefix (called N) is a parameter of the integer representation. 352 The N-bit prefix allows filling the current byte. If the value is 353 small enough (strictly less than 2^N-1), it is encoded within the 354 N-bit prefix. Otherwise all the bits of the prefix are set to 1 and 355 the value is encoded using an unsigned variable length integer [2] 356 representation. 358 The algorithm to represent an integer I is as follows: 360 1. If I < 2^N - 1, encode I on N bits 362 2. Else, encode 2^N - 1 on N bits and do the following steps: 364 3. 366 1. Set I to (I - 2^N - 1) and Q to 1 368 2. While Q > 0 370 3. 372 1. Compute Q and R, quotient and remainder of I divided by 373 2^7 375 2. If Q is strictly greater than 0, write one 1 bit; 376 otherwise, write one 0 bit 378 3. Encode R on the next 7 bits 380 4. I = Q 382 4.1.1.1. Example 1: Encoding 10 using a 5-bit prefix 384 The value 10 is to be encoded with a 5-bit prefix. 386 o 10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit 387 prefix. 389 +-----+-----+-----+-----+-----+-----+-----+-----+ 390 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 391 +-----+-----+-----+-----+-----+-----+-----+-----+ 392 | X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits 393 +-----+-----+-----+-----+-----+-----+-----+-----+ 395 4.1.1.2. Example 2: Encoding 1337 using a 5-bit prefix 397 The value I=1337 is to be encoded with a 5-bit prefix. 399 o 1337 is greater than 31 (= 2^5 - 1). 401 o 403 * The 5-bit prefix is filled with its max value (31). 405 o The value to represent on next bytes is I = 1337 - 2^5 = 1305. 407 o 409 * 1305 = 128*10 + 25, i.e. Q=10 and R=25. 411 * Q is greater than 1, bit 8 is set to 1. 413 * The remainder R=25 is encoded on next 7 bits. 415 * I is replaced by the quotient Q=10. 417 o The value to represent on next bytes is I = 10. 419 o 421 * 10 = 128*0 + 10, i.e. Q=0 and R=10. 423 * Q is equal to 0, bit 16 is set to 0. 425 * The remainder R=10 is encoded on next 7 bits. 427 * I is replaced by the quotient Q=0. 429 o The process ends. 431 +----+-----+-----+-----+-----+-----+-----+-----+ 432 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 433 +-----+-----+-----+-----+-----+-----+-----+-----+ 434 | X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31 435 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | Q>=1, R=25 436 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | Q=0 , R=10 437 +-----+-----+-----+-----+-----+-----+-----+-----+ 439 4.1.2. String literal representation 441 Literal strings can represent header names, header values or header 442 values suffix in the case of delta coding. They are encoded in two 443 parts: 445 1. The string length, defined as the number of bytes needed to store 446 its UTF-8 representation, is represented as an integer with a 447 zero bits prefix. If the string length is strictly less than 448 128, it is represented as one byte. 450 2. The string value represented as a list of UTF-8 characters. 452 4.2. Indexed Header Representation 454 Indexed headers can be represented as short indexed header if the 455 matching pair index is strictly below 64. Otherwise it is 456 represented as a long indexed header. 458 4.2.1. Short Indexed Header 460 +-------+-------+-------+-------+-------+-------+-------+-------+ 461 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 462 +-------+-------+-------+-------+-------+-------+-------+-------+ 463 | 1 | 0 | 00 0000 - 11 1111 | 464 | | | Matching pair index | 465 | | | (if strictly lower than 64) | 466 +-------+-------+-------+-------+-------+-------+-------+-------+ 467 This representation starts with the '10' 2-bit pattern, followed by 468 the index of the matching pair, represented on 6 bits. A short 469 indexed header is always coded in one byte. 471 4.2.2. Long Indexed Header 473 +-------+-------+-------+-------+-------+-------+-------+-------+ 474 | 0 | 1 | 2 | 3 | ... | ... | e | f | 475 +-------+-------+-------+-------+-------+-------+-------+-------+ 476 | 1 | 1 | 00 0000 0000 0000 - 11 1111 1111 1111 1111 | 477 | | | Matching pair index | 478 | | | (if equal to or greater than 64) | 479 +-------+-------+-------+-------+-------+-------+-------+-------+ 481 This representation starts with the '11' 2-bit pattern, followed by 482 the value of the index of the matching pair minus 64, represented as 483 an integer with a 14-bit prefix A long indexed header is coded in two 484 bytes if the index minus 64 is strictly below 16383. 486 4.3. Literal Header Representation 488 4.3.1. Literal Header without Indexing 490 +-------+-------+-------+-------+-------+-------+-------+-------+ 491 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 492 +-------+-------+-------+-------+-------+-------+-------+-------+ 493 | | | | 0 0000 | 494 | | | | New header name symbol | 495 | 0 | 0 | 0 |---------------------------------------| 496 | | | | 0 0001 - 1 1111 | 497 | | | | Index of matching header name | 498 +-------+-------+-------+-------+-------+-------+-------+-------+ 500 This representation, which does not involve updating the header 501 table, starts with the '000' 3-bit pattern. 503 If the header name matches a header name entry whose index is IN, the 504 value (IN+1) is represented as an integer with a 5-bit prefix. Note 505 that if the index is strictly below 30, one byte is used. 507 If the header name does not match a header name entry, the value 0 is 508 represented on 5 bits followed by the header name, represented as a 509 literal string. 511 Header name representation is followed by the header value 512 represented as a literal string. 514 4.3.2. Literal Header with Indexing 516 +-------+-------+-------+-------+-------+-------+-------+-------+ 517 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 518 +-------+-------+-------+-------+-------+-------+-------+-------+ 519 | | | | | 0000 | 520 | | | |Indexing| New header name symbol | 521 | 0 | 0 | 1 | |-------------------------------| 522 | | | | Mode | 0001 - 1111 | 523 | | | | | Index of matching header name | 524 +-------+-------+-------+-------+-------+-------+-------+-------+ 526 This representation starts with the '001' 3-bit pattern. The fourth 527 bit sets the indexing mode: 0 for incremental indexing, 1 for 528 substitution indexing. 530 If the header name matches a header name entry whose index is IN, the 531 value (IN+1) is represented as an integer with a 4-bit prefix. Note 532 that if the index is strictly below 14, one byte is used. 534 If the header name does not match a header name entry, the value 0 is 535 represented on 4 bits followed by the header name, represented as a 536 literal string. 538 Header name representation is followed by the header value 539 represented as a string as described in Section 4.1.2. In the case 540 of substitution indexing, the substituted (name,value) pair index is 541 inserted before the header value as a zero-bit prefix integer. The 542 header value is represented as a literal string. 544 4.4. Delta Header Representation 546 4.4.1. Delta Header without Indexing 548 +-------+-------+-------+-------+-------+-------+-------+-------+ 549 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 550 +-------+-------+-------+-------+-------+-------+-------+-------+ 551 | 0 | 1 | 0 | 0 0000 - 1 1111 | 552 | | | | Index of reference pair | 553 +-------+-------+-------+-------+-------+-------+-------+-------+ 555 This representation starts with the '010' 3-bit pattern. 557 It continues with the index IR of the reference header pair. The 558 value IR is represented as an integer with a 5-bit prefix. Note that 559 if the index is strictly below 31, one byte is used. 561 Index value is followed by: 563 1. the length of the common prefix shared between the header value 564 and the pair value, represented as an integer with a zero-bit 565 prefix. 567 2. the header value suffix represented as a literal string. 569 4.4.2. Delta Header with Indexing 571 +-------+-------+-------+-------+-------+-------+-------+-------+ 572 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 573 +-------+-------+-------+-------+-------+-------+-------+-------+ 574 | 0 | 1 | 1 |Indexing| 0000 - 1111 | 575 | | | | Mode | Index of reference pair | 576 +-------+-------+-------+-------+-------+-------+-------+-------+ 578 This representation starts with the '011' 3-bit pattern. The fourth 579 bit sets the indexing mode, 0 for incremental indexing and 1 for 580 substitution indexing. 582 It continues with the index IR of the reference header pair. The 583 value IR is represented as an integer with a 4-bit prefix. Note that 584 if the index is strictly below 15, one byte is used. 586 Index value is followed by: 588 1. the length of the common prefix shared between the header value 589 and the pair value, represented as an integer with a zero-bit 590 prefix. 592 2. the header value suffix, represented as a literal string. 594 5. Parameter Negotiation 596 Two parameters may be used to accomodate the client and server 597 processing and memory requirements: 599 o A parameter Nh that configures the size of the header table. The 600 size can be computed as 2^Nh. Nh is exchanged as an unsigned 601 integer. 603 o A parameter Nd that configures the Deflate step. If Nd is equal 604 to zero, no Deflate step is used. Otherwise, Deflate is used with 605 a sliding window equal to 2^Nd. Huffman-only coding is advertised 606 using the Deflate block initial bits. Nd is exchanged as an 607 unsigned integer. 609 This section should be further completed, including but not limited 610 to the following points: 612 o Define default values? 614 o Define when negotiation happens: at the beginning only, any time 615 during the session... 617 o Define how are exchanged these parameters, probably using SETTINGS 618 frames, through the definition of 4 settings (outgoing-Nd, 619 outgoing-Nh, preferred-incomingNd, preferred-incoming-Nh). 621 6. Open Questions 623 6.1. Typed Codecs 625 Typed codecs may be useful to represent header values, especially on 626 response side. An additional typed header representation could be 627 defined, adding support for a small number of codecs such as: 629 o An Integer codec: may be useful for headers such as 'Age' and 630 'Content-Length'. 632 o A Date codec: may be useful for headers such as 'Date', 'Expires', 633 'If-Modified-Since', 'Last-Modified'. 635 6.2. Specific header processing 637 Some (name,value) pairs may be singled out to improve network nodes 638 processing, such as: 640 o The request line (verb, version and URL) for HTTP requests. 642 o The response line (status and version) for HTTP responses. 644 For those headers, the specification may define specific rules that 645 can improve the processing cost, at the expense of some compression 646 loss: 648 o All those headers are placed as the first headers in the 649 SYN_STREAM frame, with a predefined order. 651 o Verb, version and status are represented as integers with zero-bit 652 prefix. 654 o Indexed, delta or literal representation may be used for URL 655 values. In the case of delta and literal representation, only the 656 substitution mode is used so that a processor only needs to store 657 the URL of the previous message to compute the URL of the current 658 message. 660 6.3. Security Issues 662 Adequate use of delta and indexed representation before using of 663 Deflate are supposed to solve security issues such as the CRIME 664 attack. For instance, if cookie headers are represented as indexed 665 headers as much as possible, attackers may be prevented from 666 progressively learning its value. 668 This point should be confirmed with deeper analysis. Additional 669 study should also be done to evaluate whether the proposed indexed 670 and delta representation create any new security issue. 672 6.4. Deflate Partial Usage 674 To circumvent Deflate issues related to both security and network 675 intermediaries, the header set of a given message can be split in two 676 buckets. A first bucket would be sent without using Deflate, while 677 the second bucket would be further compressed using Deflate. The 678 decision would be done by the encoder. The specification could 679 define a minimum set of headers that SHOULD never be compressed using 680 Deflate, for instance URLs and cookies. 682 Another possibility would be to define Deflate as a specific 683 representation. The use of Deflate would then be decided on per- 684 header basis. That would enable excluding any header that may 685 contain sensitive data. The overall scheme would be less efficient 686 though (padding bits and so on). 688 Additional analysis of the complexity and benefit of these approaches 689 would be needed to go further. For instance, these approaches should 690 be compared to the use of Deflate restricted to Huffman-coding in 691 terms of simplicity and compression benefits. 693 6.5. Max length and entry numbers 695 The integer representation allows representation of unbounded values. 696 If bounding the table entries number or string lengths, the integer 697 encoding may be further optimized. 699 o Decide whether to limit the length of strings to a max value and 700 if so which value, 32768? 702 o Decide whether to limit name table entries to 256? 704 o Decide whether to limit header table entries to 16384? 706 7. Security Considerations 708 This section should be completed according the previous sections. 710 8. IANA Considerations 712 This memo includes no request to IANA. 714 9. References 716 Appendix A. Initial header names 718 A.1. Requests 720 Indexes strictly lower than 14 are always encoded on 1 byte. Hence, 721 the 14 most frequent names should be set in the 14 first positions. 722 This table may be updated based on statistical analysis of header 723 names frequency and specific HTTP 2.0 header rules (like removal of 724 'proxy-connection', url being split or not...). 726 +---------+------------------------------------+ 727 | Index | Header Name | 728 +---------+------------------------------------+ 729 | 0 | accept | 730 +---------+------------------------------------+ 731 | 1 | accept-charset | 732 +---------+------------------------------------+ 733 | 2 | accept-encoding | 734 +---------+------------------------------------+ 735 | 3 | accept-language | 736 +---------+------------------------------------+ 737 | 4 | cookie | 738 +---------+------------------------------------+ 739 | 5 | method | 740 +---------+------------------------------------+ 741 | 6 | host | 742 +---------+------------------------------------+ 743 | 7 | if-modified-since | 744 +---------+------------------------------------+ 745 | 8 | keep-alive | 746 +---------+------------------------------------+ 747 | 9 | url | 748 +---------+------------------------------------+ 749 | 10 | user-agent | 750 +---------+------------------------------------+ 751 | 11 | version | 752 +---------+------------------------------------+ 753 | 12 | proxy-connection | 754 +---------+------------------------------------+ 755 | 13 | referer | 756 +---------+------------------------------------+ 757 | 14 | accept-datetime | 758 +---------+------------------------------------+ 759 | 15 | authorization | 760 +---------+------------------------------------+ 761 | 16 | allow | 762 +---------+------------------------------------+ 763 | 17 | cache-control | 764 +---------+------------------------------------+ 765 | 18 | connection | 766 +---------+------------------------------------+ 767 | 19 | content-length | 768 +---------+------------------------------------+ 769 | 20 | content-md5 | 770 +---------+------------------------------------+ 771 | 21 | content-type | 772 +---------+------------------------------------+ 773 | 22 | date | 774 +---------+------------------------------------+ 775 | 23 | expect | 776 +---------+------------------------------------+ 777 | 24 | from | 778 +---------+------------------------------------+ 779 | 25 | if-match | 780 +---------+------------------------------------+ 781 | 26 | if-none-match | 782 +---------+------------------------------------+ 783 | 27 | if-range | 784 +---------+------------------------------------+ 785 | 28 | if-unmodified-since | 786 +---------+------------------------------------+ 787 | 29 | max-forwards | 788 +---------+------------------------------------+ 789 | 30 | pragma | 790 +---------+------------------------------------+ 791 | 31 | proxy-authorization | 792 +---------+------------------------------------+ 793 | 32 | range | 794 +---------+------------------------------------+ 795 | 33 | te | 796 +---------+------------------------------------+ 797 | 34 | upgrade | 798 +---------+------------------------------------+ 799 | 35 | via | 800 +---------+------------------------------------+ 801 | 36 | warning | 802 +---------+------------------------------------+ 804 A.2. Responses 806 Indexes strictly lower than 14 are always encoded on 1 byte. Hence, 807 the 14 most frequent names should be set in the 14 first positions. 808 This table may be updated based on statistical analysis of header 809 names frequency and specific HTTP 2.0 header rules. 811 +---------+------------------------------------+ 812 | Index | Header Name | 813 +---------+------------------------------------+ 814 | 0 | age | 815 +---------+------------------------------------+ 816 | 1 | cache-control | 817 +---------+------------------------------------+ 818 | 2 | content-length | 819 +---------+------------------------------------+ 820 | 3 | content-type | 821 +---------+------------------------------------+ 822 | 4 | date | 823 +---------+------------------------------------+ 824 | 5 | etag | 825 +---------+------------------------------------+ 826 | 6 | expires | 827 +---------+------------------------------------+ 828 | 7 | last-modified | 829 +---------+------------------------------------+ 830 | 8 | server | 831 +---------+------------------------------------+ 832 | 9 | set-cookie | 833 +---------+------------------------------------+ 834 | 10 | status | 835 +---------+------------------------------------+ 836 | 11 | vary | 837 +---------+------------------------------------+ 838 | 12 | version | 839 +---------+------------------------------------+ 840 | 13 | via | 841 +---------+------------------------------------+ 842 | 14 | access-control-allow-origin | 843 +---------+------------------------------------+ 844 | 15 | accept-ranges | 845 +---------+------------------------------------+ 846 | 16 | allow | 847 +---------+------------------------------------+ 848 | 17 | connection | 849 +---------+------------------------------------+ 850 | 18 | content-disposition | 851 +---------+------------------------------------+ 852 | 19 | content-encoding | 853 +---------+------------------------------------+ 854 | 20 | content-language | 855 +---------+------------------------------------+ 856 | 21 | content-location | 857 +---------+------------------------------------+ 858 | 22 | content-md5 | 859 +---------+------------------------------------+ 860 | 23 | content-range | 861 +---------+------------------------------------+ 862 | 24 | link | 863 +---------+------------------------------------+ 864 | 25 | location | 865 +---------+------------------------------------+ 866 | 26 | p3p | 867 +---------+------------------------------------+ 868 | 27 | pragma | 869 +---------+------------------------------------+ 870 | 28 | proxy-authenticate | 871 +---------+------------------------------------+ 872 | 29 | refresh | 873 +---------+------------------------------------+ 874 | 30 | retry-after | 875 +---------+------------------------------------+ 876 | 31 | strict-transport-security | 877 +---------+------------------------------------+ 878 | 32 | trailer | 879 +---------+------------------------------------+ 880 | 33 | transfer-encoding | 881 +---------+------------------------------------+ 882 | 34 | warning | 883 +---------+------------------------------------+ 884 | 35 | www-authenticate | 885 +---------+------------------------------------+ 887 A.3. Example 889 Here is an example that illustrates different representations and how 890 tables are updated. 892 A.3.1. First header set 894 The first header set to represent is the following: 896 url: http://www.example.org/my-example/index.html 897 user-agent: my-user-agent 898 x-my-header: first 900 The header table is empty, all headers are represented as literal 901 headers with indexing. The 'x-my-header' header name is not in the 902 header name table and is encoded literally. This gives the following 903 representation: 905 0x2A (literal header with indexing, name index = 9) 906 0x2C (header value string length = 44) 907 http://www.example.org/my-example/index.html 908 0x2B (literal header with indexing, name index = 10) 909 0x0D (header value string length = 43) 910 my-user-agent 911 0x20 (literal header with indexing, new name) 912 0x0B (header name string length = 11) 913 x-my-header 914 0x05 (header value string length = 5) 915 first 917 The header tables are as follow after the processing of these 918 headers: 920 Name table 921 +---------+---------------------------------------------+ 922 | Index | Header Name | 923 +---------+---------------------------------------------+ 924 | 0 | accept | 925 +---------+---------------------------------------------+ 926 | 1 | accept-charset | 927 +---------+---------------------------------------------+ 928 | ... | ... | 929 +---------+---------------------------------------------+ 930 | 36 | warning | 931 +---------+---------------------------------------------+ 932 | 37 | x-my-header | added name 933 +---------+---------------------------------------------+ 935 Header table 936 +----+-------------+------------------------------------+ 937 | 0 | url | http://www.example.org/ | added pair 938 | | | my-example/index.html | 939 +----+-------------+------------------------------------+ 940 | 1 | user-agent | my-user-agent | added pair 941 +----+-------------+------------------------------------+ 942 | 2 | x-my-header | first | added pair 943 +----+-------------+------------------------------------+ 945 A.3.2. Second header set 947 The second header set to represent is the following: 949 url: http://www.example.org/my-example/resources/script.js 950 user-agent: my-user-agent 951 x-my-header: second 953 The url header is represented as a delta header with substitution. 954 The user-agent header will be represented as a short header. The x 955 -my-header will be represented as a literal header with indexing. 957 0x70 (delta header with substitution, header index = 0) 958 0x22 (common prefix length = 32) 959 0x13 (suffix value length = 19) 960 resources/script.js 961 0x81 (indexed header, index = 1) 962 0x2f 0x17 (literal header with indexing, name index = 37) 963 0x05 (header value string length = 5) 964 second 966 The name table remains unchanged. The header table is updated as 967 follow: 969 +----+-------------+------------------------------------+ 970 | 0 | url | http://www.example.org/ | substituted 971 | | | my-example/resources/script.js | pair 972 +----+-------------+------------------------------------+ 973 | 1 | user-agent | my-user-agent | 974 +----+-------------+------------------------------------+ 975 | 2 | x-my-header | first | 976 +----+-------------+------------------------------------+ 977 | 3 | x-my-header | second | added pair 978 +----+-------------+------------------------------------+ 980 Authors' Addresses 982 Herve Ruellan 984 Email: herve.ruellan@crf.canon.fr 986 Jun Fujisawa 987 Canon, Inc. 988 3-30-2 Shimomaruko 989 Ohta-ku, Tokyo 146-8501 990 Japan 992 Email: fujisawa.jun@canon.co.jp 994 Romain Bellessort 996 Email: romain.bellessort@crf.canon.fr 998 Youenn Fablet 1000 Email: youenn.fablet@crf.canon.fr