Movatterモバイル変換

RFC 9204	QPACK	June 2022
Krasic, et al.	Standards Track	[Page]

2.Compression Process Overview

Like HPACK, QPACK uses two tables for associating field lines ("headers") toindices. The static table (Section 3.1) is predefined and containscommon header field lines (some of them with an empty value). The dynamic table(Section 3.2) is built up over the course of the connection and canbe used by the encoder to index both header and trailer field lines in theencoded field sections.¶

QPACK defines unidirectional streams for sending instructions from encoder todecoder and vice versa.¶

2.1.Encoder

An encoder converts a header or trailer section into a series of representationsby emitting either an indexed or a literal representation for each field line inthe list; seeSection 4.5. Indexed representations achievehigh compression by replacing the literal name and possibly the value with anindex to either the static or dynamic table. References to the static table andliteral representations do not require any dynamic state and never riskhead-of-line blocking. References to the dynamic table risk head-of-lineblocking if the encoder has not received an acknowledgment indicating the entryis available at the decoder.¶

An encoderMAY insert any entry in the dynamic table it chooses; it is notlimited to field lines it is compressing.¶

QPACK preserves the ordering of field lines within each field section. AnencoderMUST emit field representations in the order they appear in the inputfield section.¶

QPACK is designed to place the burden of optional state tracking on the encoder,resulting in relatively simple decoders.¶

2.1.1.Limits on Dynamic Table Insertions

Inserting entries into the dynamic table might not be possible if the tablecontains entries that cannot be evicted.¶

A dynamic table entry cannot be evicted immediately after insertion, even if ithas never been referenced. Once the insertion of a dynamic table entry has beenacknowledged and there are no outstanding references to the entry inunacknowledged representations, the entry becomes evictable. Note thatreferences on the encoder stream never preclude the eviction of an entry,because those references are guaranteed to be processed before the instructionevicting the entry.¶

If the dynamic table does not contain enough room for a new entry withoutevicting other entries, and the entries that would be evicted are notevictable, the encoderMUST NOT insert that entry into the dynamic table(including duplicates of existing entries). In order to avoid this, an encoderthat uses the dynamic table has to keep track of each dynamic table entryreferenced by each field section until those representations are acknowledged bythe decoder; seeSection 4.4.1.¶

2.1.1.1.Avoiding Prohibited Insertions

To ensure that the encoder is not prevented from adding new entries, the encodercan avoid referencing entries that are close to eviction. Rather thanreference such an entry, the encoder can emit a Duplicate instruction(Section 4.3.4) and reference the duplicate instead.¶

Determining which entries are too close to eviction to reference is an encoderpreference. One heuristic is to target a fixed amount of available space in thedynamic table: either unused space or space that can be reclaimed by evictingnon-blocking entries. To achieve this, the encoder can maintain a drainingindex, which is the smallest absolute index (Section 3.2.4) in the dynamic tablethat it will emit a reference for. As new entries are inserted, the encoderincreases the draining index to maintain the section of the table that it willnot reference. If the encoder does not create new references to entries with anabsolute index lower than the draining index, the number of unacknowledgedreferences to those entries will eventually become zero, allowing them to beevicted.¶

             <-- Newer Entries          Older Entries -->               (Larger Indices)       (Smaller Indices)   +--------+---------------------------------+----------+   | Unused |          Referenceable          | Draining |   | Space  |             Entries             | Entries  |   +--------+---------------------------------+----------+            ^                                 ^          ^            |                                 |          |      Insertion Point                 Draining Index  Dropping                                                       Point

Figure 1:Draining Dynamic Table Entries

2.1.2.Blocked Streams

Because QUIC does not guarantee order between data on different streams, adecoder might encounter a representation that references a dynamic table entrythat it has not yet received.¶

Each encoded field section contains a Required Insert Count (Section 4.5.1),the lowest possible value for the Insert Count with which the field section canbe decoded. For a field section encoded using references to the dynamic table,the Required Insert Count is one larger than the largest absolute index of allreferenced dynamic table entries. For a field section encoded with no referencesto the dynamic table, the Required Insert Count is zero.¶

When the decoder receives an encoded field section with a Required Insert Countgreater than its own Insert Count, the stream cannot be processed immediatelyand is considered "blocked"; seeSection 2.2.1.¶

The decoder specifies an upper bound on the number of streams that can beblocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; seeSection 5.An encoderMUST limit the number of streams that could become blocked to thevalue of SETTINGS_QPACK_BLOCKED_STREAMS at all times. If a decoder encountersmore blocked streams than it promised to support, itMUST treat this as aconnection error of type QPACK_DECOMPRESSION_FAILED.¶

Note that the decoder might not become blocked on every stream that risksbecoming blocked.¶

An encoder can decide whether to risk having a stream become blocked. Ifpermitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS, compression efficiencycan often be improved by referencing dynamic table entries that are still intransit, but if there is loss or reordering, the stream can become blocked atthe decoder. An encoder can avoid the risk of blocking by only referencingdynamic table entries that have been acknowledged, but this could mean usingliterals. Since literals make the encoded field section larger, this can resultin the encoder becoming blocked on congestion or flow-control limits.¶

2.1.3.Avoiding Flow-Control Deadlocks

Writing instructions on streams that are limited by flow control can producedeadlocks.¶

A decoder might stop issuing flow-control credit on the stream that carries anencoded field section until the necessary updates are received on the encoderstream. If the granting of flow-control credit on the encoder stream (or theconnection as a whole) depends on the consumption and release of data on thestream carrying the encoded field section, a deadlock might result.¶

More generally, a stream containing a large instruction can become deadlocked ifthe decoder withholds flow-control credit until the instruction is completelyreceived.¶

To avoid these deadlocks, an encoderSHOULD NOT write an instruction unlesssufficient stream and connection flow-control credit is available for the entireinstruction.¶

2.1.4.Known Received Count

The Known Received Count is the total number of dynamic table insertions andduplications acknowledged by the decoder. The encoder tracks the Known ReceivedCount in order to identify which dynamic table entries can be referenced withoutpotentially blocking a stream. The decoder tracks the Known Received Count inorder to be able to send Insert Count Increment instructions.¶

A Section Acknowledgment instruction (Section 4.4.1) implies thatthe decoder has received all dynamic table state necessary to decode the fieldsection. If the Required Insert Count of the acknowledged field section isgreater than the current Known Received Count, the Known Received Count isupdated to that Required Insert Count value.¶

An Insert Count Increment instruction (Section 4.4.3) increases theKnown Received Count by its Increment parameter. SeeSection 2.2.2.3 forguidance.¶

2.2.Decoder

As in HPACK, the decoder processes a series of representations and emits thecorresponding field sections. It also processes instructions received on theencoder stream that modify the dynamic table. Note that encoded field sectionsand encoder stream instructions arrive on separate streams. This is unlikeHPACK, where encoded field sections (header blocks) can contain instructionsthat modify the dynamic table, and there is no dedicated stream of HPACKinstructions.¶

