draft-ietf-httpbis-messaging-14.txt   draft-ietf-httpbis-messaging-latest.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: July 17, 2021 J. Reschke, Ed. Expires: September 7, 2021 J. Reschke, Ed.
greenbytes greenbytes
January 13, 2021 March 6, 2021
HTTP/1.1 HTTP/1.1
draft-ietf-httpbis-messaging-14 draft-ietf-httpbis-messaging-latest
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.15. The changes in this draft are summarized in Appendix D.16.
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 July 17, 2021. This Internet-Draft will expire on September 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 6 skipping to change at page 3, line 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 . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16 5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23
7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 23 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 24
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
7.2. Transfer Codings for Compression . . . . . . . . . . . . 24 7.2. Transfer Codings for Compression . . . . . . . . . . . . 25
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. Negotiating Transfer Codings . . . . . . . . . . . . . . 25 7.4. Negotiating Transfer Codings . . . . . . . . . . . . . . 26
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 27 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Associating a Response to a Request . . . . . . . . . . . 28 9.2. Associating a Response to a Request . . . . . . . . . . . 28
9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 28 9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29
9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 29 9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30
9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 29 9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 30
9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 30 9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31
9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 31 9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 31 9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 32
9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 33 9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 34
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 33 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 34
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 34 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 35
10.1. Media Type message/http . . . . . . . . . . . . . . . . 34 10.1. Media Type message/http . . . . . . . . . . . . . . . . 35
10.2. Media Type application/http . . . . . . . . . . . . . . 35 10.2. Media Type application/http . . . . . . . . . . . . . . 36
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 36 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 37
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 37 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 38
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 38 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 39
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 38 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
12.1. Field Name Registration . . . . . . . . . . . . . . . . 39 12.1. Field Name Registration . . . . . . . . . . . . . . . . 40
12.2. Media Type Registration . . . . . . . . . . . . . . . . 39 12.2. Media Type Registration . . . . . . . . . . . . . . . . 40
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 39 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 40
12.4. ALPN Protocol ID Registration . . . . . . . . . . . . . 40 12.4. ALPN Protocol ID Registration . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 43 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 44
Appendix B. Differences between HTTP and MIME . . . . . . . . . 45 Appendix B. Differences between HTTP and MIME . . . . . . . . . 46
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 45 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 46
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 45 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 46
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 46 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 47
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 46 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 47
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 46 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 47
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 46 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 47
Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 47 Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 48
C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 47 C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 48
C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 47 C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 48
C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 47 C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 48
C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 47 C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 48
C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 48 C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 49
C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 48 C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 49
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 49 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 50
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 49 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 50
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 49 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 50
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 50 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 51
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 50 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 51
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 51 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 52
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 51 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 52
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 51 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 52
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 52 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 53
D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 52 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 53
D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 52 D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 53
D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 53 D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 54
D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 53 D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 54
D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 53 D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 54
D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 53 D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 54
D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 54 D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 55
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.16. Since draft-ietf-httpbis-messaging-14 . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
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/1.1 is defined by: hypertext information systems. HTTP/1.1 is defined by:
o This document o This document
skipping to change at page 8, line 25 skipping to change at page 8, line 25
after it as a new request, either of which might result in a security after it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or such whitespace in a response might be ignored by some clients or
cause others to cease parsing. cause others to cease parsing.
When a server listening only for HTTP request messages, or processing When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message, what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server grammar aside from the robustness exceptions listed above, the server
SHOULD respond with a 400 (Bad Request) response. SHOULD respond with a 400 (Bad Request) response and close the
connection.
2.3. HTTP Version 2.3. HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". of the protocol. This specification defines version "1.1".
Section 2.5 of [Semantics] specifies the semantics of HTTP version Section 2.5 of [Semantics] specifies the semantics of HTTP version
numbers. numbers.
The version of an HTTP/1.x message is indicated by an HTTP-version The version of an HTTP/1.x message is indicated by an HTTP-version
field in the start-line. HTTP-version is case-sensitive. field in the start-line. HTTP-version is case-sensitive.
skipping to change at page 8, line 51 skipping to change at page 8, line 52
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0 constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1. the recipient supports HTTP/1.1.
Intermediaries that process HTTP messages (i.e., all intermediaries Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) MUST send their own HTTP-version other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they are not allowed to in forwarded messages, unless it is purposefully downgraded as a
blindly forward the start-line without ensuring that the protocol workaround for an upstream issue. In other words, an intermediary is
version in that message matches a version to which that intermediary not allowed to blindly forward the start-line without ensuring that
is conformant for both the receiving and sending of messages. the protocol version in that message matches a version to which that
Forwarding an HTTP message without rewriting the HTTP-version might intermediary is conformant for both the receiving and sending of
result in communication errors when downstream recipients use the messages. Forwarding an HTTP message without rewriting the HTTP-
message sender's version to determine what features are safe to use version might result in communication errors when downstream
for later communication with that sender. recipients use the message sender's version to determine what
features are safe to use for later communication with that sender.
A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it
is known or suspected that the client incorrectly implements the HTTP is known or suspected that the client incorrectly implements the HTTP
specification and is incapable of correctly processing later version specification and is incapable of correctly processing later version
responses, such as when a client fails to parse the version number responses, such as when a client fails to parse the version number
correctly or when an intermediary is known to blindly forward the correctly or when an intermediary is known to blindly forward the
HTTP-version even when it doesn't conform to the given minor version HTTP-version even when it doesn't conform to the given minor version
of the protocol. Such protocol downgrades SHOULD NOT be performed of the protocol. Such protocol downgrades SHOULD NOT be performed
unless triggered by specific client attributes, such as when one or unless triggered by specific client attributes, such as when one or
more of the request header fields (e.g., User-Agent) uniquely match more of the request header fields (e.g., User-Agent) uniquely match
skipping to change at page 19, line 29 skipping to change at page 19, line 44
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 potential content. For messages that decimal number of octets, for potential content. For messages that
do include content, the Content-Length field value provides the do include content, the Content-Length field value provides the
framing information necessary for determining where the data (and framing information necessary for determining where the data (and
message) ends. For messages that do not include content, the message) ends. For messages that do not include content, the
Content-Length indicates the size of the selected representation Content-Length indicates the size of the selected representation
(Section 8.6 of [Semantics]). (Section 8.6 of [Semantics]).
A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field.
| *Note:* HTTP's use of Content-Length for message framing | *Note:* HTTP's use of Content-Length for message framing
| differs significantly from the same field's use in MIME, where | differs significantly from the same field's use in MIME, where
| it is an optional field used only within the "message/external- | it is an optional field used only within the "message/external-
| body" media-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
message, and thus cannot contain a message body or trailer message, and thus cannot contain a message body or trailer
section(s). section.
2. Any 2xx (Successful) response to a CONNECT request implies that 2. Any 2xx (Successful) response to a CONNECT request implies that
the connection will become a tunnel immediately after the empty the connection will become a tunnel immediately after the empty
line that concludes the header fields. A client MUST ignore any line that concludes the header fields. A client MUST ignore any
Content-Length or Transfer-Encoding header fields received in Content-Length or Transfer-Encoding header fields received in
such a message. such a message.
3. If a message is received with both a Transfer-Encoding and a 3. If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to Content-Length. Such a message might indicate an attempt to
skipping to change at page 21, line 38 skipping to change at page 22, line 16
client that sends a request containing a message body SHOULD use a client that sends a request containing a message body SHOULD use a
valid Content-Length header field if the message body length is known valid Content-Length header field if the message body length is known
in advance, rather than the chunked transfer coding, since some in advance, rather than the chunked transfer coding, since some
existing services respond to chunked with a 411 (Length Required) existing services respond to chunked with a 411 (Length Required)
status code even though they understand the chunked transfer coding. status code even though they understand the chunked transfer coding.
This is typically because such services are implemented via a gateway This is typically because such services are implemented via a gateway
that requires a content-length in advance of being called and the that requires a content-length in advance of being called and the
server is unable or unwilling to buffer the entire request before server is unable or unwilling to buffer the entire request before
processing. processing.
A user agent that sends a request containing a message body MUST send A user agent that sends a request that contains a message body MUST
a valid Content-Length header field if it does not know the server send either a valid Content-Length header field or use the chunked
will handle HTTP/1.1 (or later) requests; such knowledge can be in transfer coding. A client MUST NOT use the chunked transfer encoding
the form of specific user configuration or by remembering the version unless it knows the server will handle HTTP/1.1 (or later) requests;
of a prior received response. such knowledge can be in the form of specific user configuration or
by remembering the version of a prior received response.
If the final response to the last request on a connection has been If the final response to the last request on a connection has been
completely received and there remains additional data to read, a user completely received and there remains additional data to read, a user
agent MAY discard the remaining data or attempt to determine if that agent MAY discard the remaining data or attempt to determine if that
data belongs as part of the prior message body, which might be the data belongs as part of the prior message body, which might be the
case if the prior message's Content-Length value is incorrect. A case if the prior message's Content-Length value is incorrect. A
client MUST NOT process, cache, or forward such extra data as a client MUST NOT process, cache, or forward such extra data as a
separate response, since such behavior would be vulnerable to cache separate response, since such behavior would be vulnerable to cache
poisoning. poisoning.
skipping to change at page 22, line 50 skipping to change at page 23, line 35
chunk-data = 1*OCTET ; a sequence of chunk-size octets chunk-data = 1*OCTET ; a sequence of chunk-size octets
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked transfer coding is complete the chunk-data in octets. The chunked transfer coding is complete
when a chunk with a chunk-size of zero is received, possibly followed when a chunk with a chunk-size of zero is received, possibly followed
by a trailer section, and finally terminated by an empty line. by a trailer section, and finally terminated by an empty line.
A recipient MUST be able to parse and decode the chunked transfer A recipient MUST be able to parse and decode the chunked transfer
coding. coding.
Note that HTTP/1.1 does not define any means to limit the size of a HTTP/1.1 does not define any means to limit the size of a chunked
chunked response such that an intermediary can be assured of response such that an intermediary can be assured of buffering the
buffering the entire response. entire response. Additionally, very large chunk sizes may cause
overflows or loss of precision if their values are not represented
accurately in a receiving implementation. Therefore, recipients MUST
anticipate potentially large decimal numerals and prevent parsing
errors due to integer conversion overflows or precision loss due to
integer representation.
The chunked encoding does not define any parameters. Their presence The chunked encoding does not define any parameters. Their presence
SHOULD be treated as an error. SHOULD be treated as an error.
7.1.1. Chunk Extensions 7.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
extensions, immediately following the chunk-size, for the sake of extensions, immediately following the chunk-size, for the sake of
supplying per-chunk metadata (such as a signature or hash), mid- supplying per-chunk metadata (such as a signature or hash), mid-
message control information, or randomization of message body size. message control information, or randomization of message body size.
skipping to change at page 25, line 48 skipping to change at page 26, line 36
transfer coding defined in this specification. transfer coding defined in this specification.
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
7.4. Negotiating Transfer Codings 7.4. Negotiating Transfer Codings
The TE field (Section 10.1.4 of [Semantics]) is used in HTTP/1.1 to The TE field (Section 10.1.4 of [Semantics]) is used in HTTP/1.1 to
indicate what transfer-codings, besides chunked, the client is indicate what transfer-codings, besides chunked, the client is
willing to accept in the response, and whether or not the client is willing to accept in the response, and whether or not the client is
willing to accept trailer fields in a chunked transfer coding. willing to preserve trailer fields in a chunked transfer coding.
A client MUST NOT send the chunked transfer coding name in TE; A client MUST NOT send the chunked transfer coding name in TE;
chunked is always acceptable for HTTP/1.1 recipients. chunked is always acceptable for HTTP/1.1 recipients.
Three examples of TE use are below. Three examples of TE use are below.
TE: deflate TE: deflate
TE: TE:
TE: trailers, deflate;q=0.5 TE: trailers, deflate;q=0.5
skipping to change at page 27, line 6 skipping to change at page 27, line 42
fields to convey the full meaning of the response, then the client fields to convey the full meaning of the response, then the client
cannot assume that meaning has been conveyed; the client might need cannot assume that meaning has been conveyed; the client might need
to repeat the request in order to determine what action to take next. to repeat the request in order to determine what action to take next.
A message body that uses the chunked transfer coding is incomplete if A message body that uses the chunked transfer coding is incomplete if
the zero-sized chunk that terminates the encoding has not been the zero-sized chunk that terminates the encoding has not been
received. A message that uses a valid Content-Length is incomplete received. A message that uses a valid Content-Length is incomplete
if the size of the message body received (in octets) is less than the if the size of the message body received (in octets) is less than the
value given by Content-Length. A response that has neither chunked value given by Content-Length. A response that has neither chunked
transfer coding nor Content-Length is terminated by closure of the transfer coding nor Content-Length is terminated by closure of the
connection and, thus, is considered complete regardless of the number connection and, if the header section was received intact, is
of message body octets received, provided that the header section was considered complete unless an error was indicated by the underlying
received intact. connection (e.g., an "incomplete close" in TLS would leave the
response incomplete, as described in Section 9.8).
9. Connection Management 9. Connection Management
HTTP messaging is independent of the underlying transport- or HTTP messaging is independent of the underlying transport- or
session-layer connection protocol(s). HTTP only presumes a reliable session-layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport response structures onto the data units of an underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
skipping to change at page 31, line 35 skipping to change at page 32, line 31
time. For example, a client might have started to send a new request time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle" at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a closed while it was idle, but from the client's point of view, a
request is in progress. request is in progress.
A server SHOULD sustain persistent connections, when possible, and A server SHOULD sustain persistent connections, when possible, and
allow the underlying transport's flow-control mechanisms to resolve allow the underlying transport's flow-control mechanisms to resolve
temporary overloads, rather than terminate connections with the temporary overloads, rather than terminate connections with the
expectation that clients will retry. The latter technique can expectation that clients will retry. The latter technique can
exacerbate network congestion. exacerbate network congestion or server load.
A client sending a message body SHOULD monitor the network connection A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
9.6. Tear-down 9.6. Tear-down
skipping to change at page 33, line 32 skipping to change at page 34, line 26
as a persistent connection). as a persistent connection).
9.8. TLS Connection Closure 9.8. TLS Connection Closure
TLS provides a facility for secure connection closure. When a valid TLS provides a facility for secure connection closure. When a valid
closure alert is received, an implementation can be assured that no closure alert is received, an implementation can be assured that no
further data will be received on that connection. TLS further data will be received on that connection. TLS
implementations MUST initiate an exchange of closure alerts before implementations MUST initiate an exchange of closure alerts before
closing a connection. A TLS implementation MAY, after sending a closing a connection. A TLS implementation MAY, after sending a
closure alert, close the connection without waiting for the peer to closure alert, close the connection without waiting for the peer to
send its closure alert, generating an "incomplete close". Note that send its closure alert, generating an "incomplete close". This
an implementation which does this MAY choose to reuse the session. SHOULD only be done when the application knows (typically through
This SHOULD only be done when the application knows (typically detecting HTTP message boundaries) that it has sent or received all
through detecting HTTP message boundaries) that it has received all
the message data that it cares about. the message data that it cares about.
As specified in [RFC8446], any implementation which receives a An incomplete close does not call into question the security of the
connection close without first receiving a valid closure alert (a data already received, but it could indicate that subsequent data
"premature close") MUST NOT reuse that session. Note that a might have been truncated. As TLS is not directly aware of HTTP
premature close does not call into question the security of the data message framing, it is necessary to examine the HTTP data itself to
already received, but simply indicates that subsequent data might determine whether messages were complete. Handing of incomplete
have been truncated. Because TLS is oblivious to HTTP request/ messages is defined in Section 8.
response boundaries, it is necessary to examine the HTTP data itself
(specifically the Content-Length header) to determine whether the
truncation occurred inside a message or between messages.
When encountering a premature close, a client SHOULD treat as When encountering an incomplete close, a client SHOULD treat as
completed all requests for which it has received as much data as completed all requests for which it has received as much data as
specified in the Content-Length header. specified in the Content-Length header or, when a Transfer-Encoding
of chunked is used, for which the terminal zero-length chunk has been
received. A response that has neither chunked transfer coding nor
Content-Length is complete only if a valid closure alert has been
received. Treating an incomplete message as complete could expose
implementations to attack.
A client detecting an incomplete close SHOULD recover gracefully. It A client detecting an incomplete close SHOULD recover gracefully.
MAY resume a TLS session closed in this fashion.
Clients MUST send a closure alert before closing the connection. Clients MUST send a closure alert before closing the connection.
Clients which are unprepared to receive any more data MAY choose not Clients that do not expect to receive any more data MAY choose not to
to wait for the server's closure alert and simply close the wait for the server's closure alert and simply close the connection,
connection, thus generating an incomplete close on the server side. thus generating an incomplete close on the server side.
Servers SHOULD be prepared to receive an incomplete close from the Servers SHOULD be prepared to receive an incomplete close from the
client, since the client can often determine when the end of server client, since the client can often determine when the end of server
data is. Servers SHOULD be willing to resume TLS sessions closed in data is.
this fashion.
Servers MUST attempt to initiate an exchange of closure alerts with Servers MUST attempt to initiate an exchange of closure alerts with
the client before closing the connection. Servers MAY close the the client before closing the connection. Servers MAY close the
connection after sending the closure alert, thus generating an connection after sending the closure alert, thus generating an
incomplete close on the client side. incomplete close on the client side.
10. Enclosing Messages as Data 10. Enclosing Messages as Data
10.1. Media Type message/http 10.1. Media Type message/http
skipping to change at page 38, line 10 skipping to change at page 39, line 10
This specification has introduced new requirements on request This specification has introduced new requirements on request
parsing, particularly with regard to message framing in Section 6.3, parsing, particularly with regard to message framing in Section 6.3,
to reduce the effectiveness of request smuggling. to reduce the effectiveness of request smuggling.
11.3. Message Integrity 11.3. Message Integrity
HTTP does not define a specific mechanism for ensuring message HTTP does not define a specific mechanism for ensuring message
integrity, instead relying on the error-detection ability of integrity, instead relying on the error-detection ability of
underlying transport protocols and the use of length or chunk- underlying transport protocols and the use of length or chunk-
delimited framing to detect completeness. Additional integrity delimited framing to detect completeness. Historically, the lack of
mechanisms, such as hash functions or digital signatures applied to a single integrity mechanism has been justified by the informal
the content, can be selectively added to messages via extensible nature of most HTTP communication. However, the prevalence of HTTP
metadata fields. Historically, the lack of a single integrity as an information access mechanism has resulted in its increasing use
mechanism has been justified by the informal nature of most HTTP within environments where verification of message integrity is
communication. However, the prevalence of HTTP as an information crucial.
access mechanism has resulted in its increasing use within
environments where verification of message integrity is crucial.
User agents are encouraged to implement configurable means for The mechanisms provided with the "https" scheme, such as
detecting and reporting failures of message integrity such that those authenticated encryption, provide protection against modification of
means can be enabled within environments for which integrity is messages. Care is needed however to ensure that connection closure
necessary. For example, a browser being used to view medical history cannot be used to truncate messages (see Section 9.8). User agents
or drug interaction information needs to indicate to the user when might refuse to accept incomplete messages or treat them specially.
such information is detected by the protocol to be incomplete, For example, a browser being used to view medical history or drug
expired, or corrupted during transfer. Such mechanisms might be interaction information needs to indicate to the user when such
selectively enabled via user agent extensions or the presence of information is detected by the protocol to be incomplete, expired, or
message integrity metadata in a response. At a minimum, user agents corrupted during transfer. Such mechanisms might be selectively
ought to provide some indication that allows a user to distinguish enabled via user agent extensions or the presence of message
between a complete and incomplete response message (Section 8) when integrity metadata in a response.
such verification is desired.
The "http" scheme provides no protection against accidental or
malicious modification of messages.
Extensions to the protocol might be used to mitigate the risk of
unwanted modification of messages by intermediaries, even when the
"https" scheme is used. Integrity might be assured by using hash
functions or digital signatures that are selectively added to
messages via extensible metadata fields.
11.4. Message Confidentiality 11.4. Message Confidentiality
HTTP relies on underlying transport protocols to provide message HTTP relies on underlying transport protocols to provide message
confidentiality when that is desired. HTTP has been specifically confidentiality when that is desired. HTTP has been specifically
designed to be independent of the transport protocol, such that it designed to be independent of the transport protocol, such that it
can be used over many different forms of encrypted connection, with can be used over many different forms of encrypted connection, with
the selection of such transports being identified by the choice of the selection of such transports being identified by the choice of
URI scheme or within user agent configuration. URI scheme or within user agent configuration.
skipping to change at page 41, line 7 skipping to change at page 42, line 7
+----------+-----------------------------+----------------+ +----------+-----------------------------+----------------+
Table 3 Table 3
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. Reschke,
Ed., "HTTP Caching", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cache-latest, January 2021, draft-ietf-httpbis-cache-latest, March 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache- <https://tools.ietf.org/html/draft-ietf-httpbis-cache-
latest>. latest>.
[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
Format 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,
skipping to change at page 42, line 8 skipping to change at page 43, line 8
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. Reschke,
Ed., "HTTP Semantics", Work in Progress, Internet-Draft, Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
draft-ietf-httpbis-semantics-latest, January 2021, draft-ietf-httpbis-semantics-latest, March 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
latest>. latest>.
[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., "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.
skipping to change at page 45, line 38 skipping to change at page 46, line 38
MIME protocol was used to construct the message. Use of the MIME- MIME protocol was used to construct the message. Use of the MIME-
Version header field indicates that the message is in full Version header field indicates that the message is in full
conformance with the MIME protocol (as defined in [RFC2045]). conformance with the MIME protocol (as defined in [RFC2045]).
Senders are responsible for ensuring full conformance (where Senders are responsible for ensuring full conformance (where
possible) when exporting HTTP messages to strict MIME environments. possible) when exporting HTTP messages to strict MIME environments.
B.2. Conversion to Canonical Form B.2. Conversion to Canonical Form
MIME requires that an Internet mail body part be converted to MIME requires that an Internet mail body part be converted to
canonical form prior to being transferred, as described in Section 4 canonical form prior to being transferred, as described in Section 4
of [RFC2049]. Appendix of [Semantics] describes the forms allowed of [RFC2049], and that content with a type of "text" represent line
for subtypes of the "text" media type when transmitted over HTTP. breaks as CRLF, forbidding the use of CR or LF outside of line break
[RFC2046] requires that content with a type of "text" represent line sequences [RFC2046]. In contrast, HTTP does not care whether CRLF,
breaks as CRLF and forbids the use of CR or LF outside of line break bare CR, or bare LF are used to indicate a line break within content.
sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line
break within text content.
A proxy or gateway from HTTP to a strict MIME environment ought to A proxy or gateway from HTTP to a strict MIME environment ought to
translate all line breaks within text media types to the RFC 2049 translate all line breaks within text media types to the RFC 2049
canonical form of CRLF. Note, however, this might be complicated by canonical form of CRLF. Note, however, this might be complicated by
the presence of a Content-Encoding and by the fact that HTTP allows the presence of a Content-Encoding and by the fact that HTTP allows
the use of some charsets that do not use octets 13 and 10 to the use of some charsets that do not use octets 13 and 10 to
represent CR and LF, respectively. represent CR and LF, respectively.
Conversion will break any cryptographic checksums applied to the Conversion will break any cryptographic checksums applied to the
original content unless the original content is already in canonical original content unless the original content is already in canonical
skipping to change at page 54, line 31 skipping to change at page 55, line 31
both Content-Length and Transfer-Encoding, before processing both Content-Length and Transfer-Encoding, before processing
Transfer-Encoding, and that ought to be treated as an error, but Transfer-Encoding, and that ought to be treated as an error, but
an intermediary can choose to forward the message downstream after an intermediary can choose to forward the message downstream after
removing the Content-Length and processing the Transfer-Encoding removing the Content-Length and processing the Transfer-Encoding
(<https://github.com/httpwg/http-core/issues/617>) (<https://github.com/httpwg/http-core/issues/617>)
o Changed to using "content" instead of "payload" or "payload data" o Changed to using "content" instead of "payload" or "payload data"
to avoid confusion with the payload of version-specific messaging to avoid confusion with the payload of version-specific messaging
frames (<https://github.com/httpwg/http-core/issues/654>) frames (<https://github.com/httpwg/http-core/issues/654>)
D.16. Since draft-ietf-httpbis-messaging-14
o In Section 7.1, clarify large chunk handling issues
(<https://github.com/httpwg/http-core/issues/749>)
o In Section 2.2, explicitly close the connection after sending a
400 (<https://github.com/httpwg/http-core/issues/750>)
o In Section 2.3, refine version requirements for intermediaries
(<https://github.com/httpwg/http-core/issues/751>)
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)
 End of changes. 36 change blocks. 
147 lines changed or deleted 173 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/