draft-ietf-httpbis-http2bis-01.txt   draft-ietf-httpbis-http2bis-latest.txt 
HTTPbis Working Group M. Thomson, Ed. HTTPbis Working Group 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: August 26, 2021 February 22, 2021 Expires: November 7, 2021 May 6, 2021
Hypertext Transfer Protocol Version 2 (HTTP/2) Hypertext Transfer Protocol Version 2 (HTTP/2)
draft-ietf-httpbis-http2bis-01 draft-ietf-httpbis-http2bis-latest
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 perception of latency by introducing header resources and a reduced perception of latency by introducing header
field compression and allowing multiple concurrent exchanges on the field compression and allowing multiple concurrent exchanges on the
same connection. It also introduces unsolicited push of same connection.
representations from servers to clients.
This specification is an alternative to, but does not obsolete, the This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
This document obsoletes RFC 7540 and RFC 8740.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the HTTPBIS Working Group Discussion of this document takes place on the HTTPBIS Working Group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 August 26, 2021. This Internet-Draft will expire on November 7, 2021.
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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
5.4.3. Connection Termination . . . . . . . . . . . . . . . 31 5.4.3. Connection Termination . . . . . . . . . . . . . . . 31
5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 31 5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 31
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 32 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 32
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 36 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 37 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 37
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 38 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 38
6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 39 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 39
6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 39 6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 39
6.5.3. Settings Synchronization . . . . . . . . . . . . . . 40 6.5.3. Settings Synchronization . . . . . . . . . . . . . . 41
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 41 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 41
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 46 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 47
6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 48 6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 48
6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 49 6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 49
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 50 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 50
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 50 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 50
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 51 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 51
8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . 52 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . 52
8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 52 8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 52
8.1.1. Upgrading from HTTP/2 . . . . . . . . . . . . . . . . 54 8.1.1. Upgrading from HTTP/2 . . . . . . . . . . . . . . . . 54
8.1.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . 54 8.1.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . 54
8.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 58 8.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 58
8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . 60 8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . 61
8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 61 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 62
8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 62 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 63
8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . 63 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . 64
8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . 64 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . 65
9. Additional HTTP Requirements/Considerations . . . . . . . . . 65 9. Additional HTTP Requirements/Considerations . . . . . . . . . 66
9.1. Connection Management . . . . . . . . . . . . . . . . . . 65 9.1. Connection Management . . . . . . . . . . . . . . . . . . 67
9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 66 9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 67
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 67 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 68
9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 67 9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 68
9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 68 9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 69
9.2.3. TLS 1.3 Features . . . . . . . . . . . . . . . . . . 69 9.2.3. TLS 1.3 Features . . . . . . . . . . . . . . . . . . 70
10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 70
10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 69 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 70
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 70 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 71
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 70 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 71
10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 71 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 72
10.5. Denial-of-Service Considerations . . . . . . . . . . . . 71 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 72
10.5.1. Limits on Field Block Size . . . . . . . . . . . . . 73 10.5.1. Limits on Field Block Size . . . . . . . . . . . . . 74
10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 73 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 74
10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 74 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 75
10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 74 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 75
10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 75 10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 76
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
11.1. Registration of HTTP/2 Identification Strings . . . . . 75 11.1. Registration of HTTP/2 Identification Strings . . . . . 76
11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 76 11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 77
11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 77 11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 78
11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 78 11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 79
11.5. HTTP2-Settings Header Field Registration . . . . . . . . 79 11.5. HTTP2-Settings Header Field Registration . . . . . . . . 80
11.6. PRI Method Registration . . . . . . . . . . . . . . . . 80 11.6. PRI Method Registration . . . . . . . . . . . . . . . . 81
11.7. The h2c Upgrade Token . . . . . . . . . . . . . . . . . 80 11.7. The h2c Upgrade Token . . . . . . . . . . . . . . . . . 81
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
12.1. Normative References . . . . . . . . . . . . . . . . . . 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 81
12.2. Informative References . . . . . . . . . . . . . . . . . 82 12.2. Informative References . . . . . . . . . . . . . . . . . 83
Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 84 Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 85
Appendix B. Changes from RFC 7540 . . . . . . . . . . . . . . . 95 Appendix B. Changes from RFC 7540 . . . . . . . . . . . . . . . 96
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 96 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 97
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a wildly successful The Hypertext Transfer Protocol (HTTP) is a wildly successful
protocol. However, the way HTTP/1.1 uses the underlying transport protocol. However, the way HTTP/1.1 uses the underlying transport
([HTTP11]) has several characteristics that have a negative overall ([HTTP11]) has several characteristics that have a negative overall
effect on application performance today. effect on application performance today.
In particular, HTTP/1.0 allowed only one request to be outstanding at 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, a time on a given TCP connection. HTTP/1.1 added request pipelining,
skipping to change at page 5, line 10 skipping to change at page 5, line 10
requests complete more quickly, further improving performance. requests complete more quickly, further improving performance.
The resulting protocol is more friendly to the network because fewer The resulting protocol is more friendly to the network because fewer
TCP connections can be used in comparison to HTTP/1.x. This means TCP connections can be used in comparison to HTTP/1.x. This means
less competition with other flows and longer-lived connections, which less competition with other flows and longer-lived connections, which
in turn lead to better utilization of available network capacity. in turn lead to better utilization of available network capacity.
Finally, HTTP/2 also enables more efficient processing of messages Finally, HTTP/2 also enables more efficient processing of messages
through use of binary message framing. through use of binary message framing.
This document obsoletes RFC 7540 [RFC7540] and RFC 8740 [RFC8740].
2. HTTP/2 Protocol Overview 2. HTTP/2 Protocol Overview
HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2
supports all of the core features of HTTP but aims to be more supports all of the core features of HTTP but aims to be more
efficient than HTTP/1.1. efficient than HTTP/1.1.
The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each
frame type serves a different purpose. For example, HEADERS and DATA frame type serves a different purpose. For example, HEADERS and DATA
frames form the basis of HTTP requests and responses (Section 8.1); frames form the basis of HTTP requests and responses (Section 8.1);
other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are
skipping to change at page 5, line 34 skipping to change at page 5, line 36
Streams are largely independent of each other, so a blocked or Streams are largely independent of each other, so a blocked or
stalled request or response does not prevent progress on other stalled request or response does not prevent progress on other
streams. streams.
Flow control and prioritization ensure that it is possible to Flow control and prioritization ensure that it is possible to
efficiently use multiplexed streams. Flow control (Section 5.2) efficiently use multiplexed streams. Flow control (Section 5.2)
helps to ensure that only data that can be used by a receiver is helps to ensure that only data that can be used by a receiver is
transmitted. Prioritization (Section 5.3) ensures that limited transmitted. Prioritization (Section 5.3) ensures that limited
resources can be directed to the most important streams first. resources can be directed to the most important streams first.
HTTP/2 adds a new interaction mode whereby a server can push
responses to a client (Section 8.2). Server push allows 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 PUSH_PROMISE frame. The server is then able to send a
response to the synthetic request on a separate stream.
Because HTTP header fields used in a connection can contain large Because HTTP header fields used in a connection can contain large
amounts of redundant data, frames that contain them are compressed amounts of redundant data, frames that contain them are compressed
(Section 4.3). This has especially advantageous impact upon request (Section 4.3). This has especially advantageous impact upon request
sizes in the common case, allowing many requests to be compressed sizes in the common case, allowing many requests to be compressed
into one packet. into one packet.
Finally, HTTP/2 adds a new, optional interaction mode whereby a
server can push responses to a client (Section 8.2). 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 PUSH_PROMISE frame.
The server is then able to send a response to the synthetic request
on a separate stream.
2.1. Document Organization 2.1. Document Organization
The HTTP/2 specification is split into four parts: The HTTP/2 specification is split into four parts:
o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is
initiated. initiated.
o The frame (Section 4) and stream (Section 5) layers describe the o The frame (Section 4) and stream (Section 5) layers describe the
way HTTP/2 frames are structured and formed into multiplexed way HTTP/2 frames are structured and formed into multiplexed
streams. streams.
skipping to change at page 39, line 35 skipping to change at page 39, line 35
The following parameters are defined: The following parameters are defined:
SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the
remote endpoint of the maximum size of the compression table used remote endpoint of the maximum size of the compression table used
to decode field blocks, in octets. The encoder can select any to decode field blocks, in octets. The encoder can select any
size equal to or less than this value by using signaling specific size equal to or less than this value by using signaling specific
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.2). An endpoint MUST NOT send a server push (Section 8.2). A server MUST NOT send a PUSH_PROMISE
PUSH_PROMISE frame if it receives this parameter set to a value of frame if it receives this parameter set to a value of 0. A client
0. An endpoint that has both set this parameter to 0 and had it that has both set this parameter to 0 and had it acknowledged MUST
acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a treat the receipt of a PUSH_PROMISE frame as a connection error
connection error (Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
The initial value is 1, which indicates that server push is The initial value of SETTINGS_ENABLE_PUSH is 1, which indicates
permitted. Any value other than 0 or 1 MUST be treated as a that server push is permitted. Any value other than 0 or 1 MUST
connection error (Section 5.4.1) of type PROTOCOL_ERROR. 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
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
receipt of a SETTINGS frame with SETTINGS_ENABLE_PUSH set to 1 as
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
permits the receiver to create. Initially, there is no limit to permits the receiver to create. Initially, there is no limit to
this value. It is recommended that this value be no smaller than this value. It is recommended that this value be no smaller than
100, so as to not unnecessarily limit parallelism. 100, so as to not unnecessarily limit parallelism.
A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be
treated as special by endpoints. A zero value does prevent the treated as special by endpoints. A zero value does prevent the
skipping to change at page 55, line 40 skipping to change at page 56, line 6
believed sufficient to negotiate the use of alternative protocols. believed sufficient to negotiate the use of alternative protocols.
8.1.2.3. Request Pseudo-Header Fields 8.1.2.3. Request Pseudo-Header Fields
The following pseudo-header fields are defined for HTTP/2 requests: The following pseudo-header fields are defined for HTTP/2 requests:
o The ":method" pseudo-header field includes the HTTP method o The ":method" pseudo-header field includes the HTTP method
(Section 9 of [HTTP]). (Section 9 of [HTTP]).
o The ":scheme" pseudo-header field includes the scheme portion of o The ":scheme" pseudo-header field includes the scheme portion of
the target URI (Section 3.1 of [RFC3986]). the request target. The scheme is taken from the target URI
(Section 3.1 of [RFC3986]) when generating a request directly, or
from the scheme of a translated request (for example. see
Section 3.3 of [HTTP11]). Scheme is omitted for CONNECT requests
(Section 8.3).
":scheme" is not restricted to "http" and "https" schemed URIs. A ":scheme" is not restricted to "http" and "https" schemed URIs. A
proxy or gateway can translate requests for non-HTTP schemes, proxy or gateway can translate requests for non-HTTP schemes,
enabling the use of HTTP to interact with non-HTTP services. enabling the use of HTTP to interact with non-HTTP services.
o The ":authority" pseudo-header field includes the authority o The ":authority" pseudo-header field includes the authority
portion of the target URI (Section 3.2 of [RFC3986]). The portion of the target URI (Section 3.2 of [RFC3986]). The
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.
To ensure that HTTP/1.1 control data can be reproduced accurately, Clients that generate HTTP/2 requests directly SHOULD use the
this pseudo-header field MUST be omitted when translating from an ":authority" pseudo-header field instead of the "Host" header
HTTP/1.1 request that has a request target in origin or asterisk field.
form (see Section 3.2 of [HTTP11]). Clients that generate HTTP/2
requests directly SHOULD use the ":authority" pseudo-header field An intermediary that translates a request to HTTP/2 from HTTP/1.1,
instead of the "Host" header field. An intermediary that converts with an origin-, asterisk-, or authority-form request target (see
an HTTP/2 request to HTTP/1.1 MUST create a "Host" header field if Section 3.2 of [HTTP11]) MUST retain the "Host" header field and
one is not present in a request by copying the value of the not add an ":authority" pseudo-header field. For an absolute-form
":authority" pseudo-header field. request target, the intermediary MUST obtain a value for the
":authority" pseudo-header field from the request URI and retain
the value of the "Host" header field.
An intermediary that translates a request to HTTP/1.1 from HTTP/2
MUST create a "Host" header field if one is not present in a
request by copying the value of the ":authority" pseudo-header
field.
A request that was translated from absolute form could include
both ":authority" and "Host". The value of the "Host" header
field is ignored, as defined in Section 3.2.2 of [HTTP11].
o The ":path" pseudo-header field includes the path and query parts o The ":path" pseudo-header field includes the path and query parts
of the target URI (the "path-absolute" production and optionally a of the target URI (the "path-absolute" production and optionally a
'?' character followed by the "query" production (see Sections 3.3 '?' character followed by the "query" production (see Sections 3.3
and 3.4 of [RFC3986]). A request in asterisk form includes the and 3.4 of [RFC3986]). A request in asterisk form includes the
value '*' for the ":path" pseudo-header field. value '*' for the ":path" pseudo-header field.
This pseudo-header field MUST NOT be empty for "http" or "https" This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'. The exception to this rule is an MUST include a value of '/'. The exception to this rule is an
skipping to change at page 61, line 26 skipping to change at page 62, line 20
client to easily test a connection. Connections that remain idle can client to easily test a connection. Connections that remain idle can
become broken as some middleboxes (for instance, network address become broken as some middleboxes (for instance, network address
translators or load balancers) silently discard connection bindings. translators or load balancers) silently discard connection bindings.
The PING frame allows a client to safely test whether a connection is The PING frame allows a client to safely test whether a connection is
still active without sending a request. still active without sending a request.
8.2. Server Push 8.2. Server Push
HTTP/2 allows a server to pre-emptively send (or "push") responses HTTP/2 allows a server to pre-emptively send (or "push") responses
(along with corresponding "promised" requests) to a client in (along with corresponding "promised" requests) to a client in
association with a previous client-initiated request. This can be association with a previous client-initiated request.
useful when the server knows the client will need to have those
responses available in order to fully process the response to the Server push was designed to allow a server to improve client-
original request. perceived performance by predicting what requests will follow those
that it receives, thereby removing a round trip for them. For
example, a request for HTML is often followed by requests for
stylesheets and scripts referenced by that page. When these requests
are pushed, the client does not need to wait to receive the
references to them in the HTML and issue separate requests.
In practice, server push is difficult to use effectively, because it
requires the server to correctly anticipate the additional requests
the client will make, taking into account factors such as caching,
content negotiation, and user behavior. Errors in prediction can
lead to performance degradation, due to the opportunity cost that the
additional data on the wire represents. In particular, pushing any
significant amount of data can cause contention issues with more-
important responses.
A client can request that server push be disabled, though this is A client can request that server push be disabled, though this is
negotiated for each hop independently. The SETTINGS_ENABLE_PUSH negotiated for each hop independently. The SETTINGS_ENABLE_PUSH
setting can be set to 0 to indicate that server push is disabled. setting can be set to 0 to indicate that server push is disabled.
Promised requests MUST be safe (see Section 9.2.1 of [HTTP]) and Promised requests MUST be safe (see Section 9.2.1 of [HTTP]) and
cacheable (see Section 9.2.3 of [HTTP]). Promised requests cannot cacheable (see Section 9.2.3 of [HTTP]). Promised requests cannot
include any content or a trailer section. Clients that receive a include any content or a trailer section. Clients that receive a
promised request that is not cacheable, that is not known to be safe, promised request that is not cacheable, that is not known to be safe,
or that indicates the presence of request content MUST reset the or that indicates the presence of request content MUST reset the
skipping to change at page 62, line 23 skipping to change at page 63, line 30
PROTOCOL_ERROR. PROTOCOL_ERROR.
An intermediary can receive pushes from the server and choose not to An intermediary can receive pushes from the server and choose not to
forward them on to the client. In other words, how to make use of forward them on to the client. In other words, how to make use of
the pushed information is up to that intermediary. Equally, the the pushed information is up to that intermediary. Equally, the
intermediary might choose to make additional pushes to the client, intermediary might choose to make additional pushes to the client,
without any action taken by the server. without any action taken by the server.
A client cannot push. Thus, servers MUST treat the receipt of a A client cannot push. Thus, servers MUST treat the receipt of a
PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. Clients MUST reject any attempt to change the PROTOCOL_ERROR. A server cannot set the SETTINGS_ENABLE_PUSH setting
SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the to a value other than 0 (see Section 6.5.2).
message as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
8.2.1. Push Requests 8.2.1. Push Requests
Server push is semantically equivalent to a server responding to a Server push is semantically equivalent to a server responding to a
request; however, in this case, that request is also sent by the request; however, in this case, that request is also sent by the
server, as a PUSH_PROMISE frame. server, as a PUSH_PROMISE frame.
The PUSH_PROMISE frame includes a field block that contains control The PUSH_PROMISE frame includes a field block that contains control
data and a complete set of request header fields that the server data and a complete set of request header fields that the server
attributes to the request. It is not possible to push a response to attributes to the request. It is not possible to push a response to
skipping to change at page 75, line 39 skipping to change at page 76, line 39
This might have privacy implications in certain scenarios. This might have privacy implications in certain scenarios.
11. IANA Considerations 11. IANA Considerations
A string for identifying HTTP/2 is entered into the "Application- A string for identifying HTTP/2 is entered into the "Application-
Layer Protocol Negotiation (ALPN) Protocol IDs" registry established Layer Protocol Negotiation (ALPN) Protocol IDs" registry established
in [TLS-ALPN]. in [TLS-ALPN].
This document establishes a registry for frame types, settings, and This document establishes a registry for frame types, settings, and
error codes. These new registries appear in the new "Hypertext error codes. These new registries appear in the new "Hypertext
Transfer Protocol version 2 (HTTP/2) Parameters" section. Transfer Protocol version 2 (HTTP/2)" section.
This document registers the "HTTP2-Settings" header field for use in This document registers the "HTTP2-Settings" header field for use in
HTTP. HTTP.
This document registers the "PRI" method for use in HTTP to avoid This document registers the "PRI" method for use in HTTP to avoid
collisions with the connection preface (Section 3.5). collisions with the connection preface (Section 3.5).
11.1. Registration of HTTP/2 Identification Strings 11.1. Registration of HTTP/2 Identification Strings
This document creates two registrations for the identification of This document creates two registrations for the identification of
skipping to change at page 80, line 40 skipping to change at page 81, line 40
Expected Version Tokens: None Expected Version Tokens: None
Reference: Section 3.2 of this document Reference: Section 3.2 of this document
12. References 12. References
12.1. Normative References 12.1. Normative References
[CACHE] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [CACHE] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-14 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-15 (work in
progress), January 2021. progress), March 2021.
[COMPRESSION] [COMPRESSION]
Peon, R. and H. Ruellan, "HPACK: Header Compression for Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015. HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011. DOI 10.17487/RFC6265, April 2011.
[FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4, [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4,
July 2013, <http://dx.doi.org/10.6028/NIST.FIPS.186-4>. July 2013, <http://dx.doi.org/10.6028/NIST.FIPS.186-4>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-14 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-15
(work in progress), January 2021. (work in progress), March 2021.
[HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", draft-ietf-httpbis-messaging-14 (work in Ed., "HTTP/1.1", draft-ietf-httpbis-messaging-15 (work in
progress), January 2021. progress), March 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66,
STD 66, DOI 10.17487/RFC3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, BCP 26, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008. DOI 10.17487/RFC5226, May 2008.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, STD 68, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008. DOI 10.17487/RFC5234, January 2008.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018. 2018.
[TCP] Postel, J., "Transmission Control Protocol", RFC 793, [TCP] Postel, J., "Transmission Control Protocol", STD 7,
STD 7, DOI 10.17487/RFC0793, September 1981. RFC 793, DOI 10.17487/RFC0793, September 1981.
[TLS-ALPN] [TLS-ALPN]
Friedl, S., Popov, A., Langley, A., and E. Stephan, Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014. July 2014.
[TLS-ECDHE] [TLS-ECDHE]
Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
skipping to change at page 82, line 19 skipping to change at page 83, line 19
[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.
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, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016. April 2016.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", RFC 3864, BCP 90, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", July 2013, CRIME Attack", 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>.
[DNS-TERMS] [DNS-TERMS]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
skipping to change at page 83, line 9 skipping to change at page 84, line 9
for Transport Layer Security (TLS)", RFC 4492, for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006. DOI 10.17487/RFC4492, May 2006.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012. Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance", Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014. RFC 7323, DOI 10.17487/RFC7323, September 2014.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015.
[RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
DOI 10.17487/RFC8740, February 2020.
[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, [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7525, BCP 195, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015. 2015.
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:
o TLS_NULL_WITH_NULL_NULL o TLS_NULL_WITH_NULL_NULL
 End of changes. 29 change blocks. 
95 lines changed or deleted 140 lines changed or added

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