The decoderMUST emit field lines in the order their representations appear inthe encoded field section.¶

2.2.1.Blocked Decoding

Upon receipt of an encoded field section, the decoder examines the RequiredInsert Count. When the Required Insert Count is less than or equal to thedecoder's Insert Count, the field section can be processed immediately.Otherwise, the stream on which the field section was received becomes blocked.¶

While blocked, encoded field section dataSHOULD remain in the blocked stream'sflow-control window. This data is unusable until the stream becomes unblocked,and releasing the flow control prematurely makes the decoder vulnerable tomemory exhaustion attacks. A stream becomes unblocked when the Insert Countbecomes greater than or equal to the Required Insert Count for all encodedfield sections the decoder has started reading from the stream.¶

When processing encoded field sections, the decoder expects the Required InsertCount to equal the lowest possible value for the Insert Count with which thefield section can be decoded, as prescribed inSection 2.1.2. If itencounters a Required Insert Count smaller than expected, itMUST treat this asa connection error of type QPACK_DECOMPRESSION_FAILED; seeSection 2.2.3. If it encounters a Required Insert Count larger thanexpected, itMAY treat this as a connection error of typeQPACK_DECOMPRESSION_FAILED.¶

2.2.2.State Synchronization

The decoder signals the following events by emitting decoder instructions(Section 4.4) on the decoder stream.¶

2.2.2.1.Completed Processing of a Field Section

After the decoder finishes decoding a field section encoded usingrepresentations containing dynamic table references, itMUST emit a SectionAcknowledgment instruction (Section 4.4.1). A stream may carrymultiple field sections in the case of intermediate responses, trailers, andpushed requests. The encoder interprets each Section Acknowledgmentinstruction as acknowledging the earliest unacknowledged field sectioncontaining dynamic table references sent on the given stream.¶

2.2.2.2.Abandonment of a Stream

When an endpoint receives a stream reset before the end of a stream or beforeall encoded field sections are processed on that stream, or when it abandonsreading of a stream, it generates a Stream Cancellation instruction; seeSection 4.4.2. This signals to the encoder that all references to thedynamic table on that stream are no longer outstanding. A decoder with amaximum dynamic table capacity (Section 3.2.3) equal tozeroMAY omit sending Stream Cancellations, because the encoder cannot have anydynamic table references. An encoder cannot infer from this instruction thatany updates to the dynamic table have been received.¶

The Section Acknowledgment and Stream Cancellation instructions permit theencoder to remove references to entries in the dynamic table. When an entrywith an absolute index lower than the Known Received Count has zero references,then it is considered evictable; seeSection 2.1.1.¶

2.2.2.3.New Table Entries

After receiving new table entries on the encoder stream, the decoder chooseswhen to emit Insert Count Increment instructions; seeSection 4.4.3. Emitting this instruction after adding each newdynamic table entry will provide the timeliest feedback to the encoder, butcould be redundant with other decoder feedback. By delaying an Insert CountIncrement instruction, the decoder might be able to coalesce multiple InsertCount Increment instructions or replace them entirely with SectionAcknowledgments; seeSection 4.4.1. However, delaying too longmay lead to compression inefficiencies if the encoder waits for an entry to beacknowledged before using it.¶

2.2.3.Invalid References

If the decoder encounters a reference in a field line representation to adynamic table entry that has already been evicted or that has an absoluteindex greater than or equal to the declared Required Insert Count(Section 4.5.1), itMUST treat this as a connection error of typeQPACK_DECOMPRESSION_FAILED.¶

If the decoder encounters a reference in an encoder instruction to a dynamictable entry that has already been evicted, itMUST treat this as a connectionerror of type QPACK_ENCODER_STREAM_ERROR.¶

3.Reference Tables

Unlike in HPACK, entries in the QPACK static and dynamic tables are addressedseparately. The following sections describe how entries in each table areaddressed.¶

3.1.Static Table

The static table consists of a predefined list of field lines, each of which hasa fixed index over time. Its entries are defined inAppendix A.¶

All entries in the static table have a name and a value. However, values can beempty (that is, have a length of 0). Each entry is identified by a uniqueindex.¶

Note that the QPACK static table is indexed from 0, whereas the HPACK statictable is indexed from 1.¶

When the decoder encounters an invalid static table index in a field linerepresentation, itMUST treat this as a connection error of typeQPACK_DECOMPRESSION_FAILED. If this index is received on the encoder stream,thisMUST be treated as a connection error of type QPACK_ENCODER_STREAM_ERROR.¶

3.2.Dynamic Table

The dynamic table consists of a list of field lines maintained in first-in,first-out order. A QPACK encoder and decoder share a dynamic table that isinitially empty. The encoder adds entries to the dynamic table and sends themto the decoder via instructions on the encoder stream; seeSection 4.3.¶

The dynamic table can contain duplicate entries (i.e., entries with the samename and same value). Therefore, duplicate entriesMUST NOT be treated as anerror by the decoder.¶

Dynamic table entries can have empty values.¶

3.2.1.Dynamic Table Size

The size of the dynamic table is the sum of the size of its entries.¶

The size of an entry is the sum of its name's length in bytes, its value'slength in bytes, and 32 additional bytes. The size of an entry is calculatedusing the length of its name and value without Huffman encoding applied.¶

3.2.2.Dynamic Table Capacity and Eviction

The encoder sets the capacity of the dynamic table, which serves as the upperlimit on its size. The initial capacity of the dynamic table is zero. Theencoder sends a Set Dynamic Table Capacity instruction(Section 4.3.1) with a non-zero capacity to begin using the dynamictable.¶

Before a new entry is added to the dynamic table, entries are evicted from theend of the dynamic table until the size of the dynamic table is less than orequal to (table capacity - size of new entry). The encoderMUST NOT cause adynamic table entry to be evicted unless that entry is evictable; seeSection 2.1.1. The new entry is then added to the table. It is anerror if the encoder attempts to add an entry that is larger than the dynamictable capacity; the decoderMUST treat this as a connection error of typeQPACK_ENCODER_STREAM_ERROR.¶

A new entry can reference an entry in the dynamic table that will be evictedwhen adding this new entry into the dynamic table. Implementations arecautioned to avoid deleting the referenced name or value if the referenced entryis evicted from the dynamic table prior to inserting the new entry.¶

Whenever the dynamic table capacity is reduced by the encoder(Section 4.3.1), entries are evicted from the end of the dynamictable until the size of the dynamic table is less than or equal to the new tablecapacity. This mechanism can be used to completely clear entries from thedynamic table by setting a capacity of 0, which can subsequently be restored.¶

3.2.3.Maximum Dynamic Table Capacity

