idnits 2.17.1 draft-snell-httpbis-bohe-07.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 an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 194 has weird spacing: '... bit coun...' == Line 196 has weird spacing: '... bit coun...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 23, 2013) is 3993 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '25' on line 746 -- Looks like a reference, but probably isn't: '24' on line 837 -- Looks like a reference, but probably isn't: '12' on line 871 -- Looks like a reference, but probably isn't: '14' on line 839 -- Looks like a reference, but probably isn't: '15' on line 784 -- Looks like a reference, but probably isn't: '6' on line 872 -- Looks like a reference, but probably isn't: '7' on line 843 -- Looks like a reference, but probably isn't: '10' on line 835 -- Looks like a reference, but probably isn't: '5' on line 861 -- Looks like a reference, but probably isn't: '18' on line 805 -- Looks like a reference, but probably isn't: '17' on line 870 -- Looks like a reference, but probably isn't: '9' on line 867 -- Looks like a reference, but probably isn't: '13' on line 809 -- Looks like a reference, but probably isn't: '8' on line 923 -- Looks like a reference, but probably isn't: '11' on line 820 -- Looks like a reference, but probably isn't: '19' on line 841 -- Looks like a reference, but probably isn't: '4' on line 846 == Unused Reference: 'RFC2119' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC6265' is defined on line 556, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.M. Snell 3 Internet-Draft April 23, 2013 4 Intended status: Informational 5 Expires: October 25, 2013 7 HTTP/2.0 Discussion: Stored Header Encoding 8 draft-snell-httpbis-bohe-07 10 Abstract 12 This memo describes a proposed alternative encoding for headers that 13 combines the best concepts from the proposed Delta and HeaderDiff 14 options with the typed value codecs introduced by previous versions 15 of this draft. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF 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 October 25, 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. 46 Table of Contents 48 1. Stored Header Encoding . . . . . . . . . . . . . . . . . . . 2 49 2. State Model . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Header Serialization . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Header Group Prefix . . . . . . . . . . . . . . . . . . . 6 52 3.2. Index Header Group . . . . . . . . . . . . . . . . . . . 7 53 3.3. Index Range Header Group . . . . . . . . . . . . . . . . 7 54 3.4. Cloned Index Header Group . . . . . . . . . . . . . . . . 8 55 3.5. Literal Header Group . . . . . . . . . . . . . . . . . . 8 56 4. Header Values . . . . . . . . . . . . . . . . . . . . . . . . 9 57 4.1. UTF-8 Text Values . . . . . . . . . . . . . . . . . . . . 10 58 4.2. Numeric Values . . . . . . . . . . . . . . . . . . . . . 10 59 4.3. Timestamp Values . . . . . . . . . . . . . . . . . . . . 10 60 4.4. Raw Binary Octet Values . . . . . . . . . . . . . . . . . 10 61 4.5. Unsigned Variable Length Integer Syntax . . . . . . . . . 11 62 4.6. Huffman Coding . . . . . . . . . . . . . . . . . . . . . 11 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 6.2. Informational References . . . . . . . . . . . . . . . . 13 67 Appendix A. Huffman Tables . . . . . . . . . . . . . . . . . . . 13 68 Appendix B. Static Storage Cache . . . . . . . . . . . . . . . . 20 69 Appendix C. Updated Standard Header Definitions . . . . . . . . 23 70 Appendix D. State Management Alternatives . . . . . . . . . . . 25 71 Appendix E. Alternative Timestamp encodings . . . . . . . . . . 26 72 Appendix F. Alternative uvarint encodings . . . . . . . . . . . 27 73 F.1. Option 1: . . . . . . . . . . . . . . . . . . . . . . . . 27 74 F.2. Option 2: . . . . . . . . . . . . . . . . . . . . . . . . 28 75 Appendix G. Set-Cookie and Cookie Alternatives . . . . . . . . . 29 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 78 1. Stored Header Encoding 80 The Stored Header Encoding is an alternative "binary header encoding" 81 for HTTP/2.0 that combines the best elements from three other 82 proposed encodings, including: 84 o The "Header Delta Compression" scheme proposed by Roberto Peon in 85 http://tools.ietf.org/html/draft-rpeon-httpbis-header- 86 compression-03 88 o The "Header Diff" encoding proposed by Herve Reullan, Jun 89 Fujisawa, Romain Bellessort, and Youenn Fablet in http:// 90 tools.ietf.org/html/draft-ruellan-headerdiff-00 92 o The "Binary Optimized Header Encoding" proposed by James Snell 93 (me) in http://tools.ietf.org/html/draft-snell-httpbis-bohe-03 95 The Stored Header Encoding seeks to find an elegant, efficient and 96 simple marriage of the best concepts from each of these separate 97 proposals. 99 2. State Model 101 The compressor and decompressor each maintain a cache of header value 102 pairs. There is a static cache, prepopulated by the specification, 103 and a dynamic cache, populated through the compression and 104 decompression process. Each cache contains a maximum of 128 105 individual key+value pairs. 107 Each item in the index is referenced by an 8-bit identifier. The 108 most significant bit identifies whether an item from the static or 109 dynamic cache is being referenced. Note: the Nil byte (0x00) is a 110 valid identifier for the dynamic cache. 112 0xxxxxxx -- Dynamic Cache 113 1xxxxxxx -- Static Cache 115 The dynamic cache is managed in a "least recently written" style, 116 that is, as the cache fills to capacity in both number of entries and 117 maximum stored byte size, the least recently written items are 118 dropped and those index positions are reused. 120 Index positions from the dynamic cache are assigned in "encounter 121 order", beginning from 0x00 and increasing monotonically to 0x7F. 122 That is to say, the positions are assigned in precisely the same 123 order that they are serialized, and thereby encountered by the 124 decompressor upon reading and processing the block. 126 Each item in the store consists of a Header Name and a Value. The 127 Name is a lower-case ISO-8859-1 character sequence. The Value is 128 either a UTF-8 string, a number, a Timestamp or an arbitrary sequence 129 of binary octets. 131 The available size of the stored compression state can be capped by 132 the decompressor. Each stored value contributes to the accumulated 133 size of the storage state. As new key+value pairs are assigned 134 positions in the dynamic cache, the least-recently assigned items 135 must be removed if necessary to free up the required space. 137 The size of string values is measured by the number of UTF-8 bytes 138 required for the character sequence. 140 The size of number and timestamp values are measured by the number of 141 unsigned variable length integer (uvarint) encoded bytes it takes to 142 represent the value (see the section of value types below). 144 The size of raw binary values is measured by the number of octets. 146 Header names DO NOT contribute to the stored state size of the 147 compressor; only the size of the value is considered. Duplicate 148 values MUST be counted individually. 150 3. Header Serialization 152 Headers are serialized into four typed header groups, each 153 represented by a two-bit identifier. These groups are serialized 154 sequentially. A serialized header block can contain, at most 256 155 header groups. The first byte of the serialized block is an 156 unsigned, 0-based counter indicating the number of groups. A 157 serialized block MUST contain at least one header group. 159 00 -- Index Header Group 160 01 -- Index Range Header Group 161 10 -- Cloned Index Header Group 162 11 -- Literal Header Group 164 The Cloned Index (10) and Literal (11) header group types have an 165 additional "ephemeral" property that indicates whether or not the 166 group affects the compression state. 168 Each header group contains a single 8-bit prefix and up to 32 169 distinct header instances. 171 Wire Format 173 header-block = OCTET *(index-header-group / 174 index-range-header-group / 175 cloned-index-header-group / 176 literal-header-group) 178 ; Header Group Prefix = 8 bits ... 179 ; First two bits = header-group-type 180 ; Third bit = ephemeral flag 181 ; Final five bits = instance counter 182 ; 183 index-header-group-type = 00 184 index-range-group-type = 01 185 cloned-index-group-type = 10 186 literal-group-type = 11 187 count = 5bit 189 index-header-prefix = index-header-group-type 190 unset count ; 000xxxxx 191 index-range-header-prefix = index-header-group-type 192 unset count ; 010xxxxx 193 cloned-index-header-prefix = cloned-index-group-type 194 bit count ; 10?xxxxx 195 literal-header-prefix = literal-group-type 196 bit count ; 11?xxxxx 198 ; Cache Index Identifier = 8 bits ... 199 ; 0xxxxxxx = Dynamic Cache Identifier 200 ; 1xxxxxxx = Static Cache Identifier 201 cache-index = %x00-FF 203 ; Index Header Group 204 index-header-group = index-header-prefix 205 1*32cache-index 207 ; Index-Range Header Group 208 ; Contains a pair of cache-index values, second MUST 209 ; me strictly higher in value than the first... 210 index-range-header-group = index-range-header-prefix 211 1*32(cache-index cache-index) 213 ; Cloned-Index Header Group 214 cloned-index-header-group = cloned-index-header-prefix 215 1*32(cache-index value) 217 ; Literal Header Group 218 literal-header-group = literal-header-prefix 219 1*32(name value) 221 value = text-value / 222 number-value / 223 timestamp-value / 224 binary-value 226 text-value-type = 00 ; two bits 227 number-value-type = 01 228 timestamp-value-type = 10 229 binary-value-type = 11 231 text-value-prefix = text-value-type 232 unset count ; 000xxxxx 233 number-value-prefix = number-value-type 234 unset count ; 010xxxxx 236 timestamp-value-prefix = timestamp-value-type 237 unset count ; 100xxxxx 238 binary-value-prefix = binary-value-type 239 unset count ; 110xxxxx 241 text-value = text-value-prefix *32string 242 number-value = number-value-type *32uvarint 243 timestamp-value = timestamp-value-prefix *32uvarint 244 binary-value = binary-value-prefix uvarint *OCTET 246 uvarint = *uvarint-continuation uvarint-final 247 uvarint-continuation = %x80-FF 248 uvarint-final = %x00-7F 250 name = 1*tchar 251 tchar = "!" / "#" / "$" / "%" / "&" / 252 "'" / "*" / "+" / "-" / "." / 253 "^" / "_" / "`" / "|" / "~" 254 / DIGIT / ALPHA 256 string = uvarint *(HUFFMAN-ENCODED-CHAR) 257 HUFFMAN-EOF 258 padding-to-nearest-byte; 259 padding-to-nearest-byte = *7unset 261 bit = set / unset 262 unset = 0 263 set = 1 265 3.1. Header Group Prefix 267 The Header Group Prefix is a single octet that provides three 268 distinct pieces of information: 270 00 0 00000 272 The first two most significant bits of the header group prefix 273 identify the group type. 275 The next bit is the "ephemeral flag" and is used only for Cloned and 276 Literal group types. This bit indicates whether or not the group 277 alters the stored compression state. 279 The remaining five bits specify the number of header instances in the 280 group, with 00000 indicating that the group contains 1 instance and 281 11111 contains 32. A header group MUST contain at least one 282 instance. 284 The remaining serialization of the header group depends entirely on 285 the group type. 287 3.2. Index Header Group 289 The serialization of the Index Header Group consists of the Header 290 Group Prefix and up to 32 additional octets, each referencing a 291 single 8-bit storage index identifier for items in either the Static 292 or Dynamic Cache. 294 For instance 296 00000000 00000000 = References item #0 from 297 the dynamic cache 299 00000001 00000000 10000000 = References item #0 from the 300 dynamic cache and item #0 301 from the static cache 303 Index Header Groups do not affect the stored compression state. If 304 an Index Header Group references a header index that has not yet been 305 allocated, the deserialization MUST terminate with an error. This 306 likely means that the compression state has become out of sync and 307 needs to be reestablished. 309 3.3. Index Range Header Group 311 The serialization of the Index Range Header Group consists of the 312 Header Group Prefix and up to 32 additional 2-octet (16 bits) pairs 313 of 8-bit storage index identifiers. Each pair specifies a sequential 314 range of adjacent ranges. 316 For instance: 318 01000000 00000000 00000100 = References items #0-#4 from 319 the dynamic cache. 320 (five distinct items total) 322 A range MAY span dynamic and static index values. Index values are 323 treated as unsigned byte values, so indices from the static cache are 324 numerically greater than dynamic cache values.. e.g. 326 01000000 01111111 10000001 = References item #127 from the 327 dynamic cache, and items #0 328 and #1 from the static cache. 330 Index Range Header Groups do not affect the stored compression state. 331 If a range references a header index that has not yet been allocated, 332 the deserialization MUST terminate with an error. This likely means 333 that the compression state has become out of sync and needs to be 334 reestablished. 336 3.4. Cloned Index Header Group 338 The serialization of the Cloned Index Header Group consists of the 339 Header Group Prefix and up to 32 Index+Value pairs. Each Index+Value 340 pair consists of a leading 8-bit storage index of an existing stored 341 header followed by a new serialized value. The serialization of the 342 value depends on the value type (see discussion of Value 343 serialization below). 345 The Cloned Header Group affects the stored compression state if, and 346 only if, the "ephemeral" flag in the Header Group Prefix is NOT set. 347 If the header group is not marked as being ephemeral, then the 348 specified value is stored in the next available storage index using 349 the key name from the referenced storage index. 351 For instance, assume the dynamic cache currently contains an item at 352 index #1 with key name "foo" and value "bar", the following causes a 353 new item to be added to the storage with key name "foo" and value 354 "baz": 356 10000000 00000001 00000000 00000100 357 10111000 01001111 10110101 00100000 359 An explanation of the value syntax is given a bit later. 361 If a Cloned Header Group references a header index that has not yet 362 been allocated, the deserialization MUST terminate with an error. 363 This likely means that the compression state has become out of sync 364 and needs to be reestablished. 366 3.5. Literal Header Group 368 The serialization of the Literal Header Group consists of the Header 369 Group Prefix and up to 32 Name+Value pairs. Each Name+Value pair 370 consists of a length-prefixed sequence of ASCII bytes specifying the 371 Header Name followed by the serialized value. The serialization of 372 the value depends on the value type. The length prefix is encoded as 373 an unsigned variable length integer (uvarint). The length prefix 374 SHOULD NOT be longer than five octets and SHOULD NOT specify a value 375 larger than 0xFFFF. 377 The Literal Heaer Group affects the stored compression state if, and 378 only if, the "ephemeral" flag in the Header Group Prefix is NOT set. 379 If the header group is not marked as being ephemeral, then the 380 specified key name and value is stored in the next available storage 381 index. 383 For instance: 385 11000000 00000011 01100110 01101111 386 01101111 00000000 00000010 10111000 387 01000100 11010010 389 Stores a new header with name "foo" and value "baz" in the dynamic 390 cache. 392 Each Header Group consists of up to 32 distinct Header Instances. If 393 a particular serialization block contains more than 32 intances of a 394 given type, then multiple instances of the Header Group Type can be 395 included in the serialized block. For instance, if a given message 396 contains 33 index references, the serialized block may contain two 397 separate Index Header Groups. While this is allowed, it is expected 398 to be rare. 400 4. Header Values 402 Header Values can be one of four types, each identified by a two-bit 403 identifier. 405 o 00 -- UTF-8 Text 407 o 01 -- Numeric 409 o 10 -- Timetamp 411 o 11 -- Raw Binary Octets 413 An individual value MAY consist of up to 32 distinct discreet "value 414 instances". A value with multiple instances is considered, for all 415 intensive purposes, to be a single value. 417 Each serialized value is preceded by an 8-bit Value Prefix. 419 00 0 00000 421 The first two most significant bits specifies the value type. 423 The third significant bit is a reserved flag. Future iterations of 424 this specification might make use of this bit. 426 The final five least-significant bits specify the number of discreet 427 instances in the value. 00000 indicates that one instance is 428 included, 11111 indicates that 32 instances are included. The value 429 MUST contain at least one instance. 431 The remaining serialization depends entirely on the type. 433 4.1. UTF-8 Text Values 435 UTF-8 Text is encoded as a length-prefixed sequence of Huffman- 436 encoded UTF-8 octets. The length prefix is encoded as an unsigned 437 variable-length integer specifying the number of octets after 438 applying the Huffman-encoding. 440 4.2. Numeric Values 442 Numeric values are encoded as unsigned variable-length integers 443 (uvarint) of up to a maximum of 10-octets. Unsigned values larger 444 than 64-bits (0xFFFFFFFFFFFFFFFF) are supported by this format but 445 SHOULD NOT be used. Negative values cannot be represented using this 446 syntax. The uvarint syntax is described below. 448 4.3. Timestamp Values 450 Timestamp values are encoded as unsigned variable-length integers 451 specifying the number of milliseconds that have passed since the 452 standard Epoch (1970-01-01T00:00:00 GMT). The syntax is identical 453 that used for Numeric Values. Dates prior to the epoch cannot be 454 represented using this syntax. 456 Representing timestamps in this manner ensures that timestamps will 457 always encode using six bytes up and until 2109-05-15T07:35:00 GMT, 458 then as seven bytes up to and until 19809-03-05T11:03:41 GMT. 460 4.4. Raw Binary Octet Values 462 Binary values are encoded as a length prefixed sequence of arbitrary 463 octets. The length prefix is encoded as an unsigned variable length 464 integer. 466 4.5. Unsigned Variable Length Integer Syntax 468 The uvarint syntax is identical to that used by Google's protobufs. 469 They are serialized with the least-significant bytes first in batches 470 of 7-bits, with the most significant bit per byte reserved as a 471 continuation bit. Values less than or equal to 127 are serialized 472 using at most one byte; values less than or equal to 16383 are 473 serialized using at most two bytes; values less than or equal to 474 2097151 are serialized using at most three bytes. 476 def uvarint(num): 477 return [] if num = 0 478 ret = [] 479 while(num != 0): 480 m = num >>> 7 ; unsigned shift left 7 bits 481 ret.push (byte)((num & ~0x80) | ( m > 0 ? 0x80 : 0x00 )); 482 num = m; 483 return ret; 485 For example, the binary representation of the 32-bit integer 217 is: 487 00000000 00000000 00000000 11011001 489 The variable length encoding is: 491 11011001 00000001 493 The binary representation of the 32-bit integer 1386210052 is: 495 01010010 10011111 11100011 00000100 497 The variable length encoding is: 499 10000100 11000110 11111111 10010100 00000101 501 4.6. Huffman Coding 503 All UTF-8 text values are compressed using a modified static huffman 504 code. "Modified" because the encoded version may contain compact- 505 representations of raw, arbitrary UTF-8 bytes that are not covered by 506 the static huffman code table. 508 There are two huffman tables in use, one for HTTP Requests and 509 another for HTTP Responses, each covers UTF-8 codepoints strictly 510 less than 128 as well the fifty possible UTF-8 leading octets. 512 The encoded result MUST end with a specific terminal sequence of bits 513 called the "HUFFMAN_EOF". Currently, the HUFFMAN_EOF is the same for 514 both the Request and Response tables, but that could change if the 515 tables are regenerated. Currently, the HUFFMAN_EOF sequence is 516 101001. 518 Codepoints >= 128 are handled by first taking the leading octet of 519 the UTF-8 representation and serializing it's associated huffman code 520 from the table to the output stream, then, depending on the octets 521 value, serializing the six least significant bits from each of the 522 remaining trailing octets. 524 For instance, the UTF-8 character U+00D4 (LATIN CAPITAL LETTER O WITH 525 CIRCUMFLEX), with UTF-8 representation of C394 (hex) is encoded as: 527 11000100 01010010 10010000 529 The first 8-bits represents the huffman-table prefix, the first six 530 most significant bytes of the second octet are taken directly from 531 the six least significant bits of the second UTF-8 byte (0x94). 532 Following those six bits are the six bits of the HUFFMAN_EOF 101001, 533 followed by four unset padding bits. 535 The number of raw UTF-8 bits to write depends on the value of the 536 leading octet. If the value is between 0xC2 and 0xDF (inclusive), 537 six bits from the second continuation byte is encoded. If the value 538 is between 0xE0 and 0xEF (inclusive), six bits from the second and 539 third continuation bytes are encoded. If the value is between 0xF0 540 and 0xF4 (inclusive), six bits from the second, third and fourth 541 continuation bytes are encoded. UTF-8 codepoints that require 542 greater than four bytes to encode cannot be represented. 544 5. Security Considerations 546 TBD 548 6. References 549 6.1. Normative References 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 6.2. Informational References 556 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 557 April 2011. 559 Appendix A. Huffman Tables 561 Request Table 563 ( 0) |11111111|11111111|11111111|0 [25] 1fffffe [25] 564 ( 1) |11111111|11111111|11111111|1 [25] 1ffffff [25] 565 ( 2) |11111111|11111111|11100000 [24] ffffe0 [24] 566 ( 3) |11111111|11111111|11100001 [24] ffffe1 [24] 567 ( 4) |11111111|11111111|11100010 [24] ffffe2 [24] 568 ( 5) |11111111|11111111|11100011 [24] ffffe3 [24] 569 ( 6) |11111111|11111111|11100100 [24] ffffe4 [24] 570 ( 7) |11111111|11111111|11100101 [24] ffffe5 [24] 571 ( 8) |11111111|11111111|11100110 [24] ffffe6 [24] 572 ( 9) |11111111|11111111|11100111 [24] ffffe7 [24] 573 ( 10) |11111111|11111111|11101000 [24] ffffe8 [24] 574 ( 11) |11111111|11111111|11101001 [24] ffffe9 [24] 575 ( 12) |11111111|11111111|11101010 [24] ffffea [24] 576 ( 13) |11111111|11111111|11101011 [24] ffffeb [24] 577 ( 14) |11111111|11111111|11101100 [24] ffffec [24] 578 ( 15) |11111111|11111111|11101101 [24] ffffed [24] 579 ( 16) |11111111|11111111|11101110 [24] ffffee [24] 580 ( 17) |11111111|11111111|11101111 [24] ffffef [24] 581 ( 18) |11111111|11111111|11110000 [24] fffff0 [24] 582 ( 19) |11111111|11111111|11110001 [24] fffff1 [24] 583 ( 20) |11111111|11111111|11110010 [24] fffff2 [24] 584 ( 21) |11111111|11111111|11110011 [24] fffff3 [24] 585 ( 22) |11111111|11111111|11110100 [24] fffff4 [24] 586 ( 23) |11111111|11111111|11110101 [24] fffff5 [24] 587 ( 24) |11111111|11111111|11110110 [24] fffff6 [24] 588 ( 25) |11111111|11111111|11110111 [24] fffff7 [24] 589 ( 26) |11111111|11111111|11111000 [24] fffff8 [24] 590 ( 27) |11111111|11111111|11111001 [24] fffff9 [24] 591 ( 28) |11111111|11111111|11111010 [24] fffffa [24] 592 ( 29) |11111111|11111111|11111011 [24] fffffb [24] 593 ( 30) |11111111|11111111|11111100 [24] fffffc [24] 594 ( 31) |11111111|11111111|11111101 [24] fffffd [24] 595 ' ' ( 32) |11111111|0110 [12] ff6 [12] 596 '!' ( 33) |11111111|0111 [12] ff7 [12] 597 '"' ( 34) |11111111|111010 [14] 3ffa [14] 598 '#' ( 35) |11111111|1111100 [15] 7ffc [15] 599 '$' ( 36) |11111111|1111101 [15] 7ffd [15] 600 '%' ( 37) |011000 [6] 18 [6] 601 '&' ( 38) |1010100 [7] 54 [7] 602 ''' ( 39) |11111111|1111110 [15] 7ffe [15] 603 '(' ( 40) |11111111|1000 [12] ff8 [12] 604 ')' ( 41) |11111111|1001 [12] ff9 [12] 605 '*' ( 42) |11111111|1010 [12] ffa [12] 606 '+' ( 43) |11111111|1011 [12] ffb [12] 607 ',' ( 44) |11111011|10 [10] 3ee [10] 608 '-' ( 45) |011001 [6] 19 [6] 609 '.' ( 46) |00010 [5] 2 [5] 610 '/' ( 47) |00011 [5] 3 [5] 611 '0' ( 48) |011010 [6] 1a [6] 612 '1' ( 49) |011011 [6] 1b [6] 613 '2' ( 50) |011100 [6] 1c [6] 614 '3' ( 51) |011101 [6] 1d [6] 615 '4' ( 52) |1010101 [7] 55 [7] 616 '5' ( 53) |1010110 [7] 56 [7] 617 '6' ( 54) |1010111 [7] 57 [7] 618 '7' ( 55) |1011000 [7] 58 [7] 619 '8' ( 56) |1011001 [7] 59 [7] 620 '9' ( 57) |1011010 [7] 5a [7] 621 ':' ( 58) |011110 [6] 1e [6] 622 ';' ( 59) |11111011|11 [10] 3ef [10] 623 '<' ( 60) |11111111|11111111|10 [18] 3fffe [18] 624 '=' ( 61) |011111 [6] 1f [6] 625 '>' ( 62) |11111111|11111110|0 [17] 1fffc [17] 626 '?' ( 63) |11110110|0 [9] 1ec [9] 627 '@' ( 64) |11111111|11100 [13] 1ffc [13] 628 'A' ( 65) |10111010 [8] ba [8] 629 'B' ( 66) |11110110|1 [9] 1ed [9] 630 'C' ( 67) |10111011 [8] bb [8] 631 'D' ( 68) |10111100 [8] bc [8] 632 'E' ( 69) |11110111|0 [9] 1ee [9] 633 'F' ( 70) |10111101 [8] bd [8] 634 'G' ( 71) |11111100|00 [10] 3f0 [10] 635 'H' ( 72) |11111100|01 [10] 3f1 [10] 636 'I' ( 73) |11110111|1 [9] 1ef [9] 637 'J' ( 74) |11111100|10 [10] 3f2 [10] 638 'K' ( 75) |11111111|010 [11] 7fa [11] 639 'L' ( 76) |11111100|11 [10] 3f3 [10] 640 'M' ( 77) |11111000|0 [9] 1f0 [9] 641 'N' ( 78) |11111101|00 [10] 3f4 [10] 642 'O' ( 79) |11111101|01 [10] 3f5 [10] 643 'P' ( 80) |11111000|1 [9] 1f1 [9] 644 'Q' ( 81) |11111101|10 [10] 3f6 [10] 645 'R' ( 82) |11111001|0 [9] 1f2 [9] 646 'S' ( 83) |11111001|1 [9] 1f3 [9] 647 'T' ( 84) |11111010|0 [9] 1f4 [9] 648 'U' ( 85) |11111101|11 [10] 3f7 [10] 649 'V' ( 86) |11111110|00 [10] 3f8 [10] 650 'W' ( 87) |11111110|01 [10] 3f9 [10] 651 'X' ( 88) |11111110|10 [10] 3fa [10] 652 'Y' ( 89) |11111110|11 [10] 3fb [10] 653 'Z' ( 90) |11111111|00 [10] 3fc [10] 654 '[' ( 91) |11111111|111011 [14] 3ffb [14] 655 '\' ( 92) |11111111|11111111|11111110 [24] fffffe [24] 656 ']' ( 93) |11111111|111100 [14] 3ffc [14] 657 '^' ( 94) |11111111|111101 [14] 3ffd [14] 658 '_' ( 95) |1011011 [7] 5b [7] 659 '`' ( 96) |11111111|11111111|110 [19] 7fffe [19] 660 'a' ( 97) |00100 [5] 4 [5] 661 'b' ( 98) |1011100 [7] 5c [7] 662 'c' ( 99) |00101 [5] 5 [5] 663 'd' (100) |100000 [6] 20 [6] 664 'e' (101) |0000 [4] 0 [4] 665 'f' (102) |100001 [6] 21 [6] 666 'g' (103) |100010 [6] 22 [6] 667 'h' (104) |100011 [6] 23 [6] 668 'i' (105) |00110 [5] 6 [5] 669 'j' (106) |10111110 [8] be [8] 670 'k' (107) |10111111 [8] bf [8] 671 'l' (108) |100100 [6] 24 [6] 672 'm' (109) |100101 [6] 25 [6] 673 'n' (110) |100110 [6] 26 [6] 674 'o' (111) |00111 [5] 7 [5] 675 'p' (112) |01000 [5] 8 [5] 676 'q' (113) |11111010|1 [9] 1f5 [9] 677 'r' (114) |01001 [5] 9 [5] 678 's' (115) |01010 [5] a [5] 679 't' (116) |01011 [5] b [5] 680 'u' (117) |100111 [6] 27 [6] 681 'v' (118) |11000000 [8] c0 [8] 682 'w' (119) |101000 [6] 28 [6] 683 'x' (120) |11000001 [8] c1 [8] 684 'y' (121) |11000010 [8] c2 [8] 685 'z' (122) |11111011|0 [9] 1f6 [9] 686 '{' (123) |11111111|11111110|1 [17] 1fffd [17] 687 '|' (124) |11111111|1100 [12] ffc [12] 688 '}' (125) |11111111|11111111|0 [17] 1fffe [17] 689 '~' (126) |11111111|1101 [12] ffd [12] 690 (127) |101001 [6] 29 [6] 691 (0xC2) |11000011 [8] c3 [8] 692 (0xC3) |11000100 [8] c4 [8] 693 (0xC4) |11000101 [8] c5 [8] 694 (0xC5) |11000110 [8] c6 [8] 695 (0xC6) |11000111 [8] c7 [8] 696 (0xC7) |11001000 [8] c8 [8] 697 (0xC8) |11001001 [8] c9 [8] 698 (0xC9) |11001010 [8] ca [8] 699 (0xCA) |11001011 [8] cb [8] 700 (0xCB) |11001100 [8] cc [8] 701 (0xCC) |11001101 [8] cd [8] 702 (0xCD) |11001110 [8] ce [8] 703 (0xCE) |11001111 [8] cf [8] 704 (0xCF) |11010000 [8] d0 [8] 705 (0xD0) |11010001 [8] d1 [8] 706 (0xD1) |11010010 [8] d2 [8] 707 (0xD2) |11010011 [8] d3 [8] 708 (0xD3) |11010100 [8] d4 [8] 709 (0xD4) |11010101 [8] d5 [8] 710 (0xD5) |11010110 [8] d6 [8] 711 (0xD6) |11010111 [8] d7 [8] 712 (0xD7) |11011000 [8] d8 [8] 713 (0xD8) |11011001 [8] d9 [8] 714 (0xD9) |11011010 [8] da [8] 715 (0xDA) |11011011 [8] db [8] 716 (0xDB) |11011100 [8] dc [8] 717 (0xDC) |11011101 [8] dd [8] 718 (0xDD) |11011110 [8] de [8] 719 (0xDE) |11011111 [8] df [8] 720 (0xDF) |11100000 [8] e0 [8] 721 (0xE0) |11100001 [8] e1 [8] 722 (0xE1) |11100010 [8] e2 [8] 723 (0xE2) |11100011 [8] e3 [8] 724 (0xE3) |11100100 [8] e4 [8] 725 (0xE4) |11100101 [8] e5 [8] 726 (0xE5) |11100110 [8] e6 [8] 727 (0xE6) |11100111 [8] e7 [8] 728 (0xE7) |11101000 [8] e8 [8] 729 (0xE8) |11101001 [8] e9 [8] 730 (0xE9) |11101010 [8] ea [8] 731 (0xEA) |11101011 [8] eb [8] 732 (0xEB) |11101100 [8] ec [8] 733 (0xEC) |11101101 [8] ed [8] 734 (0xED) |11101110 [8] ee [8] 735 (0xEE) |11101111 [8] ef [8] 736 (0xEF) |11110000 [8] f0 [8] 737 (0xF0) |11110001 [8] f1 [8] 738 (0xF1) |11110010 [8] f2 [8] 739 (0xF2) |11110011 [8] f3 [8] 740 (0xF3) |11110100 [8] f4 [8] 741 (0xF4) |11110101 [8] f5 [8] 743 Response Table: 745 ( 0) |11111111|11111111|11111111|0 [25] 1fffffe [25] 746 ( 1) |11111111|11111111|11111111|1 [25] 1ffffff [25] 747 ( 2) |11111111|11111111|11100000 [24] ffffe0 [24] 748 ( 3) |11111111|11111111|11100001 [24] ffffe1 [24] 749 ( 4) |11111111|11111111|11100010 [24] ffffe2 [24] 750 ( 5) |11111111|11111111|11100011 [24] ffffe3 [24] 751 ( 6) |11111111|11111111|11100100 [24] ffffe4 [24] 752 ( 7) |11111111|11111111|11100101 [24] ffffe5 [24] 753 ( 8) |11111111|11111111|11100110 [24] ffffe6 [24] 754 ( 9) |11111111|11111111|11100111 [24] ffffe7 [24] 755 ( 10) |11111111|11111111|11101000 [24] ffffe8 [24] 756 ( 11) |11111111|11111111|11101001 [24] ffffe9 [24] 757 ( 12) |11111111|11111111|11101010 [24] ffffea [24] 758 ( 13) |11111111|11111111|11101011 [24] ffffeb [24] 759 ( 14) |11111111|11111111|11101100 [24] ffffec [24] 760 ( 15) |11111111|11111111|11101101 [24] ffffed [24] 761 ( 16) |11111111|11111111|11101110 [24] ffffee [24] 762 ( 17) |11111111|11111111|11101111 [24] ffffef [24] 763 ( 18) |11111111|11111111|11110000 [24] fffff0 [24] 764 ( 19) |11111111|11111111|11110001 [24] fffff1 [24] 765 ( 20) |11111111|11111111|11110010 [24] fffff2 [24] 766 ( 21) |11111111|11111111|11110011 [24] fffff3 [24] 767 ( 22) |11111111|11111111|11110100 [24] fffff4 [24] 768 ( 23) |11111111|11111111|11110101 [24] fffff5 [24] 769 ( 24) |11111111|11111111|11110110 [24] fffff6 [24] 770 ( 25) |11111111|11111111|11110111 [24] fffff7 [24] 771 ( 26) |11111111|11111111|11111000 [24] fffff8 [24] 772 ( 27) |11111111|11111111|11111001 [24] fffff9 [24] 773 ( 28) |11111111|11111111|11111010 [24] fffffa [24] 774 ( 29) |11111111|11111111|11111011 [24] fffffb [24] 775 ( 30) |11111111|11111111|11111100 [24] fffffc [24] 776 ( 31) |11111111|11111111|11111101 [24] fffffd [24] 777 ' ' ( 32) |11111111|0110 [12] ff6 [12] 778 '!' ( 33) |11111111|0111 [12] ff7 [12] 779 '"' ( 34) |11111111|111010 [14] 3ffa [14] 780 '#' ( 35) |11111111|1111100 [15] 7ffc [15] 781 '$' ( 36) |11111111|1111101 [15] 7ffd [15] 782 '%' ( 37) |011000 [6] 18 [6] 783 '&' ( 38) |1010100 [7] 54 [7] 784 ''' ( 39) |11111111|1111110 [15] 7ffe [15] 785 '(' ( 40) |11111111|1000 [12] ff8 [12] 786 ')' ( 41) |11111111|1001 [12] ff9 [12] 787 '*' ( 42) |11111111|1010 [12] ffa [12] 788 '+' ( 43) |11111111|1011 [12] ffb [12] 789 ',' ( 44) |11111011|10 [10] 3ee [10] 790 '-' ( 45) |011001 [6] 19 [6] 791 '.' ( 46) |00010 [5] 2 [5] 792 '/' ( 47) |00011 [5] 3 [5] 793 '0' ( 48) |011010 [6] 1a [6] 794 '1' ( 49) |011011 [6] 1b [6] 795 '2' ( 50) |011100 [6] 1c [6] 796 '3' ( 51) |011101 [6] 1d [6] 797 '4' ( 52) |1010101 [7] 55 [7] 798 '5' ( 53) |1010110 [7] 56 [7] 799 '6' ( 54) |1010111 [7] 57 [7] 800 '7' ( 55) |1011000 [7] 58 [7] 801 '8' ( 56) |1011001 [7] 59 [7] 802 '9' ( 57) |1011010 [7] 5a [7] 803 ':' ( 58) |011110 [6] 1e [6] 804 ';' ( 59) |11111011|11 [10] 3ef [10] 805 '<' ( 60) |11111111|11111111|10 [18] 3fffe [18] 806 '=' ( 61) |011111 [6] 1f [6] 807 '>' ( 62) |11111111|11111110|0 [17] 1fffc [17] 808 '?' ( 63) |11110110|0 [9] 1ec [9] 809 '@' ( 64) |11111111|11100 [13] 1ffc [13] 810 'A' ( 65) |10111010 [8] ba [8] 811 'B' ( 66) |11110110|1 [9] 1ed [9] 812 'C' ( 67) |10111011 [8] bb [8] 813 'D' ( 68) |10111100 [8] bc [8] 814 'E' ( 69) |11110111|0 [9] 1ee [9] 815 'F' ( 70) |10111101 [8] bd [8] 816 'G' ( 71) |11111100|00 [10] 3f0 [10] 817 'H' ( 72) |11111100|01 [10] 3f1 [10] 818 'I' ( 73) |11110111|1 [9] 1ef [9] 819 'J' ( 74) |11111100|10 [10] 3f2 [10] 820 'K' ( 75) |11111111|010 [11] 7fa [11] 821 'L' ( 76) |11111100|11 [10] 3f3 [10] 822 'M' ( 77) |11111000|0 [9] 1f0 [9] 823 'N' ( 78) |11111101|00 [10] 3f4 [10] 824 'O' ( 79) |11111101|01 [10] 3f5 [10] 825 'P' ( 80) |11111000|1 [9] 1f1 [9] 826 'Q' ( 81) |11111101|10 [10] 3f6 [10] 827 'R' ( 82) |11111001|0 [9] 1f2 [9] 828 'S' ( 83) |11111001|1 [9] 1f3 [9] 829 'T' ( 84) |11111010|0 [9] 1f4 [9] 830 'U' ( 85) |11111101|11 [10] 3f7 [10] 831 'V' ( 86) |11111110|00 [10] 3f8 [10] 832 'W' ( 87) |11111110|01 [10] 3f9 [10] 833 'X' ( 88) |11111110|10 [10] 3fa [10] 834 'Y' ( 89) |11111110|11 [10] 3fb [10] 835 'Z' ( 90) |11111111|00 [10] 3fc [10] 836 '[' ( 91) |11111111|111011 [14] 3ffb [14] 837 '\' ( 92) |11111111|11111111|11111110 [24] fffffe [24] 838 ']' ( 93) |11111111|111100 [14] 3ffc [14] 839 '^' ( 94) |11111111|111101 [14] 3ffd [14] 840 '_' ( 95) |1011011 [7] 5b [7] 841 '`' ( 96) |11111111|11111111|110 [19] 7fffe [19] 842 'a' ( 97) |00100 [5] 4 [5] 843 'b' ( 98) |1011100 [7] 5c [7] 844 'c' ( 99) |00101 [5] 5 [5] 845 'd' (100) |100000 [6] 20 [6] 846 'e' (101) |0000 [4] 0 [4] 847 'f' (102) |100001 [6] 21 [6] 848 'g' (103) |100010 [6] 22 [6] 849 'h' (104) |100011 [6] 23 [6] 850 'i' (105) |00110 [5] 6 [5] 851 'j' (106) |10111110 [8] be [8] 852 'k' (107) |10111111 [8] bf [8] 853 'l' (108) |100100 [6] 24 [6] 854 'm' (109) |100101 [6] 25 [6] 855 'n' (110) |100110 [6] 26 [6] 856 'o' (111) |00111 [5] 7 [5] 857 'p' (112) |01000 [5] 8 [5] 858 'q' (113) |11111010|1 [9] 1f5 [9] 859 'r' (114) |01001 [5] 9 [5] 860 's' (115) |01010 [5] a [5] 861 't' (116) |01011 [5] b [5] 862 'u' (117) |100111 [6] 27 [6] 863 'v' (118) |11000000 [8] c0 [8] 864 'w' (119) |101000 [6] 28 [6] 865 'x' (120) |11000001 [8] c1 [8] 866 'y' (121) |11000010 [8] c2 [8] 867 'z' (122) |11111011|0 [9] 1f6 [9] 868 '{' (123) |11111111|11111110|1 [17] 1fffd [17] 869 '|' (124) |11111111|1100 [12] ffc [12] 870 '}' (125) |11111111|11111111|0 [17] 1fffe [17] 871 '~' (126) |11111111|1101 [12] ffd [12] 872 (127) |101001 [6] 29 [6] 873 (0xC2) |11000011 [8] c3 [8] 874 (0xC3) |11000100 [8] c4 [8] 875 (0xC4) |11000101 [8] c5 [8] 876 (0xC5) |11000110 [8] c6 [8] 877 (0xC6) |11000111 [8] c7 [8] 878 (0xC7) |11001000 [8] c8 [8] 879 (0xC8) |11001001 [8] c9 [8] 880 (0xC9) |11001010 [8] ca [8] 881 (0xCA) |11001011 [8] cb [8] 882 (0xCB) |11001100 [8] cc [8] 883 (0xCC) |11001101 [8] cd [8] 884 (0xCD) |11001110 [8] ce [8] 885 (0xCE) |11001111 [8] cf [8] 886 (0xCF) |11010000 [8] d0 [8] 887 (0xD0) |11010001 [8] d1 [8] 888 (0xD1) |11010010 [8] d2 [8] 889 (0xD2) |11010011 [8] d3 [8] 890 (0xD3) |11010100 [8] d4 [8] 891 (0xD4) |11010101 [8] d5 [8] 892 (0xD5) |11010110 [8] d6 [8] 893 (0xD6) |11010111 [8] d7 [8] 894 (0xD7) |11011000 [8] d8 [8] 895 (0xD8) |11011001 [8] d9 [8] 896 (0xD9) |11011010 [8] da [8] 897 (0xDA) |11011011 [8] db [8] 898 (0xDB) |11011100 [8] dc [8] 899 (0xDC) |11011101 [8] dd [8] 900 (0xDD) |11011110 [8] de [8] 901 (0xDE) |11011111 [8] df [8] 902 (0xDF) |11100000 [8] e0 [8] 903 (0xE0) |11100001 [8] e1 [8] 904 (0xE1) |11100010 [8] e2 [8] 905 (0xE2) |11100011 [8] e3 [8] 906 (0xE3) |11100100 [8] e4 [8] 907 (0xE4) |11100101 [8] e5 [8] 908 (0xE5) |11100110 [8] e6 [8] 909 (0xE6) |11100111 [8] e7 [8] 910 (0xE7) |11101000 [8] e8 [8] 911 (0xE8) |11101001 [8] e9 [8] 912 (0xE9) |11101010 [8] ea [8] 913 (0xEA) |11101011 [8] eb [8] 914 (0xEB) |11101100 [8] ec [8] 915 (0xEC) |11101101 [8] ed [8] 916 (0xED) |11101110 [8] ee [8] 917 (0xEE) |11101111 [8] ef [8] 918 (0xEF) |11110000 [8] f0 [8] 919 (0xF0) |11110001 [8] f1 [8] 920 (0xF1) |11110010 [8] f2 [8] 921 (0xF2) |11110011 [8] f3 [8] 922 (0xF3) |11110100 [8] f4 [8] 923 (0xF4) |11110101 [8] f5 [8] 925 Appendix B. Static Storage Cache 927 0x80 "date" = NIL 928 0x81 ":scheme" = "https" 929 0x82 ":scheme" = "http" 930 0x83 ":scheme" = "ftp" 931 0x84 ":method" = "get" 932 0x85 ":method" = "post" 933 0x86 ":method" = "put" 934 0x87 ":method" = "delete" 935 0x88 ":method" = "options" 936 0x89 ":method" = "patch" 937 0x8A ":method" = "connect" 938 0x8B ":path" = "/" 939 0x8C ":host" = NIL 940 0x8D "cookie" = NIL 941 0x8E ":status" = 100 942 0x8F ":status" = 101 943 0x90 ":status" = 102 944 0x91 ":status" = 200 945 0x92 ":status" = 201 946 0x93 ":status" = 202 947 0x94 ":status" = 203 948 0x95 ":status" = 204 949 0x96 ":status" = 205 950 0x97 ":status" = 206 951 0x98 ":status" = 207 952 0x99 ":status" = 208 953 0x9A ":status" = 300 954 0x9B ":status" = 301 955 0x9C ":status" = 302 956 0x9D ":status" = 303 957 0x9E ":status" = 304 958 0x9F ":status" = 305 959 0xA0 ":status" = 307 960 0xA1 ":status" = 308 961 0xA2 ":status" = 400 962 0xA3 ":status" = 401 963 0xA4 ":status" = 402 964 0xA5 ":status" = 403 965 0xA6 ":status" = 404 966 0xA7 ":status" = 405 967 0xA8 ":status" = 406 968 0xA9 ":status" = 407 969 0xAA ":status" = 408 970 0xAB ":status" = 409 971 0xAC ":status" = 410 972 0xAD ":status" = 411 973 0xAE ":status" = 412 974 0xAF ":status" = 413 975 0xB0 ":status" = 414 976 0xB1 ":status" = 415 977 0xB2 ":status" = 416 978 0xB3 ":status" = 417 979 0xB4 ":status" = 500 980 0xB5 ":status" = 501 981 0xB6 ":status" = 502 982 0xB7 ":status" = 503 983 0xB8 ":status" = 504 984 0xB9 ":status" = 505 985 0xBA ":status-text" = "OK" 986 0xBB ":version" = "1.1" 987 0xBC "accept" = NIL 988 0xBD "accept-charset" = NIL 989 0xBE "accept-encoding" = NIL 990 0xBF "accept-language" = NIL 991 0xC0 "accept-ranges" = NIL 992 0xC1 "allow" = NIL 993 0xC2 "authorization" = NIL 994 0xC3 "cache-control" = NIL 995 0xC4 "content-base" = NIL 996 0xC5 "content-encoding" = NIL 997 0xC6 "content-length" = NIL 998 0xC7 "content-location" = NIL 999 0xC8 "content-md5" = NIL 1000 0xC9 "content-range" = NIL 1001 0xCA "content-type" = NIL 1002 0xCB "content-disposition" = NIL 1003 0xCC "content-language" = NIL 1004 0xCD "etag" = NIL 1005 0xCE "expect" = NIL 1006 0xCF "expires" = NIL 1007 0xD0 "from" = NIL 1008 0xD1 "if-match" = NIL 1009 0xD2 "if-modified-since" = NIL 1010 0xD3 "if-none-match" = NIL 1011 0xD4 "if-range" = NIL 1012 0xD5 "if-unmodified-since" = NIL 1013 0xD6 "last-modified" = NIL 1014 0xD7 "location" = NIL 1015 0xD8 "max-forwards" = NIL 1016 0xD9 "origin" = NIL 1017 0xDA "pragma" = NIL 1018 0xDB "proxy-authenticate" = NIL 1019 0xDC "proxy-authorization" = NIL 1020 0xDD "range" = NIL 1021 0xDE "referer" = NIL 1022 0xDF "retry-after" = NIL 1023 0xE0 "server" = NIL 1024 0xE1 "set-cookie" = NIL 1025 0xE2 "status" = NIL 1026 0xE3 "te" = NIL 1027 0xE4 "trailer" = NIL 1028 0xE5 "transfer-encoding" = NIL 1029 0xE6 "upgrade" = NIL 1030 0xE7 "user-agent" = NIL 1031 0xE8 "vary" = NIL 1032 0xE9 "via" = NIL 1033 0xEA "warning" = NIL 1034 0xEB "www-authenticate" = NIL 1035 0xEC "access-control-allow-origin" = NIL 1036 0xED "get-dictionary" = NIL 1037 0xEE "p3p" = NIL 1038 0xEF "link" = NIL 1039 0xF0 "prefer" = NIL 1040 0xF1 "preference-applied" = NIL 1041 0xF2 "accept-patch" = NIL 1042 0xF3 NIL 1043 0xF4 NIL 1044 0xF5 NIL 1045 0xF6 NIL 1046 0xF7 NIL 1047 0xF8 NIL 1048 0xF9 NIL 1049 0xFA NIL 1050 0xFB NIL 1051 0xFC NIL 1052 0xFD NIL 1053 0xFE NIL 1054 0xFF NIL 1056 Appendix C. Updated Standard Header Definitions 1058 In order to properly deal with the backwards compatibility concerns 1059 for HTTP/1, there are several important rules for use of Typed Codecs 1060 in HTTP headers: 1062 o All header fields MUST be explicitly defined to use the new header 1063 types. All existing HTTP/1 header fields, then, will continue to 1064 be represented as ISO-8859-1 Text unless their standard 1065 definitions are updated. The HTTP/2 specification would update 1066 the definition of specific known header fields (e.g. content- 1067 length, date, if-modified-since, etc). 1069 o Extension header fields that use the typed codecs will have 1070 specific normative transformations to ISO-8859-1 defined. 1072 * UTF-8 Text will be converted to ISO-8859-1 with extended 1073 characters pct-encoded 1075 * Numbers will be converted to their ASCII equivalent values. 1077 * Date Times will be converted to their HTTP-Date equivalent 1078 values. 1080 * Binary fields will be Base64-encoded. 1082 o There will be no normative transformation from ISO-8859-1 values 1083 into the typed codecs. Implementations are free to apply 1084 transformation where those impls determine it is appropriate, but 1085 it will be perfectly legal for an implementation to pass a text 1086 value through even if it is known that a given header type has a 1087 typed codec equivalent (for instance, Content-Length may come 1088 through as a number or a text value, either will be valid). This 1089 means that when translating from HTTP/1 -> HTTP/2, receiving 1090 implementations need to be prepared to handle either value form. 1092 A Note of warning: Individual header fields MAY be defined such that 1093 they can be represented using multiple types. Numeric fields, for 1094 instance, can be represented using either the uvarint encoding or 1095 using the equivalent sequence of ASCII numbers. Implementers will 1096 need to be capable of supporting each of the possible variations. 1097 Designers of header field definitions need to be aware of the 1098 additional complexity and possible issues that allowing for such 1099 alternatives can introduce for implementers. 1101 Based on an initial survey of header fields currently defined by the 1102 HTTPbis specification documents, the following header field 1103 definitions can be updated to make use of the new types 1105 +-----------------------+--------------+----------------------------+ 1106 | Field | Type | Description | 1107 +-----------------------+--------------+----------------------------+ 1108 | content-length | Numeric or | Can be represented as | 1109 | | Text | either an unsigned, | 1110 | | | variable-length integer or | 1111 | | | a sequence of ASCII | 1112 | | | numbers. | 1113 | date | Timestamp or | Can be represented as | 1114 | | Text | either a uvarint encoded | 1115 | | | timestamp or as text | 1116 | | | (HTTP-date). | 1117 | max-forwards | Numeric or | Can be represented as | 1118 | | Text | either an unsigned, | 1119 | | | variable-length integer or | 1120 | | | a sequence of ASCII | 1121 | | | numbers. | 1122 | retry-after | Timestamp, | Can be represented as | 1123 | | Numeric or | either a uvarint encoded | 1124 | | Text | timestamp, an unsigned, | 1125 | | | variable-length integer, | 1126 | | | or the text equivalents of | 1127 | | | either (HTTP-date or | 1128 | | | sequence of ASCII numbers) | 1129 | if-modified-since | Timestamp or | Can be represented as | 1130 | | Text | either a uvarint encoded | 1131 | | | timestamp or as text | 1132 | | | (HTTP-date). | 1133 | if-unmodified-since | Timestamp or | Can be represented as | 1134 | | Text | either a uvarint encoded | 1135 | | | timestamp or as text | 1136 | | | (HTTP-date). | 1137 | last-modified | Timestamp or | Can be represented as | 1138 | | Text | either a uvarint encoded | 1139 | | | timestamp or as text | 1140 | | | (HTTP-date). | 1141 | age | Numeric or | Can be represented as | 1142 | | Text | either an unsigned, | 1143 | | | variable-length integer or | 1144 | | | a sequence of ASCII | 1145 | | | numbers. | 1146 | expires | Timestamp or | Can be represented as | 1147 | | Text | either a uvarint encoded | 1148 | | | timestamp or as text | 1149 | | | (HTTP-date). | 1150 +-----------------------+--------------+----------------------------+ 1152 Appendix D. State Management Alternatives 1154 In the current design, dynamic cache storage slots are assigned by 1155 the decompressor in "encounter order". While this is effective, it 1156 requires that all compressor and decompressor implementations utilize 1157 the exact same algorithm for assigning storage slots, precluding any 1158 implementation from experimenting with more efficient algorithms. An 1159 alternative approach is to allow the compressor to assign the slots 1160 and communicate the assigned slots with each header. This would 1161 require a single additional byte per header instance in the Literal 1162 and Cloned Header Groups. 1164 The serialization syntax for Cloned and Literal Header Groups would 1165 change to: 1167 ; Cloned-Index Header Group 1168 cloned-index-header-group = cloned-index-header-prefix 1169 1*32(cache-index cache-index value) 1171 ; Literal Header Group 1172 literal-header-group = literal-header-prefix 1173 1*32(cache-index name value) 1175 The decompressor would used the specified storage index locations to 1176 store header values rather than relying on the encounter order, 1177 increasing the general efficiency of the algorithm with a minimal 1178 impact on transmission size. 1180 On the downside, this puts the compressor in greater control over the 1181 decompressor-maintained state because the decompressor would not know 1182 how long it needs to hold on to stored items. This opens the 1183 decompressor up to possible abuse from malicious compressors. The 1184 current least-recently-written cache approach allows the decompressor 1185 to reliably drop items as space fills without fear of falling out of 1186 sync with the compressor. 1188 Appendix E. Alternative Timestamp encodings 1190 This specification currently uses the number of milliseconds from the 1191 UNIX Epoch to represent timestamps. This 64-bit number is encoded 1192 using the same uvarint encoding as Numeric fields. This means that 1193 the timestamp is encoded using a variable width that, right now (for 1194 about the next 100 years or so), will encode in six bytes, then seven 1195 bytes for the reasonable future. 1197 One possible alternative approach we can take is similar to NTP's 1198 handling of Era's. We can take the current timestamp and generate an 1199 Era value, with a maximum of 255 (0xFF). This is used as a 1200 multiplier for the timestamp value. The two values are calculated 1201 using the following formula: 1203 m = 4294967296000 1204 now = milliseconds since UNIX Epoch 1205 era = now / m 1206 ts = now % m 1208 The allowable values for "era" would be capped at 255. This value is 1209 encoded as a single byte, followed by a uvarint encoding of ts. This 1210 ensures that the timestamp will never be encoded using more than 1211 7-bytes total, though it may be encoded in as few as two bytes on 1212 extremely rare occasions (specifically, immediately following each 1213 era rollover). 1215 Wire Syntax: 1217 era = %x00-FF 1218 ts = uvarint 1219 date-time = era ts 1221 To convert back to the Epoch, the formula is equally simple: 1223 now = era * m + ts 1225 The largest date we can encode using this format is 1226 "36812-02-20T00:36:15.999Z". Dates prior to the epoch cannot be 1227 represented. 1229 The significant drawback with this approach is that current dates 1230 would encode in 7-bytes until the next era rollover, which will occur 1231 at approximately 2106-02-07T06:28:15.999Z (give or take a few leap 1232 seconds thrown in here and there). 1234 Note: The byte lengths assume we want millisecond precision. If we 1235 opted to keep the second precision currently in HTTP/1, then this 1236 alternative encoding ensures that our timestamps never exceed six- 1237 bytes in length. 1239 Appendix F. Alternative uvarint encodings 1241 The uvarint encoding currently specified by this specification is 1242 certainly not the only possible option we can use. I chose it simply 1243 because it is drop dead simple to implement. There are quite a few 1244 other approaches we can take, each of which can be used as drop-in 1245 replacements for the current approach. Below are just a couple 1246 alternatives. There are plenty others. We just need to pick the one 1247 that we feel will work the best. 1249 It ought to be noted that while each of these schemes vary in details 1250 such as endianess, specific wire-format, etc, each will typically 1251 encode the same numbers using the same number of bytes with 1252 variations of only a single byte only in the edge cases. Processing 1253 time for each is also equivalent when dealing with any number less or 1254 equal to 64-bits in length. This means that the choice is largely a 1255 matter of style than substance. 1257 F.1. Option 1: 1259 With this option, leading bits are used to indicate the total number 1260 of bytes used to encode the number value, with no fixed upper limit. 1261 Values strictly less than 128 are encoded using a single byte. 1263 0 xxxxxxx 1264 10 xxxxxx OCTET 1265 110 xxxxx 2OCTET 1266 1110 xxxx 3OCTET 1267 11110 xxx 4OCTET 1268 111110 xx 5OCTET 1269 1111110 x 6OCTET 1270 11111110 7OCTET 1271 11111111 0xxxxxxx 7OCTET 1272 11111111 10xxxxxx 8OCTET 1273 ... 1275 The number of leading 1 bits specify the number of additional bytes 1276 used to serialize the value. A single 0 bit is used to mark the end 1277 of this prefix, the remaining bits are used to encode the minimum 1278 bits necessary to encode the value (with appropriate leading 0 bits 1279 to ensure proper byte-alignment). 1281 For instance, the integer value 500, which is represented in binary 1282 as 00000001 11110100, can be encoded using two bytes, 10000001 1283 11110100 1285 The integer value 9770098, which is represented in binary as 10010101 1286 00010100 01110010, can be encoded using four bytes: 11100000 10010101 1287 00010100 01110010 1289 F.2. Option 2: 1291 This option is generally identical to the previous with the exception 1292 of being capped at a maximum of nine encoded octets total. Rather 1293 than growing indefinitely, the encoded value must never require more 1294 then eight continuation bytes to encode. Because of this 1295 restriction, there is no need for a trailing 0-bit spilling over past 1296 the first leading byte. 1298 0 xxxxxxx 1299 10 xxxxxx OCTET 1300 110 xxxxx 2OCTET 1301 1110 xxxx 3OCTET 1302 11110 xxx 4OCTET 1303 111110 xx 5OCTET 1304 1111110 x 6OCTET 1305 11111110 7OCTET 1306 11111111 8OCTET 1307 ... 1309 The number of leading 1 bits specify the number of additional bytes 1310 used to serialize the value. If the number of bytes required is less 1311 than 8, a single 0 bit is used to mark the end of this prefix, the 1312 remaining bits are used to encode the minimum bits necessary to 1313 encode the value (with appropriate leading 0 bits to ensure proper 1314 byte-alignment). 1316 For instance, the integer value 500, which is represented in binary 1317 as 00000001 11110100, can be encoded using two bytes, 10000001 1318 11110100 1320 The integer value 9770098, which is represented in binary as 10010101 1321 00010100 01110010, can be encoded using four bytes: 11100000 10010101 1322 00010100 01110010 1324 This format is not capable of encoding any number requiring more than 1325 64-bits. 1327 Appendix G. Set-Cookie and Cookie Alternatives 1329 The Cookie and Set-Cookie header fields are interesting in that they 1330 establish a subordinate layer of key+value pairs exchanged within an 1331 HTTP dialog. Up to this point, Cookies have been handled largely as 1332 blobs of text, which is generally inefficient and inflexible. Even 1333 though it works, the design is not optimum. 1335 The introduction of a new header serialization mechanism and HTTP/2's 1336 new framing provides us with an interesting opportunity to make 1337 significant improvements to the way cookies work. 1339 Consider, for example, rather than defining Set-Cookie as a header 1340 field, we could create a modified Headers Frame that contains header 1341 fields that ought to be persisted and returned by the client. 1343 The new Headers Frame flags would be: 1345 o P (0x1) - Persist. If set, the headers in this frame are to be 1346 persistently stored and returned in subsequent streams. 1348 o C (0x2) - Clear. If set, any existing stored state is cleared. 1350 o E (0x4) - Ephemeral. If set, state is only stored for the 1351 duration of this connection. 1353 o H (0x8) - HttpOnly. Equivalent to Set-Cookie HttpOnly parameter. 1355 o S (0x10) - Secure. Equivalent to Set-Cookie Secure parameter. 1357 These flags would pertain only to the header fields contained by the 1358 one Headers frame. 1360 Within the header block, similar to how special ':' prefixed HTTP 1361 header fields are handled, there would be a handful of special ':' 1362 fields: 1364 o :host - text, equivalent to the Set-Cookie domain parameter 1366 o :path - text, equivalent to the Set-Cookie path parameter 1368 o :expires - timestamp or text 1370 o :max-age - uvarint or text 1372 When the Server wishes to send Cookies to the client, rather than 1373 sending a separate Set-Cookie header for every individual name+value 1374 pair it wishes the client to persist, it would send a Stateful Header 1375 Frame. The client would receive this, persist the contained set of 1376 name+value pairs just as it would persist cookies today, then return 1377 those to the server in a separate Headers Frame in all appropriate 1378 subsequent streams. 1380 This approach has a number of distinct advantages of the current Set- 1381 Cookies mechanism: 1383 o Currently, handling Set-Cookie requires it's own separate parsing 1384 logic. With this new approach, we would leverage the same header 1385 block encoding as all other types of headers, without the need for 1386 problematic and error-prone text parsing logic. 1388 o Currently, the Set-Cookie Expires and Max-Age parameters use 1389 inefficient ASCII encodings, with this new approach, those fields 1390 are encoded using efficient variable-length encodings and allow 1391 multiple key+value pairs to be stored with the same expiration to 1392 eliminate redundancy. 1394 o Currently, cookie values are limited to a specific ASCII subset. 1395 With this new approach, Cookie values can take advantage of the 1396 exact same value type codecs described in this document. Cookie 1397 values could be text, numeric, timestamps or raw binary, providing 1398 significant new options. 1400 For example, suppose the server wishes the client to store two 1401 cookies for 10 seconds with the HttpOnly and Secure flags set. The 1402 server wishes the client to also clear any previous cookies it had 1403 stored. To accomplish this, the server would send a Stateful Headers 1404 Frame to the client with bit flags P, C, H and S set to 1 and the 1405 following key-value pairs encoded in the serialized header block: 1407 :host = "example.com" 1408 :path = "/" 1409 :max-age = 10 1410 foo = "bar" 1411 baz = 123 1413 Upon creating a new streams for the domain "example.com" and path "/ 1414 ", the client would include the "foo" and "baz" header fields in the 1415 set of headers encoded in the request: 1417 :method = GET 1418 :path = "/foo" 1419 :host = "example.com" 1420 foo = "bar" 1421 baz = 123 1423 Note that this approach is backwards compatible with Set-Cookie and 1424 Cookie in that those header fields could continue to be used by 1425 existing implementations. 1427 Author's Address 1429 James M Snell 1431 Email: jasnell@gmail.com