-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-hewitt-ietf-qpack-static-table-version-00.xml
306 lines (272 loc) · 14.6 KB
/
draft-hewitt-ietf-qpack-static-table-version-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?> <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
Use of an external entity file is not recommended. -->
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="info"
docName="draft-hewitt-ietf-qpack-static-table-version-00"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
version="3">
<front>
<title abbrev="QSTV TLS extension">The qpack_static_table_version TLS extension</title>
<seriesInfo name="Internet-Draft" value="draft-hewitt-ietf-qpack-static-table-version-00"/>
<author fullname="Rory Hewitt" initials="R" surname="Hewitt">
<organization>Akamai Technologies Inc.</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2023"/>
<!-- On draft subbmission:
* If only the current year is specified, the current day and month will be used.
* If the month and year are both specified and are the current ones, the current day will
be used
* If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
-->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- "Internet Engineering Task Force" is fine for individual submissions. If this element is
not present, the default is "Network Working Group", which is used by the RFC Editor as
a nod to the history of the RFC Series. -->
<keyword>qpack static table version http/3 h3 tls extension</keyword>
<abstract>
<t>This document specifies a new "qpack_static_table_version" TLS extension to enable clients and servers to agree upon the version of the HTTP/3 QPACK Static Table to use for communications between them.</t>
</abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>
HTTP/3 uses QPACK <xref target="RFC9204"/> for compression of the header and trailer sections.</t>
<t>
QPACK reuses core concepts from the HPACK algorithm used for HTTP/2, but as noted in its design "[...]is redesigned to allow correctness in the presence of out-of-order delivery, with flexibility for implementations to balance between resilience against head-of-line blocking and optimal compression ratio."</t>
<t>
A core feature of QPACK is the use of a 'static table' which contains a predefined list of frequently-used field lines, each of which is identified by a unique, unchanging index in the table, enabling excellent compression of these field lines. Each entry in the static table may contain a field name or a field name/value combination. Less frequently-used fields or field name/value combinations are passed in the QPACK 'dynamic table'. Because of the optimal compression, defining field lines in the static table is significantly desirable over passing them in the dynamic table.</t>
<t>
When the static table was originally defined, the field line entries it contained were calculated by determining the relative frequency with which each field line was found in a representative sampling of web traffic. However, as new HTTP fields become more frequently-used over time, it makes sense that they be added as additional entries to the static table to retain the high level of compression.</t>
<t>When clients and servers communicate using HTTP/3, they each need to be aware of how many static table entries the other is using, so there is no mismatch where one refers to a static table entry that the other does not recognize. As a result, clients and servers must agree upon the size of the static table they will both use. Because the size of the static table must be known prior to any HTTP requests passing between the client and server, this information must be passed during the TLS handshake.
</t>
<t>
This specification defines a new TLS extension which can be passed by both client and server to identify the version (size) of the static table that they will both use.
</t>
<section>
<name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.</t>
<t>
The following terms are used in this document:
</t>
<ul>
<li><strong>HTTP fields</strong>: Metadata sent as part of an HTTP message. The term encompasses both header and trailer fields. Colloquially, the term "headers" has often been used to refer to HTTP header fields and trailer fields; this document uses "fields" for generality.</li>
<li><strong>HTTP field line</strong>: A name-value pair sent as part of an HTTP field section. See Sections 6.3 and 6.5 of <xref target="RFC9110"/>.</li>
<li><strong>HTTP field value</strong>: Data associated with a field name, composed from all field line values with that field name in that section, concatenated together with comma separators.</li>
</ul>
<t>
Note that QPACK is a name, not an abbreviation.</t>
</section>
</section>
<section>
<name>QPACK Static Table Background</name>
<t>The original QPACK static table <xref target="RFC9204"/> contains 99 entries (starting at entry 0, ending at entry 98), as follows:</t>
<table>
<thead>
<tr>
<th>Entry</th>
<th>Value</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td>0 (first entry)</td>
<td>:authority</td>
<td>Field name only</td>
</tr>
<tr>
<td>1</td>
<td>:path /</td>
<td>Field name and value combination</td>
</tr>
<tr>
<td>2</td>
<td>Age 0</td>
<td>Field name and value combination</td>
</tr>
<tr>
<td colspan="3">...2 - 97...</td>
</tr>
<tr>
<td>98 (last entry)</td>
<td>x-frame-options sameorigin</td>
<td>Field name and value combination</td>
</tr>
</tbody>
</table>
<t>
The table was generated by analyzing actual Internet traffic in 2018 and including the most common header fields, after filtering out some unsupported and non-standard values. Due to this methodology, some of the entries may be inconsistent or appear multiple times with similar but not identical values. The order of the entries is optimized to encode the most common header fields with the smallest number of bytes.</t>
</section>
<section>
<name>QPACK Static Table Additions</name>
<t>
Over time, the IANA will re-sample actual internet traffic and as new field names or field name/value combinations become more prevalent, they will be appended as new entries to the static table and a new version of the static table will be published by IANA.</t>
<t>
To maintain backwards-compatibility, new static table entries MUST be appended to the end of the current published version of the static table. Once added, entries MUST NOT be removed from a published version of the static table. As new versions of the static table are published, they can be implemented by both clients and servers. It is assumed that clients and servers will support only a single version of the static table.</t>
</section>
<section>
<name>The qpack_static_table_version TLS extension</name>
<t>
The <strong>qpack_static_table_version</strong> TLS extension is an integer value which represents the number of entries in the static table supported by the sender.</t>
<t>
The extension_data for the qpack_static_table_version extension is <strong>StaticTableLength</strong>, described below using the syntax defined in <xref target="RFC8446"/>:</t>
<figure>
<sourcecode>
<![CDATA[
struct {
uint8 StaticTableLength;
} QSTVExtension;
]]>
</sourcecode>
</figure>
<t>
The <strong>default value</strong> of the qpack_static_table_version extension is <strong>99</strong> - the size of the original QPACK static table.</t>
<t>
The qpack_static_table_version extension has a minimum allowed value equal to the default value. Any value lower than the minimum allowed value, including a negative value, is invalid.</t>
<t>
The qpack_static_table_version extension is OPTIONAL and MAY be passed by a client to a server in the ClientHello, to indicate the version of the static table that the client supports - that is, the number of static table entries that the client supports. If the qpack_static_table_version extension is not present in the ClientHello, the server MUST assume that the client is using the default value.</t>
<t>
If the ClientHello includes the qpack_static_table_version extension, the server MAY respond in the ServerHello with its own version of the static table.</t>
<t>
If either the ClientHello or the ServerHello do not include the qpack_static_table_version extension, or if an invalid value is specified, then both client and server must fall back to use the default value.</t>
<t>
If both the client and the server pass the qpack_static_table_version extension, the lower version MUST be used by both client and server, thus ensuring that both client and server only reference entries in their static table up to the shared lowest version number.</t>
<t>
Sample pseudocode processing:</t>
<figure>
<name>Client processing</name>
<sourcecode>
<![CDATA[
Initialize variable C to supported StaticTableLength value
Include qpack_static_table_version with value C in ClientHello
if (ServerHello does not contain qpack_static_table_version) {
set C to default value
} else {
save qpack_static_table_version from ServerHello as S
if (S is invalid) {
set C to default value
} else if (S < C) {
set C to value of S
}
}
Use C for static table index processing]]>
</sourcecode>
</figure>
<figure>
<name>Server processing</name>
<sourcecode>
<![CDATA[
Initialize variable S to supported StaticTableLength value
if (ClientHello does not contain qpack_static_table_version) {
set S to default value
} else {
save qpack_static_table_version from ClientHello as C
if (C is invalid) {
set S to default value
} else if (C < S) {
set S to value of C
}
Include qpack_static_table_version with value S in ServerHello
}
Use S for static table index processing]]>
</sourcecode>
</figure>
<t>
Examples (assuming that multiple versions, including versions 114 and 126, have been published by IANA):
</t>
<table>
<thead>
<tr>
<th>Client value</th>
<th>Server value</th>
<th>Value used</th>
</tr>
</thead>
<tbody>
<tr>
<td>empty</td>
<td>empty</td>
<td>Version 99</td>
</tr>
<tr>
<td>empty</td>
<td>114</td>
<td>Version 99</td>
</tr>
<tr>
<td>114</td>
<td>empty</td>
<td>Version 99</td>
</tr>
<tr>
<td>114</td>
<td>126</td>
<td>Version 114</td>
</tr>
<tr>
<td>126</td>
<td>114</td>
<td>Version 114</td>
</tr>
</tbody>
</table>
</section>
<section anchor="IANA">
<!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
<name>IANA Considerations</name>
<t>This memo requests that IANA, on an ongoing basis (suggested once per year), performs an analysis of a representative sample of web traffic to determine whether any fields or field/value combinations not currently present in the latest published version of the static table are found more frequently in HTTP/3 web traffic requests than the last entry in the current version of the static table.</t>
<t>
In that case, these fields and field/value combinations should be appended as entries to the static table and a new version of the static table published.</t>
<t>
This publishing by IANA will ensure that all clients and servers that wish to use a more recent version of the static table can be sure that the new entries are added in the same order for both client and server.</t>
</section>
<section anchor="Security">
<!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
<name>Security Considerations</name>
<t>This document should not affect the security of the Internet.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9204.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>Many thanks to Rich Salz and Mike Bishop at Akamai for their invaluable help.
</t>
</section>
</back>
</rfc>