To bound the memory requirements of the decoder, the decoder limits the maximumvalue the encoder is permitted to set for the dynamic table capacity. InHTTP/3, this limit is determined by the value ofSETTINGS_QPACK_MAX_TABLE_CAPACITY sent by the decoder; seeSection 5.The encoderMUST NOT set a dynamic table capacity that exceeds this maximum, butit can choose to use a lower dynamic table capacity; seeSection 4.3.1.¶

For clients using 0-RTT data in HTTP/3, the server's maximum table capacity isthe remembered value of the setting or zero if the value was not previouslysent. When the client's 0-RTT value of the SETTING is zero, the serverMAY setit to a non-zero value in its SETTINGS frame. If the remembered value isnon-zero, the serverMUST send the same non-zero value in its SETTINGS frame. Ifit specifies any other value, or omits SETTINGS_QPACK_MAX_TABLE_CAPACITY fromSETTINGS, the encoder must treat this as a connection error of typeQPACK_DECODER_STREAM_ERROR.¶

For clients not using 0-RTT data (whether 0-RTT is not attempted or is rejected)and for all HTTP/3 servers, the maximum table capacity is 0 until the encoderprocesses a SETTINGS frame with a non-zero value ofSETTINGS_QPACK_MAX_TABLE_CAPACITY.¶

When the maximum table capacity is zero, the encoderMUST NOT insert entriesinto the dynamic table andMUST NOT send any encoder instructions on the encoderstream.¶

3.2.4.Absolute Indexing

Each entry possesses an absolute index that is fixed for the lifetime of thatentry. The first entry inserted has an absolute index of 0; indices increaseby one with each insertion.¶

3.2.5.Relative Indexing

Relative indices begin at zero and increase in the opposite direction from theabsolute index. Determining which entry has a relative index of 0 depends onthe context of the reference.¶

In encoder instructions (Section 4.3), a relative index of 0refers to the most recently inserted value in the dynamic table. Note that thismeans the entry referenced by a given relative index will change whileinterpreting instructions on the encoder stream.¶

      +-----+---------------+-------+      | n-1 |      ...      |   d   |  Absolute Index      + - - +---------------+ - - - +      |  0  |      ...      | n-d-1 |  Relative Index      +-----+---------------+-------+      ^                             |      |                             VInsertion Point               Dropping Pointn = count of entries insertedd = count of entries dropped

Figure 2:Example Dynamic Table Indexing - Encoder Stream

Unlike in encoder instructions, relative indices in field line representationsare relative to the Base at the beginning of the encoded field section; seeSection 4.5.1. This ensures that references are stable even if encoded fieldsections and dynamic table updates are processed out of order.¶

In a field line representation, a relative index of 0 refers to the entry withabsolute index equal to Base - 1.¶

               Base                |                V    +-----+-----+-----+-----+-------+    | n-1 | n-2 | n-3 | ... |   d   |  Absolute Index    +-----+-----+  -  +-----+   -   +                |  0  | ... | n-d-3 |  Relative Index                +-----+-----+-------+n = count of entries insertedd = count of entries droppedIn this example, Base = n - 2

Figure 3:Example Dynamic Table Indexing - Relative Index in Representation

3.2.6.Post-Base Indexing

Post-Base indices are used in field line representations for entries withabsolute indices greater than or equal to Base, starting at 0 for the entry withabsolute index equal to Base and increasing in the same direction as theabsolute index.¶

Post-Base indices allow an encoder to process a field section in a single passand include references to entries added while processing this (or other) fieldsections.¶

               Base                |                V    +-----+-----+-----+-----+-----+    | n-1 | n-2 | n-3 | ... |  d  |  Absolute Index    +-----+-----+-----+-----+-----+    |  1  |  0  |                    Post-Base Index    +-----+-----+n = count of entries insertedd = count of entries droppedIn this example, Base = n - 2

Figure 4:Example Dynamic Table Indexing - Post-Base Index in Representation

4.Wire Format

4.1.Primitives

4.1.1.Prefixed Integers

The prefixed integer fromSection 5.1 of [RFC7541] is used heavily throughoutthis document. The format from[RFC7541] is used unmodified. Note, however,that QPACK uses some prefix sizes not actually used in HPACK.¶

QPACK implementationsMUST be able to decode integers up to and including 62bits long.¶

4.1.2.String Literals

The string literal defined bySection 5.2 of [RFC7541] is also usedthroughout. This string format includes optional Huffman encoding.¶

HPACK defines string literals to begin on a byte boundary. They begin with asingle bit flag, denoted as 'H' in this document (indicating whether the stringis Huffman encoded), followed by the string length encoded as a 7-bit prefixinteger, and finally the indicated number of bytes of data. When Huffmanencoding is enabled, the Huffman table fromAppendix B of [RFC7541] is usedwithout modification and the indicated length is the size of the string afterencoding.¶

This document expands the definition of string literals by permitting them tobegin other than on a byte boundary. An "N-bit prefix string literal" beginsmid-byte, with the first (8-N) bits allocated to a previous field. The stringuses one bit for the Huffman flag, followed by the length of the encoded stringas a (N-1)-bit prefix integer. The prefix size, N, can have a value between 2and 8, inclusive. The remainder of the string literal is unmodified.¶

A string literal without a prefix length noted is an 8-bit prefix string literaland follows the definitions in[RFC7541] without modification.¶

4.2.Encoder and Decoder Streams

QPACK defines two unidirectional stream types:¶

An encoder stream is a unidirectional stream of type 0x02.It carries an unframed sequence of encoder instructions from encoderto decoder.¶
A decoder stream is a unidirectional stream of type 0x03.It carries an unframed sequence of decoder instructions from decoderto encoder.¶

HTTP/3 endpoints contain a QPACK encoder and decoder. Each endpointMUSTinitiate, at most, one encoder stream and, at most, one decoder stream. Receiptof a second instance of either stream typeMUST be treated as a connection errorof type H3_STREAM_CREATION_ERROR.¶

The senderMUST NOT close either of these streams, and the receiverMUST NOTrequest that the sender close either of these streams. Closure of eitherunidirectional stream typeMUST be treated as a connection error of typeH3_CLOSED_CRITICAL_STREAM.¶

An endpointMAY avoid creating an encoder stream if it will not be used (forexample, if its encoder does not wish to use the dynamic table or if the maximumsize of the dynamic table permitted by the peer is zero).¶

An endpointMAY avoid creating a decoder stream if its decoder sets the maximumcapacity of the dynamic table to zero.¶

An endpointMUST allow its peer to create an encoder stream and a decoder streameven if the connection's settings prevent their use.¶

4.3.Encoder Instructions

An encoder sends encoder instructions on the encoder stream to set the capacityof the dynamic table and add dynamic table entries. Instructions adding tableentries can use existing entries to avoid transmitting redundant information.The name can be transmitted as a reference to an existing entry in the static orthe dynamic table or as a string literal. For entries that already exist inthe dynamic table, the full entry can also be used by reference, creating aduplicate entry.¶

