idnits 2.17.1 draft-ietf-httpbis-header-compression-01.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 167: '... implementations MUST be prepared to a...' RFC 2119 keyword, line 169: '... the table, they MUST be treated as di...' RFC 2119 keyword, line 196: '...eader table size MUST NOT exceed this ...' RFC 2119 keyword, line 262: '... equivalent ones MUST be executed by t...' RFC 2119 keyword, line 563: '...substituted pair MUST correspond to a ...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2013) is 3916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 324 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: January 10, 2014 Canon CRF 6 July 09, 2013 8 HTTP/2.0 Header Compression 9 draft-ietf-httpbis-header-compression-01 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 January 10, 2014. 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 . . . . . . . . . . . . . . . 6 58 3.4. Differential Coding . . . . . . . . . . . . . . . . . . . 6 59 4. Detailed Format . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Header Blocks . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 10 66 4.4.1. Literal Header without Indexing . . . . . . . . . . . 10 67 4.4.2. Literal Header with Incremental Indexing . . . . . . 10 68 4.4.3. Literal Header with Substitution Indexing . . . . . . 11 69 5. Parameter Negotiation . . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 8. Informative References . . . . . . . . . . . . . . . . . . . 13 73 Appendix A. Initial header names . . . . . . . . . . . . . . . . 13 74 A.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 14 75 A.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 16 77 B.1. First header set . . . . . . . . . . . . . . . . . . . . 16 78 B.2. Second header set . . . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 An input header name matches the header name of a (name, value) pair 159 stored in the Header Table if they are equal using a character-based, 160 _case sensitive_ comparison. An input header value matches the 161 header value of a (name, value) pair stored in the Header Table if 162 they are equal using a character-based, _case sensitive_ comparison. 163 An input header (name, value) pair matches a pair in the Header Table 164 if both the name and value are matching as per above. 166 Generally, the header table will not contain duplicate header (name, 167 value) entries. However, implementations MUST be prepared to accept 168 duplicates without signaling an error. If duplicates are added to 169 the table, they MUST be treated as distinct entries with their own 170 index positions. 172 The header table is progressively updated based on headers 173 represented as literal (as defined in Section 3.3.1). Two update 174 mechanisms are defined: 176 o Incremental indexing: the represented header is inserted at the 177 end of the header table as a (name, value) pair. The inserted 178 pair index is set to the next free index in the table: it is equal 179 to the number of headers in the table before its insertion. 181 o Substitution indexing: the represented header contains an index to 182 an existing (name, value) pair. The existing pair value is 183 replaced by the pair representing the new header. 185 Incremental and substitution indexing are optional. If none of them 186 is selected in a header representation, the header table is not 187 updated. In particular, no update happens on the header table when 188 processing an indexed representation. 190 The header table size can be bounded so as to limit the memory 191 requirements (see the SETTINGS_MAX_BUFFER_SIZE in Section 5). The 192 header table size is defined as the sum of the size of each entry of 193 the table. The size of an entry is the sum of the length in bytes 194 (as defined in Section 4.2.2) of its name, of value's length in bytes 195 and of 32 bytes (for accounting for the entry structure overhead). 196 The header table size MUST NOT exceed this limit. 198 Before adding a new entry to the header table or changing an existing 199 one, a check has to be performed to ensure that the change will not 200 cause the table to grow in size beyond the SETTINGS_MAX_BUFFER_SIZE 201 limit. If necessary, one or more items from the beginning of the 202 table are removed until there is enough free space available to make 203 the modification. Dropping an entry from the beginning of the table 204 causes the index positions of the remaining entries in the table to 205 be decremented by 1. [[Feedback is needed on this automatic eviction 206 strategy. ]] 208 When using substitution indexing, it is possible that the existing 209 item being replaced might be one of the items removed when performing 210 the necessary size adjustment. In such cases, the substituted value 211 being added to the header table is inserted at the beginning of the 212 header table (at index position #0) and the index positions of the 213 other remaining entries in the table are incremented by 1. 215 To optimize the representation of the headers exchanged at the 216 beginning of an HTTP/2.0 session, the header table is initialized 217 with common headers. Two lists of initial headers are provided in 218 Appendix A. One is for messages sent from a client to a server, the 219 other is for messages sent from a server to a client. 221 3.3. Header Representation 223 3.3.1. Literal Representation 225 The literal representation defines a new header. A literal header is 226 represented as: 228 o A header name, with two possible representations: 230 * A literal string, as described in Section 4.2.2. 232 * A index in the header table referencing the name of the 233 corresponding header. The index is represented as an integer, 234 as described in Section 4.2.1. 236 o The header value, represented as a literal string, as described in 237 Section 4.2.2. 239 3.3.2. Indexed Representation 241 The indexed representation defines a header as a match to a (name, 242 value) pair in the header table. An indexed header is represented 243 as: 245 o An integer representing the index of the matching (name, value) 246 pair, as described in Section 4.2.1. 248 3.4. Differential Coding 250 A set of headers is encoded as a difference from the previous 251 reference set of headers. The initial reference set of headers is 252 the empty set. 254 An indexed representation toggles the presence of the header in the 255 current set of headers. If the header corresponding to the indexed 256 representation was not in the set, it is added to the set. If the 257 header index was in the set, it is removed from it. 259 A literal representation adds a header to the current set of headers. 261 To ensure a correct decoding of a set of headers, the following steps 262 or equivalent ones MUST be executed by the decoder. 264 First, upon starting the decoding of a new set of headers, the 265 reference set of headers is interpreted into the working set of 266 headers: for each header in the reference set, an entry is added to 267 the working set, containing the header name, its value, and its 268 current index in the header table. 270 Then, the header representations are processed in their order of 271 occurrence in the frame. 273 For an indexed representation, the decoder checks whether the index 274 is present in the working set. If true, the corresponding entry is 275 removed from the working set. If several entries correspond to this 276 encoded index, all these entries are removed from the working set. 277 If the index is not present in the working set, it is used to 278 retrieve the corresponding header from the header table, and a new 279 entry is added to the working set representing this header. 281 For a literal representation, a new entry is added to the working set 282 representing this header. If the literal representation specifies 283 that the header is to be indexed, the header is added accordingly to 284 the header table, and its index is included in the entry in the 285 working set. Otherwise, the entry in the working set contains an 286 undefined index. 288 When all the header representations have been processed, the working 289 set contains all the headers of the set of headers. 291 The new reference set of headers is computed by removing from the 292 working set all the headers that are not present in the header table. 294 It should be noted that during the decoding of the header 295 representations, the same index may be associated to different 296 headers in the working set and in the header table. 298 4. Detailed Format 300 4.1. Header Blocks 302 A header block consists of a set of header fields, which are name- 303 value pairs. Each header field is encoded using one of the header 304 representation. 306 4.2. Low-level representations 308 4.2.1. Integer representation 310 Integers are used to represent name indexes, pair indexes or string 311 lengths. The integer representation keeps byte-alignment as much as 312 possible as this allows various processing optimizations as well as 313 efficient use of DEFLATE. For that purpose, an integer 314 representation always finishes at the end of a byte. 316 An integer is represented in two parts: a prefix that fills the 317 current byte and an optional list of bytes that are used if the 318 integer value does not fit in the prefix. The number of bits of the 319 prefix (called N) is a parameter of the integer representation. 321 The N-bit prefix allows filling the current byte. If the value is 322 small enough (strictly less than 2^N-1), it is encoded within the 323 N-bit prefix. Otherwise all the bits of the prefix are set to 1 and 324 the value is encoded using an unsigned variable length integer [1] 325 representation. 327 The algorithm to represent an integer I is as follows: 329 1. If I < 2^N - 1, encode I on N bits 331 2. Else, encode 2^N - 1 on N bits and do the following steps: 333 3. 335 1. Set I to (I - (2^N - 1)) and Q to 1 336 2. While Q > 0 338 3. 340 1. Compute Q and R, quotient and remainder of I divided by 341 2^7 343 2. If Q is strictly greater than 0, write one 1 bit; 344 otherwise, write one 0 bit 346 3. Encode R on the next 7 bits 348 4. I = Q 350 4.2.1.1. Example 1: Encoding 10 using a 5-bit prefix 352 The value 10 is to be encoded with a 5-bit prefix. 354 o 10 is less than 31 (= 2^5 - 1) and is represented using the 5-bit 355 prefix. 357 0 1 2 3 4 5 6 7 358 +---+---+---+---+---+---+---+---+ 359 | X | X | X | 0 | 1 | 0 | 1 | 0 | 10 stored on 5 bits 360 +---+---+---+---+---+---+---+---+ 362 4.2.1.2. Example 2: Encoding 1337 using a 5-bit prefix 364 The value I=1337 is to be encoded with a 5-bit prefix. 366 o 1337 is greater than 31 (= 2^5 - 1). 368 o 370 * The 5-bit prefix is filled with its max value (31). 372 o The value to represent on next bytes is I = 1337 - (2^5 - 1) = 373 1306. 375 o 377 * 1306 = 128*10 + 26, i.e. Q=10 and R=26. 379 * Q is greater than 1, bit 8 is set to 1. 381 * The remainder R=26 is encoded on next 7 bits. 383 * I is replaced by the quotient Q=10. 385 o The value to represent on next bytes is I = 10. 387 o 389 * 10 = 128*0 + 10, i.e. Q=0 and R=10. 391 * Q is equal to 0, bit 16 is set to 0. 393 * The remainder R=10 is encoded on next 7 bits. 395 * I is replaced by the quotient Q=0. 397 o The process ends. 399 0 1 2 3 4 5 6 7 400 +---+---+---+---+---+---+---+---+ 401 | X | X | X | 1 | 1 | 1 | 1 | 1 | Prefix = 31 402 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | Q>=1, R=26 403 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | Q=0 , R=10 404 +---+---+---+---+---+---+---+---+ 406 4.2.2. String literal representation 408 Literal strings can represent header names or header values. They 409 are encoded in two parts: 411 1. The string length, defined as the number of bytes needed to store 412 its UTF-8 representation, is represented as an integer with a 413 zero bits prefix. If the string length is strictly less than 414 128, it is represented as one byte. 416 2. The string value represented as a list of UTF-8 characters. 418 4.3. Indexed Header Representation 420 0 1 2 3 4 5 6 7 421 +---+---+---+---+---+---+---+---+ 422 | 1 | Index (7+) | 423 +---+---------------------------+ 425 Indexed Header 427 This representation starts with the '1' 1-bit pattern, followed by 428 the index of the matching pair, represented as an integer with a 429 7-bit prefix. 431 4.4. Literal Header Representation 433 4.4.1. Literal Header without Indexing 435 0 1 2 3 4 5 6 7 436 +---+---+---+---+---+---+---+---+ 437 | 0 | 1 | 1 | Index (5+) | 438 +---+---+---+-------------------+ 439 | Value Length (8+) | 440 +-------------------------------+ 441 | Value String (Length octets) | 442 +-------------------------------+ 444 Literal Header without Indexing - Indexed Name 446 0 1 2 3 4 5 6 7 447 +---+---+---+---+---+---+---+---+ 448 | 0 | 1 | 1 | 0 | 449 +---+---+---+-------------------+ 450 | Name Length (8+) | 451 +-------------------------------+ 452 | Name String (Length octets) | 453 +-------------------------------+ 454 | Value Length (8+) | 455 +-------------------------------+ 456 | Value String (Length octets) | 457 +-------------------------------+ 459 Literal Header without Indexing - New Name 461 This representation, which does not involve updating the header 462 table, starts with the '011' 3-bit pattern. 464 If the header name matches the header name of a (name, value) pair 465 stored in the Header Table, the index of the pair increased by one 466 (index + 1) is represented as an integer with a 5-bit prefix. Note 467 that if the index is strictly below 31, one byte is used. 469 If the header name does not match a header name entry, the value 0 is 470 represented on 5 bits followed by the header name, represented as a 471 literal string. 473 Header name representation is followed by the header value 474 represented as a literal string as described in Section 4.2.2. 476 4.4.2. Literal Header with Incremental Indexing 477 0 1 2 3 4 5 6 7 478 +---+---+---+---+---+---+---+---+ 479 | 0 | 1 | 0 | Index (5+) | 480 +---+---+---+-------------------+ 481 | Value Length (8+) | 482 +-------------------------------+ 483 | Value String (Length octets) | 484 +-------------------------------+ 486 Literal Header with Incremental Indexing - Indexed Name 488 0 1 2 3 4 5 6 7 489 +---+---+---+---+---+---+---+---+ 490 | 0 | 1 | 0 | 0 | 491 +---+---+---+-------------------+ 492 | Name Length (8+) | 493 +-------------------------------+ 494 | Name String (Length octets) | 495 +-------------------------------+ 496 | Value Length (8+) | 497 +-------------------------------+ 498 | Value String (Length octets) | 499 +-------------------------------+ 501 Literal Header with Incremental Indexing - New Name 503 This representation starts with the '010' 3-bit pattern. 505 If the header name matches the header name of a (name, value) pair 506 stored in the Header Table, the index of the pair increased by one 507 (index + 1) is represented as an integer with a 5-bit prefix. Note 508 that if the index is strictly below 31, one byte is used. 510 If the header name does not match a header name entry, the value 0 is 511 represented on 5 bits followed by the header name, represented as a 512 literal string. 514 Header name representation is followed by the header value 515 represented as a literal string as described in Section 4.2.2. 517 4.4.3. Literal Header with Substitution Indexing 519 0 1 2 3 4 5 6 7 520 +---+---+---+---+---+---+---+---+ 521 | 0 | 0 | Index (6+) | 522 +---+---+-----------------------+ 523 | Substituted Index (8+) | 524 +-------------------------------+ 525 | Value Length (8+) | 526 +-------------------------------+ 527 | Value String (Length octets) | 528 +-------------------------------+ 530 Literal Header with Substitution Indexing - Indexed Name 532 0 1 2 3 4 5 6 7 533 +---+---+---+---+---+---+---+---+ 534 | 0 | 0 | 0 | 535 +---+---+-----------------------+ 536 | Name Length (8+) | 537 +-------------------------------+ 538 | Name String (Length octets) | 539 +-------------------------------+ 540 | Substituted Index (8+) | 541 +-------------------------------+ 542 | Value Length (8+) | 543 +-------------------------------+ 544 | Value String (Length octets) | 545 +-------------------------------+ 547 Literal Header with Substitution Indexing - New Name 549 This representation starts with the '00' 2-bit pattern. 551 If the header name matches the header name of a (name, value) pair 552 stored in the Header Table, the index of the pair increased by one 553 (index + 1) is represented as an integer with a 6-bit prefix. Note 554 that if the index is strictly below 62, one byte is used. 556 If the header name does not match a header name entry, the value 0 is 557 represented on 6 bits followed by the header name, represented as a 558 literal string. 560 The index of the substituted (name, value) pair is inserted after the 561 header name representation as a 0-bit prefix integer. 563 The index of the substituted pair MUST correspond to a position in 564 the header table containing a non-void entry. An index for the 565 substituted pair that corresponds to empty position in the header 566 table MUST be treated as an error. 568 This index is followed by the header value represented as a literal 569 string as described in Section 4.2.2. 571 5. Parameter Negotiation 572 A few parameters can be used to accomodate client and server 573 processing and memory requirements. [[These settings are currently 574 not supported as they have not been integrated in the main 575 specification. Therefore, the maximum buffer size for the header 576 table is fixed at 4096 bytes. ]] 578 SETTINGS_MAX_BUFFER_SIZE: Allows the sender to inform the remote 579 endpoint of the maximum size it accepts for the header table. 580 The default value is 4096 bytes. 581 [[Is this default value OK? Do we need a maximum size? Do we 582 want to allow infinite buffer?]] 583 When the remote endpoint receives a SETTINGS frame containing a 584 SETTINGS_MAX_BUFFER_SIZE setting with a value smaller than the one 585 currently in use, it MUST send as soon as possible a HEADER frame 586 with a stream identifier of 0x0 containing a value smaller than or 587 equal to the received setting value. 588 [[This changes slightly the behaviour of the HEADERS frame, which 589 should be updated as follows: ]] 590 A HEADER frame with a stream identifier of 0x0 indicates that the 591 sender has reduced the maximum size of the header table. The new 592 maximum size of the header table is encoded on 32-bit. The 593 decoder MUST reduce its own header table by dropping entries from 594 it until the size of the header table is lower than or equal to 595 the transmitted maximum size. 597 6. Security Considerations 599 TODO? 601 7. IANA Considerations 603 This memo includes no request to IANA. 605 8. Informative References 607 [SPDY] Belshe, M. and R. Peon, "SPDY Protocol", February 2012, 608 . 610 Appendix A. Initial header names 612 [[The tables in this section should be updated based on statistical 613 analysis of header names frequency and specific HTTP 2.0 header rules 614 (like removal of some headers). ]] 615 [[These tables are not adapted for headers contained in PUSH_PROMISE 616 frames. Either the tables can be merged, or the table for responses 617 can be updated. ]] 619 A.1. Requests 621 The following table lists the pre-defined headers that make-up the 622 initial header table user to represent requests sent from a client to 623 a server. 625 +-------+---------------------+--------------+ 626 | Index | Header Name | Header Value | 627 +-------+---------------------+--------------+ 628 | 0 | :scheme | http | 629 | 1 | :scheme | https | 630 | 2 | :host | | 631 | 3 | :path | / | 632 | 4 | :method | GET | 633 | 5 | accept | | 634 | 6 | accept-charset | | 635 | 7 | accept-encoding | | 636 | 8 | accept-language | | 637 | 9 | cookie | | 638 | 10 | if-modified-since | | 639 | 11 | keep-alive | | 640 | 12 | user-agent | | 641 | 13 | proxy-connection | | 642 | 14 | referer | | 643 | 15 | accept-datetime | | 644 | 16 | authorization | | 645 | 17 | allow | | 646 | 18 | cache-control | | 647 | 19 | connection | | 648 | 20 | content-length | | 649 | 21 | content-md5 | | 650 | 22 | content-type | | 651 | 23 | date | | 652 | 24 | expect | | 653 | 25 | from | | 654 | 26 | if-match | | 655 | 27 | if-none-match | | 656 | 28 | if-range | | 657 | 29 | if-unmodified-since | | 658 | 30 | max-forwards | | 659 | 31 | pragma | | 660 | 32 | proxy-authorization | | 661 | 33 | range | | 662 | 34 | te | | 663 | 35 | upgrade | | 664 | 36 | via | | 665 | 37 | warning | | 666 +-------+---------------------+--------------+ 667 Table 1 669 A.2. Responses 671 The following table lists the pre-defined headers that make-up the 672 initial header table used to represent responses sent from a server 673 to a client. The same header table is also used to represent request 674 headers sent from a server to a client in a PUSH_PROMISE frame. 676 +-------+-----------------------------+--------------+ 677 | Index | Header Name | Header Value | 678 +-------+-----------------------------+--------------+ 679 | 0 | :status | 200 | 680 | 1 | age | | 681 | 2 | cache-control | | 682 | 3 | content-length | | 683 | 4 | content-type | | 684 | 5 | date | | 685 | 6 | etag | | 686 | 7 | expires | | 687 | 8 | last-modified | | 688 | 9 | server | | 689 | 10 | set-cookie | | 690 | 11 | vary | | 691 | 12 | via | | 692 | 13 | access-control-allow-origin | | 693 | 14 | accept-ranges | | 694 | 15 | allow | | 695 | 16 | connection | | 696 | 17 | content-disposition | | 697 | 18 | content-encoding | | 698 | 19 | content-language | | 699 | 20 | content-location | | 700 | 21 | content-md5 | | 701 | 22 | content-range | | 702 | 23 | link | | 703 | 24 | location | | 704 | 25 | p3p | | 705 | 26 | pragma | | 706 | 27 | proxy-authenticate | | 707 | 28 | refresh | | 708 | 29 | retry-after | | 709 | 30 | strict-transport-security | | 710 | 31 | trailer | | 711 | 32 | transfer-encoding | | 712 | 33 | warning | | 713 | 34 | www-authenticate | | 714 +-------+-----------------------------+--------------+ 715 Table 2 717 Appendix B. Example 719 Here is an example that illustrates different representations and how 720 tables are updated. [[This section needs to be updated to integrate 721 differential coding.]] 723 B.1. First header set 725 The first header set to represent is the following: 727 :path: /my-example/index.html 728 user-agent: my-user-agent 729 x-my-header: first 731 The header table is empty, all headers are represented as literal 732 headers with indexing. The 'x-my-header' header name is not in the 733 header name table and is encoded literally. This gives the following 734 representation: 736 0x44 (literal header with incremental indexing, name index = 3) 737 0x16 (header value string length = 22) 738 /my-example/index.html 739 0x4D (literal header with incremental indexing, name index = 12) 740 0x0D (header value string length = 13) 741 my-user-agent 742 0x40 (literal header with incremental indexing, new name) 743 0x0B (header name string length = 11) 744 x-my-header 745 0x05 (header value string length = 5) 746 first 748 The header table is as follows after the processing of these headers: 750 Header table 751 +---------+----------------+---------------------------+ 752 | Index | Header Name | Header Value | 753 +---------+----------------+---------------------------+ 754 | 0 | :scheme | http | 755 +---------+----------------+---------------------------+ 756 | 1 | :scheme | https | 757 +---------+----------------+---------------------------+ 758 | ... | ... | ... | 759 +---------+----------------+---------------------------+ 760 | 37 | warning | | 761 +---------+----------------+---------------------------+ 762 | 38 | :path | /my-example/index.html | added header 763 +---------+----------------+---------------------------+ 764 | 39 | user-agent | my-user-agent | added header 765 +---------+----------------+---------------------------+ 766 | 40 | x-my-header | first | added header 767 +---------+----------------+---------------------------+ 769 As all the headers in the first header set are indexed in the header 770 table, all are kept in the reference set of headers, which is: 772 Reference Set: 773 :path, /my-example/index.html 774 user-agent, my-user-agent 775 x-my-header, first 777 B.2. Second header set 779 The second header set to represent is the following: 781 :path: /my-example/resources/script.js 782 user-agent: my-user-agent 783 x-my-header: second 785 Comparing this second header set to the reference set, the first and 786 third headers are from the reference set are not present in this 787 second header set and must be removed. In addition, in this new set, 788 the first and third headers have to be encoded. The path header is 789 represented as a literal header with substitution indexing. The x 790 -my-header will be represented as a literal header with incremental 791 indexing. 793 0xa6 (indexed header, index = 38: removal from reference set) 794 0xa8 (indexed header, index = 40: removal from reference set) 795 0x04 (literal header, substitution indexing, name index = 3) 796 0x26 (replaced entry index = 38) 797 0x1f (header value string length = 31) 798 /my-example/resources/script.js 799 0x5f 0x0a (literal header, incremental indexing, name index = 40) 800 0x06 (header value string length = 6) 801 second 803 The header table is updated as follow: 805 Header table 806 +---------+----------------+---------------------------+ 807 | Index | Header Name | Header Value | 808 +---------+----------------+---------------------------+ 809 | 0 | :scheme | http | 810 +---------+----------------+---------------------------+ 811 | 1 | :scheme | https | 812 +---------+----------------+---------------------------+ 813 | ... | ... | ... | 814 +---------+----------------+---------------------------+ 815 | 37 | warning | | 816 +---------+----------------+---------------------------+ 817 | 38 | :path | /my-example/resources/ | replaced 818 | | | script.js | header 819 +---------+----------------+---------------------------+ 820 | 39 | user-agent | my-user-agent | 821 +---------+----------------+---------------------------+ 822 | 40 | x-my-header | first | 823 +---------+----------------+---------------------------+ 824 | 41 | x-my-header | second | added header 825 +---------+----------------+---------------------------+ 827 All the headers in this second header set are indexed in the header 828 table, therefore, all are kept in the reference set of headers, which 829 becomes: 831 Reference Set: 832 :path, /my-example/resources/script.js 833 user-agent, my-user-agent 834 x-my-header, second 836 Authors' Addresses 838 Roberto Peon 839 Google, Inc 841 EMail: fenix@google.com 843 Herve Ruellan 844 Canon CRF 846 EMail: herve.ruellan@crf.canon.fr