draft-ietf-httpbis-messaging-14.txt   draft-ietf-httpbis-messaging-15.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7230 (if approved) M. Nottingham, Ed. Obsoletes: 7230 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Fastly Intended status: Standards Track Fastly
Expires: July 17, 2021 J. Reschke, Ed. Expires: 1 October 2021 J. Reschke, Ed.
greenbytes greenbytes
January 13, 2021 30 March 2021
HTTP/1.1 HTTP/1.1
draft-ietf-httpbis-messaging-14 draft-ietf-httpbis-messaging-15
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document specifies the HTTP/1.1 message syntax, systems. This document specifies the HTTP/1.1 message syntax,
message parsing, connection management, and related security message parsing, connection management, and related security
concerns. concerns.
This document obsoletes portions of RFC 7230. This document obsoletes portions of RFC 7230.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix D.15. The changes in this draft are summarized in Appendix D.16.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 17, 2021. This Internet-Draft will expire on 1 October 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 4 skipping to change at page 3, line 4
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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 13
3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13 3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16 5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 17
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23
7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 23 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 24
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
7.2. Transfer Codings for Compression . . . . . . . . . . . . 24 7.2. Transfer Codings for Compression . . . . . . . . . . . . 25
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. Negotiating Transfer Codings . . . . . . . . . . . . . . 25 7.4. Negotiating Transfer Codings . . . . . . . . . . . . . . 26
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 27 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Associating a Response to a Request . . . . . . . . . . . 28 9.2. Associating a Response to a Request . . . . . . . . . . . 28
9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 28 9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29
9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 29 9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30
9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 29 9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 30
9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 30 9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31
9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 31 9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 31
9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 31 9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 32
9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 33 9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 34
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 33 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 34
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 34 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 35
10.1. Media Type message/http . . . . . . . . . . . . . . . . 34 10.1. Media Type message/http . . . . . . . . . . . . . . . . 35
10.2. Media Type application/http . . . . . . . . . . . . . . 35 10.2. Media Type application/http . . . . . . . . . . . . . . 36
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 36 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 37
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 37 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 38
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 38 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 39
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 38 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
12.1. Field Name Registration . . . . . . . . . . . . . . . . 39 12.1. Field Name Registration . . . . . . . . . . . . . . . . 40
12.2. Media Type Registration . . . . . . . . . . . . . . . . 39 12.2. Media Type Registration . . . . . . . . . . . . . . . . 40
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 39 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 40
12.4. ALPN Protocol ID Registration . . . . . . . . . . . . . 40 12.4. ALPN Protocol ID Registration . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 43 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 44
Appendix B. Differences between HTTP and MIME . . . . . . . . . 45 Appendix B. Differences between HTTP and MIME . . . . . . . . . 46
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 45 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 46
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 45 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 46
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 46 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 47
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 46 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 47
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 46 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 47
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 46 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 48
Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 47 Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 48
C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 47 C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 48
C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 47 C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 48
C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 47 C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 48
C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 47 C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 49
C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 48 C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 49
C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 48 C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 49
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 49 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 50
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 49 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 50
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 49 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 51
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 50 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 51
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 50 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 52
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 51 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 52
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 51 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 52
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 51 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 52
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 52 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 53
D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 52 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 53
D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 52 D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 54
D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 53 D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 54
D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 53 D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 54
D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 53 D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 54
D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 53 D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 55
D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 54 D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 55
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.16. Since draft-ietf-httpbis-messaging-14 . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP/1.1 is defined by: hypertext information systems. HTTP/1.1 is defined by:
o This document * This document
o "HTTP Semantics" [Semantics] * "HTTP Semantics" [Semantics]
o "HTTP Caching" [Caching] * "HTTP Caching" [Caching]
This document specifies how HTTP semantics are conveyed using the This document specifies how HTTP semantics are conveyed using the
HTTP/1.1 message syntax, framing and connection management HTTP/1.1 message syntax, framing and connection management
mechanisms. Its goal is to define the complete set of requirements mechanisms. Its goal is to define the complete set of requirements
for HTTP/1.1 message parsers and message-forwarding intermediaries. for HTTP/1.1 message parsers and message-forwarding intermediaries.
This document obsoletes the portions of RFC 7230 related to HTTP/1.1 This document obsoletes the portions of RFC 7230 related to HTTP/1.1
messaging and connection management, with the changes being messaging and connection management, with the changes being
summarized in Appendix C.3. The other parts of RFC 7230 are summarized in Appendix C.3. The other parts of RFC 7230 are
obsoleted by "HTTP Semantics" [Semantics]. obsoleted by "HTTP Semantics" [Semantics].
skipping to change at page 6, line 21 skipping to change at page 6, line 21
obs-text = <obs-text, see [Semantics], Section 5.6.4> obs-text = <obs-text, see [Semantics], Section 5.6.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>
The rules below are defined in [RFC3986]: The rules below are defined in [RFC3986]:
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
uri-host = <host, see [RFC3986], Section 3.2.2>
port = <port, see [RFC3986], Section 3.2.3>
query = <query, see [RFC3986], Section 3.4> 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
skipping to change at page 8, line 25 skipping to change at page 8, line 25
after it as a new request, either of which might result in a security after it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or such whitespace in a response might be ignored by some clients or
cause others to cease parsing. cause others to cease parsing.
When a server listening only for HTTP request messages, or processing When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message, what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server grammar aside from the robustness exceptions listed above, the server
SHOULD respond with a 400 (Bad Request) response. SHOULD respond with a 400 (Bad Request) response and close the
connection.
2.3. HTTP Version 2.3. HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". of the protocol. This specification defines version "1.1".
Section 2.5 of [Semantics] specifies the semantics of HTTP version Section 2.5 of [Semantics] specifies the semantics of HTTP version
numbers. numbers.
The version of an HTTP/1.x message is indicated by an HTTP-version The version of an HTTP/1.x message is indicated by an HTTP-version
field in the start-line. HTTP-version is case-sensitive. field in the start-line. HTTP-version is case-sensitive.
skipping to change at page 8, line 51 skipping to change at page 8, line 52
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0 constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1. the recipient supports HTTP/1.1.
Intermediaries that process HTTP messages (i.e., all intermediaries Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) MUST send their own HTTP-version other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they are not allowed to in forwarded messages, unless it is purposefully downgraded as a
blindly forward the start-line without ensuring that the protocol workaround for an upstream issue. In other words, an intermediary is
version in that message matches a version to which that intermediary not allowed to blindly forward the start-line without ensuring that
is conformant for both the receiving and sending of messages. the protocol version in that message matches a version to which that
Forwarding an HTTP message without rewriting the HTTP-version might intermediary is conformant for both the receiving and sending of
result in communication errors when downstream recipients use the messages. Forwarding an HTTP message without rewriting the HTTP-
message sender's version to determine what features are safe to use version might result in communication errors when downstream
for later communication with that sender. recipients use the message sender's version to determine what
features are safe to use for later communication with that sender.
A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it
is known or suspected that the client incorrectly implements the HTTP is known or suspected that the client incorrectly implements the HTTP
specification and is incapable of correctly processing later version specification and is incapable of correctly processing later version
responses, such as when a client fails to parse the version number responses, such as when a client fails to parse the version number
correctly or when an intermediary is known to blindly forward the correctly or when an intermediary is known to blindly forward the
HTTP-version even when it doesn't conform to the given minor version HTTP-version even when it doesn't conform to the given minor version
of the protocol. Such protocol downgrades SHOULD NOT be performed of the protocol. Such protocol downgrades SHOULD NOT be performed
unless triggered by specific client attributes, such as when one or unless triggered by specific client attributes, such as when one or
more of the request header fields (e.g., User-Agent) uniquely match more of the request header fields (e.g., User-Agent) uniquely match
skipping to change at page 11, line 28 skipping to change at page 11, line 33
For example, a client wishing to retrieve a representation of the For example, a client wishing to retrieve a representation of the
resource identified as resource identified as
http://www.example.org/where?q=now http://www.example.org/where?q=now
directly from the origin server would open (or reuse) a TCP directly from the origin server would open (or reuse) a TCP
connection to port 80 of the host "www.example.org" and send the connection to port 80 of the host "www.example.org" and send the
lines: lines:
GET /where?q=now HTTP/1.1 GET /where?q=now HTTP/1.1
Host: www.example.org Host: www.example.org
followed by the remainder of the request message. followed by the remainder of the request message.
3.2.2. absolute-form 3.2.2. absolute-form
When making a request to a proxy, other than a CONNECT or server-wide When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target OPTIONS request (as detailed below), a client MUST send the target
URI in _absolute-form_ as the request-target. URI in _absolute-form_ as the request-target.
absolute-form = absolute-URI absolute-form = absolute-URI
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 7.6 of [Semantics]. "forwarding" of messages are defined in Section 7.6 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 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 the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host. that might not have implemented Host.
When a proxy receives a request with an absolute-form of request- When a proxy receives a request with an absolute-form of request-
target, the proxy MUST ignore the received Host header field (if any) target, the proxy MUST ignore the received Host header field (if any)
and instead replace it with the host information of the request- and instead replace it with the host information of the request-
target. A proxy that forwards such a request MUST generate a new target. A proxy that forwards such a request MUST generate a new
skipping to change at page 12, line 32 skipping to change at page 12, line 34
case. 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 9.3.6 of [Semantics]). requests (Section 9.3.6 of [Semantics]). It consists of only the
uri-host and port number of the tunnel destination, separated by a
colon (":").
authority-form = authority authority-form = uri-host ":" port
When making a CONNECT request to establish a tunnel through one or When making a CONNECT request to establish a tunnel through one or
more proxies, a client MUST send only the target URI's authority more proxies, a client MUST send only the host and port of the tunnel
component (excluding any userinfo and its "@" delimiter) as the destination as the request-target. The client obtains the host and
request-target. For example, port from the target URI's authority component, except that it sends
the scheme's default port if the target URI elides the port. For
example, a CONNECT request to "http://www.example.com" looks like
CONNECT www.example.com:80 HTTP/1.1 CONNECT www.example.com:80 HTTP/1.1
Host: www.example.com
3.2.4. asterisk-form 3.2.4. asterisk-form
The _asterisk-form_ of request-target is only used for a server-wide The _asterisk-form_ of request-target is only used for a server-wide
OPTIONS request (Section 9.3.7 of [Semantics]). OPTIONS request (Section 9.3.7 of [Semantics]).
asterisk-form = "*" asterisk-form = "*"
When a client wishes to request OPTIONS for the server as a whole, as When a client wishes to request OPTIONS for the server as a whole, as
opposed to a specific named resource of that server, the client MUST opposed to a specific named resource of that server, the client MUST
send only "*" (%x2A) as the request-target. For example, send only "*" (%x2A) as the request-target. For example,
OPTIONS * HTTP/1.1
OPTIONS * HTTP/1.1
If a proxy receives an OPTIONS request with an absolute-form of If a proxy receives an OPTIONS request with an absolute-form of
request-target in which the URI has an empty path and no query request-target in which the URI has an empty path and no query
component, then the last proxy on the request chain MUST send a component, then the last proxy on the request chain MUST send a
request-target of "*" when it forwards the request to the indicated request-target of "*" when it forwards the request to the indicated
origin server. origin server.
For example, the request For example, the request
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. Reconstructing the Target URI 3.3. Reconstructing the Target URI
Since the request-target often contains only part of the user agent's The target URI is the request-target when the request-target is in
target URI, a server constructs its value to properly service the absolute-form. In that case, a server will parse the URI into its
request (Section 7.1 of [Semantics]). generic components for further evaluation.
If the request-target is in absolute-form, the target URI is the same Otherwise, the server reconstructs the target URI from the connection
as the request-target. Otherwise, the target URI is constructed as context and various parts of the request message in order to identify
follows: the target resource (Section 7.1 of [Semantics]):
o If the server's configuration (or outbound gateway) provides a * If the server's configuration provides for a fixed URI scheme, or
fixed URI scheme, that scheme is used for the target URI. a scheme is provided by a trusted outbound gateway, that scheme is
Otherwise, if the request is received over a secured connection, used for the target URI. This is common in large-scale
the target URI's scheme is "https"; if not, the scheme is "http". deployments because a gateway server will receive the client's
connection context and replace that with their own connection to
the inbound server. Otherwise, if the request is received over a
secured connection, the target URI's scheme is "https"; if not,
the scheme is "http".
o If the server's configuration (or outbound gateway) provides a * If the request-target is in authority-form, the target URI's
fixed URI authority component, that authority is used for the authority component is the request-target. Otherwise, the target
target URI. If not, then if the request-target is in URI's authority component is the field value of the Host header
authority-form, the target URI's authority component is the same field. If there is no Host header field or if its field value is
as the request-target. If not, then if a Host header field is empty or invalid, the target URI's authority component is empty.
supplied with a non-empty field value, the authority component is
the same as the Host field value. Otherwise, the authority
component is assigned the default name configured for the server
and, if the connection's incoming TCP port number differs from the
default port for the target URI's scheme, then a colon (":") and
the incoming port number (in decimal form) are appended to the
authority component.
o If the request-target is in authority-form or asterisk-form, the * If the request-target is in authority-form or asterisk-form, the
target URI's combined path and query component is empty. target URI's combined path and query component is empty.
Otherwise, the combined path and query component is the same as Otherwise, the target URI's combined path and query component is
the request-target. the request-target.
o The components of the target URI, once determined as above, can be * The components of a reconstructed target URI, once determined as
combined into absolute-URI form by concatenating the scheme, above, can be recombined into absolute-URI form by concatenating
"://", authority, and combined path and query component. the scheme, "://", authority, and combined path and query
component.
Example 1: the following message received over an insecure TCP Example 1: the following message received over a secure 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
has a target URI of has a target URI of
http://www.example.org:8080/pub/WWW/TheProject.html https://www.example.org/pub/WWW/TheProject.html
Example 2: the following message received over a secured connection Example 2: the following message received over an insecure connection
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org Host: www.example.org:8080
has a target URI of has a target URI of
https://www.example.org http://www.example.org:8080
Recipients of an HTTP/1.0 request that lacks a Host header field If the target URI's authority component is empty and its URI scheme
might need to use heuristics (e.g., examination of the URI path for requires a non-empty authority (as is the case for "http" and
something unique to a particular host) in order to guess the target "https"), the server can reject the request or determine whether a
URI's authority component. configured default applies that is consistent with the incoming
connection's context. Context might include connection details like
address and port, what security has been applied, and locally-defined
information specific to that server's configuration. An empty
authority is replaced with the configured default before further
processing of the request.
Supplying a default name for authority within the context of a
secured connection is inherently unsafe if there is any chance that
the user agent's intended authority might differ from the selected
default. A server that can uniquely identify an authority from the
request context MAY use that identity as a default without this risk.
Alternatively, it might be better to redirect the request to a safe
resource that explains how to obtain a new client.
Note that reconstructing the client's target URI is only half of the
process for identifying a target resource. The other half is
determining whether that target URI identifies a resource for which
the server is willing and able to send a response, as defined in
Section 7.4 of [Semantics].
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 4 skipping to change at page 18, line 28
will be) applied to the content in order to form the message body. will be) applied to the content in order to form the message 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 dynamically generated content and to distinguish encodings delimit dynamically generated content and to distinguish encodings
that are only applied for transport efficiency or security from those that are only applied for transport efficiency or security 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 content size is not known in advance. A sender MUST NOT when the content size is not known in advance. A sender MUST NOT
apply 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 content, the sender MUST other than chunked is applied to a request's content, the sender MUST
apply chunked as the final transfer coding to ensure that the message apply chunked as the final transfer coding to ensure that the message
is properly framed. If any transfer coding other than chunked is is properly framed. If any transfer coding other than chunked is
applied to a response's content, the sender MUST either apply chunked applied to a response's content, the sender MUST either apply chunked
as the final transfer coding or terminate the message by closing the as the final transfer coding or terminate the message by closing the
connection. connection.
For example, For example,
Transfer-Encoding: gzip, chunked Transfer-Encoding: gzip, chunked
indicates that the content has been compressed using the gzip coding indicates that the content has been compressed using the gzip coding
and then chunked using the chunked coding while forming the message and then chunked using the chunked coding while forming the message
body. body.
Unlike Content-Encoding (Section 8.4.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
skipping to change at page 19, line 21 skipping to change at page 19, line 45
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 (Section 8.6 of [Semantics]) can provide
decimal number of octets, for potential content. For messages that the anticipated size, as a decimal number of octets, for potential
do include content, the Content-Length field value provides the content. For messages that do include content, the Content-Length
framing information necessary for determining where the data (and field value provides the framing information necessary for
message) ends. For messages that do not include content, the determining where the data (and message) ends. For messages that do
Content-Length indicates the size of the selected representation not include content, the Content-Length indicates the size of the
(Section 8.6 of [Semantics]). selected representation (Section 8.6 of [Semantics]).
A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field.
| *Note:* HTTP's use of Content-Length for message framing | *Note:* HTTP's use of Content-Length for message framing
| differs significantly from the same field's use in MIME, where | differs significantly from the same field's use in MIME, where
| it is an optional field used only within the "message/external- | it is an optional field used only within the "message/external-
| body" media-type. | body" media-type.
6.3. Message Body Length 6.3. Message Body Length
The length of a message body is determined by one of the following The length of a message body is determined by one of the following
(in order of precedence): (in order of precedence):
1. Any response to a HEAD request and any response with a 1xx 1. Any response to a HEAD request and any response with a 1xx
(Informational), 204 (No Content), or 304 (Not Modified) status (Informational), 204 (No Content), or 304 (Not Modified) status
code is always terminated by the first empty line after the code is always terminated by the first empty line after the
header fields, regardless of the header fields present in the header fields, regardless of the header fields present in the
message, and thus cannot contain a message body or trailer message, and thus cannot contain a message body or trailer
section(s). section.
2. Any 2xx (Successful) response to a CONNECT request implies that 2. Any 2xx (Successful) response to a CONNECT request implies that
the connection will become a tunnel immediately after the empty the connection will become a tunnel immediately after the empty
line that concludes the header fields. A client MUST ignore any line that concludes the header fields. A client MUST ignore any
Content-Length or Transfer-Encoding header fields received in Content-Length or Transfer-Encoding header fields received in
such a message. such a message.
3. If a message is received with both a Transfer-Encoding and a 3. If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to Content-Length. Such a message might indicate an attempt to
skipping to change at page 21, line 38 skipping to change at page 22, line 19
client that sends a request containing a message body SHOULD use a client that sends a request containing a message body SHOULD use a
valid Content-Length header field if the message body length is known valid Content-Length header field if the message body length is known
in advance, rather than the chunked transfer coding, since some in advance, rather than the chunked transfer coding, since some
existing services respond to chunked with a 411 (Length Required) existing services respond to chunked with a 411 (Length Required)
status code even though they understand the chunked transfer coding. status code even though they understand the chunked transfer coding.
This is typically because such services are implemented via a gateway This is typically because such services are implemented via a gateway
that requires a content-length in advance of being called and the that requires a content-length in advance of being called and the
server is unable or unwilling to buffer the entire request before server is unable or unwilling to buffer the entire request before
processing. processing.
A user agent that sends a request containing a message body MUST send A user agent that sends a request that contains a message body MUST
a valid Content-Length header field if it does not know the server send either a valid Content-Length header field or use the chunked
will handle HTTP/1.1 (or later) requests; such knowledge can be in transfer coding. A client MUST NOT use the chunked transfer encoding
the form of specific user configuration or by remembering the version unless it knows the server will handle HTTP/1.1 (or later) requests;
of a prior received response. such knowledge can be in the form of specific user configuration or
by remembering the version of a prior received response.
If the final response to the last request on a connection has been If the final response to the last request on a connection has been
completely received and there remains additional data to read, a user completely received and there remains additional data to read, a user
agent MAY discard the remaining data or attempt to determine if that agent MAY discard the remaining data or attempt to determine if that
data belongs as part of the prior message body, which might be the data belongs as part of the prior message body, which might be the
case if the prior message's Content-Length value is incorrect. A case if the prior message's Content-Length value is incorrect. A
client MUST NOT process, cache, or forward such extra data as a client MUST NOT process, cache, or forward such extra data as a
separate response, since such behavior would be vulnerable to cache separate response, since such behavior would be vulnerable to cache
poisoning. poisoning.
skipping to change at page 22, line 50 skipping to change at page 23, line 35
chunk-data = 1*OCTET ; a sequence of chunk-size octets chunk-data = 1*OCTET ; a sequence of chunk-size octets
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked transfer coding is complete the chunk-data in octets. The chunked transfer coding is complete
when a chunk with a chunk-size of zero is received, possibly followed when a chunk with a chunk-size of zero is received, possibly followed
by a trailer section, and finally terminated by an empty line. by a trailer section, and finally terminated by an empty line.
A recipient MUST be able to parse and decode the chunked transfer A recipient MUST be able to parse and decode the chunked transfer
coding. coding.
Note that HTTP/1.1 does not define any means to limit the size of a HTTP/1.1 does not define any means to limit the size of a chunked
chunked response such that an intermediary can be assured of response such that an intermediary can be assured of buffering the
buffering the entire response. entire response. Additionally, very large chunk sizes may cause
overflows or loss of precision if their values are not represented
accurately in a receiving implementation. Therefore, recipients MUST
anticipate potentially large decimal numerals and prevent parsing
errors due to integer conversion overflows or precision loss due to
integer representation.
The chunked encoding does not define any parameters. Their presence The chunked encoding does not define any parameters. Their presence
SHOULD be treated as an error. SHOULD be treated as an error.
7.1.1. Chunk Extensions 7.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
extensions, immediately following the chunk-size, for the sake of extensions, immediately following the chunk-size, for the sake of
supplying per-chunk metadata (such as a signature or hash), mid- supplying per-chunk metadata (such as a signature or hash), mid-
message control information, or randomization of message body size. message control information, or randomization of message body size.
skipping to change at page 24, line 41 skipping to change at page 25, line 28
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
} }
else { else {
discard trailer field discard trailer field
} }
read trailer field read trailer field
} }
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
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.4.1.1 of [Semantics]. See Section 8.4.1.1 of [Semantics].
deflate deflate
skipping to change at page 25, line 19 skipping to change at page 26, line 5
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 * Name
o Description * Description
o Pointer to specification text * 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.4.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
skipping to change at page 25, line 48 skipping to change at page 26, line 34
transfer coding defined in this specification. transfer coding defined in this specification.
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
7.4. Negotiating Transfer Codings 7.4. Negotiating Transfer Codings
The TE field (Section 10.1.4 of [Semantics]) is used in HTTP/1.1 to The TE field (Section 10.1.4 of [Semantics]) is used in HTTP/1.1 to
indicate what transfer-codings, besides chunked, the client is indicate what transfer-codings, besides chunked, the client is
willing to accept in the response, and whether or not the client is willing to accept in the response, and whether or not the client is
willing to accept trailer fields in a chunked transfer coding. willing to preserve trailer fields in a chunked transfer coding.
A client MUST NOT send the chunked transfer coding name in TE; A client MUST NOT send the chunked transfer coding name in TE;
chunked is always acceptable for HTTP/1.1 recipients. chunked is always acceptable for HTTP/1.1 recipients.
Three examples of TE use are below. Three examples of TE use are below.
TE: deflate TE: deflate
TE: TE:
TE: trailers, deflate;q=0.5 TE: trailers, deflate;q=0.5
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 12.4.2 of [Semantics]). The rank value is a real number in Section 12.4.2 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
skipping to change at page 27, line 6 skipping to change at page 27, line 42
fields to convey the full meaning of the response, then the client fields to convey the full meaning of the response, then the client
cannot assume that meaning has been conveyed; the client might need cannot assume that meaning has been conveyed; the client might need
to repeat the request in order to determine what action to take next. to repeat the request in order to determine what action to take next.
A message body that uses the chunked transfer coding is incomplete if A message body that uses the chunked transfer coding is incomplete if
the zero-sized chunk that terminates the encoding has not been the zero-sized chunk that terminates the encoding has not been
received. A message that uses a valid Content-Length is incomplete received. A message that uses a valid Content-Length is incomplete
if the size of the message body received (in octets) is less than the if the size of the message body received (in octets) is less than the
value given by Content-Length. A response that has neither chunked value given by Content-Length. A response that has neither chunked
transfer coding nor Content-Length is terminated by closure of the transfer coding nor Content-Length is terminated by closure of the
connection and, thus, is considered complete regardless of the number connection and, if the header section was received intact, is
of message body octets received, provided that the header section was considered complete unless an error was indicated by the underlying
received intact. connection (e.g., an "incomplete close" in TLS would leave the
response incomplete, as described in Section 9.8).
9. Connection Management 9. Connection Management
HTTP messaging is independent of the underlying transport- or HTTP messaging is independent of the underlying transport- or
session-layer connection protocol(s). HTTP only presumes a reliable session-layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport response structures onto the data units of an underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
skipping to change at page 28, line 32 skipping to change at page 29, line 21
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. HTTP implementations SHOULD support persistent
connection will not persist after the current request/response. HTTP 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 * If the close connection option is present (Section 9.6), the
not persist after the current response; else, connection will not persist after the current response; else,
o If the received protocol is HTTP/1.1 (or later), the connection * If the received protocol is HTTP/1.1 (or later), the connection
will persist after the current response; else, will persist after the current response; else,
o If the received protocol is HTTP/1.0, the "keep-alive" connection * If the received protocol is HTTP/1.0, the "keep-alive" connection
option is present, either the recipient is not a proxy or the option is present, either the recipient is not a proxy or the
message is a response, and the recipient wishes to honor the message is a response, and the recipient wishes to honor the
HTTP/1.0 "keep-alive" mechanism, the connection will persist after HTTP/1.0 "keep-alive" mechanism, the connection will persist after
the current response; otherwise, the current response; otherwise,
o The connection will close after the current response. * The connection will close after the current response.
A client that does not support persistent connections MUST send the A client that does not support persistent connections MUST send the
"close" connection option in every request message. close connection option in every request message.
A server that does not support persistent connections MUST send the A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not close connection option in every response message that does not have
have a 1xx (Informational) status code. a 1xx (Informational) status code.
A client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a "close" connection option or receives an until it sends or receives a close connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to In order to remain persistent, all messages on a connection need to
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 6. A server MUST read of the connection), as described in Section 6. A server MUST read
the entire request message body or close the connection after sending the entire request message body or close the connection after sending
its response, since otherwise the remaining data on a persistent its response, since otherwise the remaining data on a persistent
connection would be misinterpreted as the next request. Likewise, a connection would be misinterpreted as the next request. Likewise, a
client MUST read the entire response message body if it intends to client MUST read the entire response message body if it intends to
reuse the same connection for a subsequent request. reuse the same connection for a subsequent request.
A proxy server MUST NOT maintain a persistent connection with an A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
Note that the field name "Close" is reserved, since using that name
as an HTTP header field might conflict with the "close" connection
defined above.
See Appendix C.2.2 for more information on backwards compatibility See Appendix C.2.2 for more information on backwards compatibility
with HTTP/1.0 clients. with HTTP/1.0 clients.
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].
skipping to change at page 31, line 35 skipping to change at page 32, line 22
time. For example, a client might have started to send a new request time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle" at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a closed while it was idle, but from the client's point of view, a
request is in progress. request is in progress.
A server SHOULD sustain persistent connections, when possible, and A server SHOULD sustain persistent connections, when possible, and
allow the underlying transport's flow-control mechanisms to resolve allow the underlying transport's flow-control mechanisms to resolve
temporary overloads, rather than terminate connections with the temporary overloads, rather than terminate connections with the
expectation that clients will retry. The latter technique can expectation that clients will retry. The latter technique can
exacerbate network congestion. exacerbate network congestion or server load.
A client sending a message body SHOULD monitor the network connection A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
9.6. Tear-down 9.6. Tear-down
The Connection header field (Section 7.6.1 of [Semantics]) provides a The "close" connection option is defined as a signal that the sender
"close" connection option that a sender SHOULD send when it wishes to will close this connection after completion of the response. A
close the connection after the current request/response pair. sender SHOULD send a Connection header field (Section 7.6.1 of
[Semantics]) containing the close connection option when it intends
to close a connection. For example,
A client that sends a "close" connection option MUST NOT send further Connection: close
requests on that connection (after the one containing "close") and
as a request header field indicates that this is the last request
that the client will send on this connection, while in a response the
same field indicates that the server is going to close this
connection after the response message is complete.
Note that the field name "Close" is reserved, since using that name
as a header field might conflict with the close connection option.
A client that sends a close connection option MUST NOT send further
requests on that connection (after the one containing the close) and
MUST close the connection after reading the final response message MUST close the connection after reading the final response message
corresponding to this request. corresponding to this request.
A server that receives a "close" connection option MUST initiate a A server that receives a close connection option MUST initiate
close of the connection (see below) after it sends the final response closure of the connection (see below) after it sends the final
to the request that contained "close". The server SHOULD send a response to the request that contained the close connection option.
"close" connection option in its final response on that connection. The server SHOULD send a close connection option in its final
The server MUST NOT process any further requests received on that response on that connection. The server MUST NOT process any further
connection. requests received on that connection.
A server that sends a "close" connection option MUST initiate a close A server that sends a close connection option MUST initiate closure
of the connection (see below) after it sends the response containing of the connection (see below) after it sends the response containing
"close". The server MUST NOT process any further requests received the close connection option. The server MUST NOT process any further
on that connection. requests received on that connection.
A client that receives a "close" connection option MUST cease sending A client that receives a close connection option MUST cease sending
requests on that connection and close the connection after reading requests on that connection and close the connection after reading
the response message containing the "close"; if additional pipelined the response message containing the close connection option; if
requests had been sent on the connection, the client SHOULD NOT additional pipelined requests had been sent on the connection, the
assume that they will be processed by the server. client SHOULD NOT assume that they will be processed by the server.
If a server performs an immediate close of a TCP connection, there is If a server performs an immediate close of a TCP connection, there is
a significant risk that the client will not be able to read the last a significant risk that the client will not be able to read the last
HTTP response. If the server receives additional data from the HTTP response. If the server receives additional data from the
client on a fully closed connection, such as another request that was client on a fully closed connection, such as another request sent by
sent by the client before receiving the server's response, the the client before receiving the server's response, the server's TCP
server's TCP stack will send a reset packet to the client; stack will send a reset packet to the client; unfortunately, the
unfortunately, the reset packet might erase the client's reset packet might erase the client's unacknowledged input buffers
unacknowledged input buffers before they can be read and interpreted before they can be read and interpreted by the client's HTTP parser.
by the client's HTTP parser.
To avoid the TCP reset problem, servers typically close a connection To avoid the TCP reset problem, servers typically close a connection
in stages. First, the server performs a half-close by closing only in stages. First, the server performs a half-close by closing only
the write side of the read/write connection. The server then the write side of the read/write connection. The server then
continues to read from the connection until it receives a continues to read from the connection until it receives a
corresponding close by the client, or until the server is reasonably corresponding close by the client, or until the server is reasonably
certain that its own TCP stack has received the client's certain that its own TCP stack has received the client's
acknowledgement of the packet(s) containing the server's last acknowledgement of the packet(s) containing the server's last
response. Finally, the server fully closes the connection. response. Finally, the server fully closes the connection.
skipping to change at page 33, line 32 skipping to change at page 34, line 26
as a persistent connection). as a persistent connection).
9.8. TLS Connection Closure 9.8. TLS Connection Closure
TLS provides a facility for secure connection closure. When a valid TLS provides a facility for secure connection closure. When a valid
closure alert is received, an implementation can be assured that no closure alert is received, an implementation can be assured that no
further data will be received on that connection. TLS further data will be received on that connection. TLS
implementations MUST initiate an exchange of closure alerts before implementations MUST initiate an exchange of closure alerts before
closing a connection. A TLS implementation MAY, after sending a closing a connection. A TLS implementation MAY, after sending a
closure alert, close the connection without waiting for the peer to closure alert, close the connection without waiting for the peer to
send its closure alert, generating an "incomplete close". Note that send its closure alert, generating an "incomplete close". This
an implementation which does this MAY choose to reuse the session. SHOULD only be done when the application knows (typically through
This SHOULD only be done when the application knows (typically detecting HTTP message boundaries) that it has sent or received all
through detecting HTTP message boundaries) that it has received all
the message data that it cares about. the message data that it cares about.
As specified in [RFC8446], any implementation which receives a An incomplete close does not call into question the security of the
connection close without first receiving a valid closure alert (a data already received, but it could indicate that subsequent data
"premature close") MUST NOT reuse that session. Note that a might have been truncated. As TLS is not directly aware of HTTP
premature close does not call into question the security of the data message framing, it is necessary to examine the HTTP data itself to
already received, but simply indicates that subsequent data might determine whether messages were complete. Handing of incomplete
have been truncated. Because TLS is oblivious to HTTP request/ messages is defined in Section 8.
response boundaries, it is necessary to examine the HTTP data itself
(specifically the Content-Length header) to determine whether the
truncation occurred inside a message or between messages.
When encountering a premature close, a client SHOULD treat as When encountering an incomplete close, a client SHOULD treat as
completed all requests for which it has received as much data as completed all requests for which it has received as much data as
specified in the Content-Length header. specified in the Content-Length header or, when a Transfer-Encoding
of chunked is used, for which the terminal zero-length chunk has been
received. A response that has neither chunked transfer coding nor
Content-Length is complete only if a valid closure alert has been
received. Treating an incomplete message as complete could expose
implementations to attack.
A client detecting an incomplete close SHOULD recover gracefully. It A client detecting an incomplete close SHOULD recover gracefully.
MAY resume a TLS session closed in this fashion.
Clients MUST send a closure alert before closing the connection. Clients MUST send a closure alert before closing the connection.
Clients which are unprepared to receive any more data MAY choose not Clients that do not expect to receive any more data MAY choose not to
to wait for the server's closure alert and simply close the wait for the server's closure alert and simply close the connection,
connection, thus generating an incomplete close on the server side. thus generating an incomplete close on the server side.
Servers SHOULD be prepared to receive an incomplete close from the Servers SHOULD be prepared to receive an incomplete close from the
client, since the client can often determine when the end of server client, since the client can often determine when the end of server
data is. Servers SHOULD be willing to resume TLS sessions closed in data is.
this fashion.
Servers MUST attempt to initiate an exchange of closure alerts with Servers MUST attempt to initiate an exchange of closure alerts with
the client before closing the connection. Servers MAY close the the client before closing the connection. Servers MAY close the
connection after sending the closure alert, thus generating an connection after sending the closure alert, thus generating an
incomplete close on the client side. incomplete close on the client side.
10. Enclosing Messages as Data 10. Enclosing Messages as Data
10.1. Media Type message/http 10.1. Media Type message/http
skipping to change at page 38, line 10 skipping to change at page 39, line 10
This specification has introduced new requirements on request This specification has introduced new requirements on request
parsing, particularly with regard to message framing in Section 6.3, parsing, particularly with regard to message framing in Section 6.3,
to reduce the effectiveness of request smuggling. to reduce the effectiveness of request smuggling.
11.3. Message Integrity 11.3. Message Integrity
HTTP does not define a specific mechanism for ensuring message HTTP does not define a specific mechanism for ensuring message
integrity, instead relying on the error-detection ability of integrity, instead relying on the error-detection ability of
underlying transport protocols and the use of length or chunk- underlying transport protocols and the use of length or chunk-
delimited framing to detect completeness. Additional integrity delimited framing to detect completeness. Historically, the lack of
mechanisms, such as hash functions or digital signatures applied to a single integrity mechanism has been justified by the informal
the content, can be selectively added to messages via extensible nature of most HTTP communication. However, the prevalence of HTTP
metadata fields. Historically, the lack of a single integrity as an information access mechanism has resulted in its increasing use
mechanism has been justified by the informal nature of most HTTP within environments where verification of message integrity is
communication. However, the prevalence of HTTP as an information crucial.
access mechanism has resulted in its increasing use within
environments where verification of message integrity is crucial.
User agents are encouraged to implement configurable means for The mechanisms provided with the "https" scheme, such as
detecting and reporting failures of message integrity such that those authenticated encryption, provide protection against modification of
means can be enabled within environments for which integrity is messages. Care is needed however to ensure that connection closure
necessary. For example, a browser being used to view medical history cannot be used to truncate messages (see Section 9.8). User agents
or drug interaction information needs to indicate to the user when might refuse to accept incomplete messages or treat them specially.
such information is detected by the protocol to be incomplete, For example, a browser being used to view medical history or drug
expired, or corrupted during transfer. Such mechanisms might be interaction information needs to indicate to the user when such
selectively enabled via user agent extensions or the presence of information is detected by the protocol to be incomplete, expired, or
message integrity metadata in a response. At a minimum, user agents corrupted during transfer. Such mechanisms might be selectively
ought to provide some indication that allows a user to distinguish enabled via user agent extensions or the presence of message
between a complete and incomplete response message (Section 8) when integrity metadata in a response.
such verification is desired.
The "http" scheme provides no protection against accidental or
malicious modification of messages.
Extensions to the protocol might be used to mitigate the risk of
unwanted modification of messages by intermediaries, even when the
"https" scheme is used. Integrity might be assured by using hash
functions or digital signatures that are selectively added to
messages via extensible metadata fields.
11.4. Message Confidentiality 11.4. Message Confidentiality
HTTP relies on underlying transport protocols to provide message HTTP relies on underlying transport protocols to provide message
confidentiality when that is desired. HTTP has been specifically confidentiality when that is desired. HTTP has been specifically
designed to be independent of the transport protocol, such that it designed to be independent of the transport protocol, such that it
can be used over many different forms of encrypted connection, with can be used over many different forms of encrypted connection, with
the selection of such transports being identified by the choice of the selection of such transports being identified by the choice of
URI scheme or within user agent configuration. URI scheme or within user agent configuration.
skipping to change at page 39, line 14 skipping to change at page 40, line 19
12.1. Field Name Registration 12.1. Field Name Registration
First, introduce the new "Hypertext Transfer Protocol (HTTP) Field First, introduce the new "Hypertext Transfer Protocol (HTTP) Field
Name Registry" at <https://www.iana.org/assignments/http-fields> as Name Registry" at <https://www.iana.org/assignments/http-fields> as
described in Section 18.4 of [Semantics]. described in Section 18.4 of [Semantics].
Then, please update the registry with the field names listed in the Then, please update the registry with the field names listed in the
table below: table below:
------------------- ---------- ------ ------------ +===================+==========+======+============+
Field Name Status Ref. Comments | Field Name | Status | Ref. | Comments |
------------------- ---------- ------ ------------ +===================+==========+======+============+
Close standard 9.3 (reserved) | Close | standard | 9.6 | (reserved) |
MIME-Version standard B.1 +-------------------+----------+------+------------+
Transfer-Encoding standard 6.1 | MIME-Version | standard | B.1 | |
------------------- ---------- ------ ------------ +-------------------+----------+------+------------+
| Transfer-Encoding | standard | 6.1 | |
+-------------------+----------+------+------------+
Table 1 Table 1
12.2. Media Type Registration 12.2. Media Type Registration
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 10.1 and Section 10.2 for the media types information in Section 10.1 and Section 10.2 for the media types
"message/http" and "application/http", respectively. "message/http" and "application/http", respectively.
12.3. Transfer Coding Registration 12.3. Transfer Coding Registration
Please update the "HTTP Transfer Coding Registry" at Please update the "HTTP Transfer Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 7.3 and the content coding names registration procedure of Section 7.3 and the content coding names
summarized in the table below. summarized in the table below.
------------ ------------------------------- ----------- +============+===============================+===========+
Name Description Reference | Name | Description | Reference |
------------ ------------------------------- ----------- +============+===============================+===========+
chunked Transfer in a series of Section | chunked | Transfer in a series of | Section |
chunks 7.1 | | chunks | 7.1 |
compress UNIX "compress" data format Section +------------+-------------------------------+-----------+
[Welch] 7.2 | compress | UNIX "compress" data format | Section |
deflate "deflate" compressed data Section | | [Welch] | 7.2 |
([RFC1951]) inside the "zlib" 7.2 +------------+-------------------------------+-----------+
data format ([RFC1950]) | deflate | "deflate" compressed data | Section |
gzip GZIP file format [RFC1952] Section | | ([RFC1951]) inside the "zlib" | 7.2 |
7.2 | | data format ([RFC1950]) | |
trailers (reserved) Section +------------+-------------------------------+-----------+
12.3 | gzip | GZIP file format [RFC1952] | Section |
x-compress Deprecated (alias for Section | | | 7.2 |
compress) 7.2 +------------+-------------------------------+-----------+
x-gzip Deprecated (alias for gzip) Section | trailers | (reserved) | Section |
7.2 | | | 12.3 |
------------ ------------------------------- ----------- +------------+-------------------------------+-----------+
| x-compress | Deprecated (alias for | Section |
| | compress) | 7.2 |
+------------+-------------------------------+-----------+
| x-gzip | Deprecated (alias for gzip) | Section |
| | | 7.2 |
+------------+-------------------------------+-----------+
Table 2 Table 2
| *Note:* the coding name "trailers" is reserved because its use | *Note:* the coding name "trailers" is reserved because its use
| would conflict with the keyword "trailers" in the TE header | would conflict with the keyword "trailers" in the TE header
| field (Section 10.1.4 of [Semantics]). | field (Section 10.1.4 of [Semantics]).
12.4. ALPN Protocol ID Registration 12.4. ALPN Protocol ID Registration
Please update the "TLS Application-Layer Protocol Negotiation (ALPN) Please update the "TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs" registry at <https://www.iana.org/assignments/tls- Protocol IDs" registry at <https://www.iana.org/assignments/tls-
extensiontype-values/tls-extensiontype-values.xhtml> with the extensiontype-values/tls-extensiontype-values.xhtml> with the
registration below: registration below:
---------- ----------------------------- ---------------- +==========+=============================+================+
Protocol Identification Sequence Reference | Protocol | Identification Sequence | Reference |
---------- ----------------------------- ---------------- +==========+=============================+================+
HTTP/1.1 0x68 0x74 0x74 0x70 0x2f (this | HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | (this |
0x31 0x2e 0x31 ("http/1.1") specification) | | 0x31 0x2e 0x31 ("http/1.1") | specification) |
---------- ----------------------------- ---------------- +----------+-----------------------------+----------------+
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-14, January 13, 2021, draft-ietf-httpbis-cache-15, 30 March 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-14>. <https://tools.ietf.org/html/draft-ietf-httpbis-cache-15>.
[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 43, line 12
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-14, January 13, 2021, draft-ietf-httpbis-semantics-15, 30 March 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
14>. 15>.
[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 43, line 47 skipping to change at page 45, line 4
Section 5.6.1.1 of [Semantics]. Section 5.6.1.1 of [Semantics].
BWS = <BWS, see [Semantics], Section 5.6.3> BWS = <BWS, see [Semantics], 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 [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>
Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding
) ] ) ]
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = <absolute-path, see [Semantics], Section 4> absolute-path = <absolute-path, see [Semantics], Section 4>
asterisk-form = "*" asterisk-form = "*"
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
authority-form = authority 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
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-section CRLF chunked-body = *chunk last-chunk trailer-section CRLF
skipping to change at page 44, line 34 skipping to change at page 45, line 38
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
skipping to change at page 44, line 45 skipping to change at page 46, line 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
optimize performance over binary connections, to allow greater optimize performance over binary connections, to allow greater
skipping to change at page 45, line 38 skipping to change at page 46, line 43
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.3.3 of [Semantics] describes the forms of [RFC2049], and that content with a type of "text" represent line
allowed for subtypes of the "text" media type when transmitted over breaks as CRLF, forbidding the use of CR or LF outside of line break
HTTP. [RFC2046] requires that content with a type of "text" sequences [RFC2046]. In contrast, HTTP does not care whether CRLF,
represent line breaks as CRLF and forbids the use of CR or LF outside bare CR, or bare LF are used to indicate a line break within content.
of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
indicate a line break within text content.
A proxy or gateway from HTTP to a strict MIME environment ought to A proxy or gateway from HTTP to a strict MIME environment ought to
translate all line breaks within text media types to the RFC 2049 translate all line breaks within text media types to the RFC 2049
canonical form of CRLF. Note, however, this might be complicated by canonical form of CRLF. Note, however, this might be complicated by
the presence of a Content-Encoding and by the fact that HTTP allows the presence of a Content-Encoding and by the fact that HTTP allows
the use of some charsets that do not use octets 13 and 10 to the use of some charsets that do not use octets 13 and 10 to
represent CR and LF, respectively. represent CR and LF, respectively.
Conversion will break any cryptographic checksums applied to the Conversion will break any cryptographic checksums applied to the
original content unless the original content is already in canonical original content unless the original content is already in canonical
skipping to change at page 48, line 39 skipping to change at page 50, line 4
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 content. (Section 2.2) Prohibited generation of bare CRs outside of content. (Section 2.2)
The ABNF definition of authority-form has changed from the more
general authority component of a URI (in which port is optional) to
the specific host:port format that is required by CONNECT.
(Section 3.2.3)
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 49, line 26 skipping to change at page 50, line 36
(Section 7.3) (Section 7.3)
Appendix D. Change Log Appendix D. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
D.1. Between RFC7230 and draft 00 D.1. Between RFC7230 and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, * Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
o Adjust historical notes. * Adjust historical notes.
o Update links to sibling specifications. * Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty * Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x. sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x. * Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered. * Move "Acknowledgements" to the very end and make them unnumbered.
D.2. Since draft-ietf-httpbis-messaging-00 D.2. Since draft-ietf-httpbis-messaging-00
The changes in this draft are editorial, with respect to HTTP as a The changes in this draft are editorial, with respect to HTTP as a
whole, to move all core HTTP semantics into [Semantics]: whole, to move all core HTTP semantics into [Semantics]:
o Moved introduction, architecture, conformance, and ABNF extensions * Moved introduction, architecture, conformance, and ABNF extensions
from RFC 7230 (Messaging) to semantics [Semantics]. from RFC 7230 (Messaging) to semantics [Semantics].
o Moved discussion of MIME differences from RFC 7231 (Semantics) to * Moved discussion of MIME differences from RFC 7231 (Semantics) to
Appendix B since they mostly cover transforming 1.1 messages. Appendix B since they mostly cover transforming 1.1 messages.
o Moved all extensibility tips, registration procedures, and * Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
D.3. Since draft-ietf-httpbis-messaging-01 D.3. Since draft-ietf-httpbis-messaging-01
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/ * Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>) http-core/issues/75>)
o Resolved erratum 4779, no change needed here * Resolved erratum 4779, no change needed here
(<https://github.com/httpwg/http-core/issues/87>, (<https://github.com/httpwg/http-core/issues/87>,
<https://www.rfc-editor.org/errata/eid4779>) <https://www.rfc-editor.org/errata/eid4779>)
o In Section 7, fixed prose claiming transfer parameters allow bare * In Section 7, fixed prose claiming transfer parameters allow bare
names (<https://github.com/httpwg/http-core/issues/88>, names (<https://github.com/httpwg/http-core/issues/88>,
<https://www.rfc-editor.org/errata/eid4839>) <https://www.rfc-editor.org/errata/eid4839>)
o Resolved erratum 4225, no change needed here * Resolved erratum 4225, no change needed here
(<https://github.com/httpwg/http-core/issues/90>, (<https://github.com/httpwg/http-core/issues/90>,
<https://www.rfc-editor.org/errata/eid4225>) <https://www.rfc-editor.org/errata/eid4225>)
o Replace "response code" with "response status code" * Replace "response code" with "response status code"
(<https://github.com/httpwg/http-core/issues/94>, (<https://github.com/httpwg/http-core/issues/94>,
<https://www.rfc-editor.org/errata/eid4050>) <https://www.rfc-editor.org/errata/eid4050>)
o In Section 9.3, clarify statement about HTTP/1.0 keep-alive * In Section 9.3, clarify statement about HTTP/1.0 keep-alive
(<https://github.com/httpwg/http-core/issues/96>, (<https://github.com/httpwg/http-core/issues/96>,
<https://www.rfc-editor.org/errata/eid4205>) <https://www.rfc-editor.org/errata/eid4205>)
o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "=" * In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="
(<https://github.com/httpwg/http-core/issues/101>, (<https://github.com/httpwg/http-core/issues/101>,
<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc- <https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-
editor.org/errata/eid4825>) editor.org/errata/eid4825>)
o In Section 7.3, state that transfer codings should not use * In Section 7.3, state that transfer codings should not use
parameters named "q" (<https://github.com/httpwg/http-core/ parameters named "q" (<https://github.com/httpwg/http-core/
issues/15>, <https://www.rfc-editor.org/errata/eid4683>) issues/15>, <https://www.rfc-editor.org/errata/eid4683>)
o In Section 7, mark coding name "trailers" as reserved in the IANA * In Section 7, mark coding name "trailers" as reserved in the IANA
registry (<https://github.com/httpwg/http-core/issues/108>) registry (<https://github.com/httpwg/http-core/issues/108>)
D.4. Since draft-ietf-httpbis-messaging-02 D.4. Since draft-ietf-httpbis-messaging-02
o In Section 4, explain why the reason phrase should be ignored by * In Section 4, explain why the reason phrase should be ignored by
clients (<https://github.com/httpwg/http-core/issues/60>). clients (<https://github.com/httpwg/http-core/issues/60>).
o Add Section 9.2 to explain how request/response correlation is * Add Section 9.2 to explain how request/response correlation is
performed (<https://github.com/httpwg/http-core/issues/145>) performed (<https://github.com/httpwg/http-core/issues/145>)
D.5. Since draft-ietf-httpbis-messaging-03 D.5. Since draft-ietf-httpbis-messaging-03
o In Section 9.2, caution against treating data on a connection as * In Section 9.2, caution against treating data on a connection as
part of a not-yet-issued request (<https://github.com/httpwg/http- part of a not-yet-issued request (<https://github.com/httpwg/http-
core/issues/26>) core/issues/26>)
o In Section 7, remove the predefined codings from the ABNF and make * In Section 7, remove the predefined codings from the ABNF and make
it generic instead (<https://github.com/httpwg/http-core/ it generic instead (<https://github.com/httpwg/http-core/
issues/66>) issues/66>)
o Use RFC 7405 ABNF notation for case-sensitive string constants * Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
D.6. Since draft-ietf-httpbis-messaging-04 D.6. Since draft-ietf-httpbis-messaging-04
o In Section 7.8 of [Semantics], clarify that protocol-name is to be * In Section 7.8 of [Semantics], clarify that protocol-name is to be
matched case-insensitively (<https://github.com/httpwg/http-core/ matched case-insensitively (<https://github.com/httpwg/http-core/
issues/8>) issues/8>)
o In Section 5.2, add leading optional whitespace to obs-fold ABNF * In Section 5.2, add leading optional whitespace to obs-fold ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o In Section 4, add clarifications about empty reason phrases * In Section 4, add clarifications about empty reason phrases
(<https://github.com/httpwg/http-core/issues/197>) (<https://github.com/httpwg/http-core/issues/197>)
o Move discussion of retries from Section 9.3.1 into [Semantics] * Move discussion of retries from Section 9.3.1 into [Semantics]
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
D.7. Since draft-ietf-httpbis-messaging-05 D.7. Since draft-ietf-httpbis-messaging-05
* In Section 7.1.2, the trailer part has been renamed the trailer
o In Section 7.1.2, the trailer part has been renamed the trailer
section (for consistency with the header section) and trailers are section (for consistency with the header section) and trailers are
no longer merged as header fields by default, but rather can be no longer merged as header fields by default, but rather can be
discarded, kept separate from header fields, or merged with header discarded, kept separate from header fields, or merged with header
fields only if understood and defined as being mergeable fields only if understood and defined as being mergeable
(<https://github.com/httpwg/http-core/issues/16>) (<https://github.com/httpwg/http-core/issues/16>)
o In Section 2.1 and related Sections, move the trailing CRLF from * In Section 2.1 and related Sections, move the trailing CRLF from
the line grammars into the message format the line grammars into the message format
(<https://github.com/httpwg/http-core/issues/62>) (<https://github.com/httpwg/http-core/issues/62>)
o Moved Section 2.3 down (<https://github.com/httpwg/http-core/ * Moved Section 2.3 down (<https://github.com/httpwg/http-core/
issues/68>) issues/68>)
o In Section 7.8 of [Semantics], use 'websocket' instead of * In Section 7.8 of [Semantics], use 'websocket' instead of
'HTTP/2.0' in examples (<https://github.com/httpwg/http-core/ 'HTTP/2.0' in examples (<https://github.com/httpwg/http-core/
issues/112>) issues/112>)
o Move version non-specific text from Section 6 into semantics as * Move version non-specific text from Section 6 into semantics as
"payload" (<https://github.com/httpwg/http-core/issues/159>) "payload" (<https://github.com/httpwg/http-core/issues/159>)
o In Section 9.8, add text from RFC 2818 * In Section 9.8, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
D.8. Since draft-ietf-httpbis-messaging-06 D.8. Since draft-ietf-httpbis-messaging-06
o In Section 12.4, update the APLN protocol id for HTTP/1.1 * In Section 12.4, update the APLN protocol id for HTTP/1.1
(<https://github.com/httpwg/http-core/issues/49>) (<https://github.com/httpwg/http-core/issues/49>)
o In Section 5, align with updates to field terminology in semantics * 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 7.6.1 of [Semantics], clarify that new connection * In Section 7.6.1 of [Semantics], clarify that new connection
options indeed need to be registered (<https://github.com/httpwg/ options indeed need to be registered (<https://github.com/httpwg/
http-core/issues/285>) http-core/issues/285>)
o In Section 1.1, reference RFC 8174 as well * 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 D.9. Since draft-ietf-httpbis-messaging-07
o Move TE: trailers into [Semantics] (<https://github.com/httpwg/ * Move TE: trailers into [Semantics] (<https://github.com/httpwg/
http-core/issues/18>) http-core/issues/18>)
o In Section 6.3, adjust requirements for handling multiple content- * In Section 6.3, adjust requirements for handling multiple content-
length values (<https://github.com/httpwg/http-core/issues/59>) length values (<https://github.com/httpwg/http-core/issues/59>)
o Throughout, replace "effective request URI" with "target URI" * Throughout, replace "effective request URI" with "target URI"
(<https://github.com/httpwg/http-core/issues/259>) (<https://github.com/httpwg/http-core/issues/259>)
o In Section 6.1, don't claim Transfer-Encoding is supported by * In Section 6.1, don't claim Transfer-Encoding is supported by
HTTP/2 or later (<https://github.com/httpwg/http-core/issues/297>) HTTP/2 or later (<https://github.com/httpwg/http-core/issues/297>)
D.10. Since draft-ietf-httpbis-messaging-08 D.10. Since draft-ietf-httpbis-messaging-08
o In Section 2.2, disallow bare CRs (<https://github.com/httpwg/ * In Section 2.2, disallow bare CRs (<https://github.com/httpwg/
http-core/issues/31>) http-core/issues/31>)
o Appendix A now uses the sender variant of the "#" list expansion * Appendix A now uses the sender variant of the "#" list expansion
(<https://github.com/httpwg/http-core/issues/192>) (<https://github.com/httpwg/http-core/issues/192>)
o In Section 5, adjust IANA "Close" entry for new registry format * In Section 5, adjust IANA "Close" entry for new registry format
(<https://github.com/httpwg/http-core/issues/273>) (<https://github.com/httpwg/http-core/issues/273>)
D.11. Since draft-ietf-httpbis-messaging-09 D.11. Since draft-ietf-httpbis-messaging-09
o Switch to xml2rfc v3 mode for draft generation * Switch to xml2rfc v3 mode for draft generation
(<https://github.com/httpwg/http-core/issues/394>) (<https://github.com/httpwg/http-core/issues/394>)
D.12. Since draft-ietf-httpbis-messaging-10 D.12. Since draft-ietf-httpbis-messaging-10
o In Section 6.3, note that TCP half-close does not delimit a * In Section 6.3, note that TCP half-close does not delimit a
request; talk about corresponding server-side behaviour in request; talk about corresponding server-side behaviour in
Section 9.6 (<https://github.com/httpwg/http-core/issues/22>) Section 9.6 (<https://github.com/httpwg/http-core/issues/22>)
o Moved requirements specific to HTTP/1.1 from [Semantics] into * Moved requirements specific to HTTP/1.1 from [Semantics] into
Section 3.2 (<https://github.com/httpwg/http-core/issues/182>) Section 3.2 (<https://github.com/httpwg/http-core/issues/182>)
o In Section 6.1 (Transfer-Encoding), adjust ABNF to allow empty * In Section 6.1 (Transfer-Encoding), adjust ABNF to allow empty
lists (<https://github.com/httpwg/http-core/issues/210>) lists (<https://github.com/httpwg/http-core/issues/210>)
o In Section 9.7, add text from RFC 2818 * In Section 9.7, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
o Moved definitions of "TE" and "Upgrade" into [Semantics] * Moved definitions of "TE" and "Upgrade" into [Semantics]
(<https://github.com/httpwg/http-core/issues/392>) (<https://github.com/httpwg/http-core/issues/392>)
o Moved definition of "Connection" into [Semantics] * Moved definition of "Connection" into [Semantics]
(<https://github.com/httpwg/http-core/issues/407>) (<https://github.com/httpwg/http-core/issues/407>)
D.13. Since draft-ietf-httpbis-messaging-11 D.13. Since draft-ietf-httpbis-messaging-11
o Move IANA Upgrade Token Registry instructions to [Semantics] * Move IANA Upgrade Token Registry instructions to [Semantics]
(<https://github.com/httpwg/http-core/issues/450>) (<https://github.com/httpwg/http-core/issues/450>)
D.14. Since draft-ietf-httpbis-messaging-12 D.14. Since draft-ietf-httpbis-messaging-12
o Moved content of history appendix to Semantics * Moved content of history appendix to Semantics
(<https://github.com/httpwg/http-core/issues/451>) (<https://github.com/httpwg/http-core/issues/451>)
o Moved note about "close" being reserved as field name to * Moved note about "close" being reserved as field name to
Section 9.3 (<https://github.com/httpwg/http-core/issues/500>) Section 9.3 (<https://github.com/httpwg/http-core/issues/500>)
o Moved table of transfer codings into Section 12.3 * Moved table of transfer codings into Section 12.3
(<https://github.com/httpwg/http-core/issues/506>) (<https://github.com/httpwg/http-core/issues/506>)
o In Section 13.2, updated the URI for the [Linhart] paper * In Section 13.2, updated the URI for the [Linhart] paper
(<https://github.com/httpwg/http-core/issues/517>) (<https://github.com/httpwg/http-core/issues/517>)
o Changed document title to just "HTTP/1.1" * Changed document title to just "HTTP/1.1"
(<https://github.com/httpwg/http-core/issues/524>) (<https://github.com/httpwg/http-core/issues/524>)
o In Section 7, moved transfer-coding ABNF to Section 10.1.4 of * 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 * 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 D.15. Since draft-ietf-httpbis-messaging-13
o In Section 6.3, clarify that a message needs to be checked for * In Section 6.3, clarify that a message needs to be checked for
both Content-Length and Transfer-Encoding, before processing both Content-Length and Transfer-Encoding, before processing
Transfer-Encoding, and that ought to be treated as an error, but Transfer-Encoding, and that ought to be treated as an error, but
an intermediary can choose to forward the message downstream after an intermediary can choose to forward the message downstream after
removing the Content-Length and processing the Transfer-Encoding removing the Content-Length and processing the Transfer-Encoding
(<https://github.com/httpwg/http-core/issues/617>) (<https://github.com/httpwg/http-core/issues/617>)
o Changed to using "content" instead of "payload" or "payload data" * Changed to using "content" instead of "payload" or "payload data"
to avoid confusion with the payload of version-specific messaging to avoid confusion with the payload of version-specific messaging
frames (<https://github.com/httpwg/http-core/issues/654>) frames (<https://github.com/httpwg/http-core/issues/654>)
D.16. Since draft-ietf-httpbis-messaging-14
* In Section 9.6, define the close connection option, since its
definition was removed from the Connection header field for being
specific to 1.1 (<https://github.com/httpwg/http-core/issues/678>)
* In Section 3.3, clarify how the target URI is reconstructed when
the request-target is not in absolute-form and highlight risk in
selecting a default host (<https://github.com/httpwg/http-core/
issues/722>)
* In Section 7.1, clarify large chunk handling issues
(<https://github.com/httpwg/http-core/issues/749>)
* In Section 2.2, explicitly close the connection after sending a
400 (<https://github.com/httpwg/http-core/issues/750>)
* In Section 2.3, refine version requirements for intermediaries
(<https://github.com/httpwg/http-core/issues/751>)
* In Section 7.1.3, don't remove the Trailer header field
(<https://github.com/httpwg/http-core/issues/793>)
* In Section 3.2.3, changed the ABNF definition of authority-form
from the authority component (in which port is optional) to the
host:port format that has always been required by CONNECT
(<https://github.com/httpwg/http-core/issues/806>)
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. 161 change blocks. 
358 lines changed or deleted 444 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/