draft-ietf-httpbis-messaging-07.txt   draft-ietf-httpbis-messaging-08.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: September 8, 2020 J. Reschke, Ed. Expires: November 27, 2020 J. Reschke, Ed.
greenbytes greenbytes
March 7, 2020 May 26, 2020
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-07 draft-ietf-httpbis-messaging-08
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.8. The changes in this draft are summarized in Appendix D.9.
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 September 8, 2020. This Internet-Draft will expire on November 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7 2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7
2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8 2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8
3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12
3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12 3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 15 5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23
7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 23 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 24
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
7.2. Transfer Codings for Compression . . . . . . . . . . . . 24 7.2. Transfer Codings for Compression . . . . . . . . . . . . 25
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 27 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Associating a Response to a Request . . . . . . . . . . . 29 9.3. Associating a Response to a Request . . . . . . . . . . . 30
9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30 9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31
9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31 9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32
9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32 9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33
9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32 9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 34 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35
9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37 9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 38
9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37 9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 38 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 39
10.1. Media Type message/http . . . . . . . . . . . . . . . . 38 10.1. Media Type message/http . . . . . . . . . . . . . . . . 39
10.2. Media Type application/http . . . . . . . . . . . . . . 39 10.2. Media Type application/http . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 41 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 42 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12.1. Field Name Registration . . . . . . . . . . . . . . . . 43 12.1. Field Name Registration . . . . . . . . . . . . . . . . 44
12.2. Media Type Registration . . . . . . . . . . . . . . . . 43 12.2. Media Type Registration . . . . . . . . . . . . . . . . 44
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 44
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 44
12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 43 12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 47 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 48
Appendix B. Differences between HTTP and MIME . . . . . . . . . 48 Appendix B. Differences between HTTP and MIME . . . . . . . . . 49
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 49 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 50
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 49 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 50
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 49 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 50
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 50 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 51
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 50 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 51
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 50 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 51
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 50 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 51
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 51 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 52
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 51 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 52
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 52 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 53
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 52 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 53
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 52 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 53
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 54
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 53 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 54
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 53 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 54
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 54 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 55
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 55 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 56
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 55 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 56
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 55 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 56
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 55 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 56
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 56 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 57
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 57
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 59 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 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 is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" [Semantics] o "HTTP Semantics" [Semantics]
skipping to change at page 11, line 28 skipping to change at page 11, line 28
The proxy is requested to either service that request from a valid The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.7 of [Semantics]. "forwarding" of messages are defined in Section 5.7 of [Semantics].
An example absolute-form of request-line would be: An example absolute-form of request-line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
A client MUST send a Host header field in an HTTP/1.1 request even if
the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host.
When a proxy receives a request with an absolute-form of request-
target, the proxy MUST ignore the received Host header field (if any)
and instead replace it with the host information of the request-
target. A proxy that forwards such a request MUST generate a new
Host field value based on the received request-target rather than
forward the received Host field value.
When an origin server receives a request with an absolute-form of
request-target, the origin server MUST ignore the received Host
header field (if any) and instead use the host information of the
request-target. Note that if the request-target does not have an
authority component, an empty Host header field will be sent in this
case.
To allow for transition to the absolute-form for all requests in some To allow for transition to the absolute-form for all requests in some
future version of HTTP, a server MUST accept the absolute-form in future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in requests, even though HTTP/1.1 clients will only send them in
requests to proxies. requests to proxies.
3.2.3. authority-form 3.2.3. authority-form
The authority-form of request-target is only used for CONNECT The authority-form of request-target is only used for CONNECT
requests (Section 7.3.6 of [Semantics]). requests (Section 7.3.6 of [Semantics]).
skipping to change at page 12, line 28 skipping to change at page 13, line 5
OPTIONS http://www.example.org:8001 HTTP/1.1 OPTIONS http://www.example.org:8001 HTTP/1.1
would be forwarded by the final proxy as would be forwarded by the final proxy as
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org:8001 Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org". after connecting to port 8001 of host "www.example.org".
3.3. Effective Request URI 3.3. Reconstructing the Target URI
Since the request-target often contains only part of the user agent's Since the request-target often contains only part of the user agent's
target URI, a server reconstructs the intended target as an effective target URI, a server constructs its value to properly service the
request URI to properly service the request (Section 5.5 of request (Section 5.1 of [Semantics]).
[Semantics]).
If the request-target is in absolute-form, the effective request URI If the request-target is in absolute-form, the target URI is the same
is the same as the request-target. Otherwise, the effective request as the request-target. Otherwise, the target URI is constructed as
URI is constructed as follows: follows:
If the server's configuration (or outbound gateway) provides a If the server's configuration (or outbound gateway) provides a
fixed URI scheme, that scheme is used for the effective request fixed URI scheme, that scheme is used for the target URI.
URI. Otherwise, if the request is received over a TLS-secured TCP Otherwise, if the request is received over a TLS-secured TCP
connection, the effective request URI's scheme is "https"; if not, connection, the target URI's scheme is "https"; if not, the scheme
the scheme is "http". is "http".
If the server's configuration (or outbound gateway) provides a If the server's configuration (or outbound gateway) provides a
fixed URI authority component, that authority is used for the fixed URI authority component, that authority is used for the
effective request URI. If not, then if the request-target is in target URI. If not, then if the request-target is in authority-
authority-form, the effective request URI's authority component is form, the target URI's authority component is the same as the
the same as the request-target. If not, then if a Host header request-target. If not, then if a Host header field is supplied
field is supplied with a non-empty field-value, the authority with a non-empty field-value, the authority component is the same
component is the same as the Host field-value. Otherwise, the as the Host field-value. Otherwise, the authority component is
authority component is assigned the default name configured for assigned the default name configured for the server and, if the
the server and, if the connection's incoming TCP port number connection's incoming TCP port number differs from the default
differs from the default port for the effective request URI's port for the target URI's scheme, then a colon (":") and the
scheme, then a colon (":") and the incoming port number (in incoming port number (in decimal form) are appended to the
decimal form) are appended to the authority component. authority component.
If the request-target is in authority-form or asterisk-form, the If the request-target is in authority-form or asterisk-form, the
effective request URI's combined path and query component is target URI's combined path and query component is empty.
empty. Otherwise, the combined path and query component is the Otherwise, the combined path and query component is the same as
same as the request-target. the request-target.
The components of the effective request URI, once determined as The components of the target URI, once determined as above, can be
above, can be combined into absolute-URI form by concatenating the combined into absolute-URI form by concatenating the scheme,
scheme, "://", authority, and combined path and query component. "://", authority, and combined path and query component.
Example 1: the following message received over an insecure TCP Example 1: the following message received over an insecure TCP
connection connection
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080 Host: www.example.org:8080
has an effective request URI of has a target URI of
http://www.example.org:8080/pub/WWW/TheProject.html http://www.example.org:8080/pub/WWW/TheProject.html
Example 2: the following message received over a TLS-secured TCP Example 2: the following message received over a TLS-secured TCP
connection connection
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org Host: www.example.org
has an effective request URI of has a target URI of
https://www.example.org https://www.example.org
Recipients of an HTTP/1.0 request that lacks a Host header field Recipients of an HTTP/1.0 request that lacks a Host header field
might need to use heuristics (e.g., examination of the URI path for might need to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to guess the something unique to a particular host) in order to guess the target
effective request URI's authority component. URI's authority component.
4. Status Line 4. Status Line
The first line of a response message is the status-line, consisting The first line of a response message is the status-line, consisting
of the protocol version, a space (SP), the status code, another of the protocol version, a space (SP), the status code, another
space, and ending with an OPTIONAL textual phrase describing the space, and ending with an OPTIONAL textual phrase describing the
status code. status code.
status-line = HTTP-version SP status-code SP [reason-phrase] status-line = HTTP-version SP status-code SP [reason-phrase]
skipping to change at page 18, line 37 skipping to change at page 19, line 15
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 7.3.6 of any 2xx (Successful) response to a CONNECT request (Section 7.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 a transfer-encoded payload. 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 (or later) requests; such knowledge might server will handle HTTP/1.1 requests (or later minor revisions); such
be in the form of specific user configuration or by remembering the knowledge might be in the form of specific user configuration or by
version of a prior received response. A server MUST NOT send a remembering the version of a prior received response. A server MUST
response containing Transfer-Encoding unless the corresponding NOT send a response containing Transfer-Encoding unless the
request indicates HTTP/1.1 (or later). 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 a potential payload body. For messages decimal number of octets, for a potential payload body. For messages
that do include a payload body, the Content-Length field value that do include a payload body, the Content-Length field value
skipping to change at page 20, line 5 skipping to change at page 20, line 30
status code and then close the connection. status code and then close the connection.
If a message is received with both a Transfer-Encoding and a If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 11.2) or response splitting perform request smuggling (Section 11.2) or response splitting
(Section 11.1) and ought to be handled as an error. A sender (Section 11.1) and ought to be handled as an error. A sender
MUST remove the received Content-Length field prior to forwarding MUST remove the received Content-Length field prior to forwarding
such a message downstream. such a message downstream.
4. If a message is received without Transfer-Encoding and with 4. If a message is received without Transfer-Encoding and with an
either multiple Content-Length header fields having differing invalid Content-Length header field, then the message framing is
field values or a single Content-Length header field having an invalid and the recipient MUST treat it as an unrecoverable
invalid value, then the message framing is invalid and the error, unless the field value can be successfully parsed as a
recipient MUST treat it as an unrecoverable error. If this is a comma-separated list (Section 4.5 of [Semantics]), all values in
request message, the server MUST respond with a 400 (Bad Request) the list are valid, and all values in the list are the same. If
status code and then close the connection. If this is a response this is a request message, the server MUST respond with a 400
message received by a proxy, the proxy MUST close the connection (Bad Request) status code and then close the connection. If this
to the server, discard the received response, and send a 502 (Bad is a response message received by a proxy, the proxy MUST close
Gateway) response to the client. If this is a response message the connection to the server, discard the received response, and
received by a user agent, the user agent MUST close the send a 502 (Bad Gateway) response to the client. If this is a
connection to the server and discard the received response. response message received by a user agent, the user agent MUST
close the connection to the server and discard the received
response.
5. If a valid Content-Length header field is present without 5. 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 6. 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).
skipping to change at page 23, line 13 skipping to change at page 23, line 27
chunk-data = 1*OCTET ; a sequence of chunk-size octets chunk-data = 1*OCTET ; a sequence of chunk-size octets
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked transfer coding is complete the chunk-data in octets. The chunked transfer coding is complete
when a chunk with a chunk-size of zero is received, possibly followed when a chunk with a chunk-size of zero is received, possibly followed
by a trailer section, and finally terminated by an empty line. by a trailer section, and finally terminated by an empty line.
A recipient MUST be able to parse and decode the chunked transfer A recipient MUST be able to parse and decode the chunked transfer
coding. coding.
Note that HTTP/1.1 does not define any means to limit the size of a
chunked response such that an intermediary can be assured of
buffering the entire response.
The chunked encoding does not define any parameters. Their presence The chunked encoding does not define any parameters. Their presence
SHOULD be treated as an error. SHOULD be treated as an error.
7.1.1. Chunk Extensions 7.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
extensions, immediately following the chunk-size, for the sake of extensions, immediately following the chunk-size, for the sake of
supplying per-chunk metadata (such as a signature or hash), mid- supplying per-chunk metadata (such as a signature or hash), mid-
message control information, or randomization of message body size. message control information, or randomization of message body size.
skipping to change at page 26, line 23 skipping to change at page 27, line 9
t-ranking = OWS ";" OWS "q=" rank t-ranking = OWS ";" OWS "q=" rank
rank = ( "0" [ "." 0*3DIGIT ] ) rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
Three examples of TE use are below. Three examples of TE use are below.
TE: deflate TE: deflate
TE: TE:
TE: trailers, deflate;q=0.5 TE: trailers, deflate;q=0.5
The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer coding, as
defined in Section 7.1.2, on behalf of itself and any downstream
clients. For requests from an intermediary, this implies that
either: (a) all downstream clients are willing to accept trailer
fields in the forwarded response; or, (b) the intermediary will
attempt to buffer the response on behalf of downstream recipients.
Note that HTTP/1.1 does not define any means to limit the size of a
chunked response such that an intermediary can be assured of
buffering the entire response.
When multiple transfer codings are acceptable, the client MAY rank When multiple transfer codings are acceptable, the client MAY rank
the codings by preference using a case-insensitive "q" parameter the codings by preference using a case-insensitive "q" parameter
(similar to the qvalues used in content negotiation fields, (similar to the qvalues used in content negotiation fields,
Section 8.4.1 of [Semantics]). The rank value is a real number in Section 6.4.4 of [Semantics]). The rank value is a real number in
the range 0 through 1, where 0.001 is the least preferred and 1 is the range 0 through 1, where 0.001 is the least preferred and 1 is
the most preferred; a value of 0 means "not acceptable". the most preferred; a value of 0 means "not acceptable".
If the TE field value is empty or if no TE field is present, the only If the TE field value is empty or if no TE field is present, the only
acceptable transfer coding is chunked. A message with no transfer acceptable transfer coding is chunked. A message with no transfer
coding is always acceptable. coding is always acceptable.
The keyword "trailers" indicates that the sender will not discard
trailer fields, as described in Section 4.6 of [Semantics].
Since the TE header field only applies to the immediate connection, a Since the TE header field only applies to the immediate connection, a
sender of TE MUST also send a "TE" connection option within the sender of TE MUST also send a "TE" connection option within the
Connection header field (Section 9.1) in order to prevent the TE Connection header field (Section 9.1) in order to prevent the TE
field from being forwarded by intermediaries that do not support its field from being forwarded by intermediaries that do not support its
semantics. semantics.
8. Handling Incomplete Messages 8. Handling Incomplete Messages
A server that receives an incomplete request message, usually due to A server that receives an incomplete request message, usually due to
a canceled request or a triggered timeout exception, MAY send an a canceled request or a triggered timeout exception, MAY send an
skipping to change at page 28, line 14 skipping to change at page 28, line 38
processing messages received on a connection, detecting connection processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable of concurrent connections, while controlling request queues to enable
fair use and detect denial-of-service attacks. fair use and detect denial-of-service attacks.
9.1. Connection 9.1. Connection
The "Connection" header field allows the sender to list desired The "Connection" header field allows the sender to list desired
control options for the current connection. In order to avoid control options for the current connection.
confusing downstream recipients, a proxy or gateway MUST remove or
replace any received connection options before forwarding the
message.
When a field aside from Connection is used to supply control When a field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list information for or about the current connection, the sender MUST list
the corresponding field name within the Connection header field. A the corresponding field name within the Connection header field.
proxy or gateway MUST parse a received Connection header field before
a message is forwarded and, for each connection-option in this field, Intermediaries MUST parse a received Connection header field before a
message is forwarded and, for each connection-option in this field,
remove any header or trailer field(s) from the message with the same remove any header or trailer field(s) from the message with the same
name as the connection-option, and then remove the Connection header name as the connection-option, and then remove the Connection header
field itself (or replace it with the intermediary's own connection field itself (or replace it with the intermediary's own connection
options for the forwarded message). options for the forwarded message).
Hence, the Connection header field provides a declarative way of Hence, the Connection header field provides a declarative way of
distinguishing fields that are only intended for the immediate distinguishing fields that are only intended for the immediate
recipient ("hop-by-hop") from those fields that are intended for all recipient ("hop-by-hop") from those fields that are intended for all
recipients on the chain ("end-to-end"), enabling the message to be recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by to be deployed without fear that they will be blindly forwarded by
older intermediaries. older intermediaries.
Furthermore, intermediaries SHOULD remove or replace field(s) whose
semantics are known to require removal before forwarding, whether or
not they appear as a Connection option, after applying those fields'
semantics. This includes but is not limited to:
o Proxy-Connection Appendix C.1.2
o Keep-Alive Section 19.7.1 of [RFC2068]
o TE Section 7.4
o Trailer Section 4.6.3 of [Semantics]
o Transfer-Encoding Section 6.1
o Upgrade Section 9.9
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
Connection = 1#connection-option Connection = 1#connection-option
connection-option = token connection-option = token
Connection options are case-insensitive. Connection options are case-insensitive.
A sender MUST NOT send a connection option corresponding to a field A sender MUST NOT send a connection option corresponding to a field
that is intended for all recipients of the payload. For example, that is intended for all recipients of the payload. For example,
Cache-Control is never appropriate as a connection option Cache-Control is never appropriate as a connection option
skipping to change at page 44, line 17 skipping to change at page 45, line 17
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e | (this | | HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e | (this |
| | 0x31 ("http/1.1") | specification) | | | 0x31 ("http/1.1") | specification) |
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
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", draft-ietf-httpbis-cache-07 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-08 (work in
progress), March 2020. progress), May 2020.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, 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 15 skipping to change at page 46, line 15
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-07 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-08
(work in progress), March 2020. (work in progress), May 2020.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A 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 56, line 31 skipping to change at page 57, line 31
o In Section 5, align with updates to field terminology in semantics o In Section 5, align with updates to field terminology in semantics
(<https://github.com/httpwg/http-core/issues/111>) (<https://github.com/httpwg/http-core/issues/111>)
o In Section 9.1, clarify that new connection options indeed need to o In Section 9.1, clarify that new connection options indeed need to
be registered (<https://github.com/httpwg/http-core/issues/285>) be registered (<https://github.com/httpwg/http-core/issues/285>)
o In Section 1.1, reference RFC 8174 as well o In Section 1.1, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>) (<https://github.com/httpwg/http-core/issues/303>)
D.9. Since draft-ietf-httpbis-messaging-07
o Move TE: trailers into [Semantics] (<https://github.com/httpwg/
http-core/issues/18>)
o In Section 6.3, adjust requirements for handling multiple content-
length values (<https://github.com/httpwg/http-core/issues/59>)
o Throughout, replace "effective request URI" with "target URI"
(<https://github.com/httpwg/http-core/issues/259>)
o In Section 6.1, don't claim Transfer-Encoding is supported by
HTTP/2 or later (<https://github.com/httpwg/http-core/issues/297>)
Index Index
A A
absolute-form (of request-target) 11 absolute-form (of request-target) 11
application/http Media Type 39 application/http Media Type 40
asterisk-form (of request-target) 11 asterisk-form (of request-target) 12
authority-form (of request-target) 11 authority-form (of request-target) 12
C C
Connection header field 28, 33 Connection header field 28, 34
Content-Length header field 18 Content-Length header field 19
Content-Transfer-Encoding header field 50 Content-Transfer-Encoding header field 51
chunked (Coding Format) 17, 19 chunked (Coding Format) 17, 19
chunked (transfer coding) 22 chunked (transfer coding) 22
close 28, 33 close 28, 34
compress (transfer coding) 24 compress (transfer coding) 25
D D
deflate (transfer coding) 24 deflate (transfer coding) 25
E
effective request URI 12
F F
Fields Fields
Connection 28 Connection 28
MIME-Version 49 MIME-Version 50
TE 25 TE 26
Transfer-Encoding 17 Transfer-Encoding 17
Upgrade 35 Upgrade 36
G G
Grammar Grammar
absolute-form 10-11 absolute-form 10-11
ALPHA 5 ALPHA 5
asterisk-form 10-11 asterisk-form 10, 12
authority-form 10-11 authority-form 10, 12
chunk 22 chunk 23
chunk-data 22 chunk-data 23
chunk-ext 22-23 chunk-ext 23
chunk-ext-name 23 chunk-ext-name 23
chunk-ext-val 23 chunk-ext-val 23
chunk-size 22 chunk-size 23
chunked-body 22 chunked-body 23
Connection 28 Connection 29
connection-option 28 connection-option 29
CR 5 CR 5
CRLF 5 CRLF 5
CTL 5 CTL 5
DIGIT 5 DIGIT 5
DQUOTE 5 DQUOTE 5
field-line 14, 24 field-line 15, 24
field-name 14 field-name 15
field-value 14 field-value 15
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
HTTP-message 6 HTTP-message 6
HTTP-name 8 HTTP-name 8
HTTP-version 8 HTTP-version 8
last-chunk 22 last-chunk 23
LF 5 LF 5
message-body 16 message-body 17
method 9 method 9
obs-fold 16 obs-fold 16
OCTET 5 OCTET 5
origin-form 10 origin-form 10
rank 26 rank 26
reason-phrase 14 reason-phrase 15
request-line 9 request-line 9
request-target 10 request-target 10
SP 5 SP 5
start-line 6 start-line 6
status-code 14 status-code 14
status-line 13 status-line 14
t-codings 26 t-codings 26
t-ranking 26 t-ranking 26
TE 26 TE 26
trailer-section 22, 24 trailer-section 23-24
transfer-coding 21 transfer-coding 22
Transfer-Encoding 17 Transfer-Encoding 18
transfer-parameter 21 transfer-parameter 22
Upgrade 35 Upgrade 36
VCHAR 5 VCHAR 5
gzip (transfer coding) 24 gzip (transfer coding) 25
H H
Header Fields Header Fields
Connection 28 Connection 28
MIME-Version 49 MIME-Version 50
TE 25 TE 26
Transfer-Encoding 17 Transfer-Encoding 17
Upgrade 35 Upgrade 36
header line 6 header line 6
header section 6 header section 6
headers 6 headers 6
M M
MIME-Version header field 49 MIME-Version header field 50
Media Type Media Type
application/http 39 application/http 40
message/http 38 message/http 39
message/http Media Type 38 message/http Media Type 39
method 9 method 9
O O
origin-form (of request-target) 10 origin-form (of request-target) 10
R R
request-target 10 request-target 10
T T
TE header field 25 TE header field 26
Transfer-Encoding header field 17 Transfer-Encoding header field 17
U U
Upgrade header field 35 Upgrade header field 36
X X
x-compress (transfer coding) 24 x-compress (transfer coding) 25
x-gzip (transfer coding) 24 x-gzip (transfer coding) 25
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
 End of changes. 59 change blocks. 
191 lines changed or deleted 234 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/