draft-ietf-httpbis-messaging-09.txt   draft-ietf-httpbis-messaging-10.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7230 (if approved) M. Nottingham, Ed. Obsoletes: 7230 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Fastly Intended status: Standards Track Fastly
Expires: January 12, 2021 J. Reschke, Ed. Expires: January 13, 2021 J. F. Reschke, Ed.
greenbytes greenbytes
July 11, 2020 July 12, 2020
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-09 draft-ietf-httpbis-messaging-10
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document specifies the HTTP/1.1 message syntax, systems. This document specifies the HTTP/1.1 message syntax,
message parsing, connection management, and related security message parsing, connection management, and related security
concerns. concerns.
This document obsoletes portions of RFC 7230. This document obsoletes portions of RFC 7230.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP 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/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix D.10. The changes in this draft are summarized in Appendix D.11.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 12, 2021. This Internet-Draft will expire on January 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 4 skipping to change at page 3, line 5
2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7 2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7
2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8 2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8
3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12
3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13 3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16 5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 17
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24
7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 24 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 25
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25
7.2. Transfer Codings for Compression . . . . . . . . . . . . 26 7.2. Transfer Codings for Compression . . . . . . . . . . . . 26
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Associating a Response to a Request . . . . . . . . . . . 31 9.3. Associating a Response to a Request . . . . . . . . . . . 31
9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31
9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32 9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32
9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33 9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33
9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33 9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 34
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35
9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 38 9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 39
9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 39 9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 39
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 40 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 40
10.1. Media Type message/http . . . . . . . . . . . . . . . . 40 10.1. Media Type message/http . . . . . . . . . . . . . . . . 40
10.2. Media Type application/http . . . . . . . . . . . . . . 41 10.2. Media Type application/http . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 44 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12.1. Field Name Registration . . . . . . . . . . . . . . . . 44 12.1. Field Name Registration . . . . . . . . . . . . . . . . 44
12.2. Media Type Registration . . . . . . . . . . . . . . . . 44 12.2. Media Type Registration . . . . . . . . . . . . . . . . 44
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 45 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 45
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 45 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 45
12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 45 12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 47 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 49 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 48
Appendix B. Differences between HTTP and MIME . . . . . . . . . 50 Appendix B. Differences between HTTP and MIME . . . . . . . . . 50
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 51 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 50
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 51 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 50
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 51 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 51
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 52 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 51
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 52 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 51
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 52 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 51
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 52 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 52
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 53 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 52
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 53 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 53
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 54 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 53
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 54 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 54
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 54 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 54
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 55 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 54
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 55 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 55
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 56 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 55
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 56 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 55
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 57 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 56
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 57 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 56
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 57 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 56
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 57 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 57
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 58 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 57
D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 58 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 58
D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 59 D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 58
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 58
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 61 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" [Semantics] o "HTTP Semantics" [Semantics]
skipping to change at page 13, line 30 skipping to change at page 13, line 34
follows: follows:
If the server's configuration (or outbound gateway) provides a If the server's configuration (or outbound gateway) provides a
fixed URI scheme, that scheme is used for the target URI. fixed URI scheme, that scheme is used for the target URI.
Otherwise, if the request is received over a TLS-secured TCP Otherwise, if the request is received over a TLS-secured TCP
connection, the target URI's scheme is "https"; if not, the scheme connection, the target URI's scheme is "https"; if not, the scheme
is "http". is "http".
If the server's configuration (or outbound gateway) provides a If the server's configuration (or outbound gateway) provides a
fixed URI authority component, that authority is used for the fixed URI authority component, that authority is used for the
target URI. If not, then if the request-target is in authority- target URI. If not, then if the request-target is in
form, the target URI's authority component is the same as the authority-form, the target URI's authority component is the same
request-target. If not, then if a Host header field is supplied as the request-target. If not, then if a Host header field is
with a non-empty field-value, the authority component is the same supplied with a non-empty field-value, the authority component is
as the Host field-value. Otherwise, the authority component is the same as the Host field-value. Otherwise, the authority
assigned the default name configured for the server and, if the component is assigned the default name configured for the server
connection's incoming TCP port number differs from the default and, if the connection's incoming TCP port number differs from the
port for the target URI's scheme, then a colon (":") and the default port for the target URI's scheme, then a colon (":") and
incoming port number (in decimal form) are appended to the the incoming port number (in decimal form) are appended to the
authority component. authority component.
If the request-target is in authority-form or asterisk-form, the If the request-target is in authority-form or asterisk-form, the
target URI's combined path and query component is empty. target URI's combined path and query component is empty.
Otherwise, the combined path and query component is the same as Otherwise, the combined path and query component is the same as
the request-target. the request-target.
The components of the target URI, once determined as above, can be The components of the target URI, once determined as above, can be
combined into absolute-URI form by concatenating the scheme, combined into absolute-URI form by concatenating the scheme,
"://", authority, and combined path and query component. "://", authority, and combined path and query component.
skipping to change at page 15, line 40 skipping to change at page 16, line 5
field-line = field-name ":" OWS field-value OWS field-line = field-name ":" OWS field-value OWS
Most HTTP field names and the rules for parsing within field values Most HTTP field names and the rules for parsing within field values
are defined in Section 5 of [Semantics]. This section covers the are defined in Section 5 of [Semantics]. This section covers the
generic syntax for header field inclusion within, and extraction generic syntax for header field inclusion within, and extraction
from, HTTP/1.1 messages. In addition, the following header fields from, HTTP/1.1 messages. In addition, the following header fields
are defined by this document because they are specific to HTTP/1.1 are defined by this document because they are specific to HTTP/1.1
message processing: message processing:
+-------------------+----------+---------------+ +-------------------+----------+--------------+
| Field Name | Status | Reference | | Field Name | Status | Reference |
+-------------------+----------+---------------+ | Connection | standard | Section 9.1 |
| Connection | standard | Section 9.1 | | MIME-Version | standard | Appendix B.1 |
| MIME-Version | standard | Appendix B.1 | | TE | standard | Section 7.4 |
| TE | standard | Section 7.4 | | Transfer-Encoding | standard | Section 6.1 |
| Transfer-Encoding | standard | Section 6.1 | | Upgrade | standard | Section 9.9 |
| Upgrade | standard | Section 9.9 | +-------------------+----------+--------------+
+-------------------+----------+---------------+
Table 1 Table 1
Furthermore, the field name "Close" is reserved, since using that Furthermore, the field name "Close" is reserved, since using that
name as an HTTP header field might conflict with the "close" name as an HTTP header field might conflict with the "close"
connection option of the Connection header field (Section 9.1). connection option of the Connection header field (Section 9.1).
+------------+----------+------------+-------------+ +------------+----------+-----------+------------+
| Field Name | Status | Reference | Comments | | Field Name | Status | Reference | Comments |
+------------+----------+------------+-------------+ | Close | standard | Section 5 | (reserved) |
| Close | standard | Section 5 | (reserved) | +------------+----------+-----------+------------+
+------------+----------+------------+-------------+
Table 2
5.1. Field Line Parsing 5.1. Field Line Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual field names. The contents within a given field line value individual field names. The contents within a given field line value
are not parsed until a later stage of message interpretation (usually are not parsed until a later stage of message interpretation (usually
after the message's entire header section has been processed). after the message's entire header section has been processed).
No whitespace is allowed between the field name and colon. In the No whitespace is allowed between the field name and colon. In the
past, differences in the handling of such whitespace have led to past, differences in the handling of such whitespace have led to
skipping to change at page 17, line 23 skipping to change at page 17, line 37
A proxy or gateway that receives an obs-fold in a response message A proxy or gateway that receives an obs-fold in a response message
that is not within a message/http container MUST either discard the that is not within a message/http container MUST either discard the
message and replace it with a 502 (Bad Gateway) response, preferably message and replace it with a 502 (Bad Gateway) response, preferably
with a representation explaining that unacceptable line folding was with a representation explaining that unacceptable line folding was
received, or replace each received obs-fold with one or more SP received, or replace each received obs-fold with one or more SP
octets prior to interpreting the field value or forwarding the octets prior to interpreting the field value or forwarding the
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received obs- not within a message/http container MUST replace each received
fold with one or more SP octets prior to interpreting the field obs-fold with one or more SP octets prior to interpreting the field
value. value.
6. Message Body 6. Message Body
The message body (if any) of an HTTP message is used to carry the The message body (if any) of an HTTP message is used to carry the
payload body (Section 7.3.3 of [Semantics]) of that request or payload body (Section 7.3.3 of [Semantics]) of that request or
response. The message body is identical to the payload body unless a response. The message body is identical to the payload body unless a
transfer coding has been applied, as described in Section 6.1. transfer coding has been applied, as described in Section 6.1.
message-body = *OCTET message-body = *OCTET
The rules for determining when a message body is present in an The rules for determining when a message body is present in an
HTTP/1.1 message differ for requests and responses. HTTP/1.1 message differ for requests and responses.
The presence of a message body in a request is signaled by a Content- The presence of a message body in a request is signaled by a
Length or Transfer-Encoding header field. Request message framing is Content-Length or Transfer-Encoding header field. Request message
independent of method semantics, even if the method does not define framing is independent of method semantics, even if the method does
any use for a message body. not define any use for a message body.
The presence of a message body in a response depends on both the The presence of a message body in a response depends on both the
request method to which it is responding and the response status code request method to which it is responding and the response status code
(Section 4), and corresponds to when a payload body is allowed; see (Section 4), and corresponds to when a payload body is allowed; see
Section 7.3.3 of [Semantics]. Section 7.3.3 of [Semantics].
6.1. Transfer-Encoding 6.1. Transfer-Encoding
The Transfer-Encoding header field lists the transfer coding names The Transfer-Encoding header field lists the transfer coding names
corresponding to the sequence of transfer codings that have been (or corresponding to the sequence of transfer codings that have been (or
skipping to change at page 19, line 44 skipping to change at page 20, line 5
When a message does not have a Transfer-Encoding header field, a When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body. For messages decimal number of octets, for a potential payload body. For messages
that do include a payload body, the Content-Length field value that do include a payload body, the Content-Length field value
provides the framing information necessary for determining where the provides the framing information necessary for determining where the
body (and message) ends. For messages that do not include a payload body (and message) ends. For messages that do not include a payload
body, the Content-Length indicates the size of the selected body, the Content-Length indicates the size of the selected
representation (Section 7.2.4 of [Semantics]). representation (Section 7.2.4 of [Semantics]).
Note: HTTP's use of Content-Length for message framing differs | *Note:* HTTP's use of Content-Length for message framing
significantly from the same field's use in MIME, where it is an | differs significantly from the same field's use in MIME, where
optional field used only within the "message/external-body" media- | it is an optional field used only within the "message/external-
type. | body" media-type.
6.3. Message Body Length 6.3. Message Body Length
The length of a message body is determined by one of the following The length of a message body is determined by one of the following
(in order of precedence): (in order of precedence):
1. Any response to a HEAD request and any response with a 1xx 1. Any response to a HEAD request and any response with a 1xx
(Informational), 204 (No Content), or 304 (Not Modified) status (Informational), 204 (No Content), or 304 (Not Modified) status
code is always terminated by the first empty line after the code is always terminated by the first empty line after the
header fields, regardless of the header fields present in the header fields, regardless of the header fields present in the
skipping to change at page 22, line 31 skipping to change at page 22, line 37
that is being transferred. that is being transferred.
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name=value pair. Parameters are in the form of a name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the HTTP Transfer Coding registry, as defined in
Section 7.3. They are used in the TE (Section 7.4) and Transfer- Section 7.3. They are used in the TE (Section 7.4) and
Encoding (Section 6.1) header fields. Transfer-Encoding (Section 6.1) header fields.
+------------+------------------------------------------+-----------+ +------------+-------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ | chunked | Transfer in a series of | Section |
| chunked | Transfer in a series of chunks | Section 7 | | | chunks | 7.1 |
| | | .1 | | compress | UNIX "compress" data format | Section |
| compress | UNIX "compress" data format [Welch] | Section 7 | | | [Welch] | 7.2 |
| | | .2 | | deflate | "deflate" compressed data | Section |
| deflate | "deflate" compressed data ([RFC1951]) | Section 7 | | | ([RFC1951]) inside the "zlib" | 7.2 |
| | inside the "zlib" data format | .2 | | | data format ([RFC1950]) | |
| | ([RFC1950]) | | | gzip | GZIP file format [RFC1952] | Section |
| gzip | GZIP file format [RFC1952] | Section 7 | | | | 7.2 |
| | | .2 | | trailers | (reserved) | Section 7 |
| trailers | (reserved) | Section 7 | | x-compress | Deprecated (alias for | Section |
| x-compress | Deprecated (alias for compress) | Section 7 | | | compress) | 7.2 |
| | | .2 | | x-gzip | Deprecated (alias for gzip) | Section |
| x-gzip | Deprecated (alias for gzip) | Section 7 | | | | 7.2 |
| | | .2 | +------------+-------------------------------+-----------+
+------------+------------------------------------------+-----------+
Table 2 Table 3
Note: the coding name "trailers" is reserved because its use would | *Note:* the coding name "trailers" is reserved because its use
conflict with the keyword "trailers" in the TE header field | would conflict with the keyword "trailers" in the TE header
(Section 7.4). | field (Section 7.4).
7.1. Chunked Transfer Coding 7.1. Chunked Transfer Coding
The chunked transfer coding wraps the payload body in order to The chunked transfer coding wraps the payload body in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer section containing trailer fields. followed by an OPTIONAL trailer section containing trailer fields.
Chunked enables content streams of unknown size to be transferred as Chunked enables content streams of unknown size to be transferred as
a sequence of length-delimited buffers, which enables the sender to a sequence of length-delimited buffers, which enables the sender to
retain connection persistence and the recipient to know when it has retain connection persistence and the recipient to know when it has
received the entire message. received the entire message.
skipping to change at page 39, line 7 skipping to change at page 39, line 16
(Section 10.4 of [Semantics]). (Section 10.4 of [Semantics]).
9.9.1. Upgrade Protocol Names 9.9.1. Upgrade Protocol Names
This specification only defines the protocol name "HTTP" for use by This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 4.2 of [Semantics] and future updates to version rules of Section 4.2 of [Semantics] and future updates to
this specification. Additional protocol names ought to be registered this specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 9.9.2. using the registration procedure defined in Section 9.9.2.
+------+-------------------+--------------------+-------------------+ +------+-------------------+-----------------+----------------+
| Name | Description | Expected Version | Reference | | Name | Description | Expected | Reference |
| | | Tokens | | | | | Version Tokens | |
+------+-------------------+--------------------+-------------------+ | HTTP | Hypertext | any DIGIT.DIGIT | Section 4.2 of |
| HTTP | Hypertext | any DIGIT.DIGIT | Section 4.2 of | | | Transfer Protocol | (e.g, "2.0") | [Semantics] |
| | Transfer Protocol | (e.g, "2.0") | [Semantics] | +------+-------------------+-----------------+----------------+
+------+-------------------+--------------------+-------------------+
Table 4
9.9.2. Upgrade Token Registry 9.9.2. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at protocols in the Upgrade header field. The registry is maintained at
<https://www.iana.org/assignments/http-upgrade-tokens>. <https://www.iana.org/assignments/http-upgrade-tokens>.
Each registered protocol name is associated with contact information Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection and an optional set of specifications that details how the connection
skipping to change at page 40, line 26 skipping to change at page 40, line 37
Subtype name: http Subtype name: http
Required parameters: N/A Required parameters: N/A
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed message (e.g., version: The HTTP-version number of the enclosed message (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type - "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: see Section 11 Security considerations: see Section 11
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 10.1). Published specification: This specification (see Section 10.1).
Applications that use this media type: N/A Applications that use this media type: N/A
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Magic number(s): N/A
Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A
Deprecated alias names for this type: N/A File extension(s): N/A
File extension(s): N/A Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: Person and email address to contact for further information: See Aut
See Authors' Addresses section. hors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
10.2. Media Type application/http 10.2. Media Type application/http
skipping to change at page 41, line 34 skipping to change at page 41, line 40
Subtype name: http Subtype name: http
Required parameters: N/A Required parameters: N/A
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed messages (e.g., version: The HTTP-version number of the enclosed messages (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type - "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via email. is required when transmitted via email.
Security considerations: see Section 11 Security considerations: see Section 11
Interoperability considerations: N/A Interoperability considerations: N/A
skipping to change at page 41, line 45 skipping to change at page 42, line 4
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via email. is required when transmitted via email.
Security considerations: see Section 11 Security considerations: see Section 11
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 10.2). Published specification: This specification (see Section 10.2).
Applications that use this media type: N/A Applications that use this media type: N/A
Fragment identifier considerations: N/A
Additional information: Fragment identifier considerations: N/A
Deprecated alias names for this type: N/A Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: Person and email address to contact for further information: See Aut
See Authors' Addresses section. hors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
11. Security Considerations 11. Security Considerations
skipping to change at page 45, line 26 skipping to change at page 45, line 26
with the registration procedure of Section 9.9.2 and the upgrade with the registration procedure of Section 9.9.2 and the upgrade
token names summarized in the table of Section 9.9.1. token names summarized in the table of Section 9.9.1.
12.5. ALPN Protocol ID Registration 12.5. ALPN Protocol ID Registration
Please update the "TLS Application-Layer Protocol Negotiation (ALPN) Please update the "TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs" registry at <https://www.iana.org/assignments/tls- Protocol IDs" registry at <https://www.iana.org/assignments/tls-
extensiontype-values/tls-extensiontype-values.xhtml> with the extensiontype-values/tls-extensiontype-values.xhtml> with the
registration below: registration below:
+----------+--------------------------------------+-----------------+ +----------+-----------------------------+----------------+
| Protocol | Identification Sequence | Reference | | Protocol | Identification Sequence | Reference |
+----------+--------------------------------------+-----------------+ | HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | (this |
| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e | (this | | | 0x31 0x2e 0x31 ("http/1.1") | specification) |
| | 0x31 ("http/1.1") | specification) | +----------+-----------------------------+----------------+
+----------+--------------------------------------+-----------------+
Table 5
13. References 13. References
13.1. Normative References 13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-09 (work in Ed., "HTTP Caching", Work in Progress, Internet-Draft,
progress), July 2020. draft-ietf-httpbis-cache-10, July 12, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-10>.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
Specification version 3.3", RFC 1950, Format Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P., and
Randers-Pehrson, "GZIP file format specification version G. Randers-Pehrson, "GZIP file format specification
4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
skipping to change at page 46, line 38 skipping to change at page 46, line 38
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] 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/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-09 Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
(work in progress), July 2020. draft-ietf-httpbis-semantics-10, July 12, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
10>.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T. A., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
13.2. Informative References 13.2. Informative References
[Err4667] RFC Errata, Erratum ID 4667, RFC 7230, [Err4667] RFC Errata, Erratum ID 4667, RFC 7230,
<https://www.rfc-editor.org/errata/eid4667>. <https://www.rfc-editor.org/errata/eid4667>.
[Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting, [Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,
Web Cache Poisoning Attacks, and Related Topics", March Web Cache Poisoning Attacks, and Related Topics", March
2004, <http://packetstormsecurity.com/papers/general/ 2004, <http://packetstormsecurity.com/papers/general/
whitepaper_httpresponse.pdf>. whitepaper_httpresponse.pdf>.
[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
Request Smuggling", June 2005, Request Smuggling", June 2005,
<http://www.watchfire.com/news/whitepapers.aspx>. <http://www.watchfire.com/news/whitepapers.aspx>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen,
Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>. <https://www.rfc-editor.org/info/rfc1945>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/info/rfc2049>. <https://www.rfc-editor.org/info/rfc2049>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, DOI 10.17487/RFC2068, January 1997, RFC 2068, DOI 10.17487/RFC2068, January 1997,
<https://www.rfc-editor.org/info/rfc2068>. <https://www.rfc-editor.org/info/rfc2068>.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML "MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Message Syntax and Routing", Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Transfer Protocol (HTTP/1.1): Semantics and Content",
DOI 10.17487/RFC7231, June 2014, RFC 7231, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
skipping to change at page 59, line 16 skipping to change at page 58, line 33
o In Section 2.2, disallow bare CRs (<https://github.com/httpwg/ o In Section 2.2, disallow bare CRs (<https://github.com/httpwg/
http-core/issues/31>) http-core/issues/31>)
o Appendix A now uses the sender variant of the "#" list expansion o Appendix A now uses the sender variant of the "#" list expansion
(<https://github.com/httpwg/http-core/issues/192>) (<https://github.com/httpwg/http-core/issues/192>)
o In Section 5, adjust IANA "Close" entry for new registry format o In Section 5, adjust IANA "Close" entry for new registry format
(<https://github.com/httpwg/http-core/issues/273>) (<https://github.com/httpwg/http-core/issues/273>)
Index D.11. Since draft-ietf-httpbis-messaging-09
A
absolute-form (of request-target) 11
application/http Media Type 41
asterisk-form (of request-target) 12
authority-form (of request-target) 12
C
Connection header field 29, 34
Content-Length header field 19
Content-Transfer-Encoding header field 52
chunked (Coding Format) 18, 20
chunked (transfer coding) 23
close 29, 34
compress (transfer coding) 26
D
deflate (transfer coding) 26
F
Fields
Connection 29
MIME-Version 51
TE 27
Transfer-Encoding 18
Upgrade 36
G
Grammar
absolute-form 10-11
ALPHA 5
asterisk-form 10, 12
authority-form 10, 12
chunk 23
chunk-data 23
chunk-ext 23-24
chunk-ext-name 24
chunk-ext-val 24
chunk-size 23
chunked-body 23
Connection 30
connection-option 30
CR 5
CRLF 5
CTL 5
DIGIT 5
DQUOTE 5
field-line 15, 25
field-name 15
field-value 15
HEXDIG 5
HTAB 5
HTTP-message 6
HTTP-name 8
HTTP-version 8
last-chunk 23
LF 5
message-body 17
method 10
obs-fold 16
OCTET 5
origin-form 10
rank 27
reason-phrase 15
request-line 9
request-target 10
SP 5
start-line 6
status-code 15
status-line 14
t-codings 27
t-ranking 27
TE 27
trailer-section 23, 25
transfer-coding 22
Transfer-Encoding 18
transfer-parameter 22
Upgrade 37
VCHAR 5
gzip (transfer coding) 26
H
Header Fields
Connection 29
MIME-Version 51
TE 27
Transfer-Encoding 18
Upgrade 36
header line 6
header section 6
headers 6
M
MIME-Version header field 51
Media Type
application/http 41
message/http 40
message/http Media Type 40
method 10
O
origin-form (of request-target) 10
R
request-target 10
T
TE header field 27
Transfer-Encoding header field 18
U
Upgrade header field 36
X o Switch to xml2rfc v3 mode for draft generation
x-compress (transfer coding) 26 (<https://github.com/httpwg/http-core/issues/394>)
x-gzip (transfer coding) 26
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
United States of America United States of America
EMail: fielding@gbiv.com Email: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
EMail: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster 48155 48155 M√ľnster
Germany Germany
EMail: julian.reschke@greenbytes.de Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/ URI: https://greenbytes.de/tech/webdav/
 End of changes. 65 change blocks. 
270 lines changed or deleted 155 lines changed or added

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