-
Notifications
You must be signed in to change notification settings - Fork 565
/
draft-ietf-httpbis-http2bis.xml
3462 lines (3422 loc) · 254 KB
/
draft-ietf-httpbis-http2bis.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
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std" docName="draft-ietf-httpbis-http2bis-latest" tocInclude="true" symRefs="true" sortRefs="true" version="3" submissionType="IETF" consensus="true" number="9113" obsoletes="7540,8740">
<front>
<title>HTTP/2</title>
<seriesInfo name="RFC" value="9113"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
<organization>Mozilla</organization>
<address>
<postal>
<country>Australia</country>
</postal>
<email>mt@lowentropy.net</email>
</address>
</author>
<author initials="C." surname="Benfield" fullname="Cory Benfield" role="editor">
<organization>Apple Inc.</organization>
<address>
<email>cbenfield@apple.com</email>
</address>
</author>
<date month="May" year="2022"/>
<area>Applications and Real-Time</area>
<workgroup>HTTPbis</workgroup>
<keyword>HTTP</keyword>
<keyword>SPDY</keyword>
<keyword>Web</keyword>
<abstract>
<t>This specification describes an optimized expression of the semantics of the Hypertext
Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more
efficient use of network resources and a
reduced latency by introducing field compression and allowing multiple
concurrent exchanges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front>
<middle>
<section anchor="intro">
<name>Introduction</name>
<t>The performance of applications using the Hypertext Transfer Protocol
(HTTP, <xref target="RFC9110"/>) is linked to how each version of HTTP uses the underlying
transport, and the conditions under which the transport operates.</t>
<t>Making multiple concurrent requests can reduce latency and improve
application performance. HTTP/1.0 allowed only one request to be
outstanding at a time on a given TCP <xref target="RFC0793"/> connection. HTTP/1.1 <xref target="RFC9112"/>
added request pipelining, but this only partially addressed request
concurrency and still suffers from application-layer head-of-line
blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients use multiple connections
to a server to make concurrent requests.</t>
<t>Furthermore, HTTP fields are often repetitive and verbose, causing unnecessary
network traffic as well as causing the initial TCP congestion
window to quickly fill. This can result in excessive latency when multiple requests are
made on a new TCP connection.</t>
<t>HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an
underlying connection. Specifically, it allows interleaving of messages on the same
connection and uses an efficient coding for HTTP fields. It also allows prioritization of
requests, letting more important requests complete more quickly, further improving
performance.</t>
<t>The resulting protocol is more friendly to the network because fewer TCP connections can
be used in comparison to HTTP/1.x. This means less competition with other flows and
longer-lived connections, which in turn lead to better utilization of available network
capacity. Note, however, that TCP head-of-line blocking is not addressed by this protocol.</t>
<t>Finally, HTTP/2 also enables more efficient processing of messages through use of binary
message framing.</t>
<t>This document obsoletes RFCs 7540 and 8740. <xref target="revision-updates"/> lists notable changes.</t>
</section>
<section anchor="Overview">
<name>HTTP/2 Protocol Overview</name>
<t>HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supports all of the core
features of HTTP but aims to be more efficient than HTTP/1.1.</t>
<t>HTTP/2 is a connection-oriented application-layer protocol that runs over a TCP connection
(<xref target="RFC0793"/>). The client is the TCP connection initiator.</t>
<t>The basic protocol unit in HTTP/2 is a <xref target="FrameHeader">frame</xref>. Each frame
type serves a different purpose. For example, <xref target="HEADERS" format="none">HEADERS</xref> and
<xref target="DATA" format="none">DATA</xref> frames form the basis of <xref target="HttpFraming">HTTP requests and
responses</xref>; other frame types like <xref target="SETTINGS" format="none">SETTINGS</xref>,
<xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, and <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> are used in support of other
HTTP/2 features.</t>
<t>Multiplexing of requests is achieved by having each HTTP request/response exchange
associated with its own <xref target="StreamsLayer">stream</xref>. Streams are largely
independent of each other, so a blocked or stalled request or response does not prevent
progress on other streams.</t>
<t>Effective use of multiplexing depends on flow control and prioritization. <xref target="FlowControl">Flow control</xref> ensures that it is possible to efficiently use
multiplexed streams by restricting data that is transmitted to what the receiver is able to
handle. <xref target="StreamPriority">Prioritization</xref> ensures that limited resources
are used most effectively. This revision of HTTP/2 deprecates the priority signaling scheme
from <xref target="RFC7540"/>.</t>
<t>Because HTTP fields used in a connection can contain large amounts of redundant
data, frames that contain them are <xref target="FieldBlock">compressed</xref>. This has
especially advantageous impact upon request sizes in the common case, allowing many
requests to be compressed into one packet.</t>
<t>Finally, HTTP/2 adds a new, optional interaction mode whereby a server can <xref target="PushResources">push
responses to a client</xref>. This is intended to allow a server to speculatively send data to a
client that the server anticipates the client will need, trading off some network usage
against a potential latency gain. The server does this by synthesizing a request, which it
sends as a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame. The server is then able to send a response to
the synthetic request on a separate stream.</t>
<section>
<name>Document Organization</name>
<t>The HTTP/2 specification is split into four parts:</t>
<ul spacing="normal">
<li><xref target="starting">Starting HTTP/2</xref> covers how an HTTP/2 connection is
initiated.</li>
<li>The <xref target="FramingLayer">frame</xref> and <xref target="StreamsLayer">stream</xref> layers describe the way HTTP/2 frames are
structured and formed into multiplexed streams.</li>
<li><xref target="FrameTypes">Frame</xref> and <xref target="ErrorCodes">error</xref>
definitions include details of the frame and error types used in HTTP/2.</li>
<li><xref target="HttpLayer">HTTP mappings</xref> and <xref target="HttpExtra">additional
requirements</xref> describe how HTTP semantics are expressed using frames and
streams.</li>
</ul>
<t>While some of the frame- and stream-layer concepts are isolated from HTTP, this
specification does not define a completely generic frame layer. The frame and stream
layers are tailored to the needs of HTTP.</t>
</section>
<section>
<name>Conventions and Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
"<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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>All numeric values are in network byte order. Values are unsigned unless otherwise
indicated. Literal values are provided in decimal or hexadecimal as appropriate.
Hexadecimal literals are prefixed with "<tt>0x</tt>" to distinguish them
from decimal literals.</t>
<t>This specification describes binary formats using the conventions described in <xref target="RFC9000" section="1.3">RFC 9000</xref>. Note that this format uses network byte
order and that high-valued bits are listed before low-valued bits.</t>
<t>The following terms are used:</t>
<dl newline="false" spacing="normal">
<dt>client:</dt>
<dd>The endpoint that initiates an HTTP/2 connection. Clients send HTTP requests and
receive HTTP responses.</dd>
<dt>connection:</dt>
<dd>A transport-layer connection between two endpoints.</dd>
<dt>connection error:</dt>
<dd>An error that affects the entire HTTP/2 connection.</dd>
<dt>endpoint:</dt>
<dd>Either the client or server of the connection.</dd>
<dt>frame:</dt>
<dd>The smallest unit of communication within an HTTP/2 connection, consisting of a header
and a variable-length sequence of octets structured according to the frame type.</dd>
<dt>peer:</dt>
<dd>An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint
that is remote to the primary subject of discussion.</dd>
<dt>receiver:</dt>
<dd>An endpoint that is receiving frames.</dd>
<dt>sender:</dt>
<dd>An endpoint that is transmitting frames.</dd>
<dt>server:</dt>
<dd>The endpoint that accepts an HTTP/2 connection. Servers receive HTTP requests and
send HTTP responses.</dd>
<dt>stream:</dt>
<dd>A bidirectional flow of frames within the HTTP/2 connection.</dd>
<dt>stream error:</dt>
<dd>An error on the individual HTTP/2 stream.</dd>
</dl>
<t>Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined in
<xref target="RFC9110" section="3.7"/>. Intermediaries act as both client
and server at different times.</t>
<t>The term "content" as it applies to message bodies is defined in <xref target="RFC9110" section="6.4"/>.</t>
</section>
</section>
<section anchor="starting">
<name>Starting HTTP/2</name>
<t>Implementations that generate HTTP requests need to discover whether a server supports
HTTP/2.</t>
<t>HTTP/2 uses the "<tt>http</tt>" and "<tt>https</tt>" URI schemes defined in <xref target="RFC9110" section="4.2"/>, with the same default port numbers as HTTP/1.1 <xref target="RFC9112"/>. These URIs do not include any indication about what HTTP versions an
upstream server (the immediate peer to which the client wishes to establish a connection)
supports.</t>
<t>The means by which support for HTTP/2 is determined is different for "<tt>http</tt>" and "<tt>https</tt>"
URIs. Discovery for "<tt>https</tt>" URIs is described in <xref target="discover-https"/>. HTTP/2
support for "<tt>http</tt>" URIs can only be discovered by out-of-band means and requires prior knowledge
of the support as described in <xref target="known-http"/>.</t>
<section anchor="versioning">
<name>HTTP/2 Version Identification</name>
<t>The protocol defined in this document has two identifiers. Creating a connection based on
either implies the use of the transport, framing, and message semantics described in this
document.</t>
<ul spacing="normal">
<li>
<t>The string "h2" identifies the protocol where HTTP/2 uses Transport Layer Security
(TLS); see <xref target="TLSUsage"/>. This identifier is used in the <xref target="RFC7301">TLS Application-Layer Protocol Negotiation (ALPN) extension</xref>
field and in any place where HTTP/2 over TLS is identified.</t>
<t>The "h2" string is serialized into an ALPN protocol identifier as the two-octet
sequence: 0x68, 0x32.</t>
</li>
<li>
<t>The "h2c" string was previously used as a token for use in the HTTP Upgrade
mechanism's Upgrade header field (<xref target="RFC9110" section="7.8"/>). This usage
was never widely deployed and is deprecated by this document. The same applies to the
HTTP2-Settings header field, which was used with the upgrade to "h2c".</t>
</li>
</ul>
</section>
<section anchor="discover-https">
<name>Starting HTTP/2 for "<tt>https</tt>" URIs</name>
<t>A client that makes a request to an "<tt>https</tt>" URI uses <xref target="RFC8446">TLS</xref> with
the <xref target="RFC7301">ALPN extension</xref>.</t>
<t>HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" protocol identifier <bcp14>MUST NOT</bcp14>
be sent by a client or selected by a server; the "h2c" protocol identifier describes a
protocol that does not use TLS.</t>
<t>Once TLS negotiation is complete, both the client and the server <bcp14>MUST</bcp14> send a <xref target="preface">connection preface</xref>.</t>
</section>
<section anchor="known-http">
<name>Starting HTTP/2 with Prior Knowledge</name>
<t>A client can learn that a particular server supports HTTP/2 by other means. For example,
a client could be configured with knowledge that a server supports HTTP/2.</t>
<t>A client that knows that a server supports HTTP/2 can establish a TCP connection and send
the <xref target="preface">connection preface</xref> followed by HTTP/2 frames.
Servers can identify these connections by the presence of the connection preface. This
only affects the establishment of HTTP/2 connections over cleartext TCP; HTTP/2 connections
over TLS <bcp14>MUST</bcp14> use <xref target="RFC7301">protocol negotiation in
TLS</xref>.</t>
<t>Likewise, the server <bcp14>MUST</bcp14> send a <xref target="preface">connection preface</xref>.</t>
<t>Without additional information, prior support for HTTP/2 is not a strong signal that a
given server will support HTTP/2 for future connections. For example, it is possible for
server configurations to change, for configurations to differ between instances in
clustered servers, or for network conditions to change.</t>
</section>
<section anchor="preface">
<name>HTTP/2 Connection Preface</name>
<t>In HTTP/2, each endpoint is required to send a connection preface as a final confirmation
of the protocol in use and to establish the initial settings for the HTTP/2 connection.
The client and server each send a different connection preface.</t>
<t>The client connection preface starts with a sequence of 24 octets, which in hex notation
is:</t>
<artwork type="inline"><![CDATA[
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
]]></artwork>
<t>That is, the connection preface starts with the string "<tt>PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n</tt>". This sequence
<bcp14>MUST</bcp14> be followed by a <xref target="SETTINGS" format="none">SETTINGS</xref> frame (<xref target="SETTINGS"/>), which
<bcp14>MAY</bcp14> be empty. The client sends the client connection preface as the first
application data octets of a connection.</t>
<aside>
<t>Note:
The client connection preface is selected so that a large proportion of HTTP/1.1 or
HTTP/1.0 servers and intermediaries do not attempt to process further frames. Note
that this does not address the concerns raised in <xref target="TALKING"/>.</t>
</aside>
<t>The server connection preface consists of a potentially empty <xref target="SETTINGS" format="none">SETTINGS</xref>
frame (<xref target="SETTINGS"/>) that <bcp14>MUST</bcp14> be the first frame the server sends in the
HTTP/2 connection.</t>
<t>The <xref target="SETTINGS" format="none">SETTINGS</xref> frames received from a peer as part of the connection preface
<bcp14>MUST</bcp14> be acknowledged (see <xref target="SettingsSync"/>) after sending the connection
preface.</t>
<t>To avoid unnecessary latency, clients are permitted to send additional frames to the
server immediately after sending the client connection preface, without waiting to receive
the server connection preface. It is important to note, however, that the server
connection preface <xref target="SETTINGS" format="none">SETTINGS</xref> frame might include settings that necessarily
alter how a client is expected to communicate with the server. Upon receiving the
<xref target="SETTINGS" format="none">SETTINGS</xref> frame, the client is expected to honor any settings established.
In some configurations, it is possible for the server to transmit <xref target="SETTINGS" format="none">SETTINGS</xref>
before the client sends additional frames, providing an opportunity to avoid this issue.</t>
<t>Clients and servers <bcp14>MUST</bcp14> treat an invalid connection preface as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. A <xref target="GOAWAY" format="none">GOAWAY</xref> frame (<xref target="GOAWAY"/>)
<bcp14>MAY</bcp14> be omitted in this case, since an invalid preface indicates that the peer is not using
HTTP/2.</t>
</section>
</section>
<section anchor="FramingLayer">
<name>HTTP Frames</name>
<t>Once the HTTP/2 connection is established, endpoints can begin exchanging frames.</t>
<section anchor="FrameHeader">
<name>Frame Format</name>
<t>All frames begin with a fixed 9-octet header followed by a variable-length frame payload.</t>
<figure anchor="FrameLayout">
<name>Frame Layout</name>
<artwork type="inline"><![CDATA[
HTTP Frame {
Length (24),
Type (8),
Flags (8),
Reserved (1),
Stream Identifier (31),
Frame Payload (..),
}
]]></artwork>
</figure>
<t>The fields of the frame header are defined as:</t>
<dl newline="false" spacing="normal">
<dt>Length:</dt>
<dd>
<t>The length of the frame payload expressed as an unsigned 24-bit integer in units of octets. Values
greater than 2<sup>14</sup> (16,384) <bcp14>MUST NOT</bcp14> be sent unless the receiver has
set a larger value for <xref target="SETTINGS_MAX_FRAME_SIZE" format="none">SETTINGS_MAX_FRAME_SIZE</xref>.</t>
<t>The 9 octets of the frame header are not included in this value.</t>
</dd>
<dt>Type:</dt>
<dd>
<t>The 8-bit type of the frame. The frame type determines the format and semantics of
the frame. Frames defined in this document are listed in <xref target="FrameTypes"/>.
Implementations <bcp14>MUST</bcp14> ignore and discard frames of unknown types.</t>
</dd>
<dt>Flags:</dt>
<dd>
<t>An 8-bit field reserved for boolean flags specific to the frame type.</t>
<t>Flags are assigned semantics specific to the indicated frame type. Unused flags are
those that have no defined semantics for a particular frame type. Unused flags <bcp14>MUST</bcp14> be
ignored on receipt and <bcp14>MUST</bcp14> be left unset (0x00) when sending.</t>
</dd>
<dt>Reserved:</dt>
<dd>
<t>A reserved 1-bit field. The semantics of this bit are undefined, and the bit <bcp14>MUST</bcp14>
remain unset (0x00) when sending and <bcp14>MUST</bcp14> be ignored when receiving.</t>
</dd>
<dt>Stream Identifier:</dt>
<dd>
<t>A stream identifier (see <xref target="StreamIdentifiers"/>) expressed as an
unsigned 31-bit integer. The value 0x00 is reserved for frames that are associated
with the connection as a whole as opposed to an individual stream.</t>
</dd>
</dl>
<t>The structure and content of the frame payload are dependent entirely on the frame type.</t>
</section>
<section anchor="FrameSize">
<name>Frame Size</name>
<t>The size of a frame payload is limited by the maximum size that a receiver advertises in
the <xref target="SETTINGS_MAX_FRAME_SIZE" format="none">SETTINGS_MAX_FRAME_SIZE</xref> setting. This setting can have any value
between 2<sup>14</sup> (16,384) and 2<sup>24</sup>-1 (16,777,215) octets,
inclusive.</t>
<t>All implementations <bcp14>MUST</bcp14> be capable of receiving and minimally processing frames up to
2<sup>14</sup> octets in length, plus the 9-octet <xref target="FrameHeader">frame
header</xref>. The size of the frame header is not included when describing frame sizes.</t>
<aside>
<t>Note: Certain frame types, such as <xref target="PING">PING</xref>, impose additional limits
on the amount of frame payload data allowed.</t>
</aside>
<t>An endpoint <bcp14>MUST</bcp14> send an error code of <xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref> if a frame exceeds the size defined in <xref target="SETTINGS_MAX_FRAME_SIZE" format="none">SETTINGS_MAX_FRAME_SIZE</xref>, exceeds any
limit defined for the frame type, or is too small to contain mandatory frame data. A frame
size error in a frame that could alter the state of the entire connection <bcp14>MUST</bcp14> be treated
as a <xref target="ConnectionErrorHandler">connection error</xref>; this includes any
frame carrying a <xref target="FieldBlock">field block</xref> (that is, <xref target="HEADERS" format="none">HEADERS</xref>, <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, and <xref target="CONTINUATION" format="none">CONTINUATION</xref>), a <xref target="SETTINGS" format="none">SETTINGS</xref> frame, and any frame with a stream identifier of 0.</t>
<t>Endpoints are not obligated to use all available space in a frame. Responsiveness can be
improved by using frames that are smaller than the permitted maximum size. Sending large
frames can result in delays in sending time-sensitive frames (such as
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, or <xref target="PRIORITY" format="none">PRIORITY</xref>),
which, if blocked by the transmission of a large frame, could affect performance.</t>
</section>
<section anchor="FieldBlock">
<name>Field Section Compression and Decompression</name>
<t>Field section compression is the process of compressing a set of field lines (<xref target="RFC9110" section="5.2"/>) to form a
field block. Field section decompression is the process of decoding a field block into a
set of field lines. Details of HTTP/2 field section compression and decompression are
defined in <xref target="RFC7541"/>, which, for historical reasons, refers to these
processes as header compression and decompression.</t>
<t>Each field block carries all of the compressed field lines of a single field section.
Header sections also include control data associated with the message in the form of <xref target="PseudoHeaderFields">pseudo-header fields</xref> that use the same format as a
field line.</t>
<aside>
<t>Note: <xref target="RFC7540">RFC 7540</xref> used the term "header block" in place of
the more generic "field block".</t>
</aside>
<t>Field blocks carry control data and header sections for requests, responses, promised
requests, and pushed responses (see <xref target="PushResources"/>). All these messages,
except for interim responses and requests contained in <xref target="PUSH_PROMISE">PUSH_PROMISE</xref> frames, can optionally include a field block that
carries a trailer section.</t>
<t>A field section is a collection of field lines. Each of the field lines in a
field block carries a single value. The serialized field block is then divided into one or
more octet sequences, called field block fragments. The first field block fragment is transmitted within the frame
payload of <xref target="HEADERS">HEADERS</xref> or <xref target="PUSH_PROMISE">PUSH_PROMISE</xref>, each of which could be followed by <xref target="CONTINUATION">CONTINUATION</xref> frames to carry subsequent field block fragments.</t>
<t>The <xref target="RFC6265">Cookie header field</xref> is treated specially by the HTTP
mapping (see <xref target="CompressCookie"/>).</t>
<t>A receiving endpoint reassembles the field block by concatenating its fragments and then
decompresses the block to reconstruct the field section.</t>
<t>A complete field section consists of either:</t>
<ul spacing="normal">
<li>a single <xref target="HEADERS" format="none">HEADERS</xref> or <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame,
with the END_HEADERS flag set, or</li>
<li>a <xref target="HEADERS" format="none">HEADERS</xref> or <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame with the END_HEADERS
flag unset and one or more <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames,
where the last <xref target="CONTINUATION" format="none">CONTINUATION</xref> frame has the END_HEADERS flag set.</li>
</ul>
<t>Each field block is processed as a discrete unit.
Field blocks <bcp14>MUST</bcp14> be transmitted as a contiguous sequence of frames, with no interleaved
frames of any other type or from any other stream. The last frame in a sequence of
<xref target="HEADERS" format="none">HEADERS</xref> or <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames has the END_HEADERS flag set.
The last frame in a sequence of <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> or <xref target="CONTINUATION" format="none">CONTINUATION</xref>
frames has the END_HEADERS flag set. This allows a field block to be logically
equivalent to a single frame.</t>
<t>Field block fragments can only be sent as the frame payload of <xref target="HEADERS" format="none">HEADERS</xref>,
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, or <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames because these frames
carry data that can modify the compression context maintained by a receiver. An endpoint
receiving <xref target="HEADERS" format="none">HEADERS</xref>, <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, or
<xref target="CONTINUATION" format="none">CONTINUATION</xref> frames needs to reassemble field blocks and perform
decompression even if the frames are to be discarded. A receiver <bcp14>MUST</bcp14> terminate the
connection with a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref> if it does not decompress a field block.</t>
<t>A decoding error in a field block <bcp14>MUST</bcp14> be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref>.</t>
<section anchor="dynamic-table">
<name>Compression State</name>
<t>Field compression is stateful. Each endpoint has an HPACK encoder context and an HPACK
decoder context that are used for encoding and decoding all field blocks on a
connection. <xref target="RFC7541" section="4"/> defines the dynamic table, which
is the primary state for each context.</t>
<t>The dynamic table has a maximum size that is set by an HPACK decoder. An endpoint
communicates the size chosen by its HPACK decoder context using the
SETTINGS_HEADER_TABLE_SIZE setting; see <xref target="SettingValues"/>. When a
connection is established, the dynamic table size for the HPACK decoder and encoder at
both endpoints starts at 4,096 bytes, the initial value of the
SETTINGS_HEADER_TABLE_SIZE setting.</t>
<t>Any change to the maximum value set using SETTINGS_HEADER_TABLE_SIZE takes effect when
the endpoint <xref target="SettingsSync">acknowledges settings</xref>. The HPACK
encoder at that endpoint can set the dynamic table to any size up to the maximum value
set by the decoder. An HPACK encoder declares the size of the dynamic table with a
Dynamic Table Size Update instruction (<xref target="RFC7541" section="6.3"/>).</t>
<t>Once an endpoint acknowledges a change to SETTINGS_HEADER_TABLE_SIZE that reduces the
maximum below the current size of the dynamic table, its HPACK encoder <bcp14>MUST</bcp14> start the
next field block with a Dynamic Table Size Update instruction that sets the dynamic
table to a size that is less than or equal to the reduced maximum; see <xref target="RFC7541" section="4.2"/>. An endpoint <bcp14>MUST</bcp14> treat a field block that follows
an acknowledgment of the reduction to the maximum dynamic table size as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref> if it does not start
with a conformant Dynamic Table Size Update instruction.</t>
<aside>
<t>Implementers are advised that reducing the value of SETTINGS_HEADER_TABLE_SIZE is not
widely interoperable. Use of the connection preface to reduce the value below the
initial value of 4,096 is somewhat better supported, but this might fail with some
implementations.</t>
</aside>
</section>
</section>
</section>
<section anchor="StreamsLayer">
<name>Streams and Multiplexing</name>
<t>A "stream" is an independent, bidirectional sequence of frames exchanged between the client
and server within an HTTP/2 connection. Streams have several important characteristics:</t>
<ul spacing="normal">
<li>A single HTTP/2 connection can contain multiple concurrently open streams, with either
endpoint interleaving frames from multiple streams.</li>
<li>Streams can be established and used unilaterally or shared by either endpoint.</li>
<li>Streams can be closed by either endpoint.</li>
<li>The order in which frames are sent is significant. Recipients process frames
in the order they are received. In particular, the order of <xref target="HEADERS" format="none">HEADERS</xref>
and <xref target="DATA" format="none">DATA</xref> frames is semantically significant.</li>
<li>Streams are identified by an integer. Stream identifiers are assigned to streams by the
endpoint initiating the stream.</li>
</ul>
<section anchor="StreamStates">
<name>Stream States</name>
<t>The lifecycle of a stream is shown in <xref target="StreamStatesFigure"/>.</t>
<figure anchor="StreamStatesFigure">
<name>Stream States</name>
<artset>
<artwork type="svg">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="480" width="488" viewBox="0 0 488 480" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
<g transform="translate(8,16)">
<path d="M 0,112 L 0,416" fill="none" stroke="black"/>
<path d="M 56,80 L 56,144" fill="none" stroke="black"/>
<path d="M 56,240 L 56,304" fill="none" stroke="black"/>
<path d="M 88,144 L 88,232" fill="none" stroke="black"/>
<path d="M 96,304 L 96,384" fill="none" stroke="black"/>
<path d="M 144,80 L 144,144" fill="none" stroke="black"/>
<path d="M 144,240 L 144,304" fill="none" stroke="black"/>
<path d="M 200,0 L 200,64" fill="none" stroke="black"/>
<path d="M 200,160 L 200,224" fill="none" stroke="black"/>
<path d="M 200,368 L 200,432" fill="none" stroke="black"/>
<path d="M 232,64 L 232,152" fill="none" stroke="black"/>
<path d="M 232,224 L 232,360" fill="none" stroke="black"/>
<path d="M 272,0 L 272,64" fill="none" stroke="black"/>
<path d="M 272,160 L 272,224" fill="none" stroke="black"/>
<path d="M 272,368 L 272,432" fill="none" stroke="black"/>
<path d="M 328,80 L 328,144" fill="none" stroke="black"/>
<path d="M 328,240 L 328,304" fill="none" stroke="black"/>
<path d="M 376,304 L 376,384" fill="none" stroke="black"/>
<path d="M 384,144 L 384,232" fill="none" stroke="black"/>
<path d="M 416,80 L 416,144" fill="none" stroke="black"/>
<path d="M 416,240 L 416,304" fill="none" stroke="black"/>
<path d="M 472,112 L 472,416" fill="none" stroke="black"/>
<path d="M 200,0 L 272,0" fill="none" stroke="black"/>
<path d="M 128,32 L 200,32" fill="none" stroke="black"/>
<path d="M 272,32 L 344,32" fill="none" stroke="black"/>
<path d="M 200,64 L 272,64" fill="none" stroke="black"/>
<path d="M 56,80 L 144,80" fill="none" stroke="black"/>
<path d="M 328,80 L 416,80" fill="none" stroke="black"/>
<path d="M 0,112 L 56,112" fill="none" stroke="black"/>
<path d="M 416,112 L 472,112" fill="none" stroke="black"/>
<path d="M 56,144 L 144,144" fill="none" stroke="black"/>
<path d="M 328,144 L 416,144" fill="none" stroke="black"/>
<path d="M 200,160 L 272,160" fill="none" stroke="black"/>
<path d="M 136,192 L 200,192" fill="none" stroke="black"/>
<path d="M 272,192 L 336,192" fill="none" stroke="black"/>
<path d="M 200,224 L 272,224" fill="none" stroke="black"/>
<path d="M 56,240 L 144,240" fill="none" stroke="black"/>
<path d="M 328,240 L 416,240" fill="none" stroke="black"/>
<path d="M 56,304 L 144,304" fill="none" stroke="black"/>
<path d="M 328,304 L 416,304" fill="none" stroke="black"/>
<path d="M 200,368 L 272,368" fill="none" stroke="black"/>
<path d="M 96,384 L 192,384" fill="none" stroke="black"/>
<path d="M 280,384 L 376,384" fill="none" stroke="black"/>
<path d="M 0,416 L 192,416" fill="none" stroke="black"/>
<path d="M 280,416 L 472,416" fill="none" stroke="black"/>
<path d="M 200,432 L 272,432" fill="none" stroke="black"/>
<path d="M 336,192 L 356,232" fill="none" stroke="black"/>
<path d="M 344,32 L 364,72" fill="none" stroke="black"/>
<path d="M 108,72 L 128,32" fill="none" stroke="black"/>
<path d="M 116,232 L 136,192" fill="none" stroke="black"/>
<polygon class="arrowhead" points="392,232 380,226.4 380,237.6 " fill="black" transform="rotate(90,384,232)"/>
<polygon class="arrowhead" points="372,72 360,66.4 360,77.6 " fill="black" transform="rotate(63.43494882292201,364,72)"/>
<polygon class="arrowhead" points="364,232 352,226.4 352,237.6 " fill="black" transform="rotate(63.43494882292201,356,232)"/>
<polygon class="arrowhead" points="288,416 276,410.4 276,421.6 " fill="black" transform="rotate(180,280,416)"/>
<polygon class="arrowhead" points="288,384 276,378.4 276,389.6 " fill="black" transform="rotate(180,280,384)"/>
<polygon class="arrowhead" points="240,360 228,354.4 228,365.6 " fill="black" transform="rotate(90,232,360)"/>
<polygon class="arrowhead" points="240,152 228,146.4 228,157.6 " fill="black" transform="rotate(90,232,152)"/>
<polygon class="arrowhead" points="200,416 188,410.4 188,421.6 " fill="black" transform="rotate(0,192,416)"/>
<polygon class="arrowhead" points="200,384 188,378.4 188,389.6 " fill="black" transform="rotate(0,192,384)"/>
<polygon class="arrowhead" points="124,232 112,226.4 112,237.6 " fill="black" transform="rotate(116.56505117707799,116,232)"/>
<polygon class="arrowhead" points="116,72 104,66.4 104,77.6 " fill="black" transform="rotate(116.56505117707799,108,72)"/>
<polygon class="arrowhead" points="96,232 84,226.4 84,237.6 " fill="black" transform="rotate(90,88,232)"/>
<g class="text">
<text x="160" y="20">send PP</text>
<text x="312" y="20">recv PP</text>
<text x="236" y="36">idle</text>
<text x="276" y="100">send H /</text>
<text x="100" y="116">reserved</text>
<text x="268" y="116">recv H</text>
<text x="372" y="116">reserved</text>
<text x="96" y="132">(local)</text>
<text x="372" y="132">(remote)</text>
<text x="160" y="180">recv ES</text>
<text x="312" y="180">send ES</text>
<text x="52" y="196">send H</text>
<text x="236" y="196">open</text>
<text x="420" y="196">recv H</text>
<text x="100" y="260">half-</text>
<text x="372" y="260">half-</text>
<text x="100" y="276">closed</text>
<text x="276" y="276">send R /</text>
<text x="372" y="276">closed</text>
<text x="100" y="292">(remote)</text>
<text x="268" y="292">recv R</text>
<text x="368" y="292">(local)</text>
<text x="144" y="340">send ES /</text>
<text x="328" y="340">recv ES /</text>
<text x="148" y="356">send R /</text>
<text x="332" y="356">send R /</text>
<text x="140" y="372">recv R</text>
<text x="324" y="372">recv R</text>
<text x="44" y="388">send R /</text>
<text x="428" y="388">send R /</text>
<text x="36" y="404">recv R</text>
<text x="236" y="404">closed</text>
<text x="420" y="404">recv R</text>
</g>
</g>
</svg>
</artwork>
<artwork type="ascii-art"><![CDATA[
+--------+
send PP | | recv PP
,--------+ idle +--------.
/ | | \
v +--------+ v
+----------+ | +----------+
| | | send H / | |
,------+ reserved | | recv H | reserved +------.
| | (local) | | | (remote) | |
| +---+------+ v +------+---+ |
| | +--------+ | |
| | recv ES | | send ES | |
| send H | ,-------+ open +-------. | recv H |
| | / | | \ | |
| v v +---+----+ v v |
| +----------+ | +----------+ |
| | half- | | | half- | |
| | closed | | send R / | closed | |
| | (remote) | | recv R | (local) | |
| +----+-----+ | +-----+----+ |
| | | | |
| | send ES / | recv ES / | |
| | send R / v send R / | |
| | recv R +--------+ recv R | |
| send R / `----------->| |<-----------' send R / |
| recv R | closed | recv R |
`----------------------->| |<-----------------------'
+--------+
]]></artwork>
</artset>
</figure>
<dl spacing="compact">
<dt><tt>send</tt>:</dt>
<dd>endpoint sends this frame</dd>
<dt><tt>recv</tt>:</dt>
<dd>endpoint receives this frame</dd>
<dt><tt>H</tt>:</dt>
<dd><xref target="HEADERS" format="none">HEADERS</xref> frame (with implied <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames)</dd>
<dt><tt>ES</tt>:</dt>
<dd>END_STREAM flag</dd>
<dt><tt>R</tt>:</dt>
<dd><xref target="RST_STREAM" format="none">RST_STREAM</xref> frame</dd>
<dt><tt>PP</tt>:</dt>
<dd><xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame (with implied <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames); state transitions are for the promised stream</dd>
</dl>
<t>Note that this diagram shows stream state transitions and the frames and flags that affect
those transitions only. In this regard, <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames do not result
in state transitions; they are effectively part of the <xref target="HEADERS" format="none">HEADERS</xref> or
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> that they follow. For the purpose of state transitions, the
END_STREAM flag is processed as a separate event to the frame that bears it; a
<xref target="HEADERS" format="none">HEADERS</xref> frame with the END_STREAM flag set can cause two state transitions.</t>
<t>Both endpoints have a subjective view of the state of a stream that could be different
when frames are in transit. Endpoints do not coordinate the creation of streams; they are
created unilaterally by either endpoint. The negative consequences of a mismatch in
states are limited to the "closed" state after sending <xref target="RST_STREAM" format="none">RST_STREAM</xref>, where
frames might be received for some time after closing.</t>
<t>Streams have the following states:</t>
<dl newline="false" spacing="normal">
<dt>idle:</dt>
<dd>
<t>All streams start in the "idle" state.</t>
<t>The following transitions are valid from this state:</t>
<ul spacing="normal">
<li>Sending a <xref target="HEADERS" format="none">HEADERS</xref> frame as a client, or receiving a HEADERS frame
as a server, causes the stream to become "open". The stream identifier is selected as described in
<xref target="StreamIdentifiers"/>. The same <xref target="HEADERS" format="none">HEADERS</xref> frame can also
cause a stream to immediately become "half-closed".</li>
<li>Sending a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame on another stream reserves the idle
stream that is identified for later use. The stream state for the reserved
stream transitions to "reserved (local)". Only a server may send <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames.</li>
<li>Receiving a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame on another stream reserves an idle
stream that is identified for later use. The stream state for the reserved
stream transitions to "reserved (remote)". Only a client may receive <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames.</li>
<li>Note that the <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame is not sent on the idle
stream but references the newly reserved stream in the Promised Stream ID
field.</li>
<li>Opening a stream with a higher-valued stream identifier causes the stream to
transition immediately to a "closed" state; note that this transition is not shown
in the diagram.</li>
</ul>
<t>Receiving any frame other than <xref target="HEADERS" format="none">HEADERS</xref> or <xref target="PRIORITY" format="none">PRIORITY</xref> on
a stream in this state <bcp14>MUST</bcp14> be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. If this stream is initiated by the server, as described in
<xref target="StreamIdentifiers"/>, then receiving a <xref target="HEADERS" format="none">HEADERS</xref> frame <bcp14>MUST</bcp14> also
be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</dd>
<dt>reserved (local):</dt>
<dd>
<t>A stream in the "reserved (local)" state is one that has been promised by sending a
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame. A <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame reserves an
idle stream by associating the stream with an open stream that was initiated by the
remote peer (see <xref target="PushResources"/>).</t>
<t>In this state, only the following transitions are possible:</t>
<ul spacing="normal">
<li>The endpoint can send a <xref target="HEADERS" format="none">HEADERS</xref> frame. This causes the stream to
open in a "half-closed (remote)" state.</li>
<li>Either endpoint can send a <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame to cause the stream
to become "closed". This releases the stream reservation.</li>
</ul>
<t>An endpoint <bcp14>MUST NOT</bcp14> send any type of frame other than <xref target="HEADERS" format="none">HEADERS</xref>,
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, or <xref target="PRIORITY" format="none">PRIORITY</xref> in this state.</t>
<t>A <xref target="PRIORITY" format="none">PRIORITY</xref> or <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frame <bcp14>MAY</bcp14> be received in
this state. Receiving any type of frame other than <xref target="RST_STREAM" format="none">RST_STREAM</xref>,
<xref target="PRIORITY" format="none">PRIORITY</xref>, or <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> on a stream in this state
<bcp14>MUST</bcp14> be treated as a <xref target="ConnectionErrorHandler">connection error</xref>
of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</dd>
<dt>reserved (remote):</dt>
<dd>
<t>A stream in the "reserved (remote)" state has been reserved by a remote peer.</t>
<t>In this state, only the following transitions are possible:</t>
<ul spacing="normal">
<li>Receiving a <xref target="HEADERS" format="none">HEADERS</xref> frame causes the stream to transition to
"half-closed (local)".</li>
<li>Either endpoint can send a <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame to cause the stream
to become "closed". This releases the stream reservation.</li>
</ul>
<t>An endpoint <bcp14>MUST NOT</bcp14> send any type of frame other than <xref target="RST_STREAM" format="none">RST_STREAM</xref>, <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, or <xref target="PRIORITY" format="none">PRIORITY</xref> in this state.</t>
<t>Receiving any type of frame other than <xref target="HEADERS" format="none">HEADERS</xref>,
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, or <xref target="PRIORITY" format="none">PRIORITY</xref> on a stream in this state <bcp14>MUST</bcp14>
be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</dd>
<dt>open:</dt>
<dd>
<t>A stream in the "open" state may be used by both peers to send frames of any type.
In this state, sending peers observe advertised <xref target="FlowControl">stream-level
flow-control limits</xref>.</t>
<t>From this state, either endpoint can send a frame with an END_STREAM flag set, which
causes the stream to transition into one of the "half-closed" states. An endpoint
sending an END_STREAM flag causes the stream state to become "half-closed (local)";
an endpoint receiving an END_STREAM flag causes the stream state to become "half-closed
(remote)".</t>
<t>Either endpoint can send a <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame from this state, causing
it to transition immediately to "closed".</t>
</dd>
<dt>half-closed (local):</dt>
<dd>
<t>A stream that is in the "half-closed (local)" state cannot be used for sending
frames other than <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, <xref target="PRIORITY" format="none">PRIORITY</xref>, and
<xref target="RST_STREAM" format="none">RST_STREAM</xref>.</t>
<t>A stream transitions from this state to "closed" when a frame is received with the
END_STREAM flag set or when either peer sends a <xref target="RST_STREAM" format="none">RST_STREAM</xref>
frame.</t>
<t>An endpoint can receive any type of frame in this state. Providing flow-control
credit using <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frames is necessary to continue receiving
flow-controlled frames. In this state, a receiver can ignore <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frames,
which might arrive for a short period after a frame with the END_STREAM flag set is sent.</t>
<t><xref target="PRIORITY" format="none">PRIORITY</xref> frames can be received in this state.</t>
</dd>
<dt>half-closed (remote):</dt>
<dd>
<t>A stream that is "half-closed (remote)" is no longer being used by the peer to send
frames. In this state, an endpoint is no longer obligated to maintain a receiver
flow-control window.</t>
<t>If an endpoint receives additional frames, other
than <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, <xref target="PRIORITY" format="none">PRIORITY</xref>, or
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, for a stream that is in this state, it <bcp14>MUST</bcp14> respond with a <xref target="StreamErrorHandler">stream error</xref> of type
<xref target="STREAM_CLOSED" format="none">STREAM_CLOSED</xref>.</t>
<t>A stream that is "half-closed (remote)" can be used by the endpoint to send frames
of any type. In this state, the endpoint continues to observe advertised <xref target="FlowControl">stream-level flow-control limits</xref>.</t>
<t>A stream can transition from this state to "closed" by sending a frame with the
END_STREAM flag set or when either peer sends a <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame.</t>
</dd>
<dt>closed:</dt>
<dd>
<t>The "closed" state is the terminal state.</t>
<t>A stream enters the "closed" state after an endpoint both sends and receives a frame
with an END_STREAM flag set. A stream also enters the "closed" state after an endpoint
either sends or receives a <xref target="RST_STREAM" format="none">RST_STREAM</xref>
frame.</t>
<t>An endpoint <bcp14>MUST NOT</bcp14> send frames other than <xref target="PRIORITY" format="none">PRIORITY</xref> on a closed stream. An endpoint <bcp14>MAY</bcp14> treat receipt of
any other type of frame on a closed stream as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="STREAM_CLOSED" format="none">STREAM_CLOSED</xref>, except as noted below.</t>
<t>An endpoint that sends a frame with the END_STREAM flag set or a <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame might receive a <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> or <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame from its peer in the time before the peer
receives and processes the frame that closes the stream.</t>
<t>An endpoint that sends a <xref target="RST_STREAM" format="none">RST_STREAM</xref>
frame on a stream that is in the "open" or "half-closed (local)" state could receive any type of frame. The
peer might have sent or enqueued for sending these frames before processing the <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame. An endpoint <bcp14>MUST</bcp14> minimally
process and then discard any frames it receives in this state. This means updating
header compression state for <xref target="HEADERS" format="none">HEADERS</xref> and
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames. Receiving a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame also causes the promised
stream to become "reserved (remote)", even when the <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame is received on a closed stream. Additionally, the
content of <xref target="DATA" format="none">DATA</xref> frames counts toward the
connection flow-control window.</t>
<t>An endpoint can perform this minimal processing for all streams that are in the
"closed" state. Endpoints <bcp14>MAY</bcp14> use other signals to detect that a peer has received
the frames that caused the stream to enter the "closed" state and treat receipt of any frame other
than <xref target="PRIORITY" format="none">PRIORITY</xref> as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Endpoints can use frames
that indicate that the peer has received the closing signal to drive this. Endpoints
<bcp14>SHOULD NOT</bcp14> use timers for this purpose. For example, an endpoint that sends a <xref target="SETTINGS" format="none">SETTINGS</xref> frame after closing a stream can
safely treat receipt of a <xref target="DATA" format="none">DATA</xref> frame on that
stream as an error after receiving an acknowledgment of the settings. Other things
that might be used are <xref target="PING" format="none">PING</xref> frames, receiving
data on streams that were created after closing the stream, or responses to requests
created after closing the stream.</t>
</dd>
</dl>
<t>In the absence of more specific rules, implementations <bcp14>SHOULD</bcp14> treat the receipt of a frame
that is not expressly permitted in the description of a state as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Note that <xref target="PRIORITY" format="none">PRIORITY</xref> can be sent and received in any stream
state.</t>
<t>The rules in this section only apply to frames defined in this document. Receipt of
frames for which the semantics are unknown cannot be treated as an error, as the conditions
for sending and receiving those frames are also unknown; see <xref target="extensibility"/>.</t>
<t>An example of the state transitions for an HTTP request/response exchange can be found in
<xref target="HttpExamples"/>. An example of the state transitions for server push can be
found in Sections <xref target="PushRequests" format="counter"/> and <xref target="PushResponses" format="counter"/>.</t>
<section anchor="StreamIdentifiers">
<name>Stream Identifiers</name>
<t>Streams are identified by an unsigned 31-bit integer. Streams initiated by a client
<bcp14>MUST</bcp14> use odd-numbered stream identifiers; those initiated by the server <bcp14>MUST</bcp14> use
even-numbered stream identifiers. A stream identifier of zero (0x00) is used for
connection control messages; the stream identifier of zero cannot be used to establish a
new stream.</t>
<t>The identifier of a newly established stream <bcp14>MUST</bcp14> be numerically greater than all
streams that the initiating endpoint has opened or reserved. This governs streams that
are opened using a <xref target="HEADERS" format="none">HEADERS</xref> frame and streams that are reserved using
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>. An endpoint that receives an unexpected stream identifier
<bcp14>MUST</bcp14> respond with a <xref target="ConnectionErrorHandler">connection error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
<t>A <xref target="HEADERS" format="none">HEADERS</xref> frame will transition the client-initiated stream identified
by the stream identifier in the frame header from "idle" to "open". A <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>
frame will transition the server-initiated stream identified by the Promised Stream ID field in the frame payload from "idle" to "reserved (local)" or "reserved (remote)". When
a stream transitions out of the "idle" state, all streams in the "idle" state that might have been opened by the peer with a lower-valued
stream identifier immediately transition to "closed". That is, an endpoint may skip a stream identifier, with the
effect being that the skipped stream is immediately closed.</t>
<t>Stream identifiers cannot be reused. Long-lived connections can result in an endpoint
exhausting the available range of stream identifiers. A client that is unable to
establish a new stream identifier can establish a new connection for new streams. A
server that is unable to establish a new stream identifier can send a
<xref target="GOAWAY" format="none">GOAWAY</xref> frame so that the client is forced to open a new connection for
new streams.</t>
</section>
<section>
<name>Stream Concurrency</name>
<t>A peer can limit the number of concurrently active streams using the
<xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTINGS_MAX_CONCURRENT_STREAMS</xref> parameter (see <xref target="SettingValues"/>) within a <xref target="SETTINGS" format="none">SETTINGS</xref> frame. The maximum concurrent
streams setting is specific to each endpoint and applies only to the peer that receives
the setting. That is, clients specify the maximum number of concurrent streams the
server can initiate, and servers specify the maximum number of concurrent streams the
client can initiate.</t>
<t>Streams that are in the "open" state or in either of the "half-closed" states count toward
the maximum number of streams that an endpoint is permitted to open. Streams in any of
these three states count toward the limit advertised in the
<xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTINGS_MAX_CONCURRENT_STREAMS</xref> setting. Streams in either of the
"reserved" states do not count toward the stream limit.</t>
<t>Endpoints <bcp14>MUST NOT</bcp14> exceed the limit set by their peer. An endpoint that receives a
<xref target="HEADERS" format="none">HEADERS</xref> frame that causes its advertised concurrent stream limit to be
exceeded <bcp14>MUST</bcp14> treat this as a <xref target="StreamErrorHandler">stream error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref> or <xref target="REFUSED_STREAM" format="none">REFUSED_STREAM</xref>. The choice of
error code determines whether the endpoint wishes to enable automatic retry (see <xref target="Reliability"/> for details).</t>
<t>An endpoint that wishes to reduce the value of
<xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTINGS_MAX_CONCURRENT_STREAMS</xref> to a value that is below the current
number of open streams can either close streams that exceed the new value or allow
streams to complete.</t>
</section>
</section>
<section anchor="FlowControl">
<name>Flow Control</name>
<t>Using streams for multiplexing introduces contention over use of the TCP connection,
resulting in blocked streams. A flow-control scheme ensures that streams on the same
connection do not destructively interfere with each other. Flow control is used for both
individual streams and the connection as a whole.</t>
<t>HTTP/2 provides for flow control through use of the <xref target="WINDOW_UPDATE">WINDOW_UPDATE frame</xref>.</t>
<section anchor="fc-principles">
<name>Flow-Control Principles</name>
<t>HTTP/2 stream flow control aims to allow a variety of flow-control algorithms to be
used without requiring protocol changes. Flow control in HTTP/2 has the following
characteristics:</t>
<ol spacing="normal" type="1">
<li>Flow control is specific to a connection. HTTP/2 flow control operates between
the endpoints of a single hop and not over the entire end-to-end path.</li>
<li>Flow control is based on <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frames. Receivers advertise how many octets
they are prepared to receive on a stream and for the entire connection. This is a
credit-based scheme.</li>
<li>Flow control is directional with overall control provided by the receiver. A
receiver <bcp14>MAY</bcp14> choose to set any window size that it desires for each stream and for
the entire connection. A sender <bcp14>MUST</bcp14> respect flow-control limits imposed by a
receiver. Clients, servers, and intermediaries all independently advertise their
flow-control window as a receiver and abide by the flow-control limits set by
their peer when sending.</li>
<li>The initial value for the flow-control window is 65,535 octets for both new streams
and the overall connection.</li>
<li>The frame type determines whether flow control applies to a frame. Of the frames
specified in this document, only <xref target="DATA" format="none">DATA</xref> frames are subject to flow
control; all other frame types do not consume space in the advertised flow-control
window. This ensures that important control frames are not blocked by flow control.</li>
<li>An endpoint can choose to disable its own flow control, but an endpoint cannot ignore
flow-control signals from its peer.</li>
<li>HTTP/2 defines only the format and semantics of the <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>
frame (<xref target="WINDOW_UPDATE"/>). This document does not stipulate how a
receiver decides when to send this frame or the value that it sends, nor does it
specify how a sender chooses to send packets. Implementations are able to select
any algorithm that suits their needs.</li>
</ol>
<t>Implementations are also responsible for prioritizing the sending of requests and
responses, choosing how to avoid head-of-line blocking for requests, and managing the
creation of new streams. Algorithm choices for these could interact with any
flow-control algorithm.</t>
</section>
<section anchor="DisableFlowControl">
<name>Appropriate Use of Flow Control</name>
<t>Flow control is defined to protect endpoints that are operating under resource
constraints. For example, a proxy needs to share memory between many connections and
also might have a slow upstream connection and a fast downstream one. Flow control
addresses cases where the receiver is unable to process data on one stream yet wants to
continue to process other streams in the same connection.</t>
<t>Deployments that do not require this capability can advertise a flow-control window of
the maximum size (2<sup>31</sup>-1) and can maintain this window by sending a
<xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frame when any data is received. This effectively disables
flow control for that receiver. Conversely, a sender is always subject to the
flow-control window advertised by the receiver.</t>
<t>Deployments with constrained resources (for example, memory) can employ flow control to
limit the amount of memory a peer can consume. Note, however, that this can lead to
suboptimal use of available network resources if flow control is enabled without
knowledge of the bandwidth * delay product (see <xref target="RFC7323"/>).</t>
<t>Even with full awareness of the current bandwidth * delay product, implementation of
flow control can be difficult. Endpoints <bcp14>MUST</bcp14> read and process HTTP/2 frames from the
TCP receive buffer as soon as data is available. Failure to read promptly could lead to
a deadlock when critical frames, such as <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, are not read and acted upon. Reading frames promptly
does not expose endpoints to resource exhaustion attacks, as HTTP/2 flow control limits
resource commitments.</t>
</section>
<section anchor="FlowControlPerformance">
<name>Flow-Control Performance</name>
<t>If an endpoint cannot ensure that its peer always has available flow-control window
space that is greater than the peer's bandwidth * delay product on this connection, its
receive throughput will be limited by HTTP/2 flow control. This will result in degraded
performance.</t>
<t>Sending timely <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frames
can improve performance. Endpoints will want to balance the need to improve receive
throughput with the need to manage resource exhaustion risks and should take careful
note of <xref target="dos"/> in defining their strategy to manage window sizes.</t>
</section>
</section>
<section anchor="StreamPriority">
<name>Prioritization</name>
<t>In a multiplexed protocol like HTTP/2, prioritizing allocation of bandwidth and
computation resources to streams can be critical to attaining good performance. A poor
prioritization scheme can result in HTTP/2 providing poor performance. With no parallelism
at the TCP layer, performance could be significantly worse than HTTP/1.1.</t>
<t>A good prioritization scheme benefits from the application of contextual knowledge such as
the content of resources, how resources are interrelated, and how those resources will be
used by a peer. In particular, clients can possess knowledge about the priority of
requests that is relevant to server prioritization. In those cases, having clients
provide priority information can improve performance.</t>
<section anchor="PriorityHistory">
<name>Background on Priority in RFC 7540</name>
<t>RFC 7540 defined a rich system for signaling priority of requests. However, this system
proved to be complex, and it was not uniformly implemented.</t>
<t>The flexible scheme meant that it was possible for clients to express priorities in very
different ways, with little consistency in the approaches that were adopted. For
servers, implementing generic support for the scheme was complex. Implementation of
priorities was uneven in both clients and servers. Many server deployments ignored
client signals when prioritizing their handling of requests.</t>
<t>In short, the prioritization signaling in <xref target="RFC7540">RFC 7540</xref> was not
successful.</t>
</section>
<section anchor="PriorityHere">
<name>Priority Signaling in This Document</name>
<t>This update to HTTP/2 deprecates the priority signaling defined in <xref target="RFC7540">RFC 7540</xref>. The bulk of the text related to priority signals is
not included in this document. The description of frame fields and some of the
mandatory handling is retained to ensure that implementations of this document remain
interoperable with implementations that use the priority signaling described in RFC
7540.</t>
<t>A thorough description of the RFC 7540 priority scheme remains in <xref target="RFC7540" section="5.3"/>.</t>
<t>Signaling priority information is necessary to attain good performance in many cases.
Where signaling priority information is important, endpoints are encouraged to use an
alternative scheme, such as the scheme described in <xref target="RFC9218"/>.</t>
<t>Though the priority signaling from RFC 7540 was not widely adopted, the information it
provides can still be useful in the absence of better information. Endpoints that
receive priority signals in <xref target="HEADERS" format="none">HEADERS</xref> or <xref target="PRIORITY" format="none">PRIORITY</xref> frames can benefit from applying that
information. In particular, implementations that consume these signals would not
benefit from discarding these priority signals in the absence of alternatives.</t>
<t>Servers <bcp14>SHOULD</bcp14> use other contextual information in determining priority of requests in
the absence of any priority signals. Servers <bcp14>MAY</bcp14> interpret the complete absence of
signals as an indication that the client has not implemented the feature. The defaults
described in <xref target="RFC7540" section="5.3.5"/> are known to have poor performance
under most conditions, and their use is unlikely to be deliberate.</t>
</section>
</section>
<section anchor="ErrorHandler">
<name>Error Handling</name>
<t>HTTP/2 framing permits two classes of errors:</t>
<ul spacing="normal">
<li>An error condition that renders the entire connection unusable is a connection error.</li>
<li>An error in an individual stream is a stream error.</li>
</ul>
<t>A list of error codes is included in <xref target="ErrorCodes"/>.</t>
<t>It is possible that an endpoint will encounter frames that would cause multiple errors. Implementations <bcp14>MAY</bcp14> discover
multiple errors during processing, but they <bcp14>SHOULD</bcp14> report at most one stream and one connection error as a result.</t>
<t>The first stream error reported for a given stream prevents any other errors on that stream from being reported.
In comparison, the protocol permits multiple <xref target="GOAWAY" format="none">GOAWAY</xref> frames, though an
endpoint <bcp14>SHOULD</bcp14> report just one type of connection error unless an error is encountered during graceful shutdown.
If this occurs, an endpoint <bcp14>MAY</bcp14> send an additional GOAWAY frame with the new error code, in addition to any prior
GOAWAY that contained <xref target="NO_ERROR" format="none">NO_ERROR</xref>.</t>
<t>If an endpoint detects multiple different errors, it <bcp14>MAY</bcp14> choose to report any one of those
errors. If a frame causes a connection error, that error <bcp14>MUST</bcp14> be reported. Additionally,
an endpoint <bcp14>MAY</bcp14> use any applicable error code when it detects an error condition; a
generic error code (such as <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref> or <xref target="INTERNAL_ERROR" format="none">INTERNAL_ERROR</xref>) can always be used in place of more specific error
codes.</t>
<section anchor="ConnectionErrorHandler">
<name>Connection Error Handling</name>
<t>A connection error is any error that prevents further processing of the frame
layer or corrupts any connection state.</t>
<t>An endpoint that encounters a connection error <bcp14>SHOULD</bcp14> first send a <xref target="GOAWAY" format="none">GOAWAY</xref>
frame (<xref target="GOAWAY"/>) with the stream identifier of the last stream that it
successfully received from its peer. The <xref target="GOAWAY" format="none">GOAWAY</xref> frame includes an <xref target="ErrorCodes">error
code</xref> that indicates why the connection is terminating. After sending the
<xref target="GOAWAY" format="none">GOAWAY</xref> frame for an error condition, the endpoint <bcp14>MUST</bcp14> close the TCP
connection.</t>
<t>It is possible that the <xref target="GOAWAY" format="none">GOAWAY</xref> will not be reliably received by the
receiving endpoint. In the event of a connection error,
<xref target="GOAWAY" format="none">GOAWAY</xref> only provides a best-effort attempt to communicate with the peer
about why the connection is being terminated.</t>
<t>An endpoint can end a connection at any time. In particular, an endpoint <bcp14>MAY</bcp14> choose to
treat a stream error as a connection error. Endpoints <bcp14>SHOULD</bcp14> send a
<xref target="GOAWAY" format="none">GOAWAY</xref> frame when ending a connection, providing that circumstances
permit it.</t>
</section>
<section anchor="StreamErrorHandler">
<name>Stream Error Handling</name>
<t>A stream error is an error related to a specific stream that does not affect processing
of other streams.</t>
<t>An endpoint that detects a stream error sends a <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame (<xref target="RST_STREAM"/>) that contains the stream identifier of the stream where the error
occurred. The <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame includes an error code that indicates the
type of error.</t>
<t>A <xref target="RST_STREAM" format="none">RST_STREAM</xref> is the last frame that an endpoint can send on a stream.
The peer that sends the <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame <bcp14>MUST</bcp14> be prepared to receive any
frames that were sent or enqueued for sending by the remote peer. These frames can be
ignored, except where they modify connection state (such as the state maintained for
<xref target="FieldBlock">field section compression</xref> or flow control).</t>
<t>Normally, an endpoint <bcp14>SHOULD NOT</bcp14> send more than one <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame for
any stream. However, an endpoint <bcp14>MAY</bcp14> send additional <xref target="RST_STREAM" format="none">RST_STREAM</xref> frames if
it receives frames on a closed stream after more than a round-trip time. This behavior
is permitted to deal with misbehaving implementations.</t>
<t>To avoid looping, an endpoint <bcp14>MUST NOT</bcp14> send a <xref target="RST_STREAM" format="none">RST_STREAM</xref> in response to a
<xref target="RST_STREAM" format="none">RST_STREAM</xref> frame.</t>
</section>
<section>
<name>Connection Termination</name>
<t>If the TCP connection is closed or reset while streams remain in the "open" or "half-closed"
states, then the affected streams cannot be automatically retried (see <xref target="Reliability"/> for details).</t>
</section>
</section>
<section anchor="extensibility">
<name>Extending HTTP/2</name>
<t>HTTP/2 permits extension of the protocol. Within the limitations described in this
section, protocol extensions can be used to provide additional services or alter
any aspect of the protocol. Extensions are effective only within the scope of a single HTTP/2