draft-ietf-httpbis-messaging-18.txt   draft-ietf-httpbis-messaging-19.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: 19 February 2022 J. Reschke, Ed. Expires: 14 March 2022 J. Reschke, Ed.
greenbytes greenbytes
18 August 2021 10 September 2021
HTTP/1.1 HTTP/1.1
draft-ietf-httpbis-messaging-18 draft-ietf-httpbis-messaging-19
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.19. The changes in this draft are summarized in Appendix D.20.
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 19 February 2022. This Internet-Draft will expire on 14 March 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 4, line 37 skipping to change at page 4, line 37
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 . . . . . . . . . . 55 D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 55
D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 55 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 . . . . . . . . . . 56 D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 56
D.16. Since draft-ietf-httpbis-messaging-14 . . . . . . . . . . 56 D.16. Since draft-ietf-httpbis-messaging-14 . . . . . . . . . . 56
D.17. Since draft-ietf-httpbis-messaging-15 . . . . . . . . . . 57 D.17. Since draft-ietf-httpbis-messaging-15 . . . . . . . . . . 57
D.18. Since draft-ietf-httpbis-messaging-16 . . . . . . . . . . 57 D.18. Since draft-ietf-httpbis-messaging-16 . . . . . . . . . . 57
D.19. Since draft-ietf-httpbis-messaging-17 . . . . . . . . . . 57 D.19. Since draft-ietf-httpbis-messaging-17 . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 D.20. Since draft-ietf-httpbis-messaging-18 . . . . . . . . . . 57
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 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 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 [HTTP]: The rules below are defined in [HTTP]:
BWS = <BWS, see [HTTP], Section 5.6.3> BWS = <BWS, see [HTTP], Section 5.6.3>
OWS = <OWS, see [HTTP], Section 5.6.3> OWS = <OWS, see [HTTP], Section 5.6.3>
RWS = <RWS, see [HTTP], Section 5.6.3> RWS = <RWS, see [HTTP], Section 5.6.3>
absolute-path = <absolute-path, see [HTTP], Section 4> absolute-path = <absolute-path, see [HTTP], Section 4.1>
field-name = <field-name, see [HTTP], Section 5.1> field-name = <field-name, see [HTTP], Section 5.1>
field-value = <field-value, see [HTTP], Section 5.5> field-value = <field-value, see [HTTP], Section 5.5>
obs-text = <obs-text, see [HTTP], Section 5.6.4> obs-text = <obs-text, see [HTTP], Section 5.6.4>
quoted-string = <quoted-string, see [HTTP], Section 5.6.4> quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
token = <token, see [HTTP], Section 5.6.2> token = <token, see [HTTP], Section 5.6.2>
transfer-coding = transfer-coding =
<transfer-coding, see [HTTP], Section 10.1.4> <transfer-coding, see [HTTP], Section 10.1.4>
The rules below are defined in [URI]: The rules below are defined in [URI]:
skipping to change at page 9, line 48 skipping to change at page 9, line 48
instead parse on whitespace-delimited word boundaries and, aside from instead parse on whitespace-delimited word boundaries and, aside from
the CRLF terminator, treat any form of whitespace as the SP separator the CRLF 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 request (%x0C), or bare CR. However, lenient parsing can result in request
smuggling security vulnerabilities if there are multiple recipients smuggling 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.2). robustness (see Section 11.2).
HTTP does not place a predefined limit on the length of a request- HTTP does not place a predefined limit on the length of a request-
line, as described in Section 2 of [HTTP]. A server that receives a line, as described in Section 2.3 of [HTTP]. A server that receives
method longer than any that it implements SHOULD respond with a 501 a method longer than any that it implements SHOULD respond with a 501
(Not Implemented) status code. A server that receives a request- (Not Implemented) status code. A server that receives a request-
target longer than any URI it wishes to parse MUST respond with a 414 target longer than any URI it wishes to parse MUST respond with a 414
(URI Too Long) status code (see Section 15.5.15 of [HTTP]). (URI Too Long) status code (see Section 15.5.15 of [HTTP]).
Various ad hoc limitations on request-line length are found in Various ad hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets. support, at a minimum, request-line lengths of 8000 octets.
3.1. Method 3.1. Method
skipping to change at page 10, line 45 skipping to change at page 10, line 45
hypertext references, resulting in those disallowed characters being hypertext references, resulting in those disallowed characters being
sent as the request-target in a malformed request-line. sent as the request-target in a malformed request-line.
Recipients of an invalid request-line SHOULD respond with either a Recipients of an invalid request-line SHOULD respond with either a
400 (Bad Request) error or a 301 (Moved Permanently) redirect with 400 (Bad Request) error or a 301 (Moved Permanently) redirect with
the request-target properly encoded. A recipient SHOULD NOT attempt the request-target properly encoded. A recipient SHOULD NOT attempt
to autocorrect and then process the request without a redirect, since to autocorrect and then process the request without a redirect, since
the invalid request-line might be deliberately crafted to bypass the invalid request-line might be deliberately crafted to bypass
security filters along the request chain. security filters along the request chain.
A client MUST send a Host header field in all HTTP/1.1 request A client MUST send a Host header field (Section 7.2 of [HTTP]) in all
messages. If the target URI includes an authority component, then a HTTP/1.1 request messages. If the target URI includes an authority
client MUST send a field value for Host that is identical to that component, then a client MUST send a field value for Host that is
authority component, excluding any userinfo subcomponent and its "@" identical to that authority component, excluding any userinfo
delimiter (Section 4.2.1 of [HTTP]). If the authority component is subcomponent and its "@" delimiter (Section 4.2.1 of [HTTP]). If the
missing or undefined for the target URI, then a client MUST send a authority component is missing or undefined for the target URI, then
Host header field with an empty field value. a client MUST send a Host header field with an empty field value.
A server MUST respond with a 400 (Bad Request) status code to any A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field line or request message that contains more than one Host header field line or
a Host header field with an invalid field value. a Host header field with an invalid field value.
3.2.1. origin-form 3.2.1. origin-form
The most common form of request-target is the _origin-form_. The most common form of request-target is the _origin-form_.
skipping to change at page 25, line 27 skipping to change at page 25, line 27
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 content is sent, such as a message be dynamically generated while the content is sent, such as a message
integrity check, digital signature, or post-processing status. The integrity check, digital signature, or post-processing status. The
proper use and limitations of trailer fields are defined in proper use and limitations of trailer fields are defined in
Section 6.5 of [HTTP]. Section 6.5 of [HTTP].
trailer-section = *( field-line CRLF ) trailer-section = *( field-line CRLF )
A recipient that decodes and removes the chunked encoding from a A recipient that removes the chunked encoding from a message MAY
message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST selectively retain or discard the received trailer fields. A
discard any received trailer fields, store/forward them separately recipient that retains a received trailer field MUST either store/
from the header fields, or selectively merge into the header section forward the trailer field separately from the received header fields
only those trailer fields corresponding to header field definitions or merge the received trailer field into the header section. A
that are understood by the recipient to explicitly permit and define recipient MUST NOT merge a received trailer field into the header
how their corresponding trailer field value can be safely merged. section unless its corresponding header field definition explicitly
permits and instructs how the 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
skipping to change at page 35, line 20 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 through an TLS uses an exchange of closure alerts prior to (non-error)
exchange of closure alerts prior to closing a connection [TLS13]. connection closure to provide secure connection closure; see
When a valid closure alert is received, an implementation can be Section 6.1 of [TLS13]. When a valid closure alert is received, an
assured that no further data will be received on that connection. implementation can be assured that no further data will be received
on that connection.
When an implementation knows that it has sent or received all the When an implementation knows that it has sent or received all the
message data that it cares about, typically by detecting HTTP message message data that it cares about, typically by detecting HTTP message
boundaries, it might generate an "incomplete close" by sending a boundaries, it might generate an "incomplete close" by sending a
closure alert and then closing the connection without waiting to closure alert and then closing the connection without waiting to
receive the corresponding closure alert from its peer. 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
skipping to change at page 43, line 11 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-18, 18 August 2021, draft-ietf-httpbis-cache-19, 10 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-18>. cache-19>.
[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-18, 18 August 2021, draft-ietf-httpbis-semantics-19, 10 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-18>. semantics-19>.
[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 45, line 37 skipping to change at page 45, line 37
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 5.6.1.1 of [HTTP]. Section 5.6.1 of [HTTP].
BWS = <BWS, see [HTTP], Section 5.6.3> BWS = <BWS, see [HTTP], Section 5.6.3>
HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [ HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [
message-body ] message-body ]
HTTP-name = %x48.54.54.50 ; HTTP HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
OWS = <OWS, see [HTTP], Section 5.6.3> OWS = <OWS, see [HTTP], Section 5.6.3>
RWS = <RWS, see [HTTP], Section 5.6.3> RWS = <RWS, see [HTTP], Section 5.6.3>
Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding
) ] ) ]
absolute-URI = <absolute-URI, see [URI], Section 4.3> absolute-URI = <absolute-URI, see [URI], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = <absolute-path, see [HTTP], Section 4> absolute-path = <absolute-path, see [HTTP], Section 4.1>
asterisk-form = "*" asterisk-form = "*"
authority = <authority, see [URI], Section 3.2> authority = <authority, see [URI], Section 3.2>
authority-form = uri-host ":" port authority-form = uri-host ":" port
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
skipping to change at page 57, line 45 skipping to change at page 57, line 45
the ABNF (for "From" header field) (<https://github.com/httpwg/ the ABNF (for "From" header field) (<https://github.com/httpwg/
http-core/issues/915>) http-core/issues/915>)
* In Section 5.2, include text about message/http that previously * In Section 5.2, include text about message/http that previously
was in [HTTP] (<https://github.com/httpwg/http-core/issues/923>) was in [HTTP] (<https://github.com/httpwg/http-core/issues/923>)
* Throughout, disambiguate "selected representation" and "selected * Throughout, disambiguate "selected representation" and "selected
response" (now "chosen response") (<https://github.com/httpwg/ response" (now "chosen response") (<https://github.com/httpwg/
http-core/issues/958>) http-core/issues/958>)
D.20. Since draft-ietf-httpbis-messaging-18
* Improve a few crossrefs into [HTTP] (<https://github.com/httpwg/
http-core/issues/966>)
* In Section 7.1.2, improve readability of formerly overlong
sentence (<https://github.com/httpwg/http-core/issues/966>)
* Slightly rephrase Section 9.8 (<https://github.com/httpwg/http-
core/pull/972>)
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. 19 change blocks. 
34 lines changed or deleted 50 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/