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