idnits 2.17.1 draft-snell-httpbis-bohe-12.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 == 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 (August 06, 2013) is 3916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'RFC6265' is defined on line 448, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-httpbis-header-compression-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-23 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft 4 Intended status: Informational August 06, 2013 5 Expires: February 07, 2014 7 HTTP/2.0 Discussion: Stored Header Encoding 8 draft-snell-httpbis-bohe-12 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 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 February 07, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Stored Header Encoding . . . . . . . . . . . . . . . . . . . 2 52 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Header Encoding and Decoding . . . . . . . . . . . . . . . . 3 54 3.1. Literal (name,value) Representation . . . . . . . . . . . 5 55 3.1.1. Dealing with invalid name or value encodings . . . . 7 56 3.2. Indexed Representation . . . . . . . . . . . . . . . . . 7 57 3.3. Non-Indexed Literal Representation . . . . . . . . . . . 8 58 3.4. Indexed Literal Representation . . . . . . . . . . . . . 8 59 3.5. Indexed Literal Replacement Representation . . . . . . . 9 60 4. Unsigned Variable Length Integer Syntax . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 6.2. Informational References . . . . . . . . . . . . . . . . 10 65 Appendix A. Initial Header Table Entries . . . . . . . . . . . . 10 66 Appendix B. Updated Standard Header Definitions . . . . . . . . 12 67 Appendix C. Example . . . . . . . . . . . . . . . . . . . . . . 14 68 C.1. First Header Set: . . . . . . . . . . . . . . . . . . . . 14 69 C.2. Second Header Set: . . . . . . . . . . . . . . . . . . . 15 70 C.3. Third Header Set: . . . . . . . . . . . . . . . . . . . . 15 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 73 1. Stored Header Encoding 75 The Stored Header Encoding is a proposed alternative "compressed 76 header encoding" for HTTP/2.0 that offers reasonably good compression 77 ratios, support for a range of compressor strategies, efficient value 78 type codecs, constrained state requirements, routing-friendly header 79 value ordering, and easier implementation relative to the current 80 header compression proposal. 82 2. Model 84 A "header" is a (name,value) pair. The name is a sequence of lower- 85 case ASCII characters. The value is either a UTF-8 string, an 86 integer, a date-time, or an arbitrary sequence of binary octets. 88 The compressor and decompressor each maintain a synchronized cache of 89 up to 256 headers. Every header in the cache is referenced by an 90 8-bit identifier. Note that the Nil byte (0x00) is a valid 91 identifier. 93 The cache is managed in a "least recently written" style, that is, as 94 the cache fills to capacity in both number of entries and maximum 95 stored byte size, the least recently written items are cleared and 96 their index positions are reused. 98 Index positions from the cache are assigned in "encounter order", 99 beginning from 0x00 and increasing monotonically to 0xFF. That is to 100 say, the positions are assigned in precisely the same order that they 101 are serialized, and thereby encountered by the decompressor upon 102 reading and processing the block. 104 The available size of the stored compression state can be capped by 105 the decompressor using the SETTINGS_MAX_BUFFER_SIZE setting. Each 106 stored header contributes to the accumulated size of the storage 107 state. As new header pairs are assigned positions in the cache, the 108 least-recently assigned items must be cleared, if necessary, to free 109 up the required space. Clearing existing items does not change the 110 index positions of the remaining items in the cache. 112 The SETTINGS_MAX_BUFFER_SIZE setting has an initial default value of 113 4096 bytes. The decompressor can establish a new maximum buffer size 114 at any time, possibly causing header (name,value) pairs to be evicted 115 from the cache. 117 The decompressor can disable use of the storage cache completely by 118 setting the SETTINGS_MAX_BUFFER_SIZE setting to 0, forcing the cache 119 to empty completely. 121 The size of a header is calculated as: The number of octets required 122 for the name plus the number of octets required for the value plus 123 32-bytes to account for any internal storage overhead. The number of 124 octets required for the value depends on the value type: 126 o String values are measured by the number of UTF-8 encoded octets 127 required to represent the character sequence. 129 o Number and Date-Time values are measured by the number of unsigned 130 variable length integer (uvarint) encoded bytes required to 131 represent the value using a 5-bit prefix. 133 o Legacy (HTTP/1.1) values are measured by the number of octets 134 required to represent the value. 136 o Binary values are measured by the number of octets contained by 137 the sequence. 139 3. Header Encoding and Decoding 141 The set of headers is encoded for transmission using the following 142 process: 144 1. For each header, determine if the (name,value) pair already 145 exists in the table. 147 * If an exact match is found in the header table, encode the 148 indexed position of the header as an Indexed Reference and 149 advance to the next header (name,value) pair. 151 * Otherwise, move to the step #2. 153 2. Determine if a header (name,value) pair with the same name 154 already exists in the table. If a matching name is found, make 155 note of the indexed position of the matching name and continue to 156 step #3. 158 3. Determine whether the new header (name,value) pair ought to be 159 added to the header table. 161 * If the header is not to be added to the header table, encode 162 the header as a Non-Indexed Literal Representation and 163 continue to the next header (name,value) pair. 165 * Otherwise, continue to step #4. 167 4. If an existing indexed header using the same name was found in 168 the header table in step #2, determine if the new header 169 (name,value) pair ought to replace that existing entry or if it 170 ought to be added as a new entry. 172 * If the header is to replace the existing entry, encode the 173 header as an Indexed Literal Replacement Representation. 175 * Otherwise encode the header as an Indexed Literal 176 Representation. 178 Following these steps, headers are serialized into one of four 179 representation types, each represented by a two-bit prefix code. The 180 types and their codes are: 182 o 10 - Indexed 184 o 00 - Non-Indexed Literal 186 o 01 - Indexed Literal 188 o 11 - Indexed Literal Replacement 190 Each representation type is encoded into groups of up to 64 191 instances. Each group is prefixed by a single octet prefix. The two 192 most significant bits identify the representation type, the six least 193 significant bits specify the number of instances in the group, with 194 000000 indicating a single instance and 111111 indicating 64. 196 If a particular serialization block requires more than 64 instances 197 of a given type, then multiple occurrences of the group type can be 198 encoded. For instance, if a given message contains 65 Indexed 199 Representations, the encoded block would contain two separate Indexed 200 Representation groups. 202 Decoding simply reverses the encoding steps: 204 1. First initialize an empty working set of headers. 206 2. Begin iterating through each representation group: 208 * If it is an Indexed group, iterate through each index included 209 in the group, look up the corresponding (name,value) pair in 210 the header table and add that to the working set. If no 211 matching (name,value) is found, terminate and report an error. 213 * If it's a Non-Indexed Literal group, iterate through each 214 (name,value) pair included in the group and add that to the 215 working set. 217 * If it's an Indexed Literal group, iterate through each 218 (name,value) pair included in the group and add that to both 219 the header table and the working set. 221 * If it's an Indexed Literal Replacement group, iterate through 222 each (name,value) pair included in the group, replace the 223 existing entry in the header table at the identified index, 224 and add the new (name,value) to the working set. If no 225 matching (name,value) is found, terminate and report an error. 227 3. Continue with each representation group until the complete block 228 has been decoded. 230 When a single header name is used multiple times with different 231 values, the order in which those values are serialized and processed 232 is significant. The working set created by the decoding process 233 above MUST preserve the ordering of those values as received. 235 3.1. Literal (name,value) Representation 237 The structure of an encoded (name,value) pair consists of: 239 o A 3-bit value type identifier, 241 o The name, encoded either as a literal string or as the header 242 table index position of another existing header sharing the same 243 name, and 245 o The encoded value. 247 The three most-sigificant bits of the first octet identify the value 248 type. 250 This design allows for a maximum of 7 value types, five of which are 251 defined by this specification. The two remaining types are reserved 252 for future use. The currently defined value types are: 254 UTF-8 Text (000) 256 Integer (001) 258 Timestamp (010) 260 Legacy (100) 262 Raw Binary (111) 264 Of the five types, the Legacy type is reserved for encoding header 265 values conforming to the field-value construct defined by 266 [I-D.ietf-httpbis-p1-messaging], and is used specifically for 267 backwards compatibility with header fields that have not yet been 268 updated to use a more specific type value (see Appendix B). 270 If the name is encoded using an index reference to another existing 271 (name,value) pair in the header table, the remaining five least 272 significant bits of the first octet are set to zero and the next byte 273 identifies the referenced header table index position. 275 If the name is encoded as a literal string, the number of octets 276 required to represent the name is encoded as a unsigned variable 277 length integer with a five-bit prefix, filling the 5-remaining least 278 significant bits of the first octet, followed by the sequence of 279 ASCII octets conforming to the following header-name construct: 281 Header name ABNF: 283 LOWERALPHA = %x61-7A 285 header-name = "!" / "#" / "$" / "%" / "&" / "'" / 286 "*" / "+" / "-" / "." / "^" / "_" / 287 "`" / "|" / "~" / DIGIT / LOWERALPHA 289 The encoding of the value depends on the value type. 291 UTF-8 Text: 293 First, the number of UTF-8 encoded bytes required to represent the 294 value is encoded as an unsigned variable length integer with a 295 0-bit prefix, followed by the full sequence of UTF-8 bytes. 297 Integer 298 Integer values ranging from 0 to 2^64-1 are encoded as unsigned 299 variable length integers with a 0-bit prefix. Negative or 300 fractional numbers cannot be represented. 302 Timestamp 303 The timestamp is represented as the number of milliseconds 304 ellapsed since the standard Epoch (1970-01-01T00:00:00 GMT), 305 encoded as an unsigned variable length integer with a 0-bit 306 prefix. Timestamps that predate the Epoch cannot be represented. 308 Legacy 309 First, the number of octets required to represent the value is 310 encoded as an unsigned variable length integer with a 0-bit 311 prefix, followed by the full sequence of octets. 313 Raw Binary 314 The number of octets in the sequence is encoded as an unsigned 315 variable length integer with a 0-bit prefix, followed by the full 316 sequence of octets. 318 3.1.1. Dealing with invalid name or value encodings 320 Implementations encountering invalid name or value encodings MUST 321 signal an error and terminate processing of the header block. 322 Examples of such errors include: 324 o Header names that include any octets not explicitly permitted by 325 the above header-name ABNF construction; 327 o UTF-8 values that include a byte order mark, over-long or invalid 328 octet sequences, or octets representing invalid Unicode 329 codepoints; 331 o Integer or Date-Time values that encode numbers strictly larger 332 than 2^64-1; 334 3.2. Indexed Representation 336 The serialization of an Indexed Representation group consists of the 337 one-octet header group prefix followed by up to 64 single-octet 338 header table index references. 340 +--------+--------+--------+--------+---+ 341 |10xxxxxx| Index positions (1...64) ...| 342 +--------+--------------------------+---+ 344 For instance: 346 0x80 0x00 347 References item #0 from the header table. 349 0x81 0x00 0x01 350 References items #0 and #1 from the header table. 352 Indexed Representations do not modify the header table state in any 353 way. If an Indexed References specifies a header index that has not 354 yet been allocated or whose value has been cleared, decoding MUST 355 terminate with an error. 357 3.3. Non-Indexed Literal Representation 359 The serialization of a group of Non-Indexed Literal representations 360 consists of the one-octet header prefix followed by up to 64 Literal 361 (name,value) Representations. 363 +--------+--------+--------+--------+---+ 364 |00xxxxxx| (name,value)'s (1...64) ... 365 +--------+--------------------------+---+ 367 For instance: 369 0x00 0x01 0x61 0x01 0x62 370 Specifies a single header with name "a" and a UTF-8 String value 371 of "b" is to be handled as a Non-Indexed header (it is not added 372 to the header table). 374 3.4. Indexed Literal Representation 376 The serialization of a group of Indexed Literal representations 377 consists of the one-octet header prefix followed by up to 64 Literal 378 (name,value) Representations. 380 +--------+--------+--------+--------+---+ 381 |01xxxxxx| (name,value)'s (1...64) ... 382 +--------+--------------------------+---+ 384 For instance: 386 0x40 0x01 0x61 0x01 0x62 387 Specifies a single header with name "a" and a UTF-8 String value 388 of "b" is to be handled as an Indexed header (it will be added to 389 the header table). 391 0x40 0x21 0x61 0x03 392 Specifies a single header with name "a" and Integer value of 3 is 393 to be handled as an Indexed header (it will be added to the header 394 table). 396 3.5. Indexed Literal Replacement Representation 398 The serialization of a group of Indexed Literal representations 399 consists of the one-octet header prefix followed by up to 64 single 400 octet index references identifying an existing header table entry 401 followed by the new Literal (name,value) representation meant to 402 replace it. 404 +--------+--------+--------+--------+--------+ 405 |11xxxxxx| (INDEX | (name,value)(1...64)) ... 406 +--------+--------------------------+--------+ 408 For instance: 410 0xC0 0x03 0x01 0x61 0x01 0x62 411 Specifies that a single header with name "a" and a UTF-8 String 412 value of "b" is to replace the existing (name,value) entry in the 413 header table located at index position #3. 415 0xC0 0x03 0x21 0x61 0x03 416 Specifies that a single header with name "a" and Integer value of 417 3 is to replace the existing (name,value) entry in the header 418 table located at index position #3. 420 4. Unsigned Variable Length Integer Syntax 422 Unsigned integers are encoded as defined in 423 [I-D.ietf-httpbis-header-compression]. 425 5. Security Considerations 427 TBD 429 6. References 431 6.1. Normative References 433 [I-D.ietf-httpbis-header-compression] 434 Peon, R. and H. Ruellan, "HTTP/2.0 Header Compression", 435 draft-ietf-httpbis-header-compression-01 (work in 436 progress), July 2013. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 6.2. Informational References 443 [I-D.ietf-httpbis-p1-messaging] 444 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 445 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 446 httpbis-p1-messaging-23 (work in progress), July 2013. 448 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 449 April 2011. 451 Appendix A. Initial Header Table Entries 453 +-------+-----------------------------+-------+---------+ 454 | Index | Name | Value | Type | 455 +-------+-----------------------------+-------+---------+ 456 | 0 | :scheme | http | Text | 457 | 1 | :scheme | https | Text | 458 | 2 | :host | | | 459 | 3 | :path | / | | 460 | 4 | :method | GET | Text | 461 | 5 | accept | | | 462 | 6 | accept-charset | | | 463 | 7 | accept-encoding | | | 464 | 8 | accept-language | | | 465 | 9 | cookie | | | 466 | 10 | if-modified-since | | | 467 | 11 | keep-alive | | | 468 | 12 | user-agent | | | 469 | 13 | proxy-connection | | | 470 | 14 | referer | | | 471 | 15 | accept-datetime | | | 472 | 16 | authorization | | | 473 | 17 | allow | | | 474 | 18 | cache-control | | | 475 | 19 | connection | | | 476 | 20 | content-length | | | 477 | 21 | content-md5 | | | 478 | 22 | content-type | | | 479 | 23 | date | | | 480 | 24 | expect | | | 481 | 25 | from | | | 482 | 26 | if-match | | | 483 | 27 | if-none-match | | | 484 | 28 | if-range | | | 485 | 29 | if-unmodified-since | | | 486 | 30 | max-forwards | | | 487 | 31 | pragma | | | 488 | 32 | proxy-authorization | | | 489 | 33 | range | | | 490 | 34 | te | | | 491 | 35 | upgrade | | | 492 | 36 | via | | | 493 | 37 | warning | | | 494 | 38 | :status | 200 | Integer | 495 | 39 | age | | | 496 | 40 | cache-control | | | 497 | 41 | content-length | | | 498 | 42 | content-type | | | 499 | 43 | date | | | 500 | 44 | etag | | | 501 | 45 | expires | | | 502 | 46 | last-modified | | | 503 | 47 | server | | | 504 | 48 | set-cookie | | | 505 | 49 | vary | | | 506 | 50 | via | | | 507 | 51 | access-control-allow-origin | | | 508 | 52 | accept-ranges | | | 509 | 53 | allow | | | 510 | 54 | connection | | | 511 | 55 | content-disposition | | | 512 | 56 | content-encoding | | | 513 | 57 | content-language | | | 514 | 58 | content-location | | | 515 | 59 | content-md5 | | | 516 | 60 | content-range | | | 517 | 61 | link | | | 518 | 62 | location | | | 519 | 63 | p3p | | | 520 | 64 | pragma | | | 521 | 65 | proxy-authenticate | | | 522 | 66 | refresh | | | 523 | 67 | retry-after | | | 524 | 68 | strict-transport-security | | | 525 | 69 | trailer | | | 526 | 70 | transfer-encoding | | | 527 | 71 | warning | | | 528 | 72 | www-authenticate | | | 529 | 73 | user-agent | | | 530 +-------+-----------------------------+-------+---------+ 532 Appendix B. Updated Standard Header Definitions 534 To properly deal with the backwards compatibility concerns for HTTP/ 535 1, there are several important rules for use of Typed Codecs in HTTP 536 headers: 538 o All header fields MUST be explicitly defined to use the new header 539 types. All existing HTTP/1 header fields will continue to be 540 represented in conformance to the field-value construct defined by 541 [I-D.ietf-httpbis-p1-messaging] unless their specific definitions 542 are updated. Such fields MUST specify the Legacy value type when 543 serialized. The HTTP/2 specification would update the definitions 544 of specific known header fields (e.g. content-length, date, if- 545 modified-since, etc). 547 o For translation to HTTP/1.1, header fields that use the typed 548 codecs will have specific normative transformations defined. 550 * UTF-8 Text will be converted to ISO-8859-1 with extended 551 characters pct-encoded 553 * Numbers will be converted to their ASCII equivalent values. 555 * Date Times will be converted to their HTTP-Date equivalent 556 values. 558 * Binary fields will be Base64-encoded. 560 * Legacy fields are passed through untranslated. 562 o There will be no normative transformation from legacy values into 563 the typed codecs. Implementations are free to apply 564 transformation where they determine it to be appropriate, but it 565 will be perfectly acceptable for an implementation to pass a text 566 value through as a Legacy type even if it is known that a given 567 header has a typed codec equivalent. 569 A Note of warning: Individual header fields MAY be defined such that 570 they can be represented using multiple types. Numeric fields, for 571 instance, can be represented using either the uvarint encoding or 572 using the equivalent sequence of ASCII numbers. Implementers will 573 need to be capable of supporting each of the possible variations. 574 Designers of header field definitions need to be aware of the 575 additional complexity and possible issues that allowing for such 576 alternatives can introduce for implementers. 578 Based on an initial survey of header fields currently defined by the 579 HTTPbis specification documents, the following header field 580 definitions can be updated to make use of the new types 582 +---------------------+---------------+-----------------------------+ 583 | Field | Type | Description | 584 +---------------------+---------------+-----------------------------+ 585 | content-length | Numeric or | Can be represented as | 586 | | Text | either an unsigned, | 587 | | | variable-length integer or | 588 | | | a sequence of ASCII | 589 | | | numbers. | 590 | date | Timestamp or | Can be represented as | 591 | | Text | either a uvarint encoded | 592 | | | timestamp or as text (HTTP- | 593 | | | date). | 594 | max-forwards | Numeric or | Can be represented as | 595 | | Text | either an unsigned, | 596 | | | variable-length integer or | 597 | | | a sequence of ASCII | 598 | | | numbers. | 599 | retry-after | Timestamp, | Can be represented as | 600 | | Numeric or | either a uvarint encoded | 601 | | Text | timestamp, an unsigned, | 602 | | | variable-length integer, or | 603 | | | the text equivalents of | 604 | | | either (HTTP-date or | 605 | | | sequence of ASCII numbers) | 606 | if-modified-since | Timestamp or | Can be represented as | 607 | | Text | either a uvarint encoded | 608 | | | timestamp or as text (HTTP- | 609 | | | date). | 610 | if-unmodified-since | Timestamp or | Can be represented as | 611 | | Text | either a uvarint encoded | 612 | | | timestamp or as text (HTTP- | 613 | | | date). | 614 | last-modified | Timestamp or | Can be represented as | 615 | | Text | either a uvarint encoded | 616 | | | timestamp or as text (HTTP- | 617 | | | date). | 618 | age | Numeric or | Can be represented as | 619 | | Text | either an unsigned, | 620 | | | variable-length integer or | 621 | | | a sequence of ASCII | 622 | | | numbers. | 623 | expires | Timestamp or | Can be represented as | 624 | | Text | either a uvarint encoded | 625 | | | timestamp or as text (HTTP- | 626 | | | date). | 627 | etag | Binary or | Can be represented as | 628 | | Text | either an opaque sequence | 629 | | | of binary octets or using | 630 | | | the currently defined text | 631 | | | format. When represented as | 632 | | | binary octets, the Entity | 633 | | | Tag MUST be considered to | 634 | | | be a Strong Entity tag. | 635 | | | Weak Entity Tags cannot be | 636 | | | represented using the | 637 | | | binary octet option. | 638 +---------------------+---------------+-----------------------------+ 640 Appendix C. Example 642 C.1. First Header Set: 644 The first header set to represent is the following: 646 :path: /my-example/index.html 647 user-agent: my-user-agent 648 x-my-header: first 650 The header table is prefilled as defined in Appendix A, however, none 651 of the values represented in the initial set can be found in the 652 header table. All headers, then, are encoding using the Indexed 653 Literal Representation: 655 43 00 03 16 2f 6d 79 2d 65 78 656 61 6d 70 6c 65 2f 69 6e 64 65 657 78 2e 68 74 6d 6c 00 49 6d 79 658 2d 75 73 65 72 2d 61 67 65 6e 659 74 0b 78 2d 6d 79 2d 68 65 61 660 64 65 72 05 66 69 72 73 74 661 Three new entries are added to the header table: 663 +-------+-------------+------------------------+ 664 | Index | Name | Value | 665 +-------+-------------+------------------------+ 666 | 74 | :path | /my-example/index.html | 667 | 75 | user-agent | my-user-agent | 668 | 76 | x-my-header | first | 669 +-------+-------------+------------------------+ 671 C.2. Second Header Set: 673 The second header set to represent is the following: 675 :path: /my-example/resources/script.js 676 user-agent: my-user-agent 677 x-my-header: second 679 Comparing this second header set to the first, we see that the :path 680 and x-my-header headers have new values, while the user-agent value 681 remains unchanged. For the sake of the example let's encode the 682 :path and x-my-header headers using Indexed Literal Replacement 683 representations. The user-agent header will be encoded as an Indexed 684 Representation. 686 80 4b a3 4a 00 4a 1f 2f 6d 79 687 2d 65 78 61 6d 70 6c 65 2f 72 688 65 73 6f 75 72 63 65 73 2f 73 689 63 72 69 70 74 2e 6a 73 00 4c 690 06 73 65 63 6f 6e 64 692 Items #74 and #76 added by the previous header set are replaced: 694 +-------+-------------+---------------------------------+ 695 | Index | Name | Value | 696 +-------+-------------+---------------------------------+ 697 | 74 | :path | /my-example/resources/script.js | 698 | 75 | user-agent | my-user-agent | 699 | 76 | x-my-header | second | 700 +-------+-------------+---------------------------------+ 702 C.3. Third Header Set: 704 Let's suppose a third header set that is identical to the second is 705 sent: 707 82 4b 4c 4d 709 Author's Address 711 James M Snell 713 Email: jasnell@gmail.com