idnits 2.17.1 draft-ietf-httpbis-header-compression-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 248: '... equivalent ones MUST be executed by t...' RFC 2119 keyword, line 496: '...ently in use, it MUST send as soon as ...' RFC 2119 keyword, line 504: '... decoder MUST reduce its own head...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2013) is 3948 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 309 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Peon 3 Internet-Draft Google, Inc 4 Intended status: Informational H. Ruellan 5 Expires: December 27, 2013 Canon CRF 6 June 25, 2013 8 HTTP Header Compression 9 draft-ietf-httpbis-header-compression-00 11 Abstract 13 This document describes a format adapted to efficiently represent 14 HTTP headers in the context of HTTP/2.0. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 27, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Header Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Encoding Components . . . . . . . . . . . . . . . . . . . 3 54 3.2. Header Table . . . . . . . . . . . . . . . . . . . . . . 4 55 3.3. Header Representation . . . . . . . . . . . . . . . . . . 5 56 3.3.1. Literal Representation . . . . . . . . . . . . . . . 5 57 3.3.2. Indexed Representation . . . . . . . . . . . . . . . 5 58 3.4. Differential Coding . . . . . . . . . . . . . . . . . . . 5 59 4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Header Blocks . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Low-level representations . . . . . . . . . . . . . . . . 7 62 4.2.1. Integer representation . . . . . . . . . . . . . . . 7 63 4.2.2. String literal representation . . . . . . . . . . . . 9 64 4.3. Indexed Header Representation . . . . . . . . . . . . . . 9 65 4.4. Literal Header Representation . . . . . . . . . . . . . . 9 66 4.4.1. Literal Header without Indexing . . . . . . . . . . . 9 67 4.4.2. Literal Header with Incremental Indexing . . . . . . 10 68 4.4.3. Literal Header with Substitution Indexing . . . . . . 10 69 5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 8. Informative References . . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Initial header names . . . . . . . . . . . . . . . . 12 74 A.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 12 75 A.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 14 77 B.1. First header set . . . . . . . . . . . . . . . . . . . . 14 78 B.2. Second header set . . . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 This document describes a format adapted to efficiently represent 84 HTTP headers in the context of HTTP/2.0. 86 2. Overview 88 In HTTP/1.X, HTTP headers, which are necessary for the functioning of 89 the protocol, are transmitted with no transformations. 90 Unfortunately, the amount of redundancy in both the keys and the 91 values of these headers is astonishingly high, and is the cause of 92 increased latency on lower bandwidth links. This indicates that an 93 alternate encoding for headers would be beneficial to latency, and 94 that is what is proposed here. As shown by SPDY [SPDY], Deflate 95 compresses HTTP very effectively. However, the use of a compression 96 scheme which allows for arbitrary matches against the previously 97 encoded data (such as Deflate) exposes users to security issues. In 98 particular, the compression of sensitive data, together with other 99 data controlled by an attacker, may lead to leakage of that sensitive 100 data, even when the resultant bytes are transmitted over an encrypted 101 channel. Another consideration is that processing and memory costs 102 of a compressor such as Deflate may also be too high for some classes 103 of devices, for example when doing forward or reverse proxying. 105 2.1. Outline 107 The HTTP header representation described in this document is based on 108 indexing tables that store (name, value) pairs, called header tables 109 in the remainder of this document. This scheme is believed to be 110 safe for all known attacks against the compression context today. 111 Header tables are incrementally updated during the whole HTTP/2.0 112 session. Two independent header tables are used during a HTTP/2.0 113 session, one for HTTP request headers and one for HTTP response 114 headers. 116 The encoder is responsible for deciding which headers to insert as 117 (name, value) pairs in the header table. The decoder then does 118 exactly what the encoder prescribes, ending in a state that exactly 119 matches the encoder's state. This enables decoders to remain simple 120 and understand a wide variety of encoders. 122 A header may be represented as a literal or as an index. If 123 represented as a literal, the representation specifies whether this 124 header is used to update the indexing table. The different 125 representations are described in Section 3.3. 127 A set of headers is coded as a difference from the previous set of 128 headers. 130 An example illustrating the use these different mechanisms to 131 represent headers is available in Appendix B. 133 3. Header Encoding 135 3.1. Encoding Components 137 The encoding and decoding of headers relies on a few components. 138 First, a header table (see Section 3.2) is used to associate headers 139 to index values. Second, a set of headers is encoded as a difference 140 from the previous reference set of headers (see Section 3.4). 142 As messages are exchanged in two directions, from client to server 143 and from server to client, there are two sets of components: one for 144 each direction. All the headers sent in messages from the client to 145 the server are encoded (and decoded) using one set of components. 146 All the headers sent in messages from the server to the client 147 (including headers contained in PUSH_PROMISE frame) are encoded using 148 the other set of compotents. 150 3.2. Header Table 152 A header table consists of an ordered list of (name, value) pairs. A 153 pair is either inserted at the end of the table or replaces an 154 existing pair depending on the chosen representation. A pair can be 155 represented as an index which is its position in the table, starting 156 with 0 for the first entry. 158 Header names are always represented as lower-case strings. An input 159 header name matches the header name of a (name, value) pair stored in 160 the Header Table if they are equal using a character-based, _case 161 insensitive_ comparison. An input header value matches the header 162 value of a (name, value) pair stored in the Header Table if they are 163 equal using a character-based, _case sensitive_ comparison. An input 164 header (name, value) pair matches a pair in the Header Table if both 165 the name and value are matching as per above. 167 The header table is progressively updated based on headers 168 represented as literal (as defined in Section 3.3.1). Two update 169 mechanisms are defined: 171 o Incremental indexing: the represented header is inserted at the 172 end of the header table as a (name, value) pair. The inserted 173 pair index is set to the next free index in the table: it is equal 174 to the number of headers in the table before its insertion. 176 o Substitution indexing: the represented header contains an index to 177 an existing (name, value) pair. The existing pair value is 178 replaced by the pair representing the new header. 180 Incremental and substitution indexing are optional. If none of them 181 is selected in a header representation, the header table is not 182 updated. In particular, no update happens on the header table when 183 processing an indexed representation. 185 The header table size can be bounded so as to limit the memory 186 requirements (see the SETTINGS_MAX_BUFFER_SIZE in Section 5). The 187 header table size is defined as the sum of the size of each entry of 188 the table. The size of an entry is the sum of the length in bytes 189 (as defined in Section 4.2.2) of its name, of value's length in bytes 190 and of 32 bytes (for accounting for the entry structure overhead). 192 When an entry is added to the header table, if the header table size 193 is greater than the limit, the table size is reduced by dropping the 194 entries at the beginning of the table until the header table size 195 becomes lower than or equal to the limit. Dropping entries from the 196 beginning of the table causes a renumbering of the remaining entries. 197 [[Feedback is needed on this automatic eviction strategy. ]] 199 To optimize the representation of the headers exchanged at the 200 beginning of an HTTP/2.0 session, the header table is initialized 201 with common headers. Two lists of initial headers are provided in 202 Appendix A. One is for messages sent from a client to a server, the 203 other is for messages sent from a server to a client. 205 3.3. Header Representation 207 3.3.1. Literal Representation 209 The literal representation defines a new header. A literal header is 210 represented as: 212 o A header name, with two possible representations: 214 * A literal string, as described in Section 4.2.2. 216 * A index in the header table referencing the name of the 217 corresponding header. The index is represented as an integer, 218 as described in Section 4.2.1. 220 o The header value, represented as a literal string, as described in 221 Section 4.2.2. 223 3.3.2. Indexed Representation 225 The indexed representation defines a header as a match to a (name, 226 value) pair in the header table. An indexed header is represented 227 as: 229 o An integer representing the index of the matching (name, value) 230 pair, as described in Section 4.2.1. 232 3.4. Differential Coding 234 A set of headers is encoded as a difference from the previous 235 reference set of headers. The initial reference set of headers is 236 the empty set. 238 An indexed representation toggles the presence of the header in the 239 current set of headers. If the header corresponding to the indexed 240 representation was not in the set, it is added to the set. If the 241 header index was in the set, it is removed from it. 243 A literal representation adds a header to the current set of headers 244 if the header is added to the header table (either by incremental 245 indexing or by substitution indexing). 247 To ensure a correct decoding of a set of headers, the following steps 248 or equivalent ones MUST be executed by the decoder. 250 First, upon starting the decoding of a new set of headers, the 251 reference set of headers is interpreted into the working set of 252 headers: for each header in the reference set, an entry is added to 253 the working set, containing the header name, its value, and its 254 current index in the header table. 256 Then, the header representations are processed in their order of 257 occurrence in the frame. 259 For an indexed representation, the decoder checks whether the index 260 is present in the working set. If true, the corresponding entry is 261 removed from the working set. If several entries correspond to this 262 encoded index, all these entries are removed from the working set. 263 If the index is not present in the working set, it is used to 264 retrieve the corresponding header from the header table, and a new 265 entry is added to the working set representing this header. 267 For a literal representation, a new entry is added to the working set 268 representing this header. If the literal representation specifies 269 that the header is to be indexed, the header is added accordingly to 270 the header table, and its index is included in the entry in the 271 working set. Otherwise, the entry in the working set contains an 272 undefined index. 274 When all the header representations have been processed, the working 275 set contains all the headers of the set of headers. 277 The new reference set of headers is computed by removing from the 278 working set all the headers that are not present in the header table. 280 It should be noted that during the decoding of the header 281 representations, the same index may be associated to different 282 headers in the working set and in the header table. 284 4. Detailed Format 286 4.1. Header Blocks 287 A header block consists of a set of header fields, which are name- 288 value pairs. Each header field is encoded using one of the header 289 representation. 291 4.2. Low-level representations 293 4.2.1. Integer representation 295 Integers are used to represent name indexes, pair indexes or string 296 lengths. The integer representation keeps byte-alignment as much as 297 possible as this allows various processing optimizations as well as 298 efficient use of DEFLATE. For that purpose, an integer 299 representation always finishes at the end of a byte. 301 An integer is represented in two parts: a prefix that fills the 302 current byte and an optional list of bytes that are used if the 303 integer value does not fit in the prefix. The number of bits of the 304 prefix (called N) is a parameter of the integer representation. 306 The N-bit prefix allows filling the current byte. If the value is 307 small enough (strictly less than 2^N-1), it is encoded within the 308 N-bit prefix. Otherwise all the bits of the prefix are set to 1 and 309 the value is encoded using an unsigned variable length integer [1] 310 representation. 312 The algorithm to represent an integer I is as follows: 314 1. If I < 2^N - 1, encode I on N bits 316 2. Else, encode 2^N - 1 on N bits and do the following steps: 318 3. 320 1. Set I to (I - (2^N - 1)) and Q to 1 322 2. While Q > 0 324 3. 326 1. Compute Q and R, quotient and remainder of I divided by 327 2^7 329 2. If Q is strictly greater than 0, write one 1 bit; 330 otherwise, write one 0 bit 332 3. Encode R on the next 7 bits 334 4. I = Q 336 4.2.1.1. Example 1: Encoding 10 using a 5-bit prefix 338 The value 10 is to be encoded with a 5-bit prefix. 340 o 10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit 341 prefix. 343 0 1 2 3 4 5 6 7 344 +---+---+---+---+---+---+---+---+ 345 | X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits 346 +---+---+---+---+---+---+---+---+ 348 4.2.1.2. Example 2: Encoding 1337 using a 5-bit prefix 350 The value I=1337 is to be encoded with a 5-bit prefix. 352 o 1337 is greater than 31 (= 2^5 - 1). 354 o 356 * The 5-bit prefix is filled with its max value (31). 358 o The value to represent on next bytes is I = 1337 - (2^5 - 1) = 359 1306. 361 o 363 * 1306 = 128*10 + 26, i.e. Q=10 and R=26. 365 * Q is greater than 1, bit 8 is set to 1. 367 * The remainder R=26 is encoded on next 7 bits. 369 * I is replaced by the quotient Q=10. 371 o The value to represent on next bytes is I = 10. 373 o 375 * 10 = 128*0 + 10, i.e. Q=0 and R=10. 377 * Q is equal to 0, bit 16 is set to 0. 379 * The remainder R=10 is encoded on next 7 bits. 381 * I is replaced by the quotient Q=0. 383 o The process ends. 385 0 1 2 3 4 5 6 7 386 +---+---+---+---+---+---+---+---+ 387 | X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31 388 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | Q>=1, R=26 389 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | Q=0 , R=10 390 +---+---+---+---+---+---+---+---+ 392 4.2.2. String literal representation 394 Literal strings can represent header names or header values. They 395 are encoded in two parts: 397 1. The string length, defined as the number of bytes needed to store 398 its UTF-8 representation, is represented as an integer with a 399 zero bits prefix. If the string length is strictly less than 400 128, it is represented as one byte. 402 2. The string value represented as a list of UTF-8 characters. 404 4.3. Indexed Header Representation 406 0 1 2 3 4 5 6 7 407 +---+---+---+---+---+---+---+---+ 408 | 1 | Index (7+) | 409 +---+---------------------------+ 411 This representation starts with the '1' 1-bit prefix, followed by the 412 index of the matching pair, represented as an integer with a 7-bit 413 prefix. 415 4.4. Literal Header Representation 417 4.4.1. Literal Header without Indexing 419 0 1 2 3 4 5 6 7 420 +---+---+---+---+---+---+---+---+ 421 | 0 | 1 | 1 | Index (5+) | 422 +---+---+---+-------------------+ 424 This representation, which does not involve updating the header 425 table, starts with the '011' 3-bit pattern. 427 If the header name matches the header name of a (name, value) pair 428 stored in the Header Table, the index of the pair increased by one 429 (index + 1) is represented as an integer with a 5-bit prefix. Note 430 that if the index is strictly below 31, one byte is used. 432 If the header name does not match a header name entry, the value 0 is 433 represented on 5 bits followed by the header name, represented as a 434 literal string. 436 Header name representation is followed by the header value 437 represented as a literal string as described in Section 4.2.2. 439 4.4.2. Literal Header with Incremental Indexing 441 0 1 2 3 4 5 6 7 442 +---+---+---+---+---+---+---+---+ 443 | 0 | 1 | 0 | Index (5+) | 444 +---+---+---+-------------------+ 446 This representation starts with the '010' 3-bit pattern. 448 If the header name matches the header name of a (name, value) pair 449 stored in the Header Table, the index of the pair increased by one 450 (index + 1) is represented as an integer with a 5-bit prefix. Note 451 that if the index is strictly below 31, one byte is used. 453 If the header name does not match a header name entry, the value 0 is 454 represented on 5 bits followed by the header name, represented as a 455 literal string. 457 Header name representation is followed by the header value 458 represented as a literal string as described in Section 4.2.2. 460 4.4.3. Literal Header with Substitution Indexing 462 0 1 2 3 4 5 6 7 463 +---+---+---+---+---+---+---+---+ 464 | 0 | 0 | Index (6+) | 465 +---+---+-----------------------+ 467 This representation starts with the '00' 2-bit pattern. 469 If the header name matches the header name of a (name, value) pair 470 stored in the Header Table, the index of the pair increased by one 471 (index + 1) is represented as an integer with a 6-bit prefix. Note 472 that if the index is strictly below 62, one byte is used. 474 If the header name does not match a header name entry, the value 0 is 475 represented on 6 bits followed by the header name, represented as a 476 literal string. 478 The index of the substituted (name, value) pair is inserted after the 479 header name representation as a 0-bit prefix integer. 481 This index is followed by the header value represented as a literal 482 string as described in Section 4.2.2. 484 5. Parameter Negotiation 486 A few parameters can be used to accomodate client and server 487 processing and memory requirements. 489 SETTINGS_MAX_BUFFER_SIZE: Allows the sender to inform the remote 490 endpoint of the maximum size it accepts for the header table. 491 The default value is 4096 bytes. 492 [[Is this default value OK? Do we need a maximum size? Do we 493 want to allow infinite buffer?]] 494 When the remote endpoint receives a SETTINGS frame containing a 495 SETTINGS_MAX_BUFFER_SIZE setting with a value smaller than the one 496 currently in use, it MUST send as soon as possible a HEADER frame 497 with a stream identifier of 0x0 containing a value smaller than or 498 equal to the received setting value. 499 [[This changes slightly the behaviour of the HEADERS frame, which 500 should be updated as follows: ]] 501 A HEADER frame with a stream identifier of 0x0 indicates that the 502 sender has reduced the maximum size of the header table. The new 503 maximum size of the header table is encoded on 32-bit. The 504 decoder MUST reduce its own header table by dropping entries from 505 it until the size of the header table is lower than or equal to 506 the transmitted maximum size. 508 6. Security Considerations 510 TODO? 512 7. IANA Considerations 514 This memo includes no request to IANA. 516 8. Informative References 518 [SPDY] Belshe, M. and R. Peon, "SPDY Protocol", February 2012, 519 . 521 Appendix A. Initial header names 523 [[The tables in this section should be updated based on statistical 524 analysis of header names frequency and specific HTTP 2.0 header rules 525 (like removal of some headers). ]] 526 [[These tables are not adapted for headers contained in PUSH_PROMISE 527 frames. Either the tables can be merged, or the table for responses 528 can be updated. ]] 530 A.1. Requests 532 The following table lists the pre-defined headers that make-up the 533 initial header table user to represent requests sent from a client to 534 a server. 536 +-------+---------------------+--------------+ 537 | Index | Header Name | Header Value | 538 +-------+---------------------+--------------+ 539 | 0 | :scheme | http | 540 | 1 | :scheme | https | 541 | 2 | :host | | 542 | 3 | :path | / | 543 | 4 | :method | get | 544 | 5 | accept | | 545 | 6 | accept-charset | | 546 | 7 | accept-encoding | | 547 | 8 | accept-language | | 548 | 9 | cookie | | 549 | 10 | if-modified-since | | 550 | 11 | keep-alive | | 551 | 12 | user-agent | | 552 | 13 | proxy-connection | | 553 | 14 | referer | | 554 | 15 | accept-datetime | | 555 | 16 | authorization | | 556 | 17 | allow | | 557 | 18 | cache-control | | 558 | 19 | connection | | 559 | 20 | content-length | | 560 | 21 | content-md5 | | 561 | 22 | content-type | | 562 | 23 | date | | 563 | 24 | expect | | 564 | 25 | from | | 565 | 26 | if-match | | 566 | 27 | if-none-match | | 567 | 28 | if-range | | 568 | 29 | if-unmodified-since | | 569 | 30 | max-forwards | | 570 | 31 | pragma | | 571 | 32 | proxy-authorization | | 572 | 33 | range | | 573 | 34 | te | | 574 | 35 | upgrade | | 575 | 36 | via | | 576 | 37 | warning | | 577 +-------+---------------------+--------------+ 579 Table 1 581 A.2. Responses 583 The following table lists the pre-defined headers that make-up the 584 initial header table used to represent responses sent from a server 585 to a client. The same header table is also used to represent request 586 headers sent from a server to a client in a PUSH_PROMISE frame. 588 +-------+-----------------------------+--------------+ 589 | Index | Header Name | Header Value | 590 +-------+-----------------------------+--------------+ 591 | 0 | :status | 200 | 592 | 1 | age | | 593 | 2 | cache-control | | 594 | 3 | content-length | | 595 | 4 | content-type | | 596 | 5 | date | | 597 | 6 | etag | | 598 | 7 | expires | | 599 | 8 | last-modified | | 600 | 9 | server | | 601 | 10 | set-cookie | | 602 | 11 | vary | | 603 | 12 | via | | 604 | 13 | access-control-allow-origin | | 605 | 14 | accept-ranges | | 606 | 15 | allow | | 607 | 16 | connection | | 608 | 17 | content-disposition | | 609 | 18 | content-encoding | | 610 | 19 | content-language | | 611 | 20 | content-location | | 612 | 21 | content-md5 | | 613 | 22 | content-range | | 614 | 23 | link | | 615 | 24 | location | | 616 | 25 | p3p | | 617 | 26 | pragma | | 618 | 27 | proxy-authenticate | | 619 | 28 | refresh | | 620 | 29 | retry-after | | 621 | 30 | strict-transport-security | | 622 | 31 | trailer | | 623 | 32 | transfer-encoding | | 624 | 33 | warning | | 625 | 34 | www-authenticate | | 626 +-------+-----------------------------+--------------+ 628 Table 2 630 Appendix B. Example 632 Here is an example that illustrates different representations and how 633 tables are updated. [[This section needs to be updated to integrate 634 differential coding.]] 636 B.1. First header set 638 The first header set to represent is the following: 640 :path: /my-example/index.html 641 user-agent: my-user-agent 642 x-my-header: first 644 The header table is empty, all headers are represented as literal 645 headers with indexing. The 'x-my-header' header name is not in the 646 header name table and is encoded literally. This gives the following 647 representation: 649 0x44 (literal header with incremental indexing, name index = 3) 650 0x16 (header value string length = 22) 651 /my-example/index.html 652 0x4D (literal header with incremental indexing, name index = 12) 653 0x0D (header value string length = 13) 654 my-user-agent 655 0x40 (literal header with incremental indexing, new name) 656 0x0B (header name string length = 11) 657 x-my-header 658 0x05 (header value string length = 5) 659 first 661 The header table is as follows after the processing of these headers: 663 Header table 664 +---------+----------------+---------------------------+ 665 | Index | Header Name | Header Value | 666 +---------+----------------+---------------------------+ 667 | 0 | :scheme | http | 668 +---------+----------------+---------------------------+ 669 | 1 | :scheme | https | 670 +---------+----------------+---------------------------+ 671 | ... | ... | ... | 672 +---------+----------------+---------------------------+ 673 | 37 | warning | | 674 +---------+----------------+---------------------------+ 675 | 38 | :path | /my-example/index.html | added header 676 +---------+----------------+---------------------------+ 677 | 39 | user-agent | my-user-agent | added header 678 +---------+----------------+---------------------------+ 679 | 40 | x-my-header | first | added header 680 +---------+----------------+---------------------------+ 682 As all the headers in the first header set are indexed in the header 683 table, all are kept in the reference set of headers, which is: 685 Reference Set: 686 :path, /my-example/index.html 687 user-agent, my-user-agent 688 x-my-header, first 690 B.2. Second header set 692 The second header set to represent is the following: 694 :path: /my-example/resources/script.js 695 user-agent: my-user-agent 696 x-my-header: second 698 Comparing this second header set to the reference set, the first and 699 third headers are from the reference set are not present in this 700 second header set and must be removed. In addition, in this new set, 701 the first and third headers have to be encoded. The path header is 702 represented as a literal header with substitution indexing. The x 703 -my-header will be represented as a literal header with incremental 704 indexing. 706 0xa6 (indexed header, index = 38: removal from reference set) 707 0xa8 (indexed header, index = 40: removal from reference set) 708 0x04 (literal header, substitution indexing, name index = 3) 709 0x26 (replaced entry index = 38) 710 0x1f (header value string length = 31) 711 /my-example/resources/script.js 712 0x5f 0x0a (literal header, incremental indexing, name index = 40) 713 0x06 (header value string length = 6) 714 second 716 The header table is updated as follow: 718 Header table 719 +---------+----------------+---------------------------+ 720 | Index | Header Name | Header Value | 721 +---------+----------------+---------------------------+ 722 | 0 | :scheme | http | 723 +---------+----------------+---------------------------+ 724 | 1 | :scheme | https | 725 +---------+----------------+---------------------------+ 726 | ... | ... | ... | 727 +---------+----------------+---------------------------+ 728 | 37 | warning | | 729 +---------+----------------+---------------------------+ 730 | 38 | :path | /my-example/resources/ | replaced 731 | | | script.js | header 732 +---------+----------------+---------------------------+ 733 | 39 | user-agent | my-user-agent | 734 +---------+----------------+---------------------------+ 735 | 40 | x-my-header | first | 736 +---------+----------------+---------------------------+ 737 | 41 | x-my-header | second | added header 738 +---------+----------------+---------------------------+ 740 All the headers in this second header set are indexed in the header 741 table, therefore, all are kept in the reference set of headers, which 742 becomes: 744 Reference Set: 745 :path, /my-example/resources/script.js 746 user-agent, my-user-agent 747 x-my-header, second 749 Authors' Addresses 750 Roberto Peon 751 Google, Inc 753 EMail: fenix@google.com 755 Herve Ruellan 756 Canon CRF 758 EMail: herve.ruellan@crf.canon.fr