4.3.1.Set Dynamic Table Capacity

An encoder informs the decoder of a change to the dynamic table capacity usingan instruction that starts with the '001' 3-bit pattern. This is followedby the new dynamic table capacity represented as an integer with a 5-bit prefix;seeSection 4.1.1.¶

  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 0 | 1 |   Capacity (5+)   |+---+---+---+-------------------+

Figure 5:Set Dynamic Table Capacity

The new capacityMUST be lower than or equal to the limit described inSection 3.2.3. In HTTP/3, this limit is the value of theSETTINGS_QPACK_MAX_TABLE_CAPACITY parameter (Section 5) received fromthe decoder. The decoderMUST treat a new dynamic table capacity value thatexceeds this limit as a connection error of type QPACK_ENCODER_STREAM_ERROR.¶

Reducing the dynamic table capacity can cause entries to be evicted; seeSection 3.2.2. ThisMUST NOT cause the eviction of entries that are notevictable; seeSection 2.1.1. Changing the capacity of the dynamictable is not acknowledged as this instruction does not insert an entry.¶

4.3.2.Insert with Name Reference

An encoder adds an entry to the dynamic table where the field name matches thefield name of an entry stored in the static or the dynamic table using aninstruction that starts with the '1' 1-bit pattern. The second ('T') bitindicates whether the reference is to the static or dynamic table. The 6-bitprefix integer (Section 4.1.1) that follows is used to locate the tableentry for the field name. When T=1, the number represents the static tableindex; when T=0, the number is the relative index of the entry in the dynamictable.¶

The field name reference is followed by the field value represented as a stringliteral; seeSection 4.1.2.¶

     0   1   2   3   4   5   6   7   +---+---+---+---+---+---+---+---+   | 1 | T |    Name Index (6+)    |   +---+---+-----------------------+   | H |     Value Length (7+)     |   +---+---------------------------+   |  Value String (Length bytes)  |   +-------------------------------+

Figure 6:Insert Field Line -- Indexed Name

4.3.3.Insert with Literal Name

An encoder adds an entry to the dynamic table where both the field name and thefield value are represented as string literals using an instruction that startswith the '01' 2-bit pattern.¶

This is followed by the name represented as a 6-bit prefix string literal andthe value represented as an 8-bit prefix string literal; seeSection 4.1.2.¶

     0   1   2   3   4   5   6   7   +---+---+---+---+---+---+---+---+   | 0 | 1 | H | Name Length (5+)  |   +---+---+---+-------------------+   |  Name String (Length bytes)   |   +---+---------------------------+   | H |     Value Length (7+)     |   +---+---------------------------+   |  Value String (Length bytes)  |   +-------------------------------+

Figure 7:Insert Field Line -- New Name

4.3.4.Duplicate

An encoder duplicates an existing entry in the dynamic table using aninstruction that starts with the '000' 3-bit pattern. This is followed bythe relative index of the existing entry represented as an integer with a 5-bitprefix; seeSection 4.1.1.¶

     0   1   2   3   4   5   6   7   +---+---+---+---+---+---+---+---+   | 0 | 0 | 0 |    Index (5+)     |   +---+---+---+-------------------+

Figure 8:Duplicate

The existing entry is reinserted into the dynamic table without resendingeither the name or the value. This is useful to avoid adding a reference to anolder entry, which might block inserting new entries.¶

4.4.Decoder Instructions

A decoder sends decoder instructions on the decoder stream to inform the encoderabout the processing of field sections and table updates to ensure consistencyof the dynamic table.¶

4.4.1.Section Acknowledgment

After processing an encoded field section whose declared Required Insert Countis not zero, the decoder emits a Section Acknowledgment instruction. Theinstruction starts with the '1' 1-bit pattern, followed by the fieldsection's associated stream ID encoded as a 7-bit prefix integer; seeSection 4.1.1.¶

This instruction is used as described in Sections2.1.4 and2.2.2.¶

  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 1 |      Stream ID (7+)       |+---+---------------------------+

Figure 9:Section Acknowledgment

If an encoder receives a Section Acknowledgment instruction referring to astream on which every encoded field section with a non-zero Required InsertCount has already been acknowledged, thisMUST be treated as a connection errorof type QPACK_DECODER_STREAM_ERROR.¶

The Section Acknowledgment instruction might increase the Known Received Count;seeSection 2.1.4.¶

4.4.2.Stream Cancellation

When a stream is reset or reading is abandoned, the decoder emits a StreamCancellation instruction. The instruction starts with the '01' 2-bitpattern, followed by the stream ID of the affected stream encoded as a6-bit prefix integer.¶

This instruction is used as described inSection 2.2.2.¶

  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 1 |     Stream ID (6+)    |+---+---+-----------------------+

Figure 10:Stream Cancellation

4.4.3.Insert Count Increment

The Insert Count Increment instruction starts with the '00' 2-bit pattern,followed by the Increment encoded as a 6-bit prefix integer. This instructionincreases the Known Received Count (Section 2.1.4) by the value ofthe Increment parameter. The decoder should send an Increment value thatincreases the Known Received Count to the total number of dynamic tableinsertions and duplications processed so far.¶

  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 0 |     Increment (6+)    |+---+---+-----------------------+

Figure 11:Insert Count Increment

An encoder that receives an Increment field equal to zero, or one that increasesthe Known Received Count beyond what the encoder has sent,MUST treat this as aconnection error of type QPACK_DECODER_STREAM_ERROR.¶

4.5.Field Line Representations

An encoded field section consists of a prefix and a possibly empty sequence ofrepresentations defined in this section. Each representation corresponds to asingle field line. These representations reference the static table or thedynamic table in a particular state, but they do not modify that state.¶

Encoded field sections are carried in frames on streams defined by the enclosingprotocol.¶

4.5.1.Encoded Field Section Prefix

Each encoded field section is prefixed with two integers. The Required InsertCount is encoded as an integer with an 8-bit prefix using the encoding describedinSection 4.5.1.1. The Base is encoded as a Sign bit ('S') and a Delta Base valuewith a 7-bit prefix; seeSection 4.5.1.2.¶

  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|   Required Insert Count (8+)  |+---+---------------------------+| S |      Delta Base (7+)      |+---+---------------------------+|      Encoded Field Lines    ...+-------------------------------+

Figure 12:Encoded Field Section

4.5.1.1.Required Insert Count

Required Insert Count identifies the state of the dynamic table needed toprocess the encoded field section. Blocking decoders use the Required InsertCount to determine when it is safe to process the rest of the field section.¶

The encoder transforms the Required Insert Count as follows before encoding:¶

   if ReqInsertCount == 0:      EncInsertCount = 0   else:      EncInsertCount = (ReqInsertCount mod (2 * MaxEntries)) + 1

