draft-ietf-httpbis-messaging-13.txt   draft-ietf-httpbis-messaging-14.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: June 17, 2021 J. Reschke, Ed. Expires: July 17, 2021 J. Reschke, Ed.
greenbytes greenbytes
December 14, 2020 January 13, 2021
HTTP/1.1 HTTP/1.1
draft-ietf-httpbis-messaging-13 draft-ietf-httpbis-messaging-14
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.14. The changes in this draft are summarized in Appendix D.15.
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 June 17, 2021. This Internet-Draft will expire on July 17, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 47 Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 47
C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 47 C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 47
C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 47 C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 47
C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 47 C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 47
C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 47 C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 47
C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 48 C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 48
C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 48 C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 48
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 49 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 49
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 49 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 49
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 49 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 49
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 49 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 50
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 50 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 50
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 50 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 51
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 51 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 51
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 51 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 51
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 52 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 52
D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 52 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 52
D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 52 D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 52
D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 52 D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 53
D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 52 D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 53
D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 53 D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 53
D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 53 D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 53
D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 54
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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:
skipping to change at page 6, line 8 skipping to change at page 6, line 8
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character). visible [USASCII] character).
The rules below are defined in [Semantics]: The rules below are defined in [Semantics]:
BWS = <BWS, see [Semantics], Section 5.6.3> BWS = <BWS, see [Semantics], Section 5.6.3>
OWS = <OWS, see [Semantics], Section 5.6.3> OWS = <OWS, see [Semantics], Section 5.6.3>
RWS = <RWS, see [Semantics], Section 5.6.3> RWS = <RWS, see [Semantics], Section 5.6.3>
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-path = <absolute-path, see [Semantics], Section 4> absolute-path = <absolute-path, see [Semantics], Section 4>
authority = <authority, see [RFC3986], Section 3.2>
comment = <comment, see [Semantics], Section 5.6.5>
field-name = <field-name, see [Semantics], Section 5.1> field-name = <field-name, see [Semantics], Section 5.1>
field-value = <field-value, see [Semantics], Section 5.5> field-value = <field-value, see [Semantics], Section 5.5>
obs-text = <obs-text, see [Semantics], Section 5.6.4> obs-text = <obs-text, see [Semantics], Section 5.6.4>
port = <port, see [RFC3986], Section 3.2.3>
query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 5.6.4> quoted-string = <quoted-string, see [Semantics], Section 5.6.4>
token = <token, see [Semantics], Section 5.6.2> token = <token, see [Semantics], Section 5.6.2>
transfer-coding = transfer-coding =
<transfer-coding, see [Semantics], Section 10.1.4> <transfer-coding, see [Semantics], Section 10.1.4>
uri-host = <host, see [RFC3986], Section 3.2.2>
The rules below are defined in [RFC3986]:
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
authority = <authority, see [RFC3986], Section 3.2>
query = <query, see [RFC3986], Section 3.4>
2. Message 2. Message
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.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
String-based parsers can only be safely used within protocol elements String-based parsers can only be safely used within protocol elements
after the element has been extracted from the message, such as within after the element has been extracted from the message, such as within
a header field line value after message parsing has delineated the a header field line value after message parsing has delineated the
individual field lines. individual field lines.
Although the line terminator for the start-line and fields is the Although the line terminator for the start-line and fields is the
sequence CRLF, a recipient MAY recognize a single LF as a line sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR. terminator and ignore any preceding CR.
A sender MUST NOT generate a bare CR (a CR character not immediately A sender MUST NOT generate a bare CR (a CR character not immediately
followed by LF) within any protocol elements other than the payload followed by LF) within any protocol elements other than the content.
data. A recipient of such a bare CR MUST consider that element to be A recipient of such a bare CR MUST consider that element to be
invalid or replace each bare CR with SP before processing the element invalid or replace each bare CR with SP before processing the element
or forwarding the message. or forwarding the message.
Older HTTP/1.0 user agent implementations might send an extra CRLF Older HTTP/1.0 user agent implementations might send an extra CRLF
after a POST request as a workaround for some early server after a POST request as a workaround for some early server
applications that failed to read message body content that was not applications that failed to read message body content that was not
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.
skipping to change at page 17, line 21 skipping to change at page 17, line 21
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received not within a message/http container MUST replace each received
obs-fold with one or more SP octets prior to interpreting the field obs-fold with one or more SP octets prior to interpreting the field
value. value.
6. Message Body 6. Message Body
The message body (if any) of an HTTP/1.1 message is used to carry The message body (if any) of an HTTP/1.1 message is used to carry
payload data (Section 6.4 of [Semantics]) for the request or content (Section 6.4 of [Semantics]) for the request or response.
response. The message body is identical to the payload data unless a The message body is identical to the content unless a transfer coding
transfer coding has been applied, as described in Section 6.1. has been applied, as described in Section 6.1.
message-body = *OCTET message-body = *OCTET
The rules for determining when a message body is present in an The rules for determining when a message body is present in an
HTTP/1.1 message differ for requests and responses. HTTP/1.1 message differ for requests and responses.
The presence of a message body in a request is signaled by a The presence of a message body in a request is signaled by a
Content-Length or Transfer-Encoding header field. Request message Content-Length or Transfer-Encoding header field. Request message
framing is independent of method semantics. framing is independent of method semantics.
The presence of a message body in a response depends on both the The presence of a message body in a response depends on both the
request method to which it is responding and the response status code request method to which it is responding and the response status code
(Section 4), and corresponds to when payload data is allowed; see (Section 4), and corresponds to when content is allowed; see
Section 6.4 of [Semantics]. Section 6.4 of [Semantics].
6.1. Transfer-Encoding 6.1. Transfer-Encoding
The Transfer-Encoding header field lists the transfer coding names The Transfer-Encoding header field lists the transfer coding names
corresponding to the sequence of transfer codings that have been (or corresponding to the sequence of transfer codings that have been (or
will be) applied to the payload data in order to form the message will be) applied to the content in order to form the message body.
body. Transfer codings are defined in Section 7. Transfer codings are defined in Section 7.
Transfer-Encoding = #transfer-coding Transfer-Encoding = #transfer-coding
; defined in [Semantics], Section 10.1.4 ; defined in [Semantics], 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 a dynamically generated payload and to distinguish payload delimit dynamically generated content and to distinguish encodings
encodings that are only applied for transport efficiency or security that are only applied for transport efficiency or security from those
from those that are characteristics of the selected resource. that are characteristics of the selected resource.
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 payload data size is not known in advance. A sender MUST when the content size is not known in advance. A sender MUST NOT
NOT apply chunked more than once to a message body (i.e., chunking an apply chunked more than once to a message body (i.e., chunking an
already chunked message is not allowed). If any transfer coding already chunked message is not allowed). If any transfer coding
other than chunked is applied to a request's payload data, the sender other than chunked is applied to a request's content, the sender MUST
MUST apply chunked as the final transfer coding to ensure that the apply chunked as the final transfer coding to ensure that the message
message is properly framed. If any transfer coding other than is properly framed. If any transfer coding other than chunked is
chunked is applied to a response's payload data, the sender MUST applied to a response's content, the sender MUST either apply chunked
either apply chunked as the final transfer coding or terminate the as the final transfer coding or terminate the message by closing the
message by closing the connection. connection.
For example, For example,
Transfer-Encoding: gzip, chunked Transfer-Encoding: gzip, chunked
indicates that the payload data has been compressed using the gzip indicates that the content has been compressed using the gzip coding
coding and then chunked using the chunked coding while forming the and then chunked using the chunked coding while forming the message
message body. body.
Unlike Content-Encoding (Section 8.5.1 of [Semantics]), Transfer- Unlike Content-Encoding (Section 8.4.1 of [Semantics]), Transfer-
Encoding is a property of the message, not of the representation, and Encoding is a property of the message, not of the representation, and
any recipient along the request/response chain MAY decode the any recipient along the request/response chain MAY decode the
received transfer coding(s) or apply additional transfer coding(s) to received transfer coding(s) or apply additional transfer coding(s) to
the message body, assuming that corresponding changes are made to the the message body, assuming that corresponding changes are made to the
Transfer-Encoding field value. Additional information about the Transfer-Encoding field value. Additional information about the
encoding parameters can be provided by other header fields not encoding parameters can be provided by other header fields not
defined by this specification. defined by this specification.
Transfer-Encoding MAY be sent in a response to a HEAD request or in a Transfer-Encoding MAY be sent in a response to a HEAD request or in a
304 (Not Modified) response (Section 15.4.5 of [Semantics]) to a GET 304 (Not Modified) response (Section 15.4.5 of [Semantics]) to a GET
skipping to change at page 19, line 7 skipping to change at page 19, line 7
are not needed. are not needed.
A server MUST NOT send a Transfer-Encoding header field in any A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No response with a status code of 1xx (Informational) or 204 (No
Content). A server MUST NOT send a Transfer-Encoding header field in Content). A server MUST NOT send a Transfer-Encoding header field in
any 2xx (Successful) response to a CONNECT request (Section 9.3.6 of any 2xx (Successful) response to a CONNECT request (Section 9.3.6 of
[Semantics]). [Semantics]).
Transfer-Encoding was added in HTTP/1.1. It is generally assumed Transfer-Encoding was added in HTTP/1.1. It is generally assumed
that implementations advertising only HTTP/1.0 support will not that implementations advertising only HTTP/1.0 support will not
understand how to process a transfer-encoded payload. A client MUST understand how to process transfer-encoded content. A client MUST
NOT send a request containing Transfer-Encoding unless it knows the NOT send a request containing Transfer-Encoding unless it knows the
server will handle HTTP/1.1 requests (or later minor revisions); such server will handle HTTP/1.1 requests (or later minor revisions); such
knowledge might be in the form of specific user configuration or by knowledge might be in the form of specific user configuration or by
remembering the version of a prior received response. A server MUST remembering the version of a prior received response. A server MUST
NOT send a response containing Transfer-Encoding unless the NOT send a response containing Transfer-Encoding unless the
corresponding request indicates HTTP/1.1 (or later minor revisions). corresponding request indicates HTTP/1.1 (or later minor revisions).
A server that receives a request message with a transfer coding it A server that receives a request message with a transfer coding it
does not understand SHOULD respond with 501 (Not Implemented). does not understand SHOULD respond with 501 (Not Implemented).
6.2. Content-Length 6.2. Content-Length
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 payload data. For messages decimal number of octets, for potential content. For messages that
that do include payload data, the Content-Length field value provides do include content, the Content-Length field value provides the
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 payload data, 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.7 of [Semantics]). (Section 8.6 of [Semantics]).
| *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):
skipping to change at page 20, line 5 skipping to change at page 20, line 5
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(s).
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 Transfer-Encoding header field is present and the chunked 3. If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 11.2) or response splitting
(Section 11.1) and ought to be handled as an error. An
intermediary that chooses to forward the message MUST first
remove the received Content-Length field and process the
Transfer-Encoding (as described below) prior to forwarding the
message downstream.
4. If a Transfer-Encoding header field is present and the chunked
transfer coding (Section 7.1) is the final encoding, the message transfer coding (Section 7.1) is the final encoding, the message
body length is determined by reading and decoding the chunked body length is determined by reading and decoding the chunked
data until the transfer coding indicates the data is complete. data until the transfer coding indicates the data is complete.
If a Transfer-Encoding header field is present in a response and If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the the chunked transfer coding is not the final encoding, the
message body length is determined by reading the connection until message body length is determined by reading the connection until
it is closed by the server. If a Transfer-Encoding header field it is closed by the server.
is present in a request and the chunked transfer coding is not
the final encoding, the message body length cannot be determined
reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection.
If a message is received with both a Transfer-Encoding and a If a Transfer-Encoding header field is present in a request and
Content-Length header field, the Transfer-Encoding overrides the the chunked transfer coding is not the final encoding, the
Content-Length. Such a message might indicate an attempt to message body length cannot be determined reliably; the server
perform request smuggling (Section 11.2) or response splitting MUST respond with the 400 (Bad Request) status code and then
(Section 11.1) and ought to be handled as an error. A sender close the connection.
MUST remove the received Content-Length field prior to forwarding
such a message downstream.
4. If a message is received without Transfer-Encoding and with an 5. If a message is received without Transfer-Encoding and with an
invalid Content-Length header field, then the message framing is invalid Content-Length header field, then the message framing is
invalid and the recipient MUST treat it as an unrecoverable invalid and the recipient MUST treat it as an unrecoverable
error, unless the field value can be successfully parsed as a error, unless the field value can be successfully parsed as a
comma-separated list (Section 5.6.1 of [Semantics]), all values comma-separated list (Section 5.6.1 of [Semantics]), all values
in the list are valid, and all values in the list are the same. in the list are valid, and all values in the list are the same.
If this is a request message, the server MUST respond with a 400 If this is a request message, the server MUST respond with a 400
(Bad Request) status code and then close the connection. If this (Bad Request) status code and then close the connection. If this
is a response message received by a proxy, the proxy MUST close is a response message received by a proxy, the proxy MUST close
the connection to the server, discard the received response, and the connection to the server, discard the received response, and
send a 502 (Bad Gateway) response to the client. If this is a send a 502 (Bad Gateway) response to the client. If this is a
response message received by a user agent, the user agent MUST response message received by a user agent, the user agent MUST
close the connection to the server and discard the received close the connection to the server and discard the received
response. response.
5. If a valid Content-Length header field is present without 6. If a valid Content-Length header field is present without
Transfer-Encoding, its decimal value defines the expected message Transfer-Encoding, its decimal value defines the expected message
body length in octets. If the sender closes the connection or body length in octets. If the sender closes the connection or
the recipient times out before the indicated number of octets are the recipient times out before the indicated number of octets are
received, the recipient MUST consider the message to be received, the recipient MUST consider the message to be
incomplete and close the connection. incomplete and close the connection.
6. If this is a request message and none of the above are true, then 7. If this is a request message and none of the above are true, then
the message body length is zero (no message body is present). the message body length is zero (no message body is present).
7. Otherwise, this is a response message without a declared message 8. Otherwise, this is a response message without a declared message
body length, so the message body length is determined by the body length, so the message body length is determined by the
number of octets received prior to the server closing the number of octets received prior to the server closing the
connection. connection.
Since there is no way to distinguish a successfully completed, close- Since there is no way to distinguish a successfully completed, close-
delimited response message from a partially received message delimited response message from a partially received message
interrupted by network failure, a server SHOULD generate encoding or interrupted by network failure, a server SHOULD generate encoding or
length-delimited messages whenever possible. The close-delimiting length-delimited messages whenever possible. The close-delimiting
feature exists primarily for backwards compatibility with HTTP/1.0. feature exists primarily for backwards compatibility with HTTP/1.0.
skipping to change at page 22, line 8 skipping to change at page 22, line 8
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.
7. Transfer Codings 7. Transfer Codings
Transfer coding names are used to indicate an encoding transformation Transfer coding names are used to indicate an encoding transformation
that has been, can be, or might need to be applied to a payload's that has been, can be, or might need to be applied to a message's
data in order to ensure "safe transport" through the network. This content in order to ensure "safe transport" through the network.
differs from a content coding in that the transfer coding is a This differs from a content coding in that the transfer coding is a
property of the message rather than a property of the representation property of the message rather than a property of the representation
that is being transferred. that is being transferred.
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the HTTP Transfer Coding registry, as defined in
Section 7.3. They are used in the Transfer-Encoding (Section 6.1) Section 7.3. They are used in the Transfer-Encoding (Section 6.1)
and TE (Section 10.1.4 of [Semantics]) header fields (the latter also and TE (Section 10.1.4 of [Semantics]) header fields (the latter also
defining the "transfer-coding" grammar). defining the "transfer-coding" grammar).
7.1. Chunked Transfer Coding 7.1. Chunked Transfer Coding
The chunked transfer coding wraps payload data in order to transfer The chunked transfer coding wraps content in order to transfer it as
it as a series of chunks, each with its own size indicator, followed a series of chunks, each with its own size indicator, followed by an
by an OPTIONAL trailer section containing trailer fields. Chunked OPTIONAL trailer section containing trailer fields. Chunked enables
enables content streams of unknown size to be transferred as a content streams of unknown size to be transferred as a sequence of
sequence of length-delimited buffers, which enables the sender to length-delimited buffers, which enables the sender to retain
retain connection persistence and the recipient to know when it has connection persistence and the recipient to know when it has received
received the entire message. the entire message.
chunked-body = *chunk chunked-body = *chunk
last-chunk last-chunk
trailer-section trailer-section
CRLF CRLF
chunk = chunk-size [ chunk-ext ] CRLF chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF chunk-data CRLF
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
last-chunk = 1*("0") [ chunk-ext ] CRLF last-chunk = 1*("0") [ chunk-ext ] CRLF
skipping to change at page 23, line 40 skipping to change at page 23, line 40
ought to limit the total length of chunk extensions received in a ought to limit the total length of chunk extensions received in a
request to an amount reasonable for the services provided, in the request to an amount reasonable for the services provided, in the
same way that it applies length limitations and timeouts for other same way that it applies length limitations and timeouts for other
parts of a message, and generate an appropriate 4xx (Client Error) parts of a message, and generate an appropriate 4xx (Client Error)
response if that amount is exceeded. response if that amount is exceeded.
7.1.2. Chunked Trailer Section 7.1.2. Chunked Trailer Section
A trailer section allows the sender to include additional fields at A trailer section allows the sender to include additional fields at
the end of a chunked message in order to supply metadata that might the end of a chunked message in order to supply metadata that might
be dynamically generated while the payload data is sent, such as a be dynamically generated while the content is sent, such as a message
message integrity check, digital signature, or post-processing integrity check, digital signature, or post-processing status. The
status. The proper use and limitations of trailer fields are defined proper use and limitations of trailer fields are defined in
in Section 6.5 of [Semantics]. Section 6.5 of [Semantics].
trailer-section = *( field-line CRLF ) trailer-section = *( field-line CRLF )
A recipient that decodes and removes the chunked encoding from a A recipient that decodes and removes the chunked encoding from a
message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST
discard any received trailer fields, store/forward them separately discard any received trailer fields, store/forward them separately
from the header fields, or selectively merge into the header section from the header fields, or selectively merge into the header section
only those trailer fields corresponding to header field definitions only those trailer fields corresponding to header field definitions
that are understood by the recipient to explicitly permit and define that are understood by the recipient to explicitly permit and define
how their corresponding trailer field value can be safely merged. how their corresponding trailer field value can be safely merged.
7.1.3. Decoding Chunked 7.1.3. Decoding Chunked
A process for decoding the chunked transfer coding can be represented A process for decoding the chunked transfer coding can be represented
in pseudo-code as: in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-ext (if any), and CRLF read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) { while (chunk-size > 0) {
read chunk-data and CRLF read chunk-data and CRLF
append chunk-data to payload-data append chunk-data to content
length := length + chunk-size length := length + chunk-size
read chunk-size, chunk-ext (if any), and CRLF read chunk-size, chunk-ext (if any), and CRLF
} }
read trailer field read trailer field
while (trailer field is not empty) { while (trailer field is not empty) {
if (trailer fields are stored/forwarded separately) { if (trailer fields are stored/forwarded separately) {
append trailer field to existing trailer fields append trailer field to existing trailer fields
} }
else if (trailer field is understood and defined as mergeable) { else if (trailer field is understood and defined as mergeable) {
merge trailer field with existing header fields merge trailer field with existing header fields
skipping to change at page 24, line 49 skipping to change at page 24, line 49
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields Remove Trailer from existing header fields
7.2. Transfer Codings for Compression 7.2. Transfer Codings for Compression
The following transfer coding names for compression are defined by The following transfer coding names for compression are defined by
the same algorithm as their corresponding content coding: the same algorithm as their corresponding content coding:
compress (and x-compress) compress (and x-compress)
See Section 8.5.1.1 of [Semantics]. See Section 8.4.1.1 of [Semantics].
deflate deflate
See Section 8.5.1.2 of [Semantics]. See Section 8.4.1.2 of [Semantics].
gzip (and x-gzip) gzip (and x-gzip)
See Section 8.5.1.3 of [Semantics]. See Section 8.4.1.3 of [Semantics].
The compression codings do not define any parameters. Their presence The compression codings do not define any parameters. Their presence
SHOULD be treated as an error. SHOULD be treated as an error.
7.3. Transfer Coding Registry 7.3. Transfer Coding Registry
The "HTTP Transfer Coding Registry" defines the namespace for The "HTTP Transfer Coding Registry" defines the namespace for
transfer coding names. It is maintained at transfer coding names. It is maintained at
<https://www.iana.org/assignments/http-parameters>. <https://www.iana.org/assignments/http-parameters>.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 8.5.1 of [Semantics]) unless the encoding codings (Section 8.4.1 of [Semantics]) unless the encoding
transformation is identical, as is the case for the compression transformation is identical, as is the case for the compression
codings defined in Section 7.2. codings defined in Section 7.2.
The TE header field (Section 10.1.4 of [Semantics]) uses a pseudo The TE header field (Section 10.1.4 of [Semantics]) uses a pseudo
parameter named "q" as rank value when multiple transfer codings are parameter named "q" as rank value when multiple transfer codings are
acceptable. Future registrations of transfer codings SHOULD NOT acceptable. Future registrations of transfer codings SHOULD NOT
define parameters called "q" (case-insensitively) in order to avoid define parameters called "q" (case-insensitively) in order to avoid
ambiguities. ambiguities.
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
skipping to change at page 28, line 30 skipping to change at page 28, line 30
1xx) response. 1xx) response.
If an HTTP/1.1 client receives data on a connection that doesn't have If an HTTP/1.1 client receives data on a connection that doesn't have
any outstanding requests, it MUST NOT consider them to be a response any outstanding requests, it MUST NOT consider them to be a response
to a not-yet-issued request; it SHOULD close the connection, since to a not-yet-issued request; it SHOULD close the connection, since
message delimitation is now ambiguous, unless the data consists only message delimitation is now ambiguous, unless the data consists only
of one or more CRLF (which can be discarded, as per Section 2.2). of one 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. The "close" connection option is used to signal that a connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections. implementations SHOULD support persistent connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
based on the most recently received message's protocol version and based on the most recently received message's protocol version and
Connection header field (Section 7.6.1 of [Semantics]), if any: Connection header field (Section 7.6.1 of [Semantics]), if any:
o If the "close" connection option is present, the connection will o If the "close" connection option is present, the connection will
skipping to change at page 29, line 47 skipping to change at page 29, line 47
9.3.1. Retrying Requests 9.3.1. Retrying Requests
Connections can be closed at any time, with or without intention. Connections can be closed at any time, with or without intention.
Implementations ought to anticipate the need to recover from Implementations ought to anticipate the need to recover from
asynchronous close events. The conditions under which a client can asynchronous close events. The conditions under which a client can
automatically retry a sequence of outstanding requests are defined in automatically retry a sequence of outstanding requests are defined in
Section 9.2.2 of [Semantics]. Section 9.2.2 of [Semantics].
9.3.2. Pipelining 9.3.2. Pipelining
A client that supports persistent connections MAY "_pipeline_" its A client that supports persistent connections MAY _pipeline_ its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 9.2.1 of parallel if they all have safe methods (Section 9.2.1 of
[Semantics]), but it MUST send the corresponding responses in the [Semantics]), but it MUST send the corresponding responses in the
same order that the requests were received. same order that the requests were received.
A client that pipelines requests SHOULD retry unanswered requests if A client that pipelines requests SHOULD retry unanswered requests if
the connection closes before it receives all of the corresponding the connection closes before it receives all of the corresponding
responses. When retrying pipelined requests after a failed responses. When retrying pipelined requests after a failed
connection (a connection not explicitly closed by the server in its connection (a connection not explicitly closed by the server in its
skipping to change at page 30, line 47 skipping to change at page 30, line 47
that it maintains to a given server. that it maintains to a given server.
Previous revisions of HTTP gave a specific number of connections as a Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications. ceiling, but this was found to be impractical for many applications.
As a result, this specification does not mandate a particular maximum As a result, this specification does not mandate a particular maximum
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 has a large payload blocks subsequent requests side processing and/or transfers very large content would block
on the same connection. However, each connection consumes server subsequent requests on the same connection. However, each connection
resources. Furthermore, using multiple connections can cause consumes server resources. Furthermore, using multiple connections
undesirable side effects in congested networks. can cause undesirable side effects in congested networks.
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 36, line 43 skipping to change at page 36, line 43
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
11. Security Considerations 11. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security considerations relevant to HTTP message and users of known security considerations relevant to HTTP message
syntax and parsing. Security considerations about HTTP semantics, syntax and parsing. Security considerations about HTTP semantics,
payloads, and routing are addressed in [Semantics]. content, and routing are addressed in [Semantics].
11.1. Response Splitting 11.1. Response Splitting
Response splitting (a.k.a, CRLF injection) is a common technique, Response splitting (a.k.a, CRLF injection) is a common technique,
used in various attacks on Web usage, that exploits the line-based used in various attacks on Web usage, that exploits the line-based
nature of HTTP message framing and the ordered association of nature of HTTP message framing and the ordered association of
requests to responses on persistent connections [Klein]. This requests to responses on persistent connections [Klein]. This
technique can be particularly damaging when the requests pass through technique can be particularly damaging when the requests pass through
a shared cache. a shared cache.
skipping to change at page 41, line 7 skipping to change at page 41, 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-13, December 14, 2020, draft-ietf-httpbis-cache-14, January 13, 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-13>. <https://tools.ietf.org/html/draft-ietf-httpbis-cache-14>.
[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 42, line 8 skipping to change at page 42, 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-13, December 14, 2020, draft-ietf-httpbis-semantics-14, January 13, 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
13>. 14>.
[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.
13.2. Informative References 13.2. Informative References
skipping to change at page 44, line 20 skipping to change at page 44, line 20
authority-form = authority authority-form = authority
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET chunk-data = 1*OCTET
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val
] ) ] )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token / quoted-string chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-section CRLF chunked-body = *chunk last-chunk trailer-section CRLF
comment = <comment, see [Semantics], Section 5.6.5>
field-line = field-name ":" OWS field-value OWS field-line = field-name ":" OWS field-value OWS
field-name = <field-name, see [Semantics], Section 5.1> field-name = <field-name, see [Semantics], Section 5.1>
field-value = <field-value, see [Semantics], Section 5.5> field-value = <field-value, see [Semantics], Section 5.5>
last-chunk = 1*"0" [ chunk-ext ] CRLF last-chunk = 1*"0" [ chunk-ext ] CRLF
message-body = *OCTET message-body = *OCTET
method = token method = token
obs-fold = OWS CRLF RWS obs-fold = OWS CRLF RWS
obs-text = <obs-text, see [Semantics], Section 5.6.4> obs-text = <obs-text, see [Semantics], Section 5.6.4>
origin-form = absolute-path [ "?" query ] origin-form = absolute-path [ "?" query ]
port = <port, see [RFC3986], Section 3.2.3>
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 5.6.4> quoted-string = <quoted-string, see [Semantics], Section 5.6.4>
reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
request-line = method SP request-target SP HTTP-version request-line = method SP request-target SP HTTP-version
request-target = origin-form / absolute-form / authority-form / request-target = origin-form / absolute-form / authority-form /
asterisk-form asterisk-form
start-line = request-line / status-line start-line = request-line / status-line
status-code = 3DIGIT status-code = 3DIGIT
status-line = HTTP-version SP status-code SP [ reason-phrase ] status-line = HTTP-version SP status-code SP [ reason-phrase ]
token = <token, see [Semantics], Section 5.6.2> token = <token, see [Semantics], Section 5.6.2>
trailer-section = *( field-line CRLF ) trailer-section = *( field-line CRLF )
transfer-coding = <transfer-coding, see [Semantics], Section 10.1.4> transfer-coding = <transfer-coding, see [Semantics], Section 10.1.4>
uri-host = <host, see [RFC3986], Section 3.2.2>
Appendix B. Differences between HTTP and MIME Appendix B. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for the Internet Message HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open [RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible fields. However, RFC variety of representations and with extensible fields. However, RFC
2045 is focused only on email; applications of HTTP have many 2045 is focused only on email; applications of HTTP have many
characteristics that differ from email; hence, HTTP has features that characteristics that differ from email; hence, HTTP has features that
differ from MIME. These differences were carefully chosen to differ from MIME. These differences were carefully chosen to
skipping to change at page 45, line 39 skipping to change at page 45, 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]. Section 8.4.3 of [Semantics] describes the forms of [RFC2049]. Section 8.3.3 of [Semantics] describes the forms
allowed for subtypes of the "text" media type when transmitted over allowed for subtypes of the "text" media type when transmitted over
HTTP. [RFC2046] requires that content with a type of "text" HTTP. [RFC2046] requires that content with a type of "text"
represent line breaks as CRLF and forbids the use of CR or LF outside represent line breaks as CRLF and forbids the use of CR or LF outside
of line break sequences. HTTP allows CRLF, bare CR, and bare LF to of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
indicate a line break within text content. 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
skipping to change at page 46, line 52 skipping to change at page 46, line 52
appropriate Content-Transfer-Encoding if doing so will improve the appropriate Content-Transfer-Encoding if doing so will improve the
likelihood of safe transport over the destination protocol. likelihood of safe transport over the destination protocol.
B.6. MHTML and Line Length Limitations B.6. MHTML and Line Length Limitations
HTTP implementations that share code with MHTML [RFC2557] HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as canonicalization, etc., since HTTP transfers message-bodies without
payload and, aside from the "multipart/byteranges" type (Section 14.5 modification and, aside from the "multipart/byteranges" type
of [Semantics]), does not interpret the content or any MIME header (Section 14.6 of [Semantics]), does not interpret the content or any
lines that might be contained therein. MIME header lines that might be contained therein.
Appendix C. Changes from previous RFCs Appendix C. Changes from previous RFCs
C.1. Changes from HTTP/0.9 C.1. Changes from HTTP/0.9
Since HTTP/0.9 did not support header fields in a request, there is Since HTTP/0.9 did not support header fields in a request, there is
no mechanism for it to support name-based virtual hosts (selection of no mechanism for it to support name-based virtual hosts (selection of
resource by inspection of the Host header field). Any server that resource by inspection of the Host header field). Any server that
implements name-based virtual hosts ought to disable support for implements name-based virtual hosts ought to disable support for
HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
skipping to change at page 48, line 38 skipping to change at page 48, line 38
message over a MIME-compliant protocol. message over a MIME-compliant protocol.
C.3. Changes from RFC 7230 C.3. Changes from RFC 7230
Most of the sections introducing HTTP's design goals, history, Most of the sections introducing HTTP's design goals, history,
architecture, conformance criteria, protocol versioning, URIs, architecture, conformance criteria, protocol versioning, URIs,
message routing, and header fields have been moved to [Semantics]. message routing, and header fields have been moved to [Semantics].
This document has been reduced to just the messaging syntax and This document has been reduced to just the messaging syntax and
connection management requirements specific to HTTP/1.1. connection management requirements specific to HTTP/1.1.
Prohibited generation of bare CRs outside of payload data. Prohibited generation of bare CRs outside of content. (Section 2.2)
(Section 2.2)
In the ABNF for chunked extensions, re-introduced (bad) whitespace In the ABNF for chunked extensions, re-introduced (bad) whitespace
around ";" and "=". Whitespace was removed in [RFC7230], but that around ";" and "=". Whitespace was removed in [RFC7230], but that
change was found to break existing implementations (see [Err4667]). change was found to break existing implementations (see [Err4667]).
(Section 7.1.1) (Section 7.1.1)
Trailer field semantics now transcend the specifics of chunked Trailer field semantics now transcend the specifics of chunked
encoding. The decoding algorithm for chunked (Section 7.1.3) has encoding. The decoding algorithm for chunked (Section 7.1.3) has
been updated to encourage storage/forwarding of trailer fields been updated to encourage storage/forwarding of trailer fields
separately from the header section, to only allow merging into the separately from the header section, to only allow merging into the
header section if the recipient knows the corresponding field header section if the recipient knows the corresponding field
definition permits and defines how to merge, and otherwise to discard definition permits and defines how to merge, and otherwise to discard
the trailer fields instead of merging. The trailer part is now the trailer fields instead of merging. The trailer part is now
called the trailer section to be more consistent with the header called the trailer section to be more consistent with the header
section and more distinct from a body part. (Section 7.1.2) section and more distinct from a body part. (Section 7.1.2)
skipping to change at page 54, line 12 skipping to change at page 54, line 18
o In Section 7, moved transfer-coding ABNF to Section 10.1.4 of o In Section 7, moved transfer-coding ABNF to Section 10.1.4 of
[Semantics] (<https://github.com/httpwg/http-core/issues/531>) [Semantics] (<https://github.com/httpwg/http-core/issues/531>)
o Changed to using "payload data" when defining requirements about o Changed to using "payload data" when defining requirements about
the data being conveyed within a message, instead of the terms the data being conveyed within a message, instead of the terms
"payload body" or "response body" or "representation body", since "payload body" or "response body" or "representation body", since
they often get confused with the HTTP/1.1 message body (which they often get confused with the HTTP/1.1 message body (which
includes transfer coding) (<https://github.com/httpwg/http-core/ includes transfer coding) (<https://github.com/httpwg/http-core/
issues/553>) issues/553>)
D.15. Since draft-ietf-httpbis-messaging-13
o In Section 6.3, clarify that a message needs to be checked for
both Content-Length and Transfer-Encoding, before processing
Transfer-Encoding, and that ought to be treated as an error, but
an intermediary can choose to forward the message downstream after
removing the Content-Length and processing the Transfer-Encoding
(<https://github.com/httpwg/http-core/issues/617>)
o Changed to using "content" instead of "payload" or "payload data"
to avoid confusion with the payload of version-specific messaging
frames (<https://github.com/httpwg/http-core/issues/654>)
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
 End of changes. 56 change blocks. 
104 lines changed or deleted 116 lines changed or added

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