forked from httpwg/http2-spec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-httpbis-http2bis.xml
5075 lines (5022 loc) · 264 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"?>
<?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:x="http://purl.org/net/xml2rfc/ext" ipr="trust200902" category="std" docName="draft-ietf-httpbis-http2bis-latest" tocInclude="true" symRefs="true" sortRefs="true" version="3" submissionType="IETF" obsoletes="7540,8740">
<!--
<x:feedback template="mailto:[email protected]?subject={docname},%20%22{section}%22&body=<{ref}>:"/>
-->
<front>
<title abbrev="HTTP/2">Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-latest"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
<organization>Mozilla</organization>
<address>
<postal>
<country>Australia</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="C." surname="Benfield" fullname="Cory Benfield" role="editor">
<organization>Apple Inc.</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<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 perception of latency by introducing header field compression and allowing multiple
concurrent exchanges on the same connection.
</t>
<t>
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.
HTTP's existing semantics remain unchanged. This document obsoletes RFC 7540 and RFC 8740.
</t>
</abstract>
<note title="Discussion Venues" removeInRFC="true">
<t>
Discussion of this document takes place on the HTTPBIS Working Group mailing list
([email protected]), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
</t>
<t>
Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http2-spec"/>.
</t>
</note>
</front>
<middle>
<section anchor="intro">
<name>Introduction</name>
<t>
The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the way
HTTP/1.1 uses the underlying transport (<xref target="HTTP11"/>) has several
characteristics that have a negative overall effect on application performance today.
</t>
<t>
In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP
connection. HTTP/1.1 added request pipelining, but this only partially addressed request
concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1
clients that need to make many requests use multiple connections to a server in order to
achieve concurrency and thereby reduce latency.
</t>
<t>
Furthermore, HTTP header fields are often repetitive and verbose, causing unnecessary
network traffic as well as causing the initial TCP <xref target="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 request and response
messages on the same connection and uses an efficient coding for HTTP header 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.
</t>
<t>
Finally, HTTP/2 also enables more efficient processing of messages through use of binary
message framing.
</t>
<t>
This document obsoletes <xref target="RFC7540">RFC 7540</xref> and <xref target="RFC8740">RFC 8740</xref>.
</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>
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>
Flow control and prioritization ensure that it is possible to efficiently use multiplexed
streams. <xref target="FlowControl">Flow control</xref> helps to ensure that only data that
can be used by a receiver is transmitted. <xref target="StreamPriority">Prioritization</xref> ensures that limited resources can be directed
to the most important streams first.
</t>
<t>
Because HTTP header 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 the HTTP protocol and server push.
</t>
</section>
<section>
<name>Conventions and Terminology</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119">RFC 2119</xref>.
</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 convention described in <xref
target="QUIC" section="1.3">RFC 9000</xref>. Note that this format uses network byte
order and 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="HTTP" 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="HTTP" section="6.4"/>.
</t>
</section>
</section>
<section anchor="starting">
<name>Starting HTTP/2</name>
<t>
An HTTP/2 connection is an application-layer protocol running on top of a TCP connection
(<xref target="TCP"/>). The client is the TCP connection initiator.
</t>
<t>
HTTP/2 uses the "http" and "https" URI schemes defined in <xref target="HTTP" section="4.2"/>, with the same default port numbers. As a result,
implementations processing requests for target resource URIs like <tt>http://example.org/foo</tt> or <tt>https://example.com/bar</tt> are required to first discover whether the
upstream server (the immediate peer to which the client wishes to establish a connection)
supports HTTP/2.
</t>
<t>
The means by which support for HTTP/2 is determined is different for "http" and "https"
URIs. Discovery for "https" URIs is described in <xref target="discover-https"/>. HTTP/2
support for "http" 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.
</t>
<ul spacing="normal">
<li>
<t>
The string "h2" identifies the protocol where HTTP/2 uses <xref target="TLS13">Transport Layer Security (TLS)</xref>. This identifier is used in the <xref target="TLS-ALPN">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 string "h2c" identifies the protocol where HTTP/2 is run over cleartext TCP.
This identifier is used in any place where HTTP/2 over TCP is identified.
</t>
<t>
The "h2c" string is reserved from the ALPN identifier space but describes a
protocol that does not use TLS.
</t>
<t>
The "h2c" string was previously used as a token for use in the HTTP Upgrade mechanism's
Upgrade header field (<xref target="HTTP" section="7.8"/>). This usage was never widely
deployed, and is no longer specified in this document.
</t>
</li>
</ul>
<t>
Negotiating "h2" or "h2c" implies the use of the transport, security, framing, and message
semantics described in this document.
</t>
</section>
<section anchor="discover-https">
<name>Starting HTTP/2 for "https" URIs</name>
<t>
A client that makes a request to an "https" URI uses <xref target="TLS13">TLS</xref> with
the <xref target="TLS-ALPN">application-layer protocol negotiation (ALPN)
extension</xref>.
</t>
<t>
HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" protocol identifier MUST NOT
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 MUST send a <xref target="ConnectionHeader">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,
<xref target="ALT-SVC"/> describes a mechanism for advertising this capability.
</t>
<t>
A client MUST send the <xref target="ConnectionHeader">connection preface</xref> and
then MAY immediately send HTTP/2 frames to such a server; servers can identify these
connections by the presence of the connection preface. This only affects the
establishment of HTTP/2 connections over cleartext TCP; implementations that support
HTTP/2 over TLS MUST use <xref target="TLS-ALPN">protocol negotiation in TLS</xref>.
</t>
<t>
Likewise, the server MUST send a <xref target="ConnectionHeader">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="ConnectionHeader">
<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
MUST be followed by a <xref target="SETTINGS" format="none">SETTINGS</xref> frame (<xref target="SETTINGS"/>), which
MAY 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 MUST 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
MUST 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 MUST 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"/>)
MAY 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. Values
greater than 2<sup>14</sup> (16,384) MUST NOT 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. Implementations MUST ignore and discard any frame that has a type that
is unknown.
</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, and MUST be ignored and MUST be left
unset (0x0) when sending.
</t>
</dd>
<dt>Reserved:</dt>
<dd>
<t>
A reserved 1-bit field. The semantics of this bit are undefined, and the bit MUST
remain unset (0x0) when sending and MUST 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 0x0 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 is 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 MUST 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 MUST 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 MUST 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>), <xref target="SETTINGS" format="none">SETTINGS</xref>,
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 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 is
defined in <xref target="COMPRESSION"/>, which, for historical reasons, refers to these
processes as header compression and decompression.
</t>
<t>
Field blocks carry the compressed bytes of a field section, with header sections
also carrying 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: Previous versions of this specification 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 zero or more field lines. Each of the field lines in a
field block carry a single value. The serialized field block is then divided into one or
more octet sequences, called field block fragments, and 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.
</t>
<t>
The <xref target="COOKIE">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 cleared 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>
Field compression is stateful. One compression context and one decompression context are
used for the entire connection. A decoding error in a field block MUST be treated as a
<xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref>.
</t>
<t>
Each field block is processed as a discrete unit.
Field blocks MUST 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 MUST 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>
</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 the client or
server.
</li>
<li>
Streams can be closed by either endpoint.
</li>
<li>
The order in which frames are sent on a stream 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>
<artwork type="drawing"><![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 |
`----------------------->| |<----------------------'
+--------+
send: endpoint sends this frame
recv: endpoint receives this frame
H: HEADERS frame (with implied CONTINUATIONs)
ES: END_STREAM flag
R: RST_STREAM frame
PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
Note: State transitions are for the promised stream.
]]></artwork>
</figure>
<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 or receiving a <xref target="HEADERS" format="none">HEADERS</xref> frame 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)".
</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)".
</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>
</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 MUST 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 MUST NOT 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 MAY 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
MUST 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 MUST NOT 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 MUST
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 that contains an
END_STREAM flag is received 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 bearing the
END_STREAM flag 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 MUST 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 that contains
an END_STREAM flag 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>
An 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 MUST NOT send frames other than <xref target="PRIORITY" format="none">PRIORITY</xref> on a closed stream. An endpoint MAY 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" 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 MUST 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; <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames also cause the promised
stream to become "reserved", even when the <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame is received on a closed stream; and, 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 MAY use other signals to detect that a peer has received
the frames that caused stream to become "closed" 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
SHOULD NOT 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 acknowledgement 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 guidance elsewhere in this document, implementations
SHOULD 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. Frames of unknown types are ignored.
</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 with an unsigned 31-bit integer. Streams initiated by a client
MUST use odd-numbered stream identifiers; those initiated by the server MUST use
even-numbered stream identifiers. A stream identifier of zero (0x0) 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 MUST 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
MUST 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". When
a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued
stream identifier are implicitly transitioned 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 MUST NOT 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 MUST 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 for 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