HereMaxEntries is the maximum number of entries that the dynamic table canhave. The smallest entry has empty name and value strings and has the size of32. Hence,MaxEntries is calculated as:¶

   MaxEntries = floor( MaxTableCapacity / 32 )

MaxTableCapacity is the maximum capacity of the dynamic table as specified bythe decoder; seeSection 3.2.3.¶

This encoding limits the length of the prefix on long-lived connections.¶

The decoder can reconstruct the Required Insert Count using an algorithm such asthe following. If the decoder encounters a value of EncodedInsertCount thatcould not have been produced by a conformant encoder, itMUST treat this as aconnection error of type QPACK_DECOMPRESSION_FAILED.¶

TotalNumberOfInserts is the total number of inserts into the decoder's dynamictable.¶

   FullRange = 2 * MaxEntries   if EncodedInsertCount == 0:      ReqInsertCount = 0   else:      if EncodedInsertCount > FullRange:         Error      MaxValue = TotalNumberOfInserts + MaxEntries      # MaxWrapped is the largest possible value of      # ReqInsertCount that is 0 mod 2 * MaxEntries      MaxWrapped = floor(MaxValue / FullRange) * FullRange      ReqInsertCount = MaxWrapped + EncodedInsertCount - 1      # If ReqInsertCount exceeds MaxValue, the Encoder's value      # must have wrapped one fewer time      if ReqInsertCount > MaxValue:         if ReqInsertCount <= FullRange:            Error         ReqInsertCount -= FullRange      # Value of 0 must be encoded as 0.      if ReqInsertCount == 0:         Error

For example, if the dynamic table is 100 bytes, then the Required Insert Countwill be encoded modulo 6. If a decoder has received 10 inserts, then an encodedvalue of 4 indicates that the Required Insert Count is 9 for the field section.¶

4.5.1.2.Base

The Base is used to resolve references in the dynamic table as described inSection 3.2.5.¶

To save space, the Base is encoded relative to the Required Insert Count using aone-bit Sign ('S' inFigure 12) and the Delta Base value. A Sign bitof 0 indicates that the Base is greater than or equal to the value of theRequired Insert Count; the decoder adds the value of Delta Base to the RequiredInsert Count to determine the value of the Base. A Sign bit of 1 indicates thatthe Base is less than the Required Insert Count; the decoder subtracts the valueof Delta Base from the Required Insert Count and also subtracts one to determinethe value of the Base. That is:¶

   if Sign == 0:      Base = ReqInsertCount + DeltaBase   else:      Base = ReqInsertCount - DeltaBase - 1

A single-pass encoder determines the Base before encoding a field section. Ifthe encoder inserted entries in the dynamic table while encoding the fieldsection and is referencing them, Required Insert Count will be greater than theBase, so the encoded difference is negative and the Sign bit is set to 1. Ifthe field section was not encoded using representations that reference the mostrecent entry in the table and did not insert any new entries, the Base will begreater than the Required Insert Count, so the encoded difference will bepositive and the Sign bit is set to 0.¶

The value of BaseMUST NOT be negative. Though the protocol might operatecorrectly with a negative Base using post-Base indexing, it is unnecessary andinefficient. An endpointMUST treat a field block with a Sign bit of 1 asinvalid if the value of Required Insert Count is less than or equal to the valueof Delta Base.¶

An encoder that produces table updates before encoding a field section might setBase to the value of Required Insert Count. In such a case, both the Sign bitand the Delta Base will be set to zero.¶

A field section that was encoded without references to the dynamic table can useany value for the Base; setting Delta Base to zero is one of the most efficientencodings.¶

For example, with a Required Insert Count of 9, a decoder receives a Sign bitof 1 and a Delta Base of 2. This sets the Base to 6 and enables post-Baseindexing for three entries. In this example, a relative index of 1 refers tothe fifth entry that was added to the table; a post-Base index of 1 refers tothe eighth entry.¶

4.5.2.Indexed Field Line

An indexed field line representation identifies an entry in the static tableor an entry in the dynamic table with an absolute index less than the value ofthe Base.¶

  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 1 | T |      Index (6+)       |+---+---+-----------------------+

Figure 13:Indexed Field Line

This representation starts with the '1' 1-bit pattern, followed by the 'T' bit,indicating whether the reference is into the static or dynamic table. The 6-bitprefix integer (Section 4.1.1) that follows is used to locate thetable entry for the field line. When T=1, the number represents the statictable index; when T=0, the number is the relative index of the entry in thedynamic table.¶

4.5.3.Indexed Field Line with Post-Base Index

An indexed field line with post-Base index representation identifies an entryin the dynamic table with an absolute index greater than or equal to the valueof the Base.¶

  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 0 | 0 | 1 |  Index (4+)   |+---+---+---+---+---------------+

Figure 14:Indexed Field Line with Post-Base Index

This representation starts with the '0001' 4-bit pattern. This is followedby the post-Base index (Section 3.2.6) of the matching field line, representedas an integer with a 4-bit prefix; seeSection 4.1.1.¶

4.5.4.Literal Field Line with Name Reference

A literal field line with name reference representation encodes a field linewhere the field name matches the field name of an entry in the static table orthe field name of an entry in the dynamic table with an absolute index less thanthe value of the Base.¶

     0   1   2   3   4   5   6   7   +---+---+---+---+---+---+---+---+   | 0 | 1 | N | T |Name Index (4+)|   +---+---+---+---+---------------+   | H |     Value Length (7+)     |   +---+---------------------------+   |  Value String (Length bytes)  |   +-------------------------------+

Figure 15:Literal Field Line with Name Reference

This representation starts with the '01' 2-bit pattern. The following bit,'N', indicates whether an intermediary is permitted to add this field line tothe dynamic table on subsequent hops. When the 'N' bit is set, the encoded fieldlineMUST always be encoded with a literal representation. In particular, when apeer sends a field line that it received represented as a literal field linewith the 'N' bit set, itMUST use a literal representation to forward this fieldline. This bit is intended for protecting field values that are not to be putat risk by compressing them; seeSection 7.1 for moredetails.¶

The fourth ('T') bit indicates whether the reference is to the static or dynamictable. The 4-bit prefix integer (Section 4.1.1) that follows is used tolocate the table entry for the field name. When T=1, the number represents thestatic table index; when T=0, the number is the relative index of the entry inthe dynamic table.¶

Only the field name is taken from the dynamic table entry; the field value isencoded as an 8-bit prefix string literal; seeSection 4.1.2.¶

4.5.5.Literal Field Line with Post-Base Name Reference

A literal field line with post-Base name reference representation encodes afield line where the field name matches the field name of a dynamic table entrywith an absolute index greater than or equal to the value of the Base.¶

     0   1   2   3   4   5   6   7   +---+---+---+---+---+---+---+---+   | 0 | 0 | 0 | 0 | N |NameIdx(3+)|   +---+---+---+---+---+-----------+   | H |     Value Length (7+)     |   +---+---------------------------+   |  Value String (Length bytes)  |   +-------------------------------+

