< draft-ietf-httpbis-http2bis-05.txt   draft-ietf-httpbis-http2bis-06.txt >
HTTPbis M. Thomson, Ed. HTTPbis M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Obsoletes: 7540, 8740 (if approved) C. Benfield, Ed. Obsoletes: 7540, 8740 (if approved) C. Benfield, Ed.
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: 30 March 2022 26 September 2021 Expires: 22 May 2022 18 November 2021
Hypertext Transfer Protocol Version 2 (HTTP/2) Hypertext Transfer Protocol Version 2 (HTTP/2)
draft-ietf-httpbis-http2bis-05 draft-ietf-httpbis-http2bis-06
Abstract Abstract
This specification describes an optimized expression of the semantics This specification describes an optimized expression of the semantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
version 2 (HTTP/2). HTTP/2 enables a more efficient use of network version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
resources and a reduced latency by introducing field compression and resources and a reduced latency by introducing field compression and
allowing multiple concurrent exchanges on the same connection. allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFC 7540 and RFC 8740. This document obsoletes RFC 7540 and RFC 8740.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 March 2022. This Internet-Draft will expire on 22 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. HTTP/2 Protocol Overview . . . . . . . . . . . . . . . . . . 5 2. HTTP/2 Protocol Overview . . . . . . . . . . . . . . . . . . 5
2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6
2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6
3. Starting HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7 3. Starting HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. HTTP/2 Version Identification . . . . . . . . . . . . . . 8 3.1. HTTP/2 Version Identification . . . . . . . . . . . . . . 8
3.2. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 8 3.2. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 8
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Field Section Compression and Decompression . . . . . . . 12 4.3. Field Section Compression and Decompression . . . . . . . 12
5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 13 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 13
5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 19 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 19
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 20 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 20
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Flow-Control Principles . . . . . . . . . . . . . . . 20 5.2.1. Flow-Control Principles . . . . . . . . . . . . . . . 20
5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22
5.2.3. Flow Control Performance . . . . . . . . . . . . . . 22 5.2.3. Flow Control Performance . . . . . . . . . . . . . . 22
5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 22 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. Background of Priority in HTTP/2 . . . . . . . . . . 23 5.3.1. Background of Priority in HTTP/2 . . . . . . . . . . 23
5.3.2. Priority Signaling in this Document . . . . . . . . . 23 5.3.2. Priority Signaling in this Document . . . . . . . . . 23
5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 24 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 24
5.4.1. Connection Error Handling . . . . . . . . . . . . . . 24 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 25
5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 25 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 25
5.4.3. Connection Termination . . . . . . . . . . . . . . . 25 5.4.3. Connection Termination . . . . . . . . . . . . . . . 26
5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 26 5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 26
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 27 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 27
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 31 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 32 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 32
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 33 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 34 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 34
6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . 35 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . 35
6.5.3. Settings Synchronization . . . . . . . . . . . . . . 36 6.5.3. Settings Synchronization . . . . . . . . . . . . . . 36
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 37 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 37
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 44 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 43
6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 45 6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 45
6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 46 6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 46
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 47 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 47
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 47 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 47
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 48
8. Expressing HTTP Semantics in HTTP/2 . . . . . . . . . . . . . 50 8. Expressing HTTP Semantics in HTTP/2 . . . . . . . . . . . . . 50
8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 50 8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 50
8.1.1. Malformed Messages . . . . . . . . . . . . . . . . . 51 8.1.1. Malformed Messages . . . . . . . . . . . . . . . . . 51
8.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . . 52 8.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . . 52
8.2.1. Field Validity . . . . . . . . . . . . . . . . . . . 53 8.2.1. Field Validity . . . . . . . . . . . . . . . . . . . 52
8.2.2. Connection-Specific Header Fields . . . . . . . . . . 54 8.2.2. Connection-Specific Header Fields . . . . . . . . . . 54
8.2.3. Compressing the Cookie Header Field . . . . . . . . . 54 8.2.3. Compressing the Cookie Header Field . . . . . . . . . 54
8.3. HTTP Control Data . . . . . . . . . . . . . . . . . . . . 55 8.3. HTTP Control Data . . . . . . . . . . . . . . . . . . . . 55
8.3.1. Request Pseudo-Header Fields . . . . . . . . . . . . 55 8.3.1. Request Pseudo-Header Fields . . . . . . . . . . . . 55
8.3.2. Response Pseudo-Header Fields . . . . . . . . . . . . 57 8.3.2. Response Pseudo-Header Fields . . . . . . . . . . . . 57
8.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 57 8.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 57
8.4.1. Push Requests . . . . . . . . . . . . . . . . . . . . 59 8.4.1. Push Requests . . . . . . . . . . . . . . . . . . . . 59
8.4.2. Push Responses . . . . . . . . . . . . . . . . . . . 60 8.4.2. Push Responses . . . . . . . . . . . . . . . . . . . 60
8.5. The CONNECT Method . . . . . . . . . . . . . . . . . . . 61 8.5. The CONNECT Method . . . . . . . . . . . . . . . . . . . 61
8.6. The Upgrade Header Field . . . . . . . . . . . . . . . . 62 8.6. The Upgrade Header Field . . . . . . . . . . . . . . . . 62
skipping to change at page 6, line 30 skipping to change at page 6, line 30
* Frame (Section 6) and error (Section 7) definitions include * Frame (Section 6) and error (Section 7) definitions include
details of the frame and error types used in HTTP/2. details of the frame and error types used in HTTP/2.
* HTTP mappings (Section 8) and additional requirements (Section 9) * HTTP mappings (Section 8) and additional requirements (Section 9)
describe how HTTP semantics are expressed using frames and describe how HTTP semantics are expressed using frames and
streams. streams.
While some of the frame and stream layer concepts are isolated from While some of the frame and stream layer concepts are isolated from
HTTP, this specification does not define a completely generic frame HTTP, this specification does not define a completely generic frame
layer. The frame and stream layers are tailored to the needs of the layer. The frame and stream layers are tailored to the needs of the
HTTP protocol and server push. HTTP protocol.
2.2. Conventions and Terminology 2.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
All numeric values are in network byte order. Values are unsigned All numeric values are in network byte order. Values are unsigned
unless otherwise indicated. Literal values are provided in decimal unless otherwise indicated. Literal values are provided in decimal
or hexadecimal as appropriate. Hexadecimal literals are prefixed or hexadecimal as appropriate. Hexadecimal literals are prefixed
with 0x to distinguish them from decimal literals. with "0x" to distinguish them from decimal literals.
This specification describes binary formats using the convention This specification describes binary formats using the convention
described in Section 1.3 of RFC 9000 [QUIC]. Note that this format described in Section 1.3 of RFC 9000 [QUIC]. Note that this format
uses network byte order and high-valued bits are listed before low- uses network byte order and high-valued bits are listed before low-
valued bits. valued bits.
The following terms are used: The following terms are used:
client: The endpoint that initiates an HTTP/2 connection. Clients client: The endpoint that initiates an HTTP/2 connection. Clients
send HTTP requests and receive HTTP responses. send HTTP requests and receive HTTP responses.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
In HTTP/2, each endpoint is required to send a connection preface as 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 a final confirmation of the protocol in use and to establish the
initial settings for the HTTP/2 connection. The client and server initial settings for the HTTP/2 connection. The client and server
each send a different connection preface. each send a different connection preface.
The client connection preface starts with a sequence of 24 octets, The client connection preface starts with a sequence of 24 octets,
which in hex notation is: which in hex notation is:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
That is, the connection preface starts with the string PRI * That is, the connection preface starts with the string "PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n. This sequence MUST be followed by a HTTP/2.0\r\n\r\nSM\r\n\r\n". This sequence MUST be followed by a
SETTINGS frame (Section 6.5), which MAY be empty. The client sends SETTINGS frame (Section 6.5), which MAY be empty. The client sends
the client connection preface as the first application data octets of the client connection preface as the first application data octets of
a connection. a connection.
| Note: The client connection preface is selected so that a large | Note: The client connection preface is selected so that a large
| proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries | proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries
| do not attempt to process further frames. Note that this does | do not attempt to process further frames. Note that this does
| not address the concerns raised in [TALKING]. | not address the concerns raised in [TALKING].
The server connection preface consists of a potentially empty The server connection preface consists of a potentially empty
skipping to change at page 11, line 11 skipping to change at page 11, line 11
The fields of the frame header are defined as: The fields of the frame header are defined as:
Length: The length of the frame payload expressed as an unsigned Length: The length of the frame payload expressed as an unsigned
24-bit integer. Values greater than 2^14 (16,384) MUST NOT be 24-bit integer. Values greater than 2^14 (16,384) MUST NOT be
sent unless the receiver has set a larger value for sent unless the receiver has set a larger value for
SETTINGS_MAX_FRAME_SIZE. SETTINGS_MAX_FRAME_SIZE.
The 9 octets of the frame header are not included in this value. The 9 octets of the frame header are not included in this value.
Type: The 8-bit type of the frame. The frame type determines the Type: The 8-bit type of the frame. The frame type determines the
format and semantics of the frame. Implementations MUST ignore format and semantics of the frame. Frames defined in this
documented are listed in Section 6. Implementations MUST ignore
and discard any frame that has a type that is unknown. and discard any frame that has a type that is unknown.
Flags: An 8-bit field reserved for boolean flags specific to the Flags: An 8-bit field reserved for boolean flags specific to the
frame type. frame type.
Flags are assigned semantics specific to the indicated frame type. Flags are assigned semantics specific to the indicated frame type.
Unused flags are those that have no defined semantics for a Unused flags are those that have no defined semantics for a
particular frame type, and MUST be ignored and MUST be left unset particular frame type, and MUST be ignored and MUST be left unset
(0x0) when sending. (0x0) when sending.
skipping to change at page 14, line 20 skipping to change at page 14, line 23
* Streams are identified by an integer. Stream identifiers are * Streams are identified by an integer. Stream identifiers are
assigned to streams by the endpoint initiating the stream. assigned to streams by the endpoint initiating the stream.
5.1. Stream States 5.1. Stream States
The lifecycle of a stream is shown in Figure 2. The lifecycle of a stream is shown in Figure 2.
+--------+ +--------+
send PP | | recv PP send PP | | recv PP
,--------| idle |--------. ,--------+ idle +--------.
/ | | \ / | | \
v +--------+ v v +--------+ v
+----------+ | +----------+ +----------+ | +----------+
| | | send H / | | | | | send H / | |
,------| reserved | | recv H | reserved |------. ,------+ reserved | | recv H | reserved +------.
| | (local) | | | (remote) | | | | (local) | | | (remote) | |
| +----------+ v +----------+ | | +---+------+ v +------+---+ |
| | +--------+ | | | | +--------+ | |
| | recv ES | | send ES | | | | recv ES | | send ES | |
| send H | ,-------| open |-------. | recv H | | send H | ,-------+ open +-------. | recv H |
| | / | | \ | | | | / | | \ | |
| v v +--------+ v v | | v v +---+----+ v v |
| +----------+ | +----------+ | | +----------+ | +----------+ |
| | half | | | half | | | | half | | | half | |
| | closed | | send R / | closed | | | | closed | | send R / | closed | |
| | (remote) | | recv R | (local) | | | | (remote) | | recv R | (local) | |
| +----------+ | +----------+ | | +----+-----+ | +-----+----+ |
| | | | | | | | | |
| | send ES / | recv ES / | | | | send ES / | recv ES / | |
| | send R / v send R / | | | | send R / v send R / | |
| | recv R +--------+ recv R | | | | recv R +--------+ recv R | |
| send R / `----------->| |<-----------' send R / | | send R / `----------->| |<-----------' send R / |
| recv R | closed | recv R | | recv R | closed | recv R |
`----------------------->| |<----------------------' `----------------------->| |<-----------------------'
+--------+ +--------+
Figure 2: Stream States Figure 2: Stream States
send: endpoint sends this frame send: endpoint sends this frame
recv: endpoint receives this frame recv: endpoint receives this frame
H: HEADERS frame (with implied CONTINUATION frames) H: HEADERS frame (with implied CONTINUATION frames)
ES: END_STREAM flag ES: END_STREAM flag
R: RST_STREAM frame R: RST_STREAM frame
PP: PUSH_PROMISE frame (with implied CONTINUATION frames); state PP: PUSH_PROMISE frame (with implied CONTINUATION frames); state
skipping to change at page 22, line 28 skipping to change at page 22, line 28
Conversely, a sender is always subject to the flow-control window Conversely, a sender is always subject to the flow-control window
advertised by the receiver. advertised by the receiver.
Deployments with constrained resources (for example, memory) can Deployments with constrained resources (for example, memory) can
employ flow control to limit the amount of memory a peer can consume. employ flow control to limit the amount of memory a peer can consume.
Note, however, that this can lead to suboptimal use of available Note, however, that this can lead to suboptimal use of available
network resources if flow control is enabled without knowledge of the network resources if flow control is enabled without knowledge of the
bandwidth-delay product (see [RFC7323]). bandwidth-delay product (see [RFC7323]).
Even with full awareness of the current bandwidth-delay product, Even with full awareness of the current bandwidth-delay product,
implementation of flow control can be difficult. When using flow implementation of flow control can be difficult. Endpoints MUST read
control, the receiver MUST read from the TCP receive buffer in a and process HTTP/2 frames from the TCP receive buffer as soon as data
timely fashion. Failure to do so could lead to a deadlock when is available. Failure to read promptly could lead to a deadlock when
critical frames, such as WINDOW_UPDATE, are not read and acted upon. critical frames, such as WINDOW_UPDATE, 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.
5.2.3. Flow Control Performance 5.2.3. Flow Control Performance
If an endpoint cannot ensure that its peer always has available flow If an endpoint cannot ensure that its peer always has available flow
control window space that is greater than the peer's bandwidth-delay control window space that is greater than the peer's bandwidth-delay
product on this connection, its receive throughput will be limited by product on this connection, its receive throughput will be limited by
HTTP/2 flow control. This will result in degraded performance. HTTP/2 flow control. This will result in degraded performance.
Sending timely WINDOW_UPDATE frames can improve performance. Sending timely WINDOW_UPDATE frames can improve performance.
Endpoints will want to balance the need to improve receive throughput Endpoints will want to balance the need to improve receive throughput
skipping to change at page 25, line 8 skipping to change at page 25, line 13
always be used in place of more specific error codes. always be used in place of more specific error codes.
5.4.1. Connection Error Handling 5.4.1. Connection Error Handling
A connection error is any error that prevents further processing of A connection error is any error that prevents further processing of
the frame layer or corrupts any connection state. the frame layer or corrupts any connection state.
An endpoint that encounters a connection error SHOULD first send a An endpoint that encounters a connection error SHOULD first send a
GOAWAY frame (Section 6.8) with the stream identifier of the last GOAWAY frame (Section 6.8) with the stream identifier of the last
stream that it successfully received from its peer. The GOAWAY frame stream that it successfully received from its peer. The GOAWAY frame
includes an error code that indicates why the connection is includes an error code (Section 7) that indicates why the connection
terminating. After sending the GOAWAY frame for an error condition, is terminating. After sending the GOAWAY frame for an error
the endpoint MUST close the TCP connection. condition, the endpoint MUST close the TCP connection.
It is possible that the GOAWAY will not be reliably received by the It is possible that the GOAWAY will not be reliably received by the
receiving endpoint. In the event of a connection error, GOAWAY only receiving endpoint. In the event of a connection error, GOAWAY only
provides a best-effort attempt to communicate with the peer about why provides a best-effort attempt to communicate with the peer about why
the connection is being terminated. the connection is being terminated.
An endpoint can end a connection at any time. In particular, an An endpoint can end a connection at any time. In particular, an
endpoint MAY choose to treat a stream error as a connection error. endpoint MAY choose to treat a stream error as a connection error.
Endpoints SHOULD send a GOAWAY frame when ending a connection, Endpoints SHOULD send a GOAWAY frame when ending a connection,
providing that circumstances permit it. providing that circumstances permit it.
skipping to change at page 29, line 50 skipping to change at page 29, line 50
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4. The HEADERS frame payload has the fields are described in Section 4. The HEADERS frame payload has the
following additional fields: following additional fields:
Pad Length: An 8-bit field containing the length of the frame Pad Length: An 8-bit field containing the length of the frame
padding in units of octets. This field is only present if the padding in units of octets. This field is only present if the
PADDED flag is set. PADDED flag is set.
Exclusive: A single-bit flag. This field is only present if the Exclusive: A single-bit flag. This field is only present if the
PRIORITY flag is set. PRIORITY flag is set. Priority signals in HEADERS frames are
deprecated; see Section 5.3.2.
Stream Dependency: A 31-bit stream identifier. This field is only Stream Dependency: A 31-bit stream identifier. This field is only
present if the PRIORITY flag is set. present if the PRIORITY flag is set.
Weight: An unsigned 8-bit integer. This field is only present if Weight: An unsigned 8-bit integer. This field is only present if
the PRIORITY flag is set. the PRIORITY flag is set.
Field Block Fragment: A field block fragment (Section 4.3). Field Block Fragment: A field block fragment (Section 4.3).
Padding: Padding octets that contain no application semantic value. Padding: Padding octets that contain no application semantic value.
skipping to change at page 34, line 44 skipping to change at page 34, line 44
and an unsigned 32-bit value. and an unsigned 32-bit value.
SETTINGS Frame { SETTINGS Frame {
Length (24), Length (24),
Type (8) = 4, Type (8) = 4,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31) = 0,
Setting (48) ..., Setting (48) ...,
} }
Setting { Setting {
Identifier (16), Identifier (16),
Value (32), Value (32),
} }
Figure 7: SETTINGS Frame Format Figure 7: SETTINGS Frame Format
skipping to change at page 35, line 24 skipping to change at page 35, line 24
to the compression format inside a field block (see to the compression format inside a field block (see
[COMPRESSION]). The initial value is 4,096 octets. [COMPRESSION]). The initial value is 4,096 octets.
SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable
server push (Section 8.4). A server MUST NOT send a PUSH_PROMISE server push (Section 8.4). A server MUST NOT send a PUSH_PROMISE
frame if it receives this parameter set to a value of 0. A client frame if it receives this parameter set to a value of 0. A client
that has both set this parameter to 0 and had it acknowledged MUST that has both set this parameter to 0 and had it acknowledged MUST
treat the receipt of a PUSH_PROMISE frame as a connection error treat the receipt of a PUSH_PROMISE frame as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
The initial value of SETTINGS_ENABLE_PUSH is 1, which indicates The initial value of SETTINGS_ENABLE_PUSH is 1. For a client this
that server push is permitted. Any value other than 0 or 1 MUST value indicates that it is willing to receive PUSH_PROMISE frames.
be treated as a connection error (Section 5.4.1) of type For a server this initial value has no effect, and is equivalent
PROTOCOL_ERROR. to the value 0. Any value other than 0 or 1 MUST be treated as a
connection error (Section 5.4.1) of type PROTOCOL_ERROR.
A server MUST NOT explicitly set this value to 1. A server MAY A server MUST NOT explicitly set this value to 1. A server MAY
choose to omit this setting when it sends a SETTINGS frame, but if choose to omit this setting when it sends a SETTINGS frame, but if
a server does include a value it MUST be 0. A client MUST treat a server does include a value it MUST be 0. A client MUST treat
receipt of a SETTINGS frame with SETTINGS_ENABLE_PUSH set to 1 as receipt of a SETTINGS frame with SETTINGS_ENABLE_PUSH set to 1 as
a connection error (Section 5.4.1) of type PROTOCOL_ERROR. a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
SETTINGS_MAX_CONCURRENT_STREAMS (0x3): Indicates the maximum number SETTINGS_MAX_CONCURRENT_STREAMS (0x3): Indicates the maximum number
of concurrent streams that the sender will allow. This limit is of concurrent streams that the sender will allow. This limit is
directional: it applies to the number of streams that the sender directional: it applies to the number of streams that the sender
skipping to change at page 36, line 47 skipping to change at page 36, line 49
when the peer has received and applied the changed parameter values. when the peer has received and applied the changed parameter values.
In order to provide such synchronization timepoints, the recipient of In order to provide such synchronization timepoints, the recipient of
a SETTINGS frame in which the ACK flag is not set MUST apply the a SETTINGS frame in which the ACK flag is not set MUST apply the
updated settings as soon as possible upon receipt. updated settings as soon as possible upon receipt.
The values in the SETTINGS frame MUST be processed in the order they The values in the SETTINGS frame MUST be processed in the order they
appear, with no other frame processing between values. Unsupported appear, with no other frame processing between values. Unsupported
settings MUST be ignored. Once all values have been processed, the settings MUST be ignored. Once all values have been processed, the
recipient MUST immediately emit a SETTINGS frame with the ACK flag recipient MUST immediately emit a SETTINGS frame with the ACK flag
set. Upon receiving a SETTINGS frame with the ACK flag set, the set. Upon receiving a SETTINGS frame with the ACK flag set, the
sender of the altered settings can rely on the value having been sender of the altered settings can rely on the values from the oldest
applied. unacknowledged SETTINGS frame having been applied.
If the sender of a SETTINGS frame does not receive an acknowledgement If the sender of a SETTINGS frame does not receive an acknowledgement
within a reasonable amount of time, it MAY issue a connection error within a reasonable amount of time, it MAY issue a connection error
(Section 5.4.1) of type SETTINGS_TIMEOUT. (Section 5.4.1) of type SETTINGS_TIMEOUT.
6.6. PUSH_PROMISE 6.6. PUSH_PROMISE
The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint
in advance of streams the sender intends to initiate. The in advance of streams the sender intends to initiate. The
PUSH_PROMISE frame includes the unsigned 31-bit identifier of the PUSH_PROMISE frame includes the unsigned 31-bit identifier of the
skipping to change at page 40, line 13 skipping to change at page 39, line 48
any endpoint. any endpoint.
PING Frame { PING Frame {
Length (24), Length (24),
Type (8) = 6, Type (8) = 6,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31) = 0,
Opaque Data (64), Opaque Data (64),
} }
Figure 9: PING Frame Format Figure 9: PING Frame Format
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4. fields are described in Section 4.
In addition to the frame header, PING frames MUST contain 8 octets of In addition to the frame header, PING frames MUST contain 8 octets of
opaque data in the frame payload. A sender can include any value it opaque data in the frame payload. A sender can include any value it
chooses and use those octets in any fashion. chooses and use those octets in any fashion.
Receivers of a PING frame that does not include an ACK flag MUST send Receivers of a PING frame that does not include an ACK flag MUST send
skipping to change at page 42, line 12 skipping to change at page 41, line 41
connection SHOULD still send a GOAWAY frame before terminating the connection SHOULD still send a GOAWAY frame before terminating the
connection. connection.
GOAWAY Frame { GOAWAY Frame {
Length (24), Length (24),
Type (8) = 7, Type (8) = 7,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31) = 0,
Reserved (1), Reserved (1),
Last-Stream-ID (31), Last-Stream-ID (31),
Error Code (32), Error Code (32),
Additional Debug Data (..), Additional Debug Data (..),
} }
Figure 10: GOAWAY Frame Format Figure 10: GOAWAY Frame Format
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
skipping to change at page 45, line 10 skipping to change at page 44, line 44
the increment to the flow-control window is 1 to 2^31-1 the increment to the flow-control window is 1 to 2^31-1
(2,147,483,647) octets. (2,147,483,647) octets.
The WINDOW_UPDATE frame does not define any flags. The WINDOW_UPDATE frame does not define any flags.
The WINDOW_UPDATE frame can be specific to a stream or to the entire The WINDOW_UPDATE frame can be specific to a stream or to the entire
connection. In the former case, the frame's stream identifier connection. In the former case, the frame's stream identifier
indicates the affected stream; in the latter, the value "0" indicates indicates the affected stream; in the latter, the value "0" indicates
that the entire connection is the subject of the frame. that the entire connection is the subject of the frame.
A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an A receiver MUST treat the receipt of a WINDOW_UPDATE frame with a
flow-control window increment of 0 as a stream error (Section 5.4.2) flow-control window increment of 0 as a stream error (Section 5.4.2)
of type PROTOCOL_ERROR; errors on the connection flow-control window of type PROTOCOL_ERROR; errors on the connection flow-control window
MUST be treated as a connection error (Section 5.4.1). MUST be treated as a connection error (Section 5.4.1).
WINDOW_UPDATE can be sent by a peer that has sent a frame with the WINDOW_UPDATE can be sent by a peer that has sent a frame with the
END_STREAM flag set. This means that a receiver could receive a END_STREAM flag set. This means that a receiver could receive a
WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream. WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream.
A receiver MUST NOT treat this as an error (see Section 5.1). A receiver MUST NOT treat this as an error (see Section 5.1).
A receiver that receives a flow-controlled frame MUST always account A receiver that receives a flow-controlled frame MUST always account
skipping to change at page 52, line 30 skipping to change at page 52, line 30
closing or resetting the stream. Clients MUST NOT accept a malformed closing or resetting the stream. Clients MUST NOT accept a malformed
response. response.
Endpoints that progressively process messages might have performed Endpoints that progressively process messages might have performed
some processing before identifying a request or response as some processing before identifying a request or response as
malformed. For instance, it might be possible to generate an malformed. For instance, it might be possible to generate an
informational or 404 status code without having received a complete informational or 404 status code without having received a complete
request. Similarly, intermediaries might forward incomplete messages request. Similarly, intermediaries might forward incomplete messages
before detecting errors. A server MAY generate a final response before detecting errors. A server MAY generate a final response
before receiving an entire request when the response does not depend before receiving an entire request when the response does not depend
on the remainder of the request being correct. A server or on the remainder of the request being correct.
intermediary MAY use RST_STREAM -- with a code other than
REFUSED_STREAM -- to abort a stream if a malformed request or
response is received.
These requirements are intended to protect against several types of These requirements are intended to protect against several types of
common attacks against HTTP; they are deliberately strict because common attacks against HTTP; they are deliberately strict because
being permissive can expose implementations to these vulnerabilities. being permissive can expose implementations to these vulnerabilities.
8.2. HTTP Fields 8.2. HTTP Fields
HTTP fields (Section 5 of [HTTP]) are conveyed by HTTP/2 in the HTTP fields (Section 5 of [HTTP]) are conveyed by HTTP/2 in the
HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with HPACK HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with HPACK
[COMPRESSION]. [COMPRESSION].
Field names MUST be converted to lowercase when constructing an Field names MUST be converted to lowercase when constructing an
HTTP/2 message. HTTP/2 message.
8.2.1. Field Validity 8.2.1. Field Validity
The definitions of field names and values in HTTP prohibits some The definitions of field names and values in HTTP prohibits some
characters that HPACK might be able to convey. HTTP/2 characters that HPACK might be able to convey. HTTP/2
implementations SHOULD validate field names and values according to implementations SHOULD validate field names and values according to
their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of their definitions in Sections 5.1 and 5.5 of [HTTP] respectively and
[5.5] of [HTTP] respectively and treat messages that contain treat messages that contain prohibited characters as malformed
prohibited characters as malformed (Section 8.1.1). (Section 8.1.1).
Failure to validate fields can be exploited for request smuggling Failure to validate fields can be exploited for request smuggling
attacks. In particular, unvalidated fields might enable attacks when attacks. In particular, unvalidated fields might enable attacks when
messages are forwarded using HTTP 1.1 [HTTP11], where characters such messages are forwarded using HTTP 1.1 [HTTP11], where characters such
as CR, LF, and COLON are used as delimiters. Implementations MUST as CR, LF, and COLON are used as delimiters. Implementations MUST
perform the following minimal validation of field names and values: perform the following minimal validation of field names and values:
* A field name MUST NOT contain characters in the ranges 0x00-0x20, * A field name MUST NOT contain characters in the ranges 0x00-0x20,
0x41-0x5a, or 0x7f-0xff (all ranges inclusive). This specifically 0x41-0x5a, or 0x7f-0xff (all ranges inclusive). This specifically
excludes all non-visible ASCII characters, ASCII SP (0x20), and excludes all non-visible ASCII characters, ASCII SP (0x20), and
skipping to change at page 53, line 37 skipping to change at page 53, line 28
include a colon (ASCII COLON, 0x3a). include a colon (ASCII COLON, 0x3a).
* A field value MUST NOT contain the zero value (ASCII NUL, 0x0), * A field value MUST NOT contain the zero value (ASCII NUL, 0x0),
line feed (ASCII LF, 0xa), or carriage return (ASCII CR, 0xd) at line feed (ASCII LF, 0xa), or carriage return (ASCII CR, 0xd) at
any position. any position.
* A field value MUST NOT start or end with an ASCII whitespace * A field value MUST NOT start or end with an ASCII whitespace
character (ASCII SP or HTAB, 0x20 or 0x9). character (ASCII SP or HTAB, 0x20 or 0x9).
| Note: An implementation that validates fields according the | Note: An implementation that validates fields according the
| definitions in Sections Section 5.1 of [5.1] and Section 5.5 of | definitions in Sections 5.1 and 5.5 of [HTTP] only needs an
| [5.5] of [HTTP] only needs an additional check that field names | additional check that field names do not include uppercase
| do not include uppercase characters. | characters.
A request or response that contains a field that violates any of A request or response that contains a field that violates any of
these conditions MUST be treated as malformed (Section 8.1.1). In these conditions MUST be treated as malformed (Section 8.1.1). In
particular, an intermediary that does not process fields when particular, an intermediary that does not process fields when
forwarding messages MUST NOT forward fields that contain any of the forwarding messages MUST NOT forward fields that contain any of the
values that are listed as prohibited above. values that are listed as prohibited above.
When a request message violates one of these requirements, an When a request message violates one of these requirements, an
implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request)
status code [HTTP], unless a more suitable status code is defined or status code [HTTP], unless a more suitable status code is defined or
skipping to change at page 56, line 34 skipping to change at page 56, line 31
treat a request as malformed if it contains a Host header field treat a request as malformed if it contains a Host header field
that identifies a different entity to the :authority pseudo-header that identifies a different entity to the :authority pseudo-header
field. The values of fields need to be normalized to compare them field. The values of fields need to be normalized to compare them
(see Section 6.2 of [RFC3986]). An origin server can apply any (see Section 6.2 of [RFC3986]). An origin server can apply any
normalization method, whereas other servers MUST perform scheme- normalization method, whereas other servers MUST perform scheme-
based normalization (see Section 6.2.3 of [RFC3986]) of the two based normalization (see Section 6.2.3 of [RFC3986]) of the two
fields. fields.
An intermediary that forwards a request over HTTP/2 MUST construct An intermediary that forwards a request over HTTP/2 MUST construct
an :authority pseudo-header field using the authority information an :authority pseudo-header field using the authority information
from the control data of the original request, unless the the from the control data of the original request, unless the original
original request's target URI does not contain authority request's target URI does not contain authority information (in
information (in which case it MUST NOT generate :authority). Note which case it MUST NOT generate :authority). Note that the Host
that the Host header field is not the sole source of this header field is not the sole source of this information; see
information; see Section 7.2 of [HTTP]. Section 7.2 of [HTTP].
An intermediary that needs to generate a Host header field (which An intermediary that needs to generate a Host header field (which
might be necessary to construct an HTTP/1.1 request) MUST use the might be necessary to construct an HTTP/1.1 request) MUST use the
value from the :authority pseudo-header field as the value of the value from the :authority pseudo-header field as the value of the
Host field, unless the intermediary also changes the request Host field, unless the intermediary also changes the request
target. This replaces any existing Host field to avoid potential target. This replaces any existing Host field to avoid potential
vulnerabilities in HTTP routing. vulnerabilities in HTTP routing.
An intermediary that forwards a request over HTTP/2 MAY retain any An intermediary that forwards a request over HTTP/2 MAY retain any
Host header field. Host header field.
Note that request targets for CONNECT or asterisk-form OPTIONS Note that request targets for CONNECT or asterisk-form OPTIONS
requests never include authority information. requests never include authority information; see Section 7.1 of
[HTTP].
:authority MUST NOT include the deprecated userinfo subcomponent :authority MUST NOT include the deprecated userinfo subcomponent
for http or https schemed URIs. for http or https schemed URIs.
* The :path pseudo-header field includes the path and query parts of * The :path pseudo-header field includes the path and query parts of
the target URI (the absolute-path production and optionally a '?' the target URI (the absolute-path production and optionally a '?'
character followed by the query production; see Section 4.1 of character followed by the query production; see Section 4.1 of
[HTTP]). A request in asterisk form (for OPTIONS) includes the [HTTP]). A request in asterisk form (for OPTIONS) includes the
value '*' for the :path pseudo-header field. value '*' for the :path pseudo-header field.
skipping to change at page 71, line 34 skipping to change at page 71, line 34
The cleartext version of HTTP/2 has minimal protection against cross- The cleartext version of HTTP/2 has minimal protection against cross-
protocol attacks. The connection preface (Section 3.4) contains a protocol attacks. The connection preface (Section 3.4) contains a
string that is designed to confuse HTTP/1.1 servers, but no special string that is designed to confuse HTTP/1.1 servers, but no special
protection is offered for other protocols. protection is offered for other protocols.
10.3. Intermediary Encapsulation Attacks 10.3. Intermediary Encapsulation Attacks
HPACK permits encoding of field names and values that might be HPACK permits encoding of field names and values that might be
treated as delimiters in other HTTP versions. An intermediary that treated as delimiters in other HTTP versions. An intermediary that
translates an HTTP/2 request or response MUST validate fields translates an HTTP/2 request or response MUST validate fields
according to the rules in Section 8.2 roles before translating a according to the rules in Section 8.2 before translating a message to
message to another HTTP version. Translating a field that includes another HTTP version. Translating a field that includes invalid
invalid delimiters could be used to cause recipients to incorrectly delimiters could be used to cause recipients to incorrectly interpret
interpret a message, which could be exploited by an attacker. a message, which could be exploited by an attacker.
An intermediary can reject fields that contain invalid field names or An intermediary can reject fields that contain invalid field names or
values for other reasons, in particular those that do not conform to values for other reasons, in particular those that do not conform to
the HTTP ABNF grammar from Section 5 of [HTTP]. Intermediaries that the HTTP ABNF grammar from Section 5 of [HTTP]. Intermediaries that
do not perform any validation of fields other than the minimum do not perform any validation of fields other than the minimum
required by Section 8.2 could forward messages that contain invalid required by Section 8.2 could forward messages that contain invalid
field names or values. field names or values.
An intermediary that receives any field that requires removal before An intermediary that receives any field that requires removal before
forwarding (see Section 7.6.1 of [HTTP]) MUST remove or replace those forwarding (see Section 7.6.1 of [HTTP]) MUST remove or replace those
skipping to change at page 74, line 34 skipping to change at page 74, line 34
do so. do so.
A server that receives a larger field block than it is willing to A server that receives a larger field block than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status handle can send an HTTP 431 (Request Header Fields Too Large) status
code [RFC6585]. A client can discard responses that it cannot code [RFC6585]. A client can discard responses that it cannot
process. The field block MUST be processed to ensure a consistent process. The field block MUST be processed to ensure a consistent
connection state, unless the connection is closed. connection state, unless the connection is closed.
10.5.2. CONNECT Issues 10.5.2. CONNECT Issues
The CONNECT method can be used to create disproportionate load on an The CONNECT method can be used to create disproportionate load on a
proxy, since stream creation is relatively inexpensive when compared proxy, since stream creation is relatively inexpensive when compared
to the creation and maintenance of a TCP connection. A proxy might to the creation and maintenance of a TCP connection. A proxy might
also maintain some resources for a TCP connection beyond the closing also maintain some resources for a TCP connection beyond the closing
of the stream that carries the CONNECT request, since the outgoing of the stream that carries the CONNECT request, since the outgoing
TCP connection remains in the TIME_WAIT state. Therefore, a proxy TCP connection remains in the TIME_WAIT state. Therefore, a proxy
cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the
resources consumed by CONNECT requests. resources consumed by CONNECT requests.
10.6. Use of Compression 10.6. Use of Compression
skipping to change at page 77, line 5 skipping to change at page 77, line 5
11. IANA Considerations 11. IANA Considerations
This revision of the document marks the HTTP2-Settings header field This revision of the document marks the HTTP2-Settings header field
and the h2c Upgrade token, both defined in [RFC7540], as obsolete. and the h2c Upgrade token, both defined in [RFC7540], as obsolete.
Section 11 of [RFC7540] registered the h2 and h2c ALPN identifiers Section 11 of [RFC7540] registered the h2 and h2c ALPN identifiers
along with the PRI HTTP method. RFC 7540 also established a registry along with the PRI HTTP method. RFC 7540 also established a registry
for frame types, settings, and error codes. These registrations and for frame types, settings, and error codes. These registrations and
registries apply to HTTP/2, but are not redefined in this document. registries apply to HTTP/2, but are not redefined in this document.
[RFC Editor: please remove this paragraph.] IANA is requested to IANA is requested to update references to RFC 7540 in the following
update references to RFC 7540 in the following registries to refer to registries to refer to this document: Application-Layer Protocol
this document: Application-Layer Protocol Negotiation (ALPN) Protocol Negotiation (ALPN) Protocol IDs, HTTP/2 Frame Type, HTTP/2 Settings,
IDs, HTTP/2 Frame Type, HTTP/2 Settings, HTTP/2 Error Code, and HTTP HTTP/2 Error Code, and HTTP Method Registry. The registration of the
Method Registry. The registration of the PRI method needs to be PRI method needs to be updated to refer to Section 3.4; all other
updated to refer to Section 3.4; all other section numbers have not section numbers have not changed.
changed.
11.1. HTTP2-Settings Header Field Registration 11.1. HTTP2-Settings Header Field Registration
This section marks the HTTP2-Settings header field registered by This section marks the HTTP2-Settings header field registered by
Section 11.5 of [RFC7540] in the Hypertext Transfer Protocol (HTTP) Section 11.5 of [RFC7540] in the Hypertext Transfer Protocol (HTTP)
Field Name Registry as obsolete. This capability has been removed: Field Name Registry as obsolete. This capability has been removed:
see Section 3.1. The registration is updated to include the details see Section 3.1. The registration is updated to include the details
as required by Section 18.4 of [HTTP]: as required by Section 18.4 of [HTTP]:
Field Name: HTTP2-Settings Field Name: HTTP2-Settings
Status: Standard Status: Standard
Ref.: Section 3.2.1 of [RFC7540] Ref.: Section 3.2.1 of [RFC7540]
Comments: Obsolete; see Section 11.1 Comments: Obsolete; see Section 11.1 of this document
11.2. The h2c Upgrade Token 11.2. The h2c Upgrade Token
This section records the h2c upgrade token registered by Section 11.8 This section records the h2c upgrade token registered by Section 11.8
of [RFC7540] in the Hypertext Transfer Protocol (HTTP) Upgrade Token of [RFC7540] in the Hypertext Transfer Protocol (HTTP) Upgrade Token
Registry as obsolete. This capability has been removed: see Registry as obsolete. This capability has been removed: see
Section 3.1. The registration is updated as follows: Section 3.1. The registration is updated as follows:
Value: h2c Value: h2c
skipping to change at page 79, line 22 skipping to change at page 79, line 22
2011, <https://www.rfc-editor.org/rfc/rfc6066>. 2011, <https://www.rfc-editor.org/rfc/rfc6066>.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008, (TLS) Protocol Version 1.2", RFC 5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>. <https://www.rfc-editor.org/rfc/rfc5246>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015,
<https://www.rfc-editor.org/rfc/rfc7525>.
12.2. Informative References 12.2. Informative References
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, April 2016, Alternative Services", RFC 7838, April 2016,
<https://www.rfc-editor.org/rfc/rfc7838>. <https://www.rfc-editor.org/rfc/rfc7838>.
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", 12 July 2013, CRIME Attack", 12 July 2013,
<http://breachattack.com/resources/ <http://breachattack.com/resources/
BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>. BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
skipping to change at page 79, line 47 skipping to change at page 80, line 4
[HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-18, 18 August 2021, ietf-httpbis-messaging-18, 18 August 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-18>. messaging-18>.
[I-D.ietf-httpbis-priority] [I-D.ietf-httpbis-priority]
Oku, K. and L. Pardue, "Extensible Prioritization Scheme Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", Work in Progress, Internet-Draft, draft-ietf- for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-04, 11 July 2021, httpbis-priority-10, 18 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
priority-04>. priority-10>.
[NFLX-2019-002] [NFLX-2019-002]
Netflix, "HTTP/2 Denial of Service Advisory", 13 August Netflix, "HTTP/2 Denial of Service Advisory", 13 August
2019, <https://github.com/Netflix/security- 2019, <https://github.com/Netflix/security-
bulletins/blob/master/advisories/third-party/2019-002.md>. bulletins/blob/master/advisories/third-party/2019-002.md>.
[PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
skipping to change at page 81, line 5 skipping to change at page 81, line 9
<https://www.rfc-editor.org/rfc/rfc8441>. <https://www.rfc-editor.org/rfc/rfc8441>.
[RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
DOI 10.17487/RFC8740, February 2020, DOI 10.17487/RFC8740, February 2020,
<https://www.rfc-editor.org/rfc/rfc8740>. <https://www.rfc-editor.org/rfc/rfc8740>.
[TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C. [TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C.
Jackson, "Talking to Yourself for Fun and Profit", 2011, Jackson, "Talking to Yourself for Fun and Profit", 2011,
<http://w2spconf.com/2011/papers/websocket.pdf>. <http://w2spconf.com/2011/papers/websocket.pdf>.
[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015,
<https://www.rfc-editor.org/rfc/rfc7525>.
Appendix A. Prohibited TLS 1.2 Cipher Suites Appendix A. Prohibited TLS 1.2 Cipher Suites
An HTTP/2 implementation MAY treat the negotiation of any of the An HTTP/2 implementation MAY treat the negotiation of any of the
following cipher suites with TLS 1.2 as a connection error following cipher suites with TLS 1.2 as a connection error
(Section 5.4.1) of type INADEQUATE_SECURITY: (Section 5.4.1) of type INADEQUATE_SECURITY:
* TLS_NULL_WITH_NULL_NULL * TLS_NULL_WITH_NULL_NULL
* TLS_RSA_WITH_NULL_MD5 * TLS_RSA_WITH_NULL_MD5
* TLS_RSA_WITH_NULL_SHA * TLS_RSA_WITH_NULL_SHA
* TLS_RSA_EXPORT_WITH_RC4_40_MD5 * TLS_RSA_EXPORT_WITH_RC4_40_MD5
 End of changes. 45 change blocks. 
81 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/