draft-ietf-httpbis-messaging-17.txt   draft-ietf-httpbis-messaging-18.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: 27 January 2022 J. Reschke, Ed. Expires: 19 February 2022 J. Reschke, Ed.
greenbytes greenbytes
26 July 2021 18 August 2021
HTTP/1.1 HTTP/1.1
draft-ietf-httpbis-messaging-17 draft-ietf-httpbis-messaging-18
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.18. The changes in this draft are summarized in Appendix D.19.
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 27 January 2022. This Internet-Draft will expire on 19 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 22 skipping to change at page 3, line 22
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 20 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 20
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 23 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . 25 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. Negotiating Transfer Codings . . . . . . . . . . . . . . 27 7.4. Negotiating Transfer Codings . . . . . . . . . . . . . . 27
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 29
9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Associating a Response to a Request . . . . . . . . . . . 29 9.2. Associating a Response to a Request . . . . . . . . . . . 29
9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30 9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31 9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32 9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33 9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 34 9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 35
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 36 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 36
10.1. Media Type message/http . . . . . . . . . . . . . . . . 36 10.1. Media Type message/http . . . . . . . . . . . . . . . . 36
10.2. Media Type application/http . . . . . . . . . . . . . . 37 10.2. Media Type application/http . . . . . . . . . . . . . . 37
11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 38 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 38
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 39 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 39
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 39 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 40
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 40 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 40
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12.1. Field Name Registration . . . . . . . . . . . . . . . . 40 12.1. Field Name Registration . . . . . . . . . . . . . . . . 41
12.2. Media Type Registration . . . . . . . . . . . . . . . . 41 12.2. Media Type Registration . . . . . . . . . . . . . . . . 41
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 41 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 41
12.4. ALPN Protocol ID Registration . . . . . . . . . . . . . 42 12.4. ALPN Protocol ID Registration . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 45
Appendix B. Differences between HTTP and MIME . . . . . . . . . 46 Appendix B. Differences between HTTP and MIME . . . . . . . . . 47
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 46 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 47
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 47 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 47
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 47 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 47 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 48
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 47 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 48
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 48 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 48
Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 48 Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 49
C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 48 C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 49
C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 48 C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 49
C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 48 C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 49
C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 49 C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 49
C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 49 C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 50
C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 50 C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 50
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 50 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 51
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 50 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 51
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 51 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 51
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 51 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 52
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 52 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 52
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 52 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 53
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 52 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 53
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 53 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 53
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 53 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 54
D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 53 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 54
D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 54 D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 54
D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 54 D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 55
D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 54 D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 55
D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 55 D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 55
D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 55 D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 55
D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 55 D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 56
D.16. Since draft-ietf-httpbis-messaging-14 . . . . . . . . . . 55 D.16. Since draft-ietf-httpbis-messaging-14 . . . . . . . . . . 56
D.17. Since draft-ietf-httpbis-messaging-15 . . . . . . . . . . 56 D.17. Since draft-ietf-httpbis-messaging-15 . . . . . . . . . . 57
D.18. Since draft-ietf-httpbis-messaging-16 . . . . . . . . . . 56 D.18. Since draft-ietf-httpbis-messaging-16 . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56 D.19. Since draft-ietf-httpbis-messaging-17 . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
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:
* This document * This document
skipping to change at page 6, line 27 skipping to change at page 6, line 27
The rules below are defined in [URI]: The rules below are defined in [URI]:
absolute-URI = <absolute-URI, see [URI], Section 4.3> absolute-URI = <absolute-URI, see [URI], Section 4.3>
authority = <authority, see [URI], Section 3.2> authority = <authority, see [URI], Section 3.2>
uri-host = <host, see [URI], Section 3.2.2> uri-host = <host, see [URI], Section 3.2.2>
port = <port, see [URI], Section 3.2.3> port = <port, see [URI], Section 3.2.3>
query = <query, see [URI], Section 3.4> query = <query, see [URI], Section 3.4>
2. Message 2. Message
HTTP/1.1 communication consists of sending stateless request and HTTP/1.1 clients and servers communicate by sending messages. See
response messages across a connection. See Section 3 of [HTTP] for Section 3 of [HTTP] for the general terminology and core concepts of
the general terminology and core concepts of HTTP. HTTP.
2.1. Message Format 2.1. Message Format
An HTTP/1.1 message consists of a start-line followed by a CRLF and a An HTTP/1.1 message consists of a start-line followed by a CRLF and a
sequence of octets in a format similar to the Internet Message Format sequence of octets in a format similar to the Internet Message Format
[RFC5322]: zero or more header field lines (collectively referred to [RFC5322]: zero or more header field lines (collectively referred to
as the "headers" or the "header section"), an empty line indicating as the "headers" or the "header section"), an empty line indicating
the end of the header section, and an optional message body. the end of the header section, and an optional message body.
HTTP-message = start-line CRLF HTTP-message = start-line CRLF
skipping to change at page 8, line 10 skipping to change at page 8, line 10
terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
or follow a request with an extra CRLF. If terminating the request or follow a request with an extra CRLF. If terminating the request
message body with a line-ending is desired, then the user agent MUST message body with a line-ending is desired, then the user agent MUST
count the terminating CRLF octets as part of the message body length. count the terminating CRLF octets as part of the message body length.
In the interest of robustness, a server that is expecting to receive In the interest of robustness, a server that is expecting to receive
and parse a request-line SHOULD ignore at least one empty line (CRLF) and parse a request-line SHOULD ignore at least one empty line (CRLF)
received prior to the request-line. received prior to the request-line.
A sender MUST NOT send whitespace between the start-line and the A sender MUST NOT send whitespace between the start-line and the
first header field. A recipient that receives whitespace between the first header field.
start-line and the first header field MUST either reject the message
as invalid or consume each whitespace-preceded line without further
processing of it (i.e., ignore the entire line, along with any
subsequent lines preceded by whitespace, until a properly formed
header field is received or the header section is terminated).
The presence of such whitespace in a request might be an attempt to A recipient that receives whitespace between the start-line and the
trick a server into ignoring that field line or processing the line first header field MUST either reject the message as invalid or
after it as a new request, either of which might result in a security consume each whitespace-preceded line without further processing of
vulnerability if other implementations within the request chain it (i.e., ignore the entire line, along with any subsequent lines
interpret the same message differently. Likewise, the presence of preceded by whitespace, until a properly formed header field is
such whitespace in a response might be ignored by some clients or received or the header section is terminated). Rejection or removal
cause others to cease parsing. of invalid whitespace-preceded lines is necessary to prevent their
misinterpretation by downstream recipients that might be vulnerable
to request smuggling (Section 11.2) or response splitting
(Section 11.1) attacks.
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 and close the SHOULD respond with a 400 (Bad Request) response and close the
connection. connection.
2.3. HTTP Version 2.3. HTTP Version
skipping to change at page 14, line 51 skipping to change at page 14, line 51
"https"), the server can reject the request or determine whether a "https"), the server can reject the request or determine whether a
configured default applies that is consistent with the incoming configured default applies that is consistent with the incoming
connection's context. Context might include connection details like connection's context. Context might include connection details like
address and port, what security has been applied, and locally-defined address and port, what security has been applied, and locally-defined
information specific to that server's configuration. An empty information specific to that server's configuration. An empty
authority is replaced with the configured default before further authority is replaced with the configured default before further
processing of the request. processing of the request.
Supplying a default name for authority within the context of a Supplying a default name for authority within the context of a
secured connection is inherently unsafe if there is any chance that secured connection is inherently unsafe if there is any chance that
the user agent's intended authority might differ from the selected the user agent's intended authority might differ from the default. A
default. A server that can uniquely identify an authority from the server that can uniquely identify an authority from the request
request context MAY use that identity as a default without this risk. context MAY use that identity as a default without this risk.
Alternatively, it might be better to redirect the request to a safe Alternatively, it might be better to redirect the request to a safe
resource that explains how to obtain a new client. resource that explains how to obtain a new client.
Note that reconstructing the client's target URI is only half of the Note that reconstructing the client's target URI is only half of the
process for identifying a target resource. The other half is process for identifying a target resource. The other half is
determining whether that target URI identifies a resource for which determining whether that target URI identifies a resource for which
the server is willing and able to send a response, as defined in the server is willing and able to send a response, as defined in
Section 7.4 of [HTTP]. Section 7.4 of [HTTP].
4. Status Line 4. Status Line
skipping to change at page 15, line 36 skipping to change at page 15, line 36
the line terminator, treat any form of whitespace as the SP separator the line terminator, treat any form of whitespace as the SP separator
while ignoring preceding or trailing whitespace; such whitespace while ignoring preceding or trailing whitespace; such whitespace
includes one or more of the following octets: SP, HTAB, VT (%x0B), FF includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
(%x0C), or bare CR. However, lenient parsing can result in response (%x0C), or bare CR. However, lenient parsing can result in response
splitting security vulnerabilities if there are multiple recipients splitting security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of of the message and each has its own unique interpretation of
robustness (see Section 11.1). robustness (see Section 11.1).
The status-code element is a 3-digit integer code describing the The status-code element is a 3-digit integer code describing the
result of the server's attempt to understand and satisfy the client's result of the server's attempt to understand and satisfy the client's
corresponding request. The rest of the response message is to be corresponding request. A recipient parses and interprets the
interpreted in light of the semantics defined for that status code. remainder of the response message in light of the semantics defined
See Section 15 of [HTTP] for information about the semantics of for that status code, if the status code is recognized by that
status codes, including the classes of status code (indicated by the recipient, or in accordance with the class of that status code when
first digit), the status codes defined by this specification, the specific code is unrecognized.
considerations for the definition of new status codes, and the IANA
registry.
status-code = 3DIGIT status-code = 3DIGIT
HTTP's core status codes are defined in Section 15 of [HTTP], along
with the classes of status codes, considerations for the definition
of new status codes, and the IANA registry for collecting such
definitions.
The reason-phrase element exists for the sole purpose of providing a The reason-phrase element exists for the sole purpose of providing a
textual description associated with the numeric status code, mostly textual description associated with the numeric status code, mostly
out of deference to earlier Internet application protocols that were out of deference to earlier Internet application protocols that were
more frequently used with interactive text clients. more frequently used with interactive text clients.
reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
A client SHOULD ignore the reason-phrase content because it is not a A client SHOULD ignore the reason-phrase content because it is not a
reliable channel for information (it might be translated for a given reliable channel for information (it might be translated for a given
locale, overwritten by intermediaries, or discarded when the message locale, overwritten by intermediaries, or discarded when the message
skipping to change at page 16, line 36 skipping to change at page 16, line 43
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 field section has been processed). after the message's entire field 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
security vulnerabilities in request routing and response handling. A security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains server MUST reject, with a response status code of 400 (Bad Request),
whitespace between a header field name and colon with a response any received request message that contains whitespace between a
status code of 400 (Bad Request). A proxy MUST remove any such header field name and colon. A proxy MUST remove any such whitespace
whitespace from a response message before forwarding the message from a response message before forwarding the message downstream.
downstream.
A field line value might be preceded and/or followed by optional A field line value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field line value is whitespace (OWS); a single SP preceding the field line value is
preferred for consistent readability by humans. The field line value preferred for consistent readability by humans. The field line value
does not include any leading or trailing whitespace: OWS occurring does not include that leading or trailing whitespace: OWS occurring
before the first non-whitespace octet of the field line value or before the first non-whitespace octet of the field line value, or
after the last non-whitespace octet of the field line value ought to after the last non-whitespace octet of the field line value, is
be excluded by parsers when extracting the field line value from a excluded by parsers when extracting the field line value from a field
field line. line.
5.2. Obsolete Line Folding 5.2. Obsolete Line Folding
Historically, HTTP field line values could be extended over multiple Historically, HTTP/1.x field values could be extended over multiple
lines by preceding each extra line with at least one space or lines by preceding each extra line with at least one space or
horizontal tab (obs-fold). This specification deprecates such line horizontal tab (obs-fold). This specification deprecates such line
folding except within the message/http media type (Section 10.1). folding except within the message/http media type (Section 10.1).
obs-fold = OWS CRLF RWS obs-fold = OWS CRLF RWS
; obsolete line folding ; obsolete line folding
A sender MUST NOT generate a message that includes line folding A sender MUST NOT generate a message that includes line folding
(i.e., that has any field line value that contains a match to the (i.e., that has any field line value that contains a match to the
obs-fold rule) unless the message is intended for packaging within obs-fold rule) unless the message is intended for packaging within
skipping to change at page 18, line 29 skipping to change at page 18, line 32
Transfer codings are defined in Section 7. Transfer codings are defined in Section 7.
Transfer-Encoding = #transfer-coding Transfer-Encoding = #transfer-coding
; defined in [HTTP], Section 10.1.4 ; defined in [HTTP], Section 10.1.4
Transfer-Encoding is analogous to the Content-Transfer-Encoding field Transfer-Encoding is analogous to the Content-Transfer-Encoding field
of MIME, which was designed to enable safe transport of binary data of MIME, which was designed to enable safe transport of binary data
over a 7-bit transport service ([RFC2045], Section 6). However, safe over a 7-bit transport service ([RFC2045], Section 6). However, safe
transport has a different focus for an 8bit-clean transfer protocol. transport has a different focus for an 8bit-clean transfer protocol.
In HTTP's case, Transfer-Encoding is primarily intended to accurately In HTTP's case, Transfer-Encoding is primarily intended to accurately
delimit dynamically generated content and to distinguish encodings delimit dynamically generated content. It also serves to distinguish
that are only applied for transport efficiency or security from those encodings that are only applied in transit from the encodings that
that are characteristics of the selected resource. are a characteristic of the selected representation.
A recipient MUST be able to parse the chunked transfer coding A recipient MUST be able to parse the chunked transfer coding
(Section 7.1) because it plays a crucial role in framing messages (Section 7.1) because it plays a crucial role in framing messages
when the content size is not known in advance. A sender MUST NOT when the content size is not known in advance. A sender MUST NOT
apply the chunked transfer coding more than once to a message body apply the chunked transfer coding more than once to a message body
(i.e., chunking an already chunked message is not allowed). If any (i.e., chunking an already chunked message is not allowed). If any
transfer coding other than chunked is applied to a request's content, transfer coding other than chunked is applied to a request's content,
the sender MUST apply chunked as the final transfer coding to ensure the sender MUST apply chunked as the final transfer coding to ensure
that the message is properly framed. If any transfer coding other that the message is properly framed. If any transfer coding other
than chunked is applied to a response's content, the sender MUST than chunked is applied to a response's content, the sender MUST
skipping to change at page 29, line 25 skipping to change at page 29, line 51
given request message with its corresponding one or more response given request message with its corresponding one or more response
messages. Hence, it relies on the order of response arrival to messages. Hence, it relies on the order of response arrival to
correspond exactly to the order in which requests are made on the correspond exactly to the order in which requests are made on the
same connection. More than one response message per request only same connection. More than one response message per request only
occurs when one or more informational responses (1xx, see occurs when one or more informational responses (1xx, see
Section 15.2 of [HTTP]) precede a final response to the same request. Section 15.2 of [HTTP]) precede a final response to the same request.
A client that has more than one outstanding request on a connection A client that has more than one outstanding request on a connection
MUST maintain a list of outstanding requests in the order sent and MUST maintain a list of outstanding requests in the order sent and
MUST associate each received response message on that connection to MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final (non- the first outstanding request that has not yet received a final (non-
1xx) response. 1xx) response.
If an HTTP/1.1 client receives data on a connection that doesn't have If a client receives data on a connection that doesn't have
any outstanding requests, it MUST NOT consider them to be a response outstanding requests, the client MUST NOT consider that data to be a
to a not-yet-issued request; it SHOULD close the connection, since valid response; the client SHOULD close the connection, since message
message delimitation is now ambiguous, unless the data consists only delimitation is now ambiguous, unless the data consists only of one
of one or more CRLF (which can be discarded, as per Section 2.2). or more CRLF (which can be discarded, as per Section 2.2).
9.3. Persistence 9.3. Persistence
HTTP/1.1 defaults to the use of _persistent connections_, allowing HTTP/1.1 defaults to the use of _persistent connections_, allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. HTTP implementations SHOULD support persistent connection. HTTP implementations SHOULD support persistent
connections. connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
based on the protocol version and Connection header field based on the protocol version and Connection header field
skipping to change at page 32, line 12 skipping to change at page 32, line 34
number of connections but, instead, encourages clients to be number of connections but, instead, encourages clients to be
conservative when opening multiple connections. conservative when opening multiple connections.
Multiple connections are typically used to avoid the "head-of-line Multiple connections are typically used to avoid the "head-of-line
blocking" problem, wherein a request that takes significant server- blocking" problem, wherein a request that takes significant server-
side processing and/or transfers very large content would block side processing and/or transfers very large content would block
subsequent requests on the same connection. However, each connection subsequent requests on the same connection. However, each connection
consumes server resources. consumes server resources.
Furthermore, using multiple connections can cause undesirable side Furthermore, using multiple connections can cause undesirable side
effects in congested networks. Using larger number of multiple effects in congested networks. Using larger numbers of connections
connections can also cause side effects in otherwise uncongested can also cause side effects in otherwise uncongested networks,
networks, because their aggregate and initially synchronized sending because their aggregate and initially synchronized sending behavior
behavior can cause congestion that would not have been present if can cause congestion that would not have been present if fewer
fewer parallel connections had been used. parallel connections had been used.
Note that a server might reject traffic that it deems abusive or Note that a server might reject traffic that it deems abusive or
characteristic of a denial-of-service attack, such as an excessive characteristic of a denial-of-service attack, such as an excessive
number of open connections from a single client. number of open connections from a single client.
9.5. Failures and Timeouts 9.5. Failures and Timeouts
Servers will usually have some timeout value beyond which they will Servers will usually have some timeout value beyond which they will
no longer maintain an inactive connection. Proxy servers might make no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
skipping to change at page 35, line 7 skipping to change at page 35, line 20
The HTTP client also acts as the TLS client. It initiates a The HTTP client also acts as the TLS client. It initiates a
connection to the server on the appropriate port and sends the TLS connection to the server on the appropriate port and sends the TLS
ClientHello to begin the TLS handshake. When the TLS handshake has ClientHello to begin the TLS handshake. When the TLS handshake has
finished, the client may then initiate the first HTTP request. All finished, the client may then initiate the first HTTP request. All
HTTP data MUST be sent as TLS "application data", but is otherwise HTTP data MUST be sent as TLS "application data", but is otherwise
treated like a normal connection for HTTP (including potential reuse treated like a normal connection for HTTP (including potential reuse
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 through an
closure alert is received, an implementation can be assured that no exchange of closure alerts prior to closing a connection [TLS13].
further data will be received on that connection. TLS When a valid closure alert is received, an implementation can be
implementations MUST initiate an exchange of closure alerts before assured that no further data will be received on that connection.
closing a connection. A TLS implementation MAY, after sending a
closure alert, close the connection without waiting for the peer to When an implementation knows that it has sent or received all the
send its closure alert, generating an "incomplete close". This message data that it cares about, typically by detecting HTTP message
SHOULD only be done when the application knows (typically through boundaries, it might generate an "incomplete close" by sending a
detecting HTTP message boundaries) that it has sent or received all closure alert and then closing the connection without waiting to
the message data that it cares about. receive the corresponding closure alert from its peer.
An incomplete close does not call into question the security of the An incomplete close does not call into question the security of the
data already received, but it could indicate that subsequent data data already received, but it could indicate that subsequent data
might have been truncated. As TLS is not directly aware of HTTP might have been truncated. As TLS is not directly aware of HTTP
message framing, it is necessary to examine the HTTP data itself to message framing, it is necessary to examine the HTTP data itself to
determine whether messages were complete. Handing of incomplete determine whether messages were complete. Handling of incomplete
messages is defined in Section 8. messages is defined in Section 8.
When encountering an incomplete 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 or, when a Transfer-Encoding specified in the Content-Length header or, when a Transfer-Encoding
of chunked is used, for which the terminal zero-length chunk has been of chunked is used, for which the terminal zero-length chunk has been
received. A response that has neither chunked transfer coding nor received. A response that has neither chunked transfer coding nor
Content-Length is complete only if a valid closure alert has been Content-Length is complete only if a valid closure alert has been
received. Treating an incomplete message as complete could expose received. Treating an incomplete message as complete could expose
implementations to attack. implementations to attack.
skipping to change at page 36, line 12 skipping to change at page 36, line 21
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
The message/http media type can be used to enclose a single HTTP The message/http media type can be used to enclose a single HTTP
request or response message, provided that it obeys the MIME request or response message, provided that it obeys the MIME
restrictions for all "message" types regarding line length and restrictions for all "message" types regarding line length and
encodings. encodings. Because of the line length limitations, field values
within message/http are allowed to use line folding (obs-fold), as
described in Section 5.2, to convey the field value over multiple
lines. A recipient of message/http data MUST replace any obsolete
line folding with one or more SP characters when the message is
consumed.
Type name: message Type name: message
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.,
skipping to change at page 42, line 27 skipping to change at page 43, line 11
+----------+-----------------------------+----------------+ +----------+-----------------------------+----------------+
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-17, 26 July 2021, draft-ietf-httpbis-cache-18, 18 August 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-17>. cache-18>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] 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-17, 26 July 2021, draft-ietf-httpbis-semantics-18, 18 August 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-17>. semantics-18>.
[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,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 56, line 46 skipping to change at page 57, line 26
This draft addresses mostly editorial issues raised during or past This draft addresses mostly editorial issues raised during or past
IETF Last Call; see <https://github.com/httpwg/http-core/ IETF Last Call; see <https://github.com/httpwg/http-core/
issues?q=label%3Ah1-messaging+created%3A%3E2021-05-26> for a summary. issues?q=label%3Ah1-messaging+created%3A%3E2021-05-26> for a summary.
Furthermore: Furthermore:
* In Section 6.1, require recipients to avoid smuggling/splitting * In Section 6.1, require recipients to avoid smuggling/splitting
attacks when processing an ambiguous message framing attacks when processing an ambiguous message framing
(<https://github.com/httpwg/http-core/issues/879>) (<https://github.com/httpwg/http-core/issues/879>)
D.19. Since draft-ietf-httpbis-messaging-17
* In Section 4, rephrase text about status code definitions in
[HTTP] (<https://github.com/httpwg/http-core/issues/915>)
* In Section 9.2, clarify how to match responses to requests
(<https://github.com/httpwg/http-core/issues/915>)
* Made reference to [RFC5322] normative, as it is referenced from
the ABNF (for "From" header field) (<https://github.com/httpwg/
http-core/issues/915>)
* In Section 5.2, include text about message/http that previously
was in [HTTP] (<https://github.com/httpwg/http-core/issues/923>)
* Throughout, disambiguate "selected representation" and "selected
response" (now "chosen response") (<https://github.com/httpwg/
http-core/issues/958>)
Acknowledgements Acknowledgements
See Appendix "Acknowledgements" of [HTTP]. See Appendix "Acknowledgements" of [HTTP].
Index Index
A C D F G H M O R T X A C D F G H M O R T X
A A
absolute-form (of request-target) Section 3.2.2 absolute-form (of request-target) Section 3.2.2
application/http Media Type Section 10.2 application/http Media Type Section 10.2
asterisk-form (of request-target) Section 3.2.4 asterisk-form (of request-target) Section 3.2.4
authority-form (of request-target) Section 3.2.3 authority-form (of request-target) Section 3.2.3
C C
Connection header field Section 9.6 Connection header field Section 9.6
 End of changes. 44 change blocks. 
111 lines changed or deleted 135 lines changed or added

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