Figure 16:Literal Field Line with Post-Base Name Reference

This representation starts with the '0000' 4-bit pattern. The fifth bit isthe 'N' bit as described inSection 4.5.4. This is followed by apost-Base index of the dynamic table entry (Section 3.2.6) encoded as aninteger with a 3-bit prefix; seeSection 4.1.1.¶

Only the field name is taken from the dynamic table entry; the field value isencoded as an 8-bit prefix string literal; seeSection 4.1.2.¶

4.5.6.Literal Field Line with Literal Name

The literal field line with literal name representation encodes afield name and a field value as string literals.¶

     0   1   2   3   4   5   6   7   +---+---+---+---+---+---+---+---+   | 0 | 0 | 1 | N | H |NameLen(3+)|   +---+---+---+---+---+-----------+   |  Name String (Length bytes)   |   +---+---------------------------+   | H |     Value Length (7+)     |   +---+---------------------------+   |  Value String (Length bytes)  |   +-------------------------------+

Figure 17:Literal Field Line with Literal Name

This representation starts with the '001' 3-bit pattern. The fourth bit isthe 'N' bit as described inSection 4.5.4. The name follows,represented as a 4-bit prefix string literal, then the value, represented as an8-bit prefix string literal; seeSection 4.1.2.¶

7.Security Considerations

This section describes potential areas of security concern with QPACK:¶

Use of compression as a length-based oracle for verifying guesses aboutsecrets that are compressed into a shared compression context.¶
Denial of service resulting from exhausting processing or memory capacity ata decoder.¶

7.1.Probing Dynamic Table State

QPACK reduces the encoded size of field sections by exploiting the redundancyinherent in protocols like HTTP. The ultimate goal of this is to reduce theamount of data that is required to send HTTP requests or responses.¶

The compression context used to encode header and trailer fields can be probedby an attacker who can both define fields to be encoded and transmitted andobserve the length of those fields once they are encoded. When an attacker cando both, they can adaptively modify requests in order to confirm guesses aboutthe dynamic table state. If a guess is compressed into a shorter length, theattacker can observe the encoded length and infer that the guess was correct.¶

This is possible even over the Transport Layer Security Protocol([TLS]) and the QUIC Transport Protocol ([QUIC-TRANSPORT]), becausewhile TLS and QUIC provide confidentiality protection for content, they onlyprovide a limited amount of protection for the length of that content.¶

Note: Padding schemes only provide limited protection against an attacker withthese capabilities, potentially only forcing an increased number of guesses tolearn the length associated with a given guess. Padding schemes also workdirectly against compression by increasing the number of bits that aretransmitted.¶

Attacks like CRIME ([CRIME]) demonstrated the existence of these generalattacker capabilities. The specific attack exploited the fact that DEFLATE([RFC1951]) removes redundancy based on prefix matching. This permitted theattacker to confirm guesses a character at a time, reducing an exponential-timeattack into a linear-time attack.¶

7.1.1.Applicability to QPACK and HTTP

QPACK mitigates, but does not completely prevent, attacks modeled on CRIME([CRIME]) by forcing a guess to match an entire field line rather thanindividual characters. An attacker can only learn whether a guess is correct ornot, so the attacker is reduced to a brute-force guess for the field valuesassociated with a given field name.¶

Therefore, the viability of recovering specific field values depends on theentropy of values. As a result, values with high entropy are unlikely to berecovered successfully. However, values with low entropy remain vulnerable.¶

Attacks of this nature are possible any time that two mutually distrustfulentities control requests or responses that are placed onto a single HTTP/3connection. If the shared QPACK compressor permits one entity to add entries tothe dynamic table, and the other to refer to those entries while encodingchosen field lines, then the attacker (the second entity) can learn the stateof the table by observing the length of the encoded output.¶

For example, requests or responses from mutually distrustful entities can occurwhen an intermediary either:¶

sends requests from multiple clients on a single connection toward an originserver, or¶
takes responses from multiple origin servers and places them on a sharedconnection toward a client.¶

Web browsers also need to assume that requests made on the same connection bydifferent web origins ([RFC6454]) are made by mutually distrustful entities.Other scenarios involving mutually distrustful entities are also possible.¶

7.1.2.Mitigation

Users of HTTP that require confidentiality for header or trailer fields can usevalues with entropy sufficient to make guessing infeasible. However, this isimpractical as a general solution because it forces all users of HTTP to takesteps to mitigate attacks. It would impose new constraints on how HTTP is used.¶

Rather than impose constraints on users of HTTP, an implementation of QPACK caninstead constrain how compression is applied in order to limit the potential fordynamic table probing.¶

An ideal solution segregates access to the dynamic table based on the entitythat is constructing the message. Field values that are added to the table areattributed to an entity, and only the entity that created a particular value canextract that value.¶

To improve compression performance of this option, certain entries might betagged as being public. For example, a web browser might make the values of theAccept-Encoding header field available in all requests.¶

An encoder without good knowledge of the provenance of field values mightinstead introduce a penalty for many field lines with the same field name anddifferent values. This penalty could cause a large number of attempts to guessa field value to result in the field not being compared to the dynamic tableentries in future messages, effectively preventing further guesses.¶

This response might be made inversely proportional to the length of thefield value. Disabling access to the dynamic table for a given field name mightoccur for shorter values more quickly or with higher probability than for longervalues.¶

This mitigation is most effective between two endpoints. If messages arere-encoded by an intermediary without knowledge of which entity constructed agiven message, the intermediary could inadvertently merge compression contextsthat the original encoder had specifically kept separate.¶

Note: Simply removing entries corresponding to the field from the dynamic tablecan be ineffectual if the attacker has a reliable way of causing values to bereinstalled. For example, a request to load an image in a web browser typicallyincludes the Cookie header field (a potentially highly valued target for thissort of attack), and websites can easily force an image to be loaded, therebyrefreshing the entry in the dynamic table.¶

7.1.3.Never-Indexed Literals

Implementations can also choose to protect sensitive fields by not compressingthem and instead encoding their value as literals.¶

Refusing to insert a field line into the dynamic table is only effective ifdoing so is avoided on all hops. The never-indexed literal bit (seeSection 4.5.4) can be used to signal to intermediaries that aparticular value was intentionally sent as a literal.¶

An intermediaryMUST NOT re-encode a value that uses a literal representationwith the 'N' bit set with another representation that would index it. If QPACKis used for re-encoding, a literal representation with the 'N' bit setMUST beused. If HPACK is used for re-encoding, the never-indexed literalrepresentation (seeSection 6.2.3 of [RFC7541])MUST be used.¶

The choice to mark that a field value should never be indexed depends on severalfactors. Since QPACK does not protect against guessing an entire field value,short or low-entropy values are more readily recovered by an adversary.Therefore, an encoder might choose not to index values with low entropy.¶

