idnits 2.17.1 draft-ietf-quic-qpack-03.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 abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 03, 2018) is 2032 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1226 -- Looks like a reference, but probably isn't: '2' on line 1228 -- Looks like a reference, but probably isn't: '3' on line 1230 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-15 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-14 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC C. Krasic 3 Internet-Draft Netflix 4 Intended status: Standards Track M. Bishop 5 Expires: April 6, 2019 Akamai Technologies 6 A. Frindell, Ed. 7 Facebook 8 October 03, 2018 10 QPACK: Header Compression for HTTP over QUIC 11 draft-ietf-quic-qpack-03 13 Abstract 15 This specification defines QPACK, a compression format for 16 efficiently representing HTTP header fields, to be used in HTTP/QUIC. 17 This is a variation of HPACK header compression that seeks to reduce 18 head-of-line blocking. 20 Note to Readers 22 Discussion of this draft takes place on the QUIC working group 23 mailing list (quic@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 26 Working Group information can be found at https://github.com/quicwg 27 [2]; source code and issues list for this draft can be found at 28 https://github.com/quicwg/base-drafts/labels/-qpack [3]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 6, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Header Tables . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Static Table . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Dynamic Table . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2.1. Maximum Table Size . . . . . . . . . . . . . . . . . 5 69 2.2.2. Calculating Table Size . . . . . . . . . . . . . . . 6 70 2.2.3. Absolute Indexing . . . . . . . . . . . . . . . . . . 6 71 2.2.4. Relative Indexing . . . . . . . . . . . . . . . . . . 6 72 2.2.5. Post-Base Indexing . . . . . . . . . . . . . . . . . 7 73 2.3. Avoiding Head-of-Line Blocking in HTTP/QUIC . . . . . . . 8 74 2.3.1. State Synchronization . . . . . . . . . . . . . . . . 9 75 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 10 76 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 10 77 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Primitives . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1.1. Prefixed Integers . . . . . . . . . . . . . . . . . . 11 81 5.1.2. String Literals . . . . . . . . . . . . . . . . . . . 11 82 5.2. QPACK Encoder Stream . . . . . . . . . . . . . . . . . . 12 83 5.2.1. Insert With Name Reference . . . . . . . . . . . . . 12 84 5.2.2. Insert Without Name Reference . . . . . . . . . . . . 13 85 5.2.3. Duplicate . . . . . . . . . . . . . . . . . . . . . . 13 86 5.2.4. Dynamic Table Size Update . . . . . . . . . . . . . . 14 87 5.3. QPACK Decoder Stream . . . . . . . . . . . . . . . . . . 14 88 5.3.1. Table State Synchronize . . . . . . . . . . . . . . . 14 89 5.3.2. Header Acknowledgement . . . . . . . . . . . . . . . 15 90 5.3.3. Stream Cancellation . . . . . . . . . . . . . . . . . 16 91 5.4. Request and Push Streams . . . . . . . . . . . . . . . . 17 92 5.4.1. Header Data Prefix . . . . . . . . . . . . . . . . . 17 93 5.4.2. Instructions . . . . . . . . . . . . . . . . . . . . 18 94 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 21 95 7. Encoding Strategies . . . . . . . . . . . . . . . . . . . . . 22 96 7.1. Single Pass Encoding . . . . . . . . . . . . . . . . . . 22 97 7.2. Preventing Eviction Races . . . . . . . . . . . . . . . . 22 98 7.3. Reference Tracking . . . . . . . . . . . . . . . . . . . 22 99 7.3.1. Blocked Dynamic Table Insertions . . . . . . . . . . 22 100 7.3.2. Blocked Decoding . . . . . . . . . . . . . . . . . . 23 101 7.4. Speculative table updates . . . . . . . . . . . . . . . . 23 102 7.5. Sample One Pass Encoding Algorithm . . . . . . . . . . . 24 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 105 9.1. Settings Registration . . . . . . . . . . . . . . . . . . 26 106 9.2. Stream Type Registration . . . . . . . . . . . . . . . . 26 107 9.3. Error Code Registration . . . . . . . . . . . . . . . . . 26 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 110 10.2. Informative References . . . . . . . . . . . . . . . . . 28 111 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 112 Appendix A. Static Table . . . . . . . . . . . . . . . . . . . . 28 113 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33 114 B.1. Since draft-ietf-quic-qpack-02 . . . . . . . . . . . . . 33 115 B.2. Since draft-ietf-quic-qpack-01 . . . . . . . . . . . . . 33 116 B.3. Since draft-ietf-quic-qpack-00 . . . . . . . . . . . . . 33 117 B.4. Since draft-ietf-quic-qcram-00 . . . . . . . . . . . . . 34 118 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 121 1. Introduction 123 The QUIC transport protocol was designed from the outset to support 124 HTTP semantics, and its design subsumes many of the features of 125 HTTP/2. HTTP/2 uses HPACK ([RFC7541]) for header compression, but 126 QUIC's stream multiplexing comes into some conflict with HPACK. A 127 key goal of the design of QUIC is to improve stream multiplexing 128 relative to HTTP/2 by reducing head-of-line blocking. If HPACK were 129 used for HTTP/QUIC, it would induce head-of-line blocking due to 130 built-in assumptions of a total ordering across frames on all 131 streams. 133 QUIC is described in [QUIC-TRANSPORT]. The HTTP/QUIC mapping is 134 described in [QUIC-HTTP]. For a full description of HTTP/2, see 135 [RFC7540]. The description of HPACK is [RFC7541]. 137 QPACK reuses core concepts from HPACK, but is redesigned to allow 138 correctness in the presence of out-of-order delivery, with 139 flexibility for implementations to balance between resilience against 140 head-of-line blocking and optimal compression ratio. The design 141 goals are to closely approach the compression ratio of HPACK with 142 substantially less head-of-line blocking under the same loss 143 conditions. 145 QPACK preserves the ordering of header fields within each header 146 list. An encoder MUST emit header field representations in the order 147 they appear in the input header list. A decoder MUST must emit 148 header fields in the order their representations appear in the input 149 header block. 151 2. Header Tables 153 Like HPACK, QPACK uses two tables for associating header fields to 154 indices. The static table (see Section 2.1) is predefined and 155 contains common header fields (some of them with an empty value). 156 The dynamic table (see Section 2.2) is built up over the course of 157 the connection and can be used by the encoder to index header fields 158 repeated in the encoded header lists. 160 Unlike in HPACK, entries in the QPACK static and dynamic tables are 161 addressed separately. The following sections describe how entries in 162 each table are addressed. 164 2.1. Static Table 166 The static table consists of a predefined static list of header 167 fields, each of which has a fixed index over time. Its entries are 168 defined in Appendix A. 170 A decoder that encounters an invalid static table index on a request 171 stream or push stream MUST treat this as a stream error of type 172 "HTTP_QPACK_DECOMPRESSION_FAILED". If this index is received on the 173 encoder stream, this MUST be treated as a connection error of type 174 "HTTP_QPACK_ENCODER_STREAM_ERROR". 176 2.2. Dynamic Table 178 The dynamic table consists of a list of header fields maintained in 179 first-in, first-out order. The dynamic table is initially empty. 180 Entries are added by instructions on the encoder stream (see 181 Section 5.2). 183 The maximum size of the dynamic table can be modified by the encoder, 184 subject to a decoder-controlled limit (see Section 4 and 185 Section 5.2.4). The initial maximum size is determined by the 186 corresponding setting when HTTP requests or responses are first 187 permitted to be sent. For clients using 0-RTT data in HTTP/QUIC, the 188 table size is the remembered value of the setting, even if the server 189 later specifies a larger maximum in its SETTINGS frame. For HTTP/ 190 QUIC servers and HTTP/QUIC clients when 0-RTT is not attempted or is 191 rejected, the initial maximum table size is the value of the setting 192 in the peer's SETTINGS frame. 194 Before a new entry is added to the dynamic table, entries are evicted 195 from the end of the dynamic table until the size of the dynamic table 196 is less than or equal to (maximum size - new entry size) or until the 197 table is empty. The encoder MUST NOT evict a dynamic table entry 198 unless it has first been acknowledged by the decoder. 200 If the size of the new entry is less than or equal to the maximum 201 size, that entry is added to the table. It is an error to attempt to 202 add an entry that is larger than the maximum size; this MUST be 203 treated as a connection error of type 204 "HTTP_QPACK_ENCODER_STREAM_ERROR". 206 A new entry can reference an entry in the dynamic table that will be 207 evicted when adding this new entry into the dynamic table. 208 Implementations are cautioned to avoid deleting the referenced name 209 if the referenced entry is evicted from the dynamic table prior to 210 inserting the new entry. 212 The dynamic table can contain duplicate entries (i.e., entries with 213 the same name and same value). Therefore, duplicate entries MUST NOT 214 be treated as an error by a decoder. 216 2.2.1. Maximum Table Size 218 The encoder decides how to update the dynamic table and as such can 219 control how much memory is used by the dynamic table. To limit the 220 memory requirements of the decoder, the dynamic table size is 221 strictly bounded. 223 The decoder determines the maximum size that the encoder is permitted 224 to use for the dynamic table. In HTTP/QUIC, this value is determined 225 by the SETTINGS_HEADER_TABLE_SIZE setting (see Section 4). 227 An encoder can choose to use less capacity than this maximum size 228 (see Section 5.2.4), but the chosen size MUST stay lower than or 229 equal to the maximum set by the decoder. Whenever the maximum size 230 for the dynamic table is reduced, entries are evicted from the end of 231 the dynamic table until the size of the dynamic table is less than or 232 equal to the maximum size. 234 This mechanism can be used to completely clear entries from the 235 dynamic table by setting a maximum size of 0, which can subsequently 236 be restored. 238 2.2.2. Calculating Table Size 240 The size of the dynamic table is the sum of the size of its entries. 242 The size of an entry is the sum of its name's length in octets (as 243 defined in Section 5.1.2), its value's length in octets, and 32. 245 The size of an entry is calculated using the length of its name and 246 value without any Huffman encoding applied. 248 "MaxEntries" is the maximum number of entries that the dynamic table 249 can have. The smallest entry has empty name and value strings and 250 has the size of 32. The MaxEntries is calculated as 252 MaxEntries = floor( MaxTableSize / 32 ) 254 MaxTableSize is the maximum size of the dynamic table as specified by 255 the decoder (see Section 2.2.1). 257 2.2.3. Absolute Indexing 259 Each entry possesses both an absolute index which is fixed for the 260 lifetime of that entry and a relative index which changes over time 261 based on the context of the reference. The first entry inserted has 262 an absolute index of "1"; indices increase sequentially with each 263 insertion. 265 2.2.4. Relative Indexing 267 The relative index begins at zero and increases in the opposite 268 direction from the absolute index. Determining which entry has a 269 relative index of "0" depends on the context of the reference. 271 On the encoder stream, a relative index of "0" always refers to the 272 most recently inserted value in the dynamic table. Note that this 273 means the entry referenced by a given relative index will change 274 while interpreting instructions on the encoder stream. 276 +---+---------------+-----------+ 277 | n | ... | d + 1 | Absolute Index 278 + - +---------------+ - - - - - + 279 | 0 | ... | n - d - 1 | Relative Index 280 +---+---------------+-----------+ 281 ^ | 282 | V 283 Insertion Point Dropping Point 285 n = count of entries inserted 286 d = count of entries dropped 288 Example Dynamic Table Indexing - Control Stream 290 Because frames from request streams can be delivered out of order 291 with instructions on the encoder stream, relative indices are 292 relative to the Base Index at the beginning of the header block (see 293 Section 5.4.1). The Base Index is an absolute index. When 294 interpreting the rest of the frame, the entry identified by Base 295 Index has a relative index of zero. The relative indices of entries 296 do not change while interpreting headers on a request or push stream. 298 Base Index 299 | 300 V 301 +---+-----+-----+-----+-------+ 302 | n | n-1 | n-2 | ... | d+1 | Absolute Index 303 +---+-----+ - +-----+ - + 304 | 0 | ... | n-d-3 | Relative Index 305 +-----+-----+-------+ 307 n = count of entries inserted 308 d = count of entries dropped 310 Example Dynamic Table Indexing - Relative Index on Request Stream 312 2.2.5. Post-Base Indexing 314 A header block on the request stream can reference entries added 315 after the entry identified by the Base Index. This allows an encoder 316 to process a header block in a single pass and include references to 317 entries added while processing this (or other) header blocks. Newly 318 added entries are referenced using Post-Base instructions. Indices 319 for Post-Base instructions increase in the same direction as absolute 320 indices, but the zero value is one higher than the Base Index. 322 Base Index 323 | 324 V 325 +---+-----+-----+-----+-----+ 326 | n | n-1 | n-2 | ... | d+1 | Absolute Index 327 +---+-----+-----+-----+-----+ 328 | 1 | 0 | Post-Base Index 329 +---+-----+ 331 n = count of entries inserted 332 d = count of entries dropped 334 Example Dynamic Table Indexing - Post-Base Index on Request Stream 336 If the decoder encounters a reference on a request or push stream to 337 a dynamic table entry which has already been dropped or which has an 338 absolute index greater than the declared Largest Reference (see 339 Section 5.4.1), it MUST treat this as a stream error of type 340 "HTTP_QPACK_DECOMPRESSION_FAILED". 342 If the decoder encounters a reference on the encoder stream to a 343 dynamic table entry which has already been dropped, it MUST treat 344 this as a connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". 346 2.3. Avoiding Head-of-Line Blocking in HTTP/QUIC 348 Because QUIC does not guarantee order between data on different 349 streams, a header block might reference an entry in the dynamic table 350 that has not yet been received. 352 Each header block contains a Largest Reference which identifies the 353 table state necessary for decoding. If the greatest absolute index 354 in the dynamic table is less than the value of the Largest Reference, 355 the stream is considered "blocked." While blocked, header field data 356 should remain in the blocked stream's flow control window. When the 357 Largest Reference is zero, the frame contains no references to the 358 dynamic table and can always be processed immediately. A stream 359 becomes unblocked when the greatest absolute index in the dynamic 360 table becomes greater than or equal to the Largest Reference for all 361 header blocks the decoder has started reading from the stream. If a 362 decoder encounters a header block where the actual largest reference 363 is not equal to the Largest Reference declared in the prefix, it MAY 364 treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED. 366 A decoder can permit the possibility of blocked streams by setting 367 SETTINGS_QPACK_BLOCKED_STREAMS to a non-zero value (see Section 4). 368 This setting specifies an upper bound on the number of streams which 369 can be blocked. 371 An encoder can decide whether to risk having a stream become blocked. 372 If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS, 373 compression efficiency can be improved by referencing dynamic table 374 entries that are still in transit, but if there is loss or reordering 375 the stream can become blocked at the decoder. An encoder avoids the 376 risk of blocking by only referencing dynamic table entries which have 377 been acknowledged, but this means using literals. Since literals 378 make the header block larger, this can result in the encoder becoming 379 blocked on congestion or flow control limits. 381 An encoder MUST limit the number of streams which could become 382 blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times. 383 Note that the decoder might not actually become blocked on every 384 stream which risks becoming blocked. If the decoder encounters more 385 blocked streams than it promised to support, it MUST treat this as a 386 stream error of type HTTP_QPACK_DECOMPRESSION_FAILED. 388 2.3.1. State Synchronization 390 The decoder stream (Section 5.3) signals key events at the decoder 391 that permit the encoder to track the decoder's state. These events 392 are: 394 o Complete processing of a header block 396 o Abandonment of a stream which might have remaining header blocks 398 o Receipt of new dynamic table entries 400 Regardless of whether a header block contained blocking references, 401 the knowledge that it has been processed permits the encoder to evict 402 entries to which no unacknowledged references remain; see 403 Section 7.3.1. When a stream is reset or abandoned, the indication 404 that these header blocks will never be processed serves a similar 405 function; see Section 5.3.3. 407 For the encoder to identify which dynamic table entries can be safely 408 used without a stream becoming blocked, the encoder tracks the 409 absolute index of the decoder's Largest Known Received entry. 411 When blocking references are permitted, the encoder uses 412 acknowledgement of header blocks to identify the Largest Known 413 Received index, as described in Section 5.3.2. 415 To acknowledge dynamic table entries which are not referenced by 416 header blocks, for example because the encoder or the decoder have 417 chosen not to risk blocked streams, the decoder sends a Table State 418 Synchronize instruction (see Section 5.3.1). 420 3. Conventions and Definitions 422 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 423 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 424 "OPTIONAL" in this document are to be interpreted as described in BCP 425 14 [RFC2119] [RFC8174] when, and only when, they appear in all 426 capitals, as shown here. 428 Definitions of terms that are used in this document: 430 Header field: A name-value pair sent as part of an HTTP message. 432 Header list: The ordered collection of header fields associated with 433 an HTTP message. A header list can contain multiple header fields 434 with the same name. It can also contain duplicate header fields. 436 Header block: The compressed representation of a header list. 438 Encoder: An implementation which transforms a header list into a 439 header block. 441 Decoder: An implementation which transforms a header block into a 442 header list. 444 QPACK is a name, not an acronym. 446 3.1. Notational Conventions 448 Diagrams use the format described in Section 3.1 of [RFC2360], with 449 the following additional conventions: 451 x (A) Indicates that x is A bits long 453 x (A+) Indicates that x uses the prefixed integer encoding defined 454 in Section 5.1 of [RFC7541], beginning with an A-bit prefix. 456 x ... Indicates that x is variable-length and extends to the end of 457 the region. 459 4. Configuration 461 QPACK defines two settings which are included in the HTTP/QUIC 462 SETTINGS frame. 464 SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of 465 2^30 - 1. The default value is 4,096 bytes. See Section 2.2 for 466 usage. 468 SETTINGS_QPACK_BLOCKED_STREAMS (0x7): An integer with a maximum 469 value of 2^16 - 1. The default value is 100. See Section 2.3. 471 5. Wire Format 473 QPACK instructions occur in three locations, each of which uses a 474 separate instruction space: 476 o The encoder stream is a unidirectional stream of type "0x48" 477 (ASCII 'H') which carries table updates from encoder to decoder. 478 Instructions on this stream modify the dynamic table state without 479 generating output to any particular request. 481 o The decoder stream is a unidirectional stream of type "0x68" 482 (ASCII 'h') which carries acknowledgements of table modifications 483 and header processing from decoder to encoder. 485 o Finally, the contents of HEADERS and PUSH_PROMISE frames on 486 request streams and push streams reference the QPACK table state. 488 There MUST be exactly one of each unidirectional stream type in each 489 direction. Receipt of a second instance of either stream type MUST 490 be treated as a connection error of HTTP_WRONG_STREAM_COUNT. Closure 491 of either unidirectional stream MUST be treated as a connection error 492 of type HTTP_CLOSED_CRITICAL_STREAM. 494 This section describes the instructions which are possible on each 495 stream type. 497 All table updates occur on the encoder stream. Request streams and 498 push streams only carry header blocks that do not modify the state of 499 the table. 501 5.1. Primitives 503 5.1.1. Prefixed Integers 505 The prefixed integer from Section 5.1 of [RFC7541] is used heavily 506 throughout this document. The format from [RFC7541] is used 507 unmodified. QPACK implementations MUST be able to decode integers up 508 to 62 bits long. 510 5.1.2. String Literals 512 The string literal defined by Section 5.2 of [RFC7541] is also used 513 throughout. This string format includes optional Huffman encoding. 515 HPACK defines string literals to begin on a byte boundary. They 516 begin with a single flag (indicating whether the string is Huffman- 517 coded), followed by the Length encoded as a 7-bit prefix integer, and 518 finally Length octets of data. When Huffman encoding is enabled, the 519 Huffman table from Appendix B of [RFC7541] is used without 520 modification. 522 This document expands the definition of string literals and permits 523 them to begin other than on a byte boundary. An "N-bit prefix string 524 literal" begins with the same Huffman flag, followed by the length 525 encoded as an (N-1)-bit prefix integer. The remainder of the string 526 literal is unmodified. 528 A string literal without a prefix length noted is an 8-bit prefix 529 string literal and follows the definitions in [RFC7541] without 530 modification. 532 5.2. QPACK Encoder Stream 534 Table updates can add a table entry, possibly using existing entries 535 to avoid transmitting redundant information. The name can be 536 transmitted as a reference to an existing entry in the static or the 537 dynamic table or as a string literal. For entries which already 538 exist in the dynamic table, the full entry can also be used by 539 reference, creating a duplicate entry. 541 The contents of the encoder stream are an unframed sequence of the 542 following instructions. 544 5.2.1. Insert With Name Reference 546 An addition to the header table where the header field name matches 547 the header field name of an entry stored in the static table or the 548 dynamic table starts with the '1' one-bit pattern. The "S" bit 549 indicates whether the reference is to the static (S=1) or dynamic 550 (S=0) table. The 6-bit prefix integer (see Section 5.1 of [RFC7541]) 551 that follows is used to locate the table entry for the header name. 552 When S=1, the number represents the static table index; when S=0, the 553 number is the relative index of the entry in the dynamic table. 555 The header name reference is followed by the header field value 556 represented as a string literal (see Section 5.2 of [RFC7541]). 558 0 1 2 3 4 5 6 7 559 +---+---+---+---+---+---+---+---+ 560 | 1 | S | Name Index (6+) | 561 +---+---+-----------------------+ 562 | H | Value Length (7+) | 563 +---+---------------------------+ 564 | Value String (Length octets) | 565 +-------------------------------+ 567 Insert Header Field -- Indexed Name 569 5.2.2. Insert Without Name Reference 571 An addition to the header table where both the header field name and 572 the header field value are represented as string literals (see 573 Section 5.1) starts with the '01' two-bit pattern. 575 The name is represented as a 6-bit prefix string literal, while the 576 value is represented as an 8-bit prefix string literal. 578 0 1 2 3 4 5 6 7 579 +---+---+---+---+---+---+---+---+ 580 | 0 | 1 | H | Name Length (5+) | 581 +---+---+---+-------------------+ 582 | Name String (Length octets) | 583 +---+---------------------------+ 584 | H | Value Length (7+) | 585 +---+---------------------------+ 586 | Value String (Length octets) | 587 +-------------------------------+ 589 Insert Header Field -- New Name 591 5.2.3. Duplicate 593 Duplication of an existing entry in the dynamic table starts with the 594 '000' three-bit pattern. The relative index of the existing entry is 595 represented as an integer with a 5-bit prefix. 597 0 1 2 3 4 5 6 7 598 +---+---+---+---+---+---+---+---+ 599 | 0 | 0 | 0 | Index (5+) | 600 +---+---+---+-------------------+ 602 Figure 1: Duplicate 604 The existing entry is re-inserted into the dynamic table without 605 resending either the name or the value. This is useful to mitigate 606 the eviction of older entries which are frequently referenced, both 607 to avoid the need to resend the header and to avoid the entry in the 608 table blocking the ability to insert new headers. 610 5.2.4. Dynamic Table Size Update 612 An encoder informs the decoder of a change to the size of the dynamic 613 table using an instruction which begins with the '001' three-bit 614 pattern. The new maximum table size is represented as an integer 615 with a 5-bit prefix (see Section 5.1 of [RFC7541]). 617 0 1 2 3 4 5 6 7 618 +---+---+---+---+---+---+---+---+ 619 | 0 | 0 | 1 | Max size (5+) | 620 +---+---+---+-------------------+ 622 Figure 2: Maximum Dynamic Table Size Change 624 The new maximum size MUST be lower than or equal to the limit 625 determined by the protocol using QPACK. A value that exceeds this 626 limit MUST be treated as a connection error of type 627 "HTTP_QPACK_ENCODER_STREAM_ERROR". In HTTP/QUIC, this limit is the 628 value of the SETTINGS_HEADER_TABLE_SIZE parameter (see Section 4) 629 received from the decoder. 631 Reducing the maximum size of the dynamic table can cause entries to 632 be evicted (see Section 4.3 of [RFC7541]). This MUST NOT cause the 633 eviction of entries with outstanding references (see Section 7.3). 634 Changing the size of the dynamic table is not acknowledged as this 635 instruction does not insert an entry. 637 5.3. QPACK Decoder Stream 639 The decoder stream carries information used to ensure consistency of 640 the dynamic table. Information is sent from the QPACK decoder to the 641 QPACK encoder; that is, the server informs the client about the 642 processing of the client's header blocks and table updates, and the 643 client informs the server about the processing of the server's header 644 blocks and table updates. 646 The contents of the decoder stream are an unframed sequence of the 647 following instructions. 649 5.3.1. Table State Synchronize 651 The Table State Synchronize instruction begins with the '00' two-bit 652 pattern. The instruction specifies the total number of dynamic table 653 inserts and duplications since the last Table State Synchronize or 654 Header Acknowledgement that increased the Largest Known Received 655 dynamic table entry. This is encoded as a 6-bit prefix integer. The 656 encoder uses this value to determine which table entries might cause 657 a stream to become blocked, as described in Section 2.3.1. 659 0 1 2 3 4 5 6 7 660 +---+---+---+---+---+---+---+---+ 661 | 0 | 0 | Insert Count (6+) | 662 +---+---+-----------------------+ 664 Figure 3: Table State Synchronize 666 An encoder that receives an Insert Count equal to zero or one that 667 increases Largest Known Received beyond what the encoder has sent 668 MUST treat this as a connection error of type 669 "HTTP_QPACK_DECODER_STREAM_ERROR". 671 A decoder chooses when to emit Table State Synchronize instructions. 672 Emitting a Table State Synchronize after adding each new dynamic 673 table entry will provide the most timely feedback to the encoder, but 674 could be redundant with other decoder feedback. By delaying a 675 Table State Synchronize, a decoder might be able to coalesce multiple 676 Table State Synchronize instructions, or replace them entirely with 677 Header Acknowledgements. However, delaying too long may lead to 678 compression inefficiencies if the encoder waits for an entry to be 679 acknowledged before using it. 681 5.3.2. Header Acknowledgement 683 After processing a header block whose declared Largest Reference is 684 not zero, the decoder emits a Header Acknowledgement instruction on 685 the decoder stream. The instruction begins with the '1' one-bit 686 pattern and includes the request stream's stream ID, encoded as a 687 7-bit prefix integer. It is used by the peer's QPACK encoder to know 688 when it is safe to evict an entry. 690 0 1 2 3 4 5 6 7 691 +---+---+---+---+---+---+---+---+ 692 | 1 | Stream ID (7+) | 693 +---+---------------------------+ 695 Figure 4: Header Acknowledgement 697 The same Stream ID can be identified multiple times, as multiple 698 header blocks can be sent on a single stream in the case of 699 intermediate responses, trailers, and pushed requests. Since header 700 frames on each stream are received and processed in order, this gives 701 the encoder precise feedback on which header blocks within a stream 702 have been fully processed. 704 If an encoder receives a Header Acknowledgement instruction referring 705 to a stream on which every header block with a non-zero Largest 706 Reference has already been acknowledged, that MUST be treated as a 707 connection error of type "HTTP_QPACK_DECODER_STREAM_ERROR". 709 When blocking references are permitted, the encoder uses 710 acknowledgement of header blocks to update the Largest Known Received 711 index. If a header block was potentially blocking, the 712 acknowledgement implies that the decoder has received all dynamic 713 table state necessary to process the header block. If the Largest 714 Reference of an acknowledged header block was greater than the 715 encoder's current Largest Known Received index, the block's Largest 716 Reference becomes the new Largest Known Received. 718 5.3.3. Stream Cancellation 720 A stream that is reset might have multiple outstanding header blocks 721 with dynamic table references. A decoder that receives a stream 722 reset before the end of a stream generates a Stream Cancellation 723 instruction on the decoder stream. Similarly, a decoder that 724 abandons reading of a stream needs to signal this using the Stream 725 Cancellation instruction. This signals to the encoder that all 726 references to the dynamic table on that stream are no longer 727 outstanding. A decoder with a maximum dynamic table size equal to 728 zero MAY omit sending Stream Cancellations, because the encoder 729 cannot have any dynamic table references. 731 An encoder cannot infer from this instruction that any updates to the 732 dynamic table have been received. 734 The instruction begins with the '01' two-bit pattern. The 735 instruction includes the stream ID of the affected stream - a request 736 or push stream - encoded as a 6-bit prefix integer. 738 0 1 2 3 4 5 6 7 739 +---+---+---+---+---+---+---+---+ 740 | 0 | 1 | Stream ID (6+) | 741 +---+---+-----------------------+ 743 Figure 5: Stream Cancellation 745 5.4. Request and Push Streams 747 HEADERS and PUSH_PROMISE frames on request and push streams reference 748 the dynamic table in a particular state without modifying it. Frames 749 on these streams emit the headers for an HTTP request or response. 751 5.4.1. Header Data Prefix 753 Header data is prefixed with two integers, "Largest Reference" and 754 "Base Index". 756 0 1 2 3 4 5 6 7 757 +---+---+---+---+---+---+---+---+ 758 | Largest Reference (8+) | 759 +---+---------------------------+ 760 | S | Delta Base Index (7+) | 761 +---+---------------------------+ 762 | Compressed Headers ... 763 +-------------------------------+ 765 Figure 6: Frame Payload 767 "Largest Reference" identifies the largest absolute dynamic index 768 referenced in the block. Blocking decoders use the Largest Reference 769 to determine when it is safe to process the rest of the block. If 770 Largest Reference is greater than zero, the encoder transforms it as 771 follows before encoding: 773 LargestReference = LargestReference mod 2*MaxEntries + 1 775 The decoder reconstructs the Largest Reference using the following 776 algorithm: 778 if LargestReference > 0: 779 LargestReference -= 1 780 CurrentWrapped = TableLargestAbsoluteIndex mod 2*MaxEntries 782 if CurrentWrapped >= LargestReference + MaxEntries: 783 # Largest Reference wrapped around 1 extra time 784 LargestReference += 2*MaxEntries 785 else if CurrentWrapped + MaxEntries < LargestReference 786 # Decoder wrapped around 1 extra time 787 CurrentWrapped += 2*MaxEntries 789 LargestReference += 790 (TableLargestAbsoluteIndex - CurrentWrapped) 792 TableLargestAbsoluteIndex is the Absolute Index of the most recently 793 inserted item in the decoder's dynamic table. This encoding limits 794 the length of the prefix on long-lived connections. 796 "Base Index" is used to resolve references in the dynamic table as 797 described in Section 2.2.4. 799 To save space, Base Index is encoded relative to Largest Reference 800 using a one-bit sign and the "Delta Base Index" value. A sign bit of 801 0 indicates that the Base Index has an absolute index that is greater 802 than or equal to the Largest Reference; the value of Delta Base Index 803 is added to the Largest Reference to determine the absolute value of 804 the Base Index. A sign bit of 1 indicates that the Base Index is 805 less than the Largest Reference. That is: 807 if sign == 0: 808 baseIndex = largestReference + deltaBaseIndex 809 else: 810 baseIndex = largestReference - deltaBaseIndex 812 A single-pass encoder is expected to determine the absolute value of 813 Base Index before encoding a header block. If the encoder inserted 814 entries in the dynamic table while encoding the header block, Largest 815 Reference will be greater than Base Index, so the encoded difference 816 is negative and the sign bit is set to 1. If the header block did 817 not reference the most recent entry in the table and did not insert 818 any new entries, Base Index will be greater than the Largest 819 Reference, so the delta will be positive and the sign bit is set to 820 0. 822 An encoder that produces table updates before encoding a header block 823 might set Largest Reference and Base Index to the same value. When 824 Largest Reference and Base Index are equal, the Delta Base Index is 825 encoded with a zero sign bit. A sign bit set to 1 when the Delta 826 Base Index is 0 MUST be treated as a decoder error. 828 A header block that does not reference the dynamic table can use any 829 value for Base Index; setting both Largest Reference and Base Index 830 to zero is the most efficient encoding. 832 5.4.2. Instructions 834 5.4.2.1. Indexed Header Field 836 An indexed header field representation identifies an entry in either 837 the static table or the dynamic table and causes that header field to 838 be added to the decoded header list, as described in Section 3.2 of 839 [RFC7541]. 841 0 1 2 3 4 5 6 7 842 +---+---+---+---+---+---+---+---+ 843 | 1 | S | Index (6+) | 844 +---+---+-----------------------+ 846 Indexed Header Field 848 If the entry is in the static table, or in the dynamic table with an 849 absolute index less than or equal to Base Index, this representation 850 starts with the '1' 1-bit pattern, followed by the "S" bit indicating 851 whether the reference is into the static (S=1) or dynamic (S=0) 852 table. Finally, the relative index of the matching header field is 853 represented as an integer with a 6-bit prefix (see Section 5.1 of 854 [RFC7541]). 856 5.4.2.2. Indexed Header Field With Post-Base Index 858 If the entry is in the dynamic table with an absolute index greater 859 than Base Index, the representation starts with the '0001' 4-bit 860 pattern, followed by the post-base index (see Section 2.2.5) of the 861 matching header field, represented as an integer with a 4-bit prefix 862 (see Section 5.1 of [RFC7541]). 864 0 1 2 3 4 5 6 7 865 +---+---+---+---+---+---+---+---+ 866 | 0 | 0 | 0 | 1 | Index (4+) | 867 +---+---+---+---+---------------+ 869 Indexed Header Field with Post-Base Index 871 5.4.2.3. Literal Header Field With Name Reference 873 A literal header field with a name reference represents a header 874 where the header field name matches the header field name of an entry 875 stored in the static table or the dynamic table. 877 If the entry is in the static table, or in the dynamic table with an 878 absolute index less than or equal to Base Index, this representation 879 starts with the '01' two-bit pattern. If the entry is in the dynamic 880 table with an absolute index greater than Base Index, the 881 representation starts with the '0000' four-bit pattern. 883 The following bit, 'N', indicates whether an intermediary is 884 permitted to add this header to the dynamic header table on 885 subsequent hops. When the 'N' bit is set, the encoded header MUST 886 always be encoded with a literal representation. In particular, when 887 a peer sends a header field that it received represented as a literal 888 header field with the 'N' bit set, it MUST use a literal 889 representation to forward this header field. This bit is intended 890 for protecting header field values that are not to be put at risk by 891 compressing them (see Section 7.1 of [RFC7541] for more details). 893 0 1 2 3 4 5 6 7 894 +---+---+---+---+---+---+---+---+ 895 | 0 | 1 | N | S |Name Index (4+)| 896 +---+---+---+---+---------------+ 897 | H | Value Length (7+) | 898 +---+---------------------------+ 899 | Value String (Length octets) | 900 +-------------------------------+ 902 Literal Header Field With Name Reference 904 For entries in the static table or in the dynamic table with an 905 absolute index less than or equal to Base Index, the header field 906 name is represented using the relative index of that entry, which is 907 represented as an integer with a 4-bit prefix (see Section 5.1 of 908 [RFC7541]). The "S" bit indicates whether the reference is to the 909 static (S=1) or dynamic (S=0) table. 911 5.4.2.4. Literal Header Field With Post-Base Name Reference 913 For entries in the dynamic table with an absolute index greater than 914 Base Index, the header field name is represented using the post-base 915 index of that entry (see Section 2.2.5) encoded as an integer with a 916 3-bit prefix. 918 0 1 2 3 4 5 6 7 919 +---+---+---+---+---+---+---+---+ 920 | 0 | 0 | 0 | 0 | N |NameIdx(3+)| 921 +---+---+---+---+---+-----------+ 922 | H | Value Length (7+) | 923 +---+---------------------------+ 924 | Value String (Length octets) | 925 +-------------------------------+ 927 Literal Header Field With Post-Base Name Reference 929 5.4.2.5. Literal Header Field Without Name Reference 931 An addition to the header table where both the header field name and 932 the header field value are represented as string literals (see 933 Section 5.1) starts with the '001' three-bit pattern. 935 The fourth bit, 'N', indicates whether an intermediary is permitted 936 to add this header to the dynamic header table on subsequent hops. 938 When the 'N' bit is set, the encoded header MUST always be encoded 939 with a literal representation. In particular, when a peer sends a 940 header field that it received represented as a literal header field 941 with the 'N' bit set, it MUST use a literal representation to forward 942 this header field. This bit is intended for protecting header field 943 values that are not to be put at risk by compressing them (see 944 Section 7.1 of [RFC7541] for more details). 946 The name is represented as a 4-bit prefix string literal, while the 947 value is represented as an 8-bit prefix string literal. 949 0 1 2 3 4 5 6 7 950 +---+---+---+---+---+---+---+---+ 951 | 0 | 0 | 1 | N | H |NameLen(3+)| 952 +---+---+---+---+---+-----------+ 953 | Name String (Length octets) | 954 +---+---------------------------+ 955 | H | Value Length (7+) | 956 +---+---------------------------+ 957 | Value String (Length octets) | 958 +-------------------------------+ 960 Literal Header Field Without Name Reference 962 6. Error Handling 964 The following error codes are defined for HTTP/QUIC to indicate 965 failures of QPACK which prevent the stream or connection from 966 continuing: 968 HTTP_QPACK_DECOMPRESSION_FAILED (TBD): The decoder failed to 969 interpret an instruction on a request or push stream and is not 970 able to continue decoding that header block. 971 HTTP_QPACK_ENCODER_STREAM_ERROR (TBD): 973 The decoder failed to interpret an instruction on the encoder 974 stream. HTTP_QPACK_DECODER_STREAM_ERROR (TBD): 976 The encoder failed to interpret an instruction on the decoder 977 stream. 979 Upon encountering an error, an implementation MAY elect to treat it 980 as a connection error even if this document prescribes that it MUST 981 be treated as a stream error. 983 7. Encoding Strategies 985 7.1. Single Pass Encoding 987 An encoder making a single pass over a list of headers must choose 988 Base Index before knowing Largest Reference. When trying to 989 reference a header inserted to the table after encoding has begun, 990 the entry is encoded with different instructions that tell the 991 decoder to use an absolute index greater than the Base Index. 993 7.2. Preventing Eviction Races 995 Due to out-of-order arrival, QPACK's eviction algorithm requires 996 changes (relative to HPACK) to avoid the possibility that an indexed 997 representation is decoded after the referenced entry has already been 998 evicted. QPACK employs a two-phase eviction algorithm, in which the 999 encoder will not evict entries that have outstanding (unacknowledged) 1000 references. 1002 7.3. Reference Tracking 1004 An encoder MUST ensure that a header block which references a dynamic 1005 table entry is not received by the decoder after the referenced entry 1006 has already been evicted. An encoder also respects the limit set by 1007 the decoder on the number of streams that are allowed to become 1008 blocked. Even if the decoder is willing to tolerate blocked streams, 1009 the encoder might choose to avoid them in certain cases. 1011 In order to enable this, the encoder will need to track outstanding 1012 (unacknowledged) header blocks and table updates using feedback 1013 received from the decoder. 1015 7.3.1. Blocked Dynamic Table Insertions 1017 An encoder MUST NOT insert an entry into the dynamic table (or 1018 duplicate an existing entry) if doing so would evict an entry with 1019 unacknowledged references. For header blocks that might rely on the 1020 newly added entry, the encoder can use a literal representation and 1021 maybe insert the entry later. 1023 To ensure that the encoder is not prevented from adding new entries, 1024 the encoder can avoid referencing entries that will be evicted 1025 soonest. Rather than reference such an entry, the encoder SHOULD 1026 emit a Duplicate instruction (see Section 5.2.3), and reference the 1027 duplicate instead. 1029 Determining which entries are too close to eviction to reference is 1030 an encoder preference. One heuristic is to target a fixed amount of 1031 available space in the dynamic table: either unused space or space 1032 that can be reclaimed by evicting unreferenced entries. To achieve 1033 this, the encoder can maintain a draining index, which is the 1034 smallest absolute index in the dynamic table that it will emit a 1035 reference for. As new entries are inserted, the encoder increases 1036 the draining index to maintain the section of the table that it will 1037 not reference. Draining entries - entries with an absolute index 1038 lower than the draining index - will not accumulate new references. 1039 The number of unacknowledged references to draining entries will 1040 eventually become zero, making the entry available for eviction. 1042 +----------+---------------------------------+--------+ 1043 | Draining | Referenceable | Unused | 1044 | Entries | Entries | Space | 1045 +----------+---------------------------------+--------+ 1046 ^ ^ ^ 1047 | | | 1048 Dropping Draining Index Base Index / 1049 Point Insertion Point 1051 Figure 7: Draining Dynamic Table Entries 1053 7.3.2. Blocked Decoding 1055 For header blocks encoded in non-blocking mode, the encoder needs to 1056 forego indexed representations that refer to table updates which have 1057 not yet been acknowledged (see Section 5.3). Since all table updates 1058 are processed in sequence on the control stream, an index into the 1059 dynamic table is sufficient to track which entries have been 1060 acknowledged. 1062 To track blocked streams, the necessary Base Index value for each 1063 stream can be used. Whenever the decoder processes a table update, 1064 it can begin decoding any blocked streams that now have their 1065 dependencies satisfied. 1067 7.4. Speculative table updates 1069 Implementations can _speculatively_ send instructions on the encoder 1070 stream which are not needed for any current HTTP request or response. 1071 Such headers could be used strategically to improve performance. For 1072 instance, the encoder might decide to _refresh_ by sending Duplicate 1073 representations for popular header fields (Section 5.2.3), ensuring 1074 they have small indices and hence minimal size on the wire. 1076 7.5. Sample One Pass Encoding Algorithm 1078 Pseudo-code for single pass encoding, excluding handling of 1079 duplicates, non-blocking mode, and reference tracking. 1081 baseIndex = dynamicTable.baseIndex 1082 largestReference = 0 1083 for header in headers: 1084 staticIdx = staticTable.getIndex(header) 1085 if staticIdx: 1086 encodeIndexReference(streamBuffer, staticIdx) 1087 continue 1089 dynamicIdx = dynamicTable.getIndex(header) 1090 if !dynamicIdx: 1091 # No matching entry. Either insert+index or encode literal 1092 nameIdx = getNameIndex(header) 1093 if shouldIndex(header) and dynamicTable.canIndex(header): 1094 encodeLiteralWithIncrementalIndex(controlBuffer, nameIdx, 1095 header) 1096 dynamicTable.add(header) 1097 dynamicIdx = dynamicTable.baseIndex 1099 if !dynamicIdx: 1100 # Couldn't index it, literal 1101 if nameIdx <= staticTable.size: 1102 encodeLiteral(streamBuffer, nameIndex, header) 1103 else: 1104 # encode literal, possibly with nameIdx above baseIndex 1105 encodeDynamicLiteral(streamBuffer, nameIndex, baseIndex, 1106 header) 1107 largestReference = max(largestReference, 1108 dynamicTable.toAbsolute(nameIdx)) 1109 else: 1110 # Dynamic index reference 1111 assert(dynamicIdx) 1112 largestReference = max(largestReference, dynamicIdx) 1113 # Encode dynamicIdx, possibly with dynamicIdx above baseIndex 1114 encodeDynamicIndexReference(streamBuffer, dynamicIdx, 1115 baseIndex) 1117 # encode the prefix 1118 encodeInteger(prefixBuffer, 0x00, largestReference, 8) 1119 if baseIndex >= largestReference: 1120 encodeInteger(prefixBuffer, 0, baseIndex - largestReference, 7) 1121 else: 1122 encodeInteger(prefixBuffer, 0x80, 1123 largestReference - baseIndex, 7) 1125 return controlBuffer, prefixBuffer + streamBuffer 1127 8. Security Considerations 1129 TBD. 1131 9. IANA Considerations 1133 9.1. Settings Registration 1135 This document creates two new settings in the "HTTP/QUIC Settings" 1136 registry established in [QUIC-HTTP]. 1138 The entries in the following table are registered by this document. 1140 +-----------------------+------+---------------+ 1141 | Setting Name | Code | Specification | 1142 +-----------------------+------+---------------+ 1143 | HEADER_TABLE_SIZE | 0x1 | Section 4 | 1144 | | | | 1145 | QPACK_BLOCKED_STREAMS | 0x7 | Section 4 | 1146 +-----------------------+------+---------------+ 1148 9.2. Stream Type Registration 1150 This document creates two new settings in the "HTTP/QUIC Stream Type" 1151 registry established in [QUIC-HTTP]. 1153 The entries in the following table are registered by this document. 1155 +----------------------+------+---------------+--------+ 1156 | Stream Type | Code | Specification | Sender | 1157 +----------------------+------+---------------+--------+ 1158 | QPACK Encoder Stream | 0x48 | Section 5 | Both | 1159 | | | | | 1160 | QPACK Decoder Stream | 0x68 | Section 5 | Both | 1161 +----------------------+------+---------------+--------+ 1163 9.3. Error Code Registration 1165 This document establishes the following new error codes in the "HTTP/ 1166 QUIC Error Code" registry established in [QUIC-HTTP]. 1168 +------------------------------+------+--------------+--------------+ 1169 | Name | Code | Description | Specificatio | 1170 | | | | n | 1171 +------------------------------+------+--------------+--------------+ 1172 | HTTP_QPACK_DECOMPRESSION_FAI | TBD | Decompressio | Section 6 | 1173 | LED | | n of a | | 1174 | | | header block | | 1175 | | | failed | | 1176 | | | | | 1177 | HTTP_QPACK_ENCODER_STREAM_ER | TBD | Error on the | Section 6 | 1178 | ROR | | encoder | | 1179 | | | stream | | 1180 | | | | | 1181 | HTTP_QPACK_DECODER_STREAM_ER | TBD | Error on the | Section 6 | 1182 | ROR | | decoder | | 1183 | | | stream | | 1184 +------------------------------+------+--------------+--------------+ 1186 10. References 1188 10.1. Normative References 1190 [QUIC-HTTP] 1191 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1192 QUIC", draft-ietf-quic-http-15 (work in progress), October 1193 2018. 1195 [QUIC-TRANSPORT] 1196 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1197 Multiplexed and Secure Transport", draft-ietf-quic- 1198 transport-14 (work in progress), October 2018. 1200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1201 Requirement Levels", BCP 14, RFC 2119, 1202 DOI 10.17487/RFC2119, March 1997, 1203 . 1205 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1206 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1207 . 1209 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1210 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1211 May 2017, . 1213 10.2. Informative References 1215 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 1216 RFC 2360, DOI 10.17487/RFC2360, June 1998, 1217 . 1219 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1220 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1221 DOI 10.17487/RFC7540, May 2015, 1222 . 1224 10.3. URIs 1226 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1228 [2] https://github.com/quicwg 1230 [3] https://github.com/quicwg/base-drafts/labels/-qpack 1232 Appendix A. Static Table 1234 +------+-----------------------------+------------------------------+ 1235 | Inde | Name | Value | 1236 | x | | | 1237 +------+-----------------------------+------------------------------+ 1238 | 0 | :authority | | 1239 | | | | 1240 | 1 | :path | / | 1241 | | | | 1242 | 2 | age | 0 | 1243 | | | | 1244 | 3 | content-disposition | | 1245 | | | | 1246 | 4 | content-length | 0 | 1247 | | | | 1248 | 5 | cookie | | 1249 | | | | 1250 | 6 | date | | 1251 | | | | 1252 | 7 | etag | | 1253 | | | | 1254 | 8 | if-modified-since | | 1255 | | | | 1256 | 9 | if-none-match | | 1257 | | | | 1258 | 10 | last-modified | | 1259 | | | | 1260 | 11 | link | | 1261 | | | | 1262 | 12 | location | | 1263 | | | | 1264 | 13 | referer | | 1265 | | | | 1266 | 14 | set-cookie | | 1267 | | | | 1268 | 15 | :method | CONNECT | 1269 | | | | 1270 | 16 | :method | DELETE | 1271 | | | | 1272 | 17 | :method | GET | 1273 | | | | 1274 | 18 | :method | HEAD | 1275 | | | | 1276 | 19 | :method | OPTIONS | 1277 | | | | 1278 | 20 | :method | POST | 1279 | | | | 1280 | 21 | :method | PUT | 1281 | | | | 1282 | 22 | :scheme | http | 1283 | | | | 1284 | 23 | :scheme | https | 1285 | | | | 1286 | 24 | :status | 103 | 1287 | | | | 1288 | 25 | :status | 200 | 1289 | | | | 1290 | 26 | :status | 304 | 1291 | | | | 1292 | 27 | :status | 404 | 1293 | | | | 1294 | 28 | :status | 503 | 1295 | | | | 1296 | 29 | accept | */* | 1297 | | | | 1298 | 30 | accept | application/dns-message | 1299 | | | | 1300 | 31 | accept-encoding | gzip, deflate, br | 1301 | | | | 1302 | 32 | accept-ranges | bytes | 1303 | | | | 1304 | 33 | access-control-allow- | cache-control | 1305 | | headers | | 1306 | | | | 1307 | 34 | access-control-allow- | content-type | 1308 | | headers | | 1309 | | | | 1310 | 35 | access-control-allow-origin | * | 1311 | | | | 1312 | 36 | cache-control | max-age=0 | 1313 | | | | 1314 | 37 | cache-control | max-age=2592000 | 1315 | | | | 1316 | 38 | cache-control | max-age=604800 | 1317 | | | | 1318 | 39 | cache-control | no-cache | 1319 | | | | 1320 | 40 | cache-control | no-store | 1321 | | | | 1322 | 41 | cache-control | public, max-age=31536000 | 1323 | | | | 1324 | 42 | content-encoding | br | 1325 | | | | 1326 | 43 | content-encoding | gzip | 1327 | | | | 1328 | 44 | content-type | application/dns-message | 1329 | | | | 1330 | 45 | content-type | application/javascript | 1331 | | | | 1332 | 46 | content-type | application/json | 1333 | | | | 1334 | 47 | content-type | application/x-www-form- | 1335 | | | urlencoded | 1336 | | | | 1337 | 48 | content-type | image/gif | 1338 | | | | 1339 | 49 | content-type | image/jpeg | 1340 | | | | 1341 | 50 | content-type | image/png | 1342 | | | | 1343 | 51 | content-type | text/css | 1344 | | | | 1345 | 52 | content-type | text/html; charset=utf-8 | 1346 | | | | 1347 | 53 | content-type | text/plain | 1348 | | | | 1349 | 54 | content-type | text/plain;charset=utf-8 | 1350 | | | | 1351 | 55 | range | bytes=0- | 1352 | | | | 1353 | 56 | strict-transport-security | max-age=31536000 | 1354 | | | | 1355 | 57 | strict-transport-security | max-age=31536000; | 1356 | | | includesubdomains | 1357 | | | | 1358 | 58 | strict-transport-security | max-age=31536000; | 1359 | | | includesubdomains; preload | 1360 | | | | 1361 | 59 | vary | accept-encoding | 1362 | | | | 1363 | 60 | vary | origin | 1364 | | | | 1365 | 61 | x-content-type-options | nosniff | 1366 | | | | 1367 | 62 | x-xss-protection | 1; mode=block | 1368 | | | | 1369 | 63 | :status | 100 | 1370 | | | | 1371 | 64 | :status | 204 | 1372 | | | | 1373 | 65 | :status | 206 | 1374 | | | | 1375 | 66 | :status | 302 | 1376 | | | | 1377 | 67 | :status | 400 | 1378 | | | | 1379 | 68 | :status | 403 | 1380 | | | | 1381 | 69 | :status | 421 | 1382 | | | | 1383 | 70 | :status | 425 | 1384 | | | | 1385 | 71 | :status | 500 | 1386 | | | | 1387 | 72 | accept-language | | 1388 | | | | 1389 | 73 | access-control-allow- | FALSE | 1390 | | credentials | | 1391 | | | | 1392 | 74 | access-control-allow- | TRUE | 1393 | | credentials | | 1394 | | | | 1395 | 75 | access-control-allow- | * | 1396 | | headers | | 1397 | | | | 1398 | 76 | access-control-allow- | get | 1399 | | methods | | 1400 | | | | 1401 | 77 | access-control-allow- | get, post, options | 1402 | | methods | | 1403 | | | | 1404 | 78 | access-control-allow- | options | 1405 | | methods | | 1406 | | | | 1407 | 79 | access-control-expose- | content-length | 1408 | | headers | | 1409 | | | | 1410 | 80 | access-control-request- | content-type | 1411 | | headers | | 1412 | | | | 1413 | 81 | access-control-request- | get | 1414 | | method | | 1415 | | | | 1416 | 82 | access-control-request- | post | 1417 | | method | | 1418 | | | | 1419 | 83 | alt-svc | clear | 1420 | | | | 1421 | 84 | authorization | | 1422 | | | | 1423 | 85 | content-security-policy | script-src 'none'; object- | 1424 | | | src 'none'; base-uri 'none' | 1425 | | | | 1426 | 86 | early-data | 1 | 1427 | | | | 1428 | 87 | expect-ct | | 1429 | | | | 1430 | 88 | forwarded | | 1431 | | | | 1432 | 89 | if-range | | 1433 | | | | 1434 | 90 | origin | | 1435 | | | | 1436 | 91 | purpose | prefetch | 1437 | | | | 1438 | 92 | server | | 1439 | | | | 1440 | 93 | timing-allow-origin | * | 1441 | | | | 1442 | 94 | upgrade-insecure-requests | 1 | 1443 | | | | 1444 | 95 | user-agent | | 1445 | | | | 1446 | 96 | x-forwarded-for | | 1447 | | | | 1448 | 97 | x-frame-options | deny | 1449 | | | | 1450 | 98 | x-frame-options | sameorigin | 1451 +------+-----------------------------+------------------------------+ 1453 Appendix B. Change Log 1455 *RFC Editor's Note:* Please remove this section prior to 1456 publication of a final version of this document. 1458 B.1. Since draft-ietf-quic-qpack-02 1460 o Largest Reference encoded modulo MaxEntries (#1763) 1462 o New Static Table (#1355) 1464 o Table Size Update with Insert Count=0 is a connection error 1465 (#1762) 1467 o Stream Cancellations are optional when 1468 SETTINGS_HEADER_TABLE_SIZE=0 (#1761) 1470 o Implementations must handle 62 bit integers (#1760) 1472 o Different error types for each QPACK stream, other changes to 1473 error handling (#1726) 1475 o Preserve header field order (#1725) 1477 o Initial table size is the maximum permitted when table is first 1478 usable (#1642) 1480 B.2. Since draft-ietf-quic-qpack-01 1482 o Only header blocks that reference the dynamic table are 1483 acknowledged (#1603, #1605) 1485 B.3. Since draft-ietf-quic-qpack-00 1487 o Renumbered instructions for consistency (#1471, #1472) 1489 o Decoder is allowed to validate largest reference (#1404, #1469) 1491 o Header block acknowledgments also acknowledge the associated 1492 largest reference (#1370, #1400) 1494 o Added an acknowledgment for unread streams (#1371, #1400) 1496 o Removed framing from encoder stream (#1361,#1467) 1498 o Control streams use typed unidirectional streams rather than fixed 1499 stream IDs (#910,#1359) 1501 B.4. Since draft-ietf-quic-qcram-00 1503 o Separate instruction sets for table updates and header blocks 1504 (#1235, #1142, #1141) 1506 o Reworked indexing scheme (#1176, #1145, #1136, #1130, #1125, 1507 #1314) 1509 o Added mechanisms that support one-pass encoding (#1138, #1320) 1511 o Added a setting to control the number of blocked decoders (#238, 1512 #1140, #1143) 1514 o Moved table updates and acknowledgments to dedicated streams 1515 (#1121, #1122, #1238) 1517 Acknowledgments 1519 This draft draws heavily on the text of [RFC7541]. The indirect 1520 input of those authors is gratefully acknowledged, as well as ideas 1521 from: 1523 o Ryan Hamilton 1525 o Patrick McManus 1527 o Kazuho Oku 1529 o Biren Roy 1531 o Ian Swett 1533 o Dmitri Tikhonov 1535 Buck's contribution was supported by Google during his employment 1536 there. 1538 A substantial portion of Mike's contribution was supported by 1539 Microsoft during his employment there. 1541 Authors' Addresses 1543 Charles 'Buck' Krasic 1544 Netflix 1546 Email: ckrasic@netflix.com 1547 Mike Bishop 1548 Akamai Technologies 1550 Email: mbishop@evequefou.be 1552 Alan Frindell (editor) 1553 Facebook 1555 Email: afrind@fb.com