An encoder might also choose not to index values for fields that are consideredto be highly valuable or sensitive to recovery, such as the Cookie orAuthorization header fields.¶

On the contrary, an encoder might prefer indexing values for fields that havelittle or no value if they were exposed. For instance, a User-Agent header fielddoes not commonly vary between requests and is sent to any server. In that case,confirmation that a particular User-Agent value has been used provides littlevalue.¶

Note that these criteria for deciding to use a never-indexed literalrepresentation will evolve over time as new attacks are discovered.¶

7.2.Static Huffman Encoding

There is no currently known attack against a static Huffman encoding. A studyhas shown that using a static Huffman encoding table created an informationleakage; however, this same study concluded that an attacker could not takeadvantage of this information leakage to recover any meaningful amount ofinformation (see[PETAL]).¶

7.3.Memory Consumption

An attacker can try to cause an endpoint to exhaust its memory. QPACK isdesigned to limit both the peak and stable amounts of memory allocated by anendpoint.¶

QPACK uses the definition of the maximum size of the dynamic table and themaximum number of blocking streams to limit the amount of memory the encoder cancause the decoder to consume. In HTTP/3, these values are controlled by thedecoder through the settings parameters SETTINGS_QPACK_MAX_TABLE_CAPACITY andSETTINGS_QPACK_BLOCKED_STREAMS, respectively (seeSection 3.2.3 andSection 2.1.2). The limit on thesize of the dynamic table takes into account the size of the data stored in thedynamic table, plus a small allowance for overhead. The limit on the number ofblocked streams is only a proxy for the maximum amount of memory required by thedecoder. The actual maximum amount of memory will depend on how much memory thedecoder uses to track each blocked stream.¶

A decoder can limit the amount of state memory used for the dynamic table bysetting an appropriate value for the maximum size of the dynamic table. InHTTP/3, this is realized by setting an appropriate value for theSETTINGS_QPACK_MAX_TABLE_CAPACITY parameter. An encoder can limit the amount ofstate memory it uses by choosing a smaller dynamic table size than the decoderallows and signaling this to the decoder (seeSection 4.3.1).¶

A decoder can limit the amount of state memory used for blocked streams bysetting an appropriate value for the maximum number of blocked streams. InHTTP/3, this is realized by setting an appropriate value for theSETTINGS_QPACK_BLOCKED_STREAMS parameter. Streams that risk becoming blockedconsume no additional state memory on the encoder.¶

An encoder allocates memory to track all dynamic table references inunacknowledged field sections. An implementation can directly limit the amountof state memory by only using as many references to the dynamic table as itwishes to track; no signaling to the decoder is required. However, limitingreferences to the dynamic table will reduce compression effectiveness.¶

The amount of temporary memory consumed by an encoder or decoder can be limitedby processing field lines sequentially. A decoder implementation does not needto retain a complete list of field lines while decoding a field section. Anencoder implementation does not need to retain a complete list of field lineswhile encoding a field section if it is using a single-pass algorithm. Notethat it might be necessary for an application to retain a complete list of fieldlines for other reasons; even if QPACK does not force this to occur, applicationconstraints might make this necessary.¶

While the negotiated limit on the dynamic table size accounts for much of thememory that can be consumed by a QPACK implementation, data that cannot beimmediately sent due to flow control is not affected by this limit.Implementations should limit the size of unsent data, especially on the decoderstream where flexibility to choose what to send is limited. Possible responsesto an excess of unsent data might include limiting the ability of the peer toopen new streams, reading only from the encoder stream, or closing theconnection.¶

7.4.Implementation Limits

An implementation of QPACK needs to ensure that large values for integers, longencoding for integers, or long string literals do not create securityweaknesses.¶

An implementation has to set a limit for the values it accepts for integers, aswell as for the encoded length; seeSection 4.1.1. In the same way, ithas to set a limit to the length it accepts for string literals; seeSection 4.1.2. These limitsSHOULD be large enough to process thelargest individual field the HTTP implementation can be configured to accept.¶

If an implementation encounters a value larger than it is able to decode, thisMUST be treated as a stream error of type QPACK_DECOMPRESSION_FAILED if on arequest stream or a connection error of the appropriate type if on the encoderor decoder stream.¶

Table 1:Additions to the HTTP/3 Settings Registry
Setting Name	Code	Specification	Default
QPACK_MAX_TABLE_CAPACITY	0x01	Section 5	0
QPACK_BLOCKED_STREAMS	0x07	Section 5	0

Table 2:Additions to the HTTP/3 Stream Types Registry
Stream Type	Code	Specification	Sender
QPACK Encoder Stream	0x02	Section 4.2	Both
QPACK Decoder Stream	0x03	Section 4.2	Both

Table 3:Additions to the HTTP/3 Error Codes Registry
Name	Code	Description	Specification
QPACK_DECOMPRESSION_FAILED	0x0200	Decoding of a field section failed	Section 6
QPACK_ENCODER_STREAM_ERROR	0x0201	Error on the encoder stream	Section 6
QPACK_DECODER_STREAM_ERROR	0x0202	Error on the decoder stream	Section 6

Table 4:Static Table
Index	Name	Value
0	:authority
1	:path	/
2	age	0
3	content-disposition
4	content-length	0
5	cookie
6	date
7	etag
8	if-modified-since
9	if-none-match
10	last-modified
11	link
12	location
13	referer
14	set-cookie
15	:method	CONNECT
16	:method	DELETE
17	:method	GET
18	:method	HEAD
19	:method	OPTIONS
20	:method	POST
21	:method	PUT
22	:scheme	http
23	:scheme	https
24	:status	103
25	:status	200
26	:status	304
27	:status	404
28	:status	503
29	accept	/
30	accept	application/dns-message
31	accept-encoding	gzip, deflate, br
32	accept-ranges	bytes
33	access-control-allow-headers	cache-control
34	access-control-allow-headers	content-type
35	access-control-allow-origin	*
36	cache-control	max-age=0
37	cache-control	max-age=2592000
38	cache-control	max-age=604800
39	cache-control	no-cache
40	cache-control	no-store
41	cache-control	public, max-age=31536000
42	content-encoding	br
43	content-encoding	gzip
44	content-type	application/dns-message
45	content-type	application/javascript
46	content-type	application/json
47	content-type	application/x-www-form-urlencoded
48	content-type	image/gif
49	content-type	image/jpeg
50	content-type	image/png
51	content-type	text/css
52	content-type	text/html; charset=utf-8
53	content-type	text/plain
54	content-type	text/plain;charset=utf-8
55	range	bytes=0-
56	strict-transport-security	max-age=31536000
57	strict-transport-security	max-age=31536000; includesubdomains
58	strict-transport-security	max-age=31536000; includesubdomains; preload
59	vary	accept-encoding
60	vary	origin
61	x-content-type-options	nosniff
62	x-xss-protection	1; mode=block
63	:status	100
64	:status	204
65	:status	206
66	:status	302
67	:status	400
68	:status	403
69	:status	421
70	:status	425
71	:status	500
72	accept-language
73	access-control-allow-credentials	FALSE
74	access-control-allow-credentials	TRUE
75	access-control-allow-headers	*
76	access-control-allow-methods	get
77	access-control-allow-methods	get, post, options
78	access-control-allow-methods	options
79	access-control-expose-headers	content-length
80	access-control-request-headers	content-type
81	access-control-request-method	get
82	access-control-request-method	post
83	alt-svc	clear
84	authorization
85	content-security-policy	script-src 'none'; object-src 'none'; base-uri 'none'
86	early-data	1
87	expect-ct
88	forwarded
89	if-range
90	origin
91	purpose	prefetch
92	server
93	timing-allow-origin	*
94	upgrade-insecure-requests	1
95	user-agent
96	x-forwarded-for
97	x-frame-options	deny
98	x-frame-options	sameorigin

Appendix B.Encoding and Decoding Examples

The following examples represent a series of exchanges between an encoder and adecoder. The exchanges are designed to exercise most QPACK instructions andhighlight potentially common patterns and their impact on dynamic table state.The encoder sends three encoded field sections containing one field line each,as well as two speculative inserts that are not referenced.¶

The state of the encoder's dynamic table is shown, along with itscurrent size. Each entry is shown with the Absolute Index of the entry (Abs),the current number of outstanding encoded field sections with references to thatentry (Ref), along with the name and value. Entries above the 'acknowledged'line have been acknowledged by the decoder.¶

B.1.Literal Field Line with Name Reference

The encoder sends an encoded field section containing a literal representationof a field with a static name reference.¶

Data                | Interpretation                             | Encoder's Dynamic TableStream: 00000                | Required Insert Count = 0, Base = 0510b 2f69 6e64 6578 | Literal Field Line with Name Reference2e68 746d 6c        |  Static Table, Index=1                    |  (:path=/index.html)                              Abs Ref Name        Value                              ^-- acknowledged --^                              Size=0

B.2.Dynamic Table

The encoder sets the dynamic table capacity, inserts a header with a dynamicname reference, then sends a potentially blocking, encoded field sectionreferencing this new entry. The decoder acknowledges processing the encodedfield section, which implicitly acknowledges all dynamic table insertions up tothe Required Insert Count.¶

Stream: Encoder3fbd01              | Set Dynamic Table Capacity=220c00f 7777 772e 6578 | Insert With Name Reference616d 706c 652e 636f | Static Table, Index=06d                  |  (:authority=www.example.com)c10c 2f73 616d 706c | Insert With Name Reference652f 7061 7468      |  Static Table, Index=1                    |  (:path=/sample/path)                              Abs Ref Name        Value                              ^-- acknowledged --^                               0   0  :authority  www.example.com                               1   0  :path       /sample/path                              Size=106Stream: 40381                | Required Insert Count = 2, Base = 010                  | Indexed Field Line With Post-Base Index                    |  Absolute Index = Base(0) + Index(0) = 0                    |  (:authority=www.example.com)11                  | Indexed Field Line With Post-Base Index                    |  Absolute Index = Base(0) + Index(1) = 1                    |  (:path=/sample/path)                              Abs Ref Name        Value                              ^-- acknowledged --^                               0   1  :authority  www.example.com                               1   1  :path       /sample/path                              Size=106Stream: Decoder84                  | Section Acknowledgment (stream=4)                              Abs Ref Name        Value                               0   0  :authority  www.example.com                               1   0  :path       /sample/path                              ^-- acknowledged --^                              Size=106

B.3.Speculative Insert

The encoder inserts a header into the dynamic table with a literal name.The decoder acknowledges receipt of the entry. The encoder does not sendany encoded field sections.¶

Stream: Encoder4a63 7573 746f 6d2d | Insert With Literal Name6b65 790c 6375 7374 |  (custom-key=custom-value)6f6d 2d76 616c 7565 |                              Abs Ref Name        Value                               0   0  :authority  www.example.com                               1   0  :path       /sample/path                              ^-- acknowledged --^                               2   0  custom-key  custom-value                              Size=160Stream: Decoder01                  | Insert Count Increment (1)                              Abs Ref Name        Value                               0   0  :authority  www.example.com                               1   0  :path       /sample/path                               2   0  custom-key  custom-value                              ^-- acknowledged --^                              Size=160

B.4.Duplicate Instruction, Stream Cancellation

The encoder duplicates an existing entry in the dynamic table, then sends anencoded field section referencing the dynamic table entries including theduplicated entry. The packet containing the encoder stream data is delayed.Before the packet arrives, the decoder cancels the stream and notifies theencoder that the encoded field section was not processed.¶

Stream: Encoder02                  | Duplicate (Relative Index = 2)                    |  Absolute Index =                    |   Insert Count(3) - Index(2) - 1 = 0                              Abs Ref Name        Value                               0   0  :authority  www.example.com                               1   0  :path       /sample/path                               2   0  custom-key  custom-value                              ^-- acknowledged --^                               3   0  :authority  www.example.com                              Size=217Stream: 80500                | Required Insert Count = 4, Base = 480                  | Indexed Field Line, Dynamic Table                    |  Absolute Index = Base(4) - Index(0) - 1 = 3                    |  (:authority=www.example.com)c1                  | Indexed Field Line, Static Table Index = 1                    |  (:path=/)81                  | Indexed Field Line, Dynamic Table                    |  Absolute Index = Base(4) - Index(1) - 1 = 2                    |  (custom-key=custom-value)                              Abs Ref Name        Value                               0   0  :authority  www.example.com                               1   0  :path       /sample/path                               2   1  custom-key  custom-value                              ^-- acknowledged --^                               3   1  :authority  www.example.com                              Size=217Stream: Decoder48                  | Stream Cancellation (Stream=8)                              Abs Ref Name        Value                               0   0  :authority  www.example.com                               1   0  :path       /sample/path                               2   0  custom-key  custom-value                              ^-- acknowledged --^                               3   0  :authority  www.example.com                              Size=217

B.5.Dynamic Table Insert, Eviction

The encoder inserts another header into the dynamic table, which evicts theoldest entry. The encoder does not send any encoded field sections.¶

Stream: Encoder810d 6375 7374 6f6d | Insert With Name Reference2d76 616c 7565 32   |  Dynamic Table, Relative Index = 1                    |  Absolute Index =                    |   Insert Count(4) - Index(1) - 1 = 2                    |  (custom-key=custom-value2)                              Abs Ref Name        Value                               1   0  :path       /sample/path                               2   0  custom-key  custom-value                              ^-- acknowledged --^                               3   0  :authority  www.example.com                               4   0  custom-key  custom-value2                              Size=215

Movatterモバイル変換

RFC 9204

QPACK: Field Compression for HTTP/3