INTRODUCTION, paragraph 1:
OLD:
HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe
Obsoletes: 2145,2616 (if approved) J. Reschke, Ed.
Updates: 2817,2818 (if approved) greenbytes
Intended status: Standards Track May 6, 2014
Expires: November 7, 2014
NEW:
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7230 Adobe
Obsoletes: 2145, 2616 J. Reschke, Ed.
Updates: 2817, 2818 greenbytes
Category: Standards Track May 2014
ISSN: 2070-1721
INTRODUCTION, paragraph 2:
OLD:
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
draft-ietf-httpbis-p1-messaging-latest
NEW:
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
INTRODUCTION, paragraph 5:
OLD:
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
.
The current issues list is at
and related
documents (including fancy diffs) can be found at
.
The changes in this draft are summarized in Appendix C.4.
Status of This Memo
NEW:
Status of This Memo
INTRODUCTION, paragraph 6:
OLD:
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
NEW:
This is an Internet Standards Track document.
INTRODUCTION, paragraph 7:
OLD:
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
NEW:
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
INTRODUCTION, paragraph 8:
OLD:
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 7, 2014.
NEW:
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7230.
Section 11., paragraph 0:
OLD:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7
2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18
2.7.3. http and https URI Normalization and Comparison . . . 19
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23
3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. Field value components . . . . . . . . . . . . . . . . 26
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35
4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41
5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 42
5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42
5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44
5.6. Associating a Response to a Request . . . . . . . . . . . 46
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54
6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
8.1. Header Field Registration . . . . . . . . . . . . . . . . 60
8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
8.3. Internet Media Type Registration . . . . . . . . . . . . . 61
8.3.1. Internet Media Type message/http . . . . . . . . . . . 61
8.3.2. Internet Media Type application/http . . . . . . . . . 62
8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64
8.5. Content Coding Registration . . . . . . . . . . . . . . . 64
8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65
8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . . 66
9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66
9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67
9.3. Attacks via Protocol Element Length . . . . . . . . . . . 68
9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68
9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70
9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
11.2. Informative References . . . . . . . . . . . . . . . . . . 74
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80
Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 82
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82
C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 83
C.3. Since draft-ietf-httpbis-p1-messaging-25 . . . . . . . . . 83
C.4. Since draft-ietf-httpbis-p1-messaging-26 . . . . . . . . . 84
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
NEW:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7
2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
2.7.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16
2.7.2. https URI Scheme . . . . . . . . . . . . . . . . . . . 18
2.7.3. http and https URI Normalization and Comparison . . . 19
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23
3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. Field Value Components . . . . . . . . . . . . . . . . 26
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35
4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41
5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 42
5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42
5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44
5.6. Associating a Response to a Request . . . . . . . . . . . 46
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54
6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54
6.6. Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
8.1. Header Field Registration . . . . . . . . . . . . . . . . 60
8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
8.3. Internet Media Type Registration . . . . . . . . . . . . . 61
8.3.1. Internet Media Type message/http . . . . . . . . . . . 61
8.3.2. Internet Media Type application/http . . . . . . . . . 62
8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64
8.5. Content Coding Registration . . . . . . . . . . . . . . . 64
8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65
8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . . 66
9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66
9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67
9.3. Attacks via Protocol Element Length . . . . . . . . . . . 68
9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68
9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70
9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
11.2. Informative References . . . . . . . . . . . . . . . . . . 74
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76
A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 77
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Section 1., paragraph 8:
OLD:
This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
versioning). This specification also updates the use of CONNECT to
establish a tunnel, previously defined in RFC 2817, and defines the
"https" URI scheme that was described informally in RFC 2818.
NEW:
This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
HTTP versioning). This specification also updates the use of
CONNECT, previously defined in RFC 2817, to establish a tunnel, and
defines the "https" URI scheme that was described informally in RFC
2818.
Section 1., paragraph 13:
OLD:
1.1. Requirement Notation
NEW:
1.1. Requirements Notation
Section 2.1., paragraph 1:
OLD:
HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport or
session-layer "connection" (Section 6). An HTTP "client" is a
program that establishes a connection to a server for the purpose of
sending one or more HTTP requests. An HTTP "server" is a program
that accepts connections in order to service HTTP requests by sending
HTTP responses.
NEW:
HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport- or
session-layer "connection" (Section 6). An HTTP "client" is a
program that establishes a connection to a server for the purpose of
sending one or more HTTP requests. An HTTP "server" is a program
that accepts connections in order to service HTTP requests by sending
HTTP responses.
Section 2.1., paragraph 2:
OLD:
The terms client and server refer only to the roles that these
programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. The term
"user agent" refers to any of the various client programs that
initiate a request, including (but not limited to) browsers, spiders
(web-based robots), command-line tools, custom applications, and
mobile apps. The term "origin server" refers to the program that can
originate authoritative responses for a given target resource. The
terms "sender" and "recipient" refer to any implementation that sends
or receives a given message, respectively.
NEW:
The terms "client" and "server" refer only to the roles that these
programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. The term
"user agent" refers to any of the various client programs that
initiate a request, including (but not limited to) browsers, spiders
(web-based robots), command-line tools, custom applications, and
mobile apps. The term "origin server" refers to the program that can
originate authoritative responses for a given target resource. The
terms "sender" and "recipient" refer to any implementation that sends
or receives a given message, respectively.
Section 2.2., paragraph 1:
OLD:
When considering the design of HTTP, it is easy to fall into a trap
of thinking that all user agents are general-purpose browsers and all
origin servers are large public websites. That is not the case in
practice. Common HTTP user agents include household appliances,
stereos, scales, firmware update scripts, command-line programs,
mobile apps, and communication devices in a multitude of shapes and
sizes. Likewise, common HTTP origin servers include home automation
units, configurable networking components, office machines,
autonomous robots, news feeds, traffic cameras, ad selectors, and
video delivery platforms.
NEW:
When considering the design of HTTP, it is easy to fall into a trap
of thinking that all user agents are general-purpose browsers and all
origin servers are large public websites. That is not the case in
practice. Common HTTP user agents include household appliances,
stereos, scales, firmware update scripts, command-line programs,
mobile apps, and communication devices in a multitude of shapes and
sizes. Likewise, common HTTP origin servers include home automation
units, configurable networking components, office machines,
autonomous robots, news feeds, traffic cameras, ad selectors, and
video-delivery platforms.
Section 2.3., paragraph 3:
OLD:
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the end-points of the
chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's
request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load
balancing.
NEW:
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the endpoints of the
chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's
request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load
balancing.
Section 2.3., paragraph 4:
OLD:
The terms "upstream" and "downstream" are used to describe
directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms inbound and
outbound are used to describe directional requirements in relation to
the request route: "inbound" means toward the origin server and
"outbound" means toward the user agent.
NEW:
The terms "upstream" and "downstream" are used to describe
directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms "inbound" and
"outbound" are used to describe directional requirements in relation
to the request route: "inbound" means toward the origin server and
"outbound" means toward the user agent.
Section 2.3., paragraph 5:
OLD:
A "proxy" is a message forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in
Section 5.7.2.
NEW:
A "proxy" is a message-forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in
Section 5.7.2.
Section 2.3., paragraph 6:
OLD:
A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection, but translates received
requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines.
NEW:
A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines.
Section 2.3., paragraph 7:
OLD:
All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers ought to conform to user agent requirements
on the gateway's inbound connection.
NEW:
All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers ought to conform to user-agent requirements
on the gateway's inbound connection.
Section 2.3., paragraph 11:
OLD:
HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or
dynamically load-balance requests across multiple servers. Hence, a
server MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems.
NEW:
HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or
dynamically load balance requests across multiple servers. Hence, a
server MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems.
Section 2.4., paragraph 5:
OLD:
There are a wide variety of architectures and configurations of
caches deployed across the World Wide Web and inside large
organizations. These include national hierarchies of proxy caches to
save transoceanic bandwidth, collaborative systems that broadcast or
multicast cache entries, archives of pre-fetched cache entries for
use in off-line or high-latency environments, and so on.
NEW:
There is a wide variety of architectures and configurations of caches
deployed across the World Wide Web and inside large organizations.
These include national hierarchies of proxy caches to save
transoceanic bandwidth, collaborative systems that broadcast or
multicast cache entries, archives of pre-fetched cache entries for
use in off-line or high-latency environments, and so on.
Section 2.5., paragraph 5:
OLD:
When a received protocol element is parsed, the recipient MUST be
able to parse any value of reasonable length that is applicable to
the recipient's role and matches the grammar defined by the
corresponding ABNF rules. Note, however, that some received protocol
elements might not be parsed. For example, an intermediary
forwarding a message might parse a header-field into generic field-
name and field-value components, but then forward the header field
without further parsing inside the field-value.
NEW:
When a received protocol element is parsed, the recipient MUST be
able to parse any value of reasonable length that is applicable to
the recipient's role and that matches the grammar defined by the
corresponding ABNF rules. Note, however, that some received protocol
elements might not be parsed. For example, an intermediary
forwarding a message might parse a header-field into generic field-
name and field-value components, but then forward the header field
without further parsing inside the field-value.
Section 2.5., paragraph 6:
OLD:
HTTP does not have specific length limitations for many of its
protocol elements because the lengths that might be appropriate will
vary widely, depending on the deployment context and purpose of the
implementation. Hence, interoperability between senders and
recipients depends on shared expectations regarding what is a
reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP
use, and is expected to continue changing in the future.
NEW:
HTTP does not have specific length limitations for many of its
protocol elements because the lengths that might be appropriate will
vary widely, depending on the deployment context and purpose of the
implementation. Hence, interoperability between senders and
recipients depends on shared expectations regarding what is a
reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP
use and is expected to continue changing in the future.
Section 2.6., paragraph 2:
OLD:
The version of an HTTP message is indicated by an HTTP-version field
in the first line of the message. HTTP-version is case-sensitive.
NEW:
The version of an HTTP message is indicated by an HTTP-version field
in the first line of the message. HTTP-version is case sensitive.
Section 2.6., paragraph 3:
OLD:
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
NEW:
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case sensitive
Section 2.6., paragraph 7:
OLD:
New header fields can be introduced without changing the protocol
version if their defined semantics allow them to be safely ignored by
recipients that do not recognize them. Header field extensibility is
discussed in Section 3.2.1.
NEW:
New header fields can be introduced without changing the protocol
version if their defined semantics allow them to be safely ignored by
recipients that do not recognize them. Header-field extensibility is
discussed in Section 3.2.1.
Section 2.6., paragraph 14:
OLD:
When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any
implementation of the same major version.
NEW:
When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards compatible to be safely processed by any
implementation of the same major version.
Section 2.7., paragraph 2:
OLD:
The definitions of "URI-reference", "absolute-URI", "relative-part",
"scheme", "authority", "port", "host", "path-abempty", "segment",
"query", and "fragment" are adopted from the URI generic syntax. An
"absolute-path" rule is defined for protocol elements that can
contain a non-empty path component. (This rule differs slightly from
RFC 3986's path-abempty rule, which allows for an empty path to be
used in references, and path-absolute rule, which does not allow
paths that begin with "//".) A "partial-URI" rule is defined for
protocol elements that can contain a relative URI but not a fragment
component.
NEW:
The definitions of "URI-reference", "absolute-URI", "relative-part",
"scheme", "authority", "port", "host", "path-abempty", "segment",
"query", and "fragment" are adopted from the URI generic syntax. An
"absolute-path" rule is defined for protocol elements that can
contain a non-empty path component. (This rule differs slightly from
the path-abempty rule of RFC 3986, which allows for an empty path to
be used in references, and path-absolute rule, which does not allow
paths that begin with "//".) A "partial-URI" rule is defined for
protocol elements that can contain a relative URI but not a fragment
component.
Section 2.7., paragraph 6:
OLD:
2.7.1. http URI scheme
NEW:
2.7.1. http URI Scheme
Section 2.7., paragraph 7:
OLD:
The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for
TCP ([RFC0793]) connections on a given port.
NEW:
The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for
TCP ([RFC793]) connections on a given port.
Section 2.7., paragraph 17:
OLD:
2.7.2. https URI scheme
NEW:
2.7.2. https URI Scheme
Section 2.1, paragraph 0:
OLD:
If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent-
encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]).
NEW:
If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host
are case insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent-
encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]).
Section 3.1., paragraph 1:
OLD:
An HTTP message can either be a request from client to server or a
response from server to client. Syntactically, the two types of
message differ only in the start-line, which is either a request-line
(for requests) or a status-line (for responses), and in the algorithm
for determining the length of the message body (Section 3.3).
NEW:
An HTTP message can be either a request from client to server or a
response from server to client. Syntactically, the two types of
message differ only in the start-line, which is either a request-line
(for requests) or a status-line (for responses), and in the algorithm
for determining the length of the message body (Section 3.3).
Section 3.1., paragraph 2:
OLD:
In theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats,
but in practice servers are implemented to only expect a request (a
response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response.
NEW:
In theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats,
but, in practice, servers are implemented only to expect a request (a
response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response.
Section 3.1.1., paragraph 1:
OLD:
A request-line begins with a method token, followed by a single space
(SP), the request-target, another single space (SP), the protocol
version, and ending with CRLF.
NEW:
A request-line begins with a method token and is followed by a single
space (SP), the request-target, another single space (SP), the
protocol version, and ends with CRLF.
Section 3.1.1., paragraph 3:
OLD:
The method token indicates the request method to be performed on the
target resource. The request method is case-sensitive.
NEW:
The method token indicates the request method to be performed on the
target resource. The request method is case sensitive.
Section 400, paragraph 1:
OLD:
HTTP does not place a pre-defined limit on the length of a request-
line, as described in Section 2.5. A server that receives a method
longer than any that it implements SHOULD respond with a 501 (Not
Implemented) status code. A server that receives a request-target
longer than any URI it wishes to parse MUST respond with a 414 (URI
Too Long) status code (see Section 6.5.12 of [RFC7231]).
NEW:
HTTP does not place a predefined limit on the length of a request-
line, as described in Section 2.5. A server that receives a method
longer than any that it implements SHOULD respond with a 501 (Not
Implemented) status code. A server that receives a request-target
longer than any URI it wishes to parse MUST respond with a 414 (URI
Too Long) status code (see Section 6.5.12 of [RFC7231]).
Section 400, paragraph 2:
OLD:
Various ad-hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets.
NEW:
Various ad hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets.
Section 3.1.2., paragraph 1:
OLD:
The first line of a response message is the status-line, consisting
of the protocol version, a space (SP), the status code, another
space, a possibly-empty textual phrase describing the status code,
and ending with CRLF.
NEW:
The first line of a response message is the status-line, consisting
of the protocol version, a space (SP), the status code, another space
(SP), a possibly empty textual phrase describing the status code,
and, finally, CRLF.
Section 3.2.1., paragraph 4:
OLD:
All defined header fields ought to be registered with IANA in the
Message Header Field Registry, as described in Section 8.3 of
[RFC7231].
NEW:
All defined header fields ought to be registered with IANA in the
"Message Headers" field registry, as described in Section 8.3 of
[RFC7231].
Section 3.2.2., paragraph 4:
OLD:
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a
special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.)
NEW:
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle Set-Cookie as a
special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.)
Section 3.2.3., paragraph 2:
OLD:
The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white-out invalid or
unwanted protocol elements during in-place message filtering.
NEW:
The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering.
Section 3.2.4., paragraph 1:
OLD:
Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field
value are not parsed until a later stage of message interpretation
(usually after the message's entire header section has been
processed). Consequently, this specification does not use ABNF rules
to define each "Field-Name: Field Value" pair, as was done in
previous editions. Instead, this specification uses ABNF rules which
are named according to each registered field name, wherein the rule
defines the valid grammar for that field's corresponding field values
(i.e., after the field-value has been extracted from the header
section by a generic field parser).
NEW:
Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field
value are not parsed until a later stage of message interpretation
(usually after the message's entire header section has been
processed). Consequently, this specification does not use ABNF rules
to define each "field-name: field-value" pair, as was done in
previous editions. Instead, this specification uses ABNF rules that
are named according to each registered field name, wherein the rule
defines the valid grammar for that field's corresponding field values
(i.e., after the field-value has been extracted from the header
section by a generic field parser).
Section 3.2.4., paragraph 8:
OLD:
Historically, HTTP has allowed field content with text in the ISO-
8859-1 [ISO-8859-1] charset, supporting other charsets only through
use of [RFC2047] encoding. In practice, most HTTP header field
values use only a subset of the US-ASCII charset [USASCII]. Newly
defined header fields SHOULD limit their field values to US-ASCII
octets. A recipient SHOULD treat other octets in field content (obs-
text) as opaque data.
NEW:
Historically, HTTP has allowed field content with text in the
ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data.
Section 3.2.5., paragraph 1:
OLD:
HTTP does not place a pre-defined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad-hoc limitations on individual header
field length are found in practice, often depending on the specific
field semantics.
NEW:
HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header
field length are found in practice, often depending on the specific
field semantics.
Section 3.2.5., paragraph 4:
OLD:
3.2.6. Field value components
NEW:
3.2.6. Field Value Components
Section 7., paragraph 1:
OLD:
Since there is no way to distinguish a successfully completed, close-
delimited message from a partially-received message interrupted by
network failure, a server SHOULD generate encoding or length-
delimited messages whenever possible. The close-delimiting feature
exists primarily for backwards compatibility with HTTP/1.0.
NEW:
Since there is no way to distinguish a successfully completed, close-
delimited message from a partially received message interrupted by
network failure, a server SHOULD generate encoding or length-
delimited messages whenever possible. The close-delimiting feature
exists primarily for backwards compatibility with HTTP/1.0.
Section 3.4., paragraph 1:
OLD:
A server that receives an incomplete request message, usually due to
a canceled request or a triggered time-out exception, MAY send an
error response prior to closing the connection.
NEW:
A server that receives an incomplete request message, usually due to
a canceled request or a triggered timeout exception, MAY send an
error response prior to closing the connection.
Section 3.4., paragraph 4:
OLD:
A message body that uses the chunked transfer coding is incomplete if
the zero-sized chunk that terminates the encoding has not been
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
value given by Content-Length. A response that has neither chunked
transfer coding nor Content-Length is terminated by closure of the
connection, and thus is considered complete regardless of the number
of message body octets received, provided that the header section was
received intact.
NEW:
A message body that uses the chunked transfer coding is incomplete if
the zero-sized chunk that terminates the encoding has not been
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
value given by Content-Length. A response that has neither chunked
transfer coding nor Content-Length is terminated by closure of the
connection and, thus, is considered complete regardless of the number
of message body octets received, provided that the header section was
received intact.
Section 4., paragraph 5:
OLD:
All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in
Section 8.4. They are used in the TE (Section 4.3) and Transfer-
Encoding (Section 3.3.1) header fields.
NEW:
All transfer-coding names are case insensitive and ought to be
registered within the "HTTP Transfer Coding" registry, as defined in
Section 8.4. They are used in the TE (Section 4.3) and Transfer-
Encoding (Section 3.3.1) header fields.
Section 4.2.3., paragraph 1:
OLD:
The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
commonly produced by the gzip file compression program [RFC1952]. A
recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
NEW:
The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
Check (CRC) that is commonly produced by the gzip file compression
program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
equivalent to "gzip".
Section 5.7.1., paragraph 8:
OLD:
A sender MAY generate comments in the Via header field to identify
the software of each recipient, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are
optional and a recipient MAY remove them prior to forwarding the
message.
NEW:
A sender MAY generate comments in the Via header field to identify
the software of each recipient, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are
optional, and a recipient MAY remove them prior to forwarding the
message.
Section 5.7.2., paragraph 6:
OLD:
A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
a message that contains a no-transform cache-control directive
(Section 5.2 of [RFC7234]).
NEW:
A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
a message that contains a no-transform Cache-Control directive
(Section 5.2 of [RFC7234]).
Section 200, paragraph 0:
OLD:
A proxy MAY transform the payload of a message that does not contain
a no-transform cache-control directive. A proxy that transforms a
payload MUST add a Warning header field with the warn-code of 214
("Transformation Applied") if one is not already in the message (see
Section 5.5 of [RFC7234]). A proxy that transforms the payload of a
200 (OK) response can further inform downstream recipients that a
transformation has been applied by changing the response status code
to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
NEW:
A proxy MAY transform the payload of a message that does not contain
a no-transform Cache-Control directive. A proxy that transforms a
payload MUST add a Warning header field with the warn-code of 214
("Transformation Applied") if one is not already in the message (see
Section 5.5 of [RFC7234]). A proxy that transforms the payload of a
200 (OK) response can further inform downstream recipients that a
transformation has been applied by changing the response status code
to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
Section 6., paragraph 1:
OLD:
HTTP messaging is independent of the underlying transport or session-
layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport
protocol is outside the scope of this specification.
NEW:
HTTP messaging is independent of the underlying transport- or
session-layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport
protocol is outside the scope of this specification.
Section 6., paragraph 3:
OLD:
HTTP implementations are expected to engage in connection management,
which includes maintaining the state of current connections,
establishing a new connection or reusing an existing connection,
processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable
fair use and detect denial of service attacks.
NEW:
HTTP implementations are expected to engage in connection management,
which includes maintaining the state of current connections,
establishing a new connection or reusing an existing connection,
processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable
fair use and detect denial-of-service attacks.
Section 6.1., paragraph 6:
OLD:
Connection options are case-insensitive.
NEW:
Connection options are case insensitive.
Section 6.2., paragraph 1:
OLD:
It is beyond the scope of this specification to describe how
connections are established via various transport or session-layer
protocols. Each connection applies to only one transport link.
NEW:
It is beyond the scope of this specification to describe how
connections are established via various transport- or session-layer
protocols. Each connection applies to only one transport link.
Section 6.3., paragraph 1:
OLD:
HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single
connection. The "close" connection-option is used to signal that a
connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections.
NEW:
HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single
connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections.
Section 6.3., paragraph 3:
OLD:
o If the close connection option is present, the connection will not
persist after the current response; else,
NEW:
o If the "close" connection option is present, the connection will
not persist after the current response; else,
Section 6.3., paragraph 7:
OLD:
A client MAY send additional requests on a persistent connection
until it sends or receives a close connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option.
NEW:
A client MAY send additional requests on a persistent connection
until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option.
Section 6.3., paragraph 10:
OLD:
See Appendix A.1.2 for more information on backward compatibility
with HTTP/1.0 clients.
NEW:
See Appendix A.1.2 for more information on backwards compatibility
with HTTP/1.0 clients.
Section 6.3.2., paragraph 1:
OLD:
A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
but MUST send the corresponding responses in the same order that the
requests were received.
NEW:
A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
but it MUST send the corresponding responses in the same order that
the requests were received.
Section 6.4., paragraph 2:
OLD:
Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications.
As a result, this specification does not mandate a particular maximum
number of connections, but instead encourages clients to be
conservative when opening multiple connections.
NEW:
Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications.
As a result, this specification does not mandate a particular maximum
number of connections but, instead, encourages clients to be
conservative when opening multiple connections.
Section 6.4., paragraph 4:
OLD:
Note that a server might reject traffic that it deems abusive or
characteristic of a denial of service attack, such as an excessive
number of open connections from a single client.
NEW:
Note that a server might reject traffic that it deems abusive or
characteristic of a denial-of-service attack, such as an excessive
number of open connections from a single client.
Section 6.4., paragraph 5:
OLD:
6.5. Failures and Time-outs
NEW:
6.5. Failures and Timeouts
Section 6.4., paragraph 6:
OLD:
Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making
more connections through the same proxy server. The use of
persistent connections places no requirements on the length (or
existence) of this time-out for either the client or the server.
NEW:
Servers will usually have some timeout value beyond which they will
no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making
more connections through the same proxy server. The use of
persistent connections places no requirements on the length (or
existence) of this timeout for either the client or the server.
Section 6.4., paragraph 7:
OLD:
A client or server that wishes to time-out SHOULD issue a graceful
close on the connection. Implementations SHOULD constantly monitor
open connections for a received closure signal and respond to it as
appropriate, since prompt closure of both sides of a connection
enables allocated system resources to be reclaimed.
NEW:
A client or server that wishes to time out SHOULD issue a graceful
close on the connection. Implementations SHOULD constantly monitor
open connections for a received closure signal and respond to it as
appropriate, since prompt closure of both sides of a connection
enables allocated system resources to be reclaimed.
Section 6.4., paragraph 9:
OLD:
A server SHOULD sustain persistent connections, when possible, and
allow the underlying transport's flow control mechanisms to resolve
temporary overloads, rather than terminate connections with the
expectation that clients will retry. The latter technique can
exacerbate network congestion.
NEW:
A server SHOULD sustain persistent connections, when possible, and
allow the underlying transport's flow-control mechanisms to resolve
temporary overloads, rather than terminate connections with the
expectation that clients will retry. The latter technique can
exacerbate network congestion.
Section 6.4., paragraph 11:
OLD:
6.6. Tear-down
NEW:
6.6. Teardown
Section 6.4., paragraph 13:
OLD:
A client that sends a close connection option MUST NOT send further
requests on that connection (after the one containing close) and MUST
close the connection after reading the final response message
corresponding to this request.
NEW:
A client that sends a "close" connection option MUST NOT send further
requests on that connection (after the one containing close) and MUST
close the connection after reading the final response message
corresponding to this request.
Section 6.4., paragraph 14:
OLD:
A server that receives a close connection option MUST initiate a
close of the connection (see below) after it sends the final response
to the request that contained close. The server SHOULD send a close
connection option in its final response on that connection. The
server MUST NOT process any further requests received on that
connection.
NEW:
A server that receives a "close" connection option MUST initiate a
close of the connection (see below) after it sends the final response
to the request that contained close. The server SHOULD send a close
connection option in its final response on that connection. The
server MUST NOT process any further requests received on that
connection.
Section 6.4., paragraph 15:
OLD:
A server that sends a close connection option MUST initiate a close
of the connection (see below) after it sends the response containing
close. The server MUST NOT process any further requests received on
that connection.
NEW:
A server that sends a "close" connection option MUST initiate a close
of the connection (see below) after it sends the response containing
close. The server MUST NOT process any further requests received on
that connection.
Section 6.4., paragraph 16:
OLD:
A client that receives a close connection option MUST cease sending
requests on that connection and close the connection after reading
the response message containing the close; if additional pipelined
requests had been sent on the connection, the client SHOULD NOT
assume that they will be processed by the server.
NEW:
A client that receives a "close" connection option MUST cease sending
requests on that connection and close the connection after reading
the response message containing the close; if additional pipelined
requests had been sent on the connection, the client SHOULD NOT
assume that they will be processed by the server.
Section 6.4., paragraph 17:
OLD:
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
HTTP response. If the server receives additional data from the
client on a fully-closed connection, such as another request that was
sent by the client before receiving the server's response, the
server's TCP stack will send a reset packet to the client;
unfortunately, the reset packet might erase the client's
unacknowledged input buffers before they can be read and interpreted
by the client's HTTP parser.
NEW:
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
HTTP response. If the server receives additional data from the
client on a fully closed connection, such as another request that was
sent by the client before receiving the server's response, the
server's TCP stack will send a reset packet to the client;
unfortunately, the reset packet might erase the client's
unacknowledged input buffers before they can be read and interpreted
by the client's HTTP parser.
Section 6.7., paragraph 9:
OLD:
The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101
response, the server is expected to continue responding to the
original request as if it had received its equivalent within the new
protocol (i.e., the server still has an outstanding request to
satisfy after the protocol has been changed, and is expected to do so
without requiring the request to be repeated).
NEW:
The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101
(Switching Protocols) response, the server is expected to continue
responding to the original request as if it had received its
equivalent within the new protocol (i.e., the server still has an
outstanding request to satisfy after the protocol has been changed,
and is expected to do so without requiring the request to be
repeated).
Section 101, paragraph 0:
OLD:
For example, if the Upgrade header field is received in a GET request
and the server decides to switch protocols, it first responds with a
101 (Switching Protocols) message in HTTP/1.1 and then immediately
follows that with the new protocol's equivalent of a response to a
GET on the target resource. This allows a connection to be upgraded
to protocols with the same semantics as HTTP without the latency cost
of an additional round-trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol.
NEW:
For example, if the Upgrade header field is received in a GET request
and the server decides to switch protocols, it first responds with a
101 (Switching Protocols) message in HTTP/1.1 and then immediately
follows that with the new protocol's equivalent of a response to a
GET on the target resource. This allows a connection to be upgraded
to protocols with the same semantics as HTTP without the latency cost
of an additional round trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol.
Section 101, paragraph 5:
OLD:
A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client
can't change the protocol it is sending in the middle of a message).
If a server receives both Upgrade and an Expect header field with the
"100-continue" expectation (Section 5.1.1 of [RFC7231]), the server
MUST send a 100 (Continue) response before sending a 101 (Switching
Protocols) response.
NEW:
A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client
can't change the protocol it is sending in the middle of a message).
If a server receives both an Upgrade and an Expect header field with
the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
server MUST send a 100 (Continue) response before sending a 101
(Switching Protocols) response.
Section 101, paragraph 8:
OLD:
7. ABNF list extension: #rule
NEW:
7. ABNF List Extension: #rule
Section 101, paragraph 17:
OLD:
For compatibility with legacy list rules, a recipient MUST parse and
ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that
they could be used as a denial of service mechanism. In other words,
a recipient MUST accept lists that satisfy the following syntax:
NEW:
For compatibility with legacy list rules, a recipient MUST parse and
ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that
they could be used as a denial-of-service mechanism. In other words,
a recipient MUST accept lists that satisfy the following syntax:
Section 101, paragraph 22:
OLD:
Then the following are valid values for example-list (not including
the double quotes, which are present for delimitation only):
NEW:
Then, the following are valid values for example-list (not including
the double quotes, which are present for delimitation only):
Section 8.1., paragraph 1:
OLD:
HTTP header fields are registered within the Message Header Field
Registry maintained at
.
NEW:
HTTP header fields are registered within the "Message Header" field
registry maintained at
.
Section 8.1., paragraph 2:
OLD:
This document defines the following HTTP header fields, so their
associated registry entries shall be updated according to the
permanent registrations below (see [BCP90]):
NEW:
This document defines the following HTTP header fields, so the
"Permanent Message Header Field Names" registry has been updated
accordingly (see [BCP90]).
Section 8.1., paragraph 4:
OLD:
Furthermore, the header field-name "Close" shall be registered as
"reserved", since using that name as an HTTP header field might
conflict with the "close" connection option of the "Connection"
header field (Section 6.1).
NEW:
Furthermore, the header field-name "Close" has been registered as
"reserved", since using that name as an HTTP header field might
conflict with the "close" connection option of the "Connection"
header field (Section 6.1).
Section 8.2., paragraph 2:
OLD:
This document defines the following URI schemes, so their associated
registry entries shall be updated according to the permanent
registrations below:
NEW:
This document defines the following URI schemes, so the "Permanent
URI Schemes" registry has been updated accordingly.
Section 8.3., paragraph 2:
OLD:
This document serves as the specification for the Internet media
types "message/http" and "application/http". The following is to be
registered with IANA.
NEW:
This document serves as the specification for the Internet media
types "message/http" and "application/http". The following has been
registered with IANA.
Section 8.3.1., paragraph 18:
OLD:
Person and email address to contact for further information: See
Authors Section.
NEW:
Person and email address to contact for further information:
See Authors' Addresses Section.
Section 8.3.1., paragraph 21:
OLD:
Author: See Authors Section.
NEW:
Author: See Authors' Addresses Section.
Section 8.3.2., paragraph 8:
OLD:
Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via E-mail.
NEW:
Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via email.
Section 8.3.2., paragraph 19:
OLD:
Person and email address to contact for further information: See
Authors Section.
NEW:
Person and email address to contact for further information:
See Authors' Addresses Section.
Section 8.3.2., paragraph 22:
OLD:
Author: See Authors Section.
NEW:
Author: See Authors' Addresses Section.
Section 8.4., paragraph 1:
OLD:
The HTTP Transfer Coding Registry defines the name space for transfer
coding names. It is maintained at
.
NEW:
The "HTTP Transfer Coding" registry defines the namespace for
transfer coding names. It is maintained at
.
Section 8.4.1., paragraph 5:
OLD:
Values to be added to this name space require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of
transfer coding defined in this specification.
NEW:
Values to be added to this namespace require IETF Review (see Section
4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
defined in this specification.
Section 8.4.2., paragraph 1:
OLD:
The HTTP Transfer Coding Registry shall be updated with the
registrations below:
NEW:
The "HTTP Transfer Coding Registry" has been updated with the
registrations below:
Section 8.5., paragraph 1:
OLD:
IANA maintains the registry of HTTP Content Codings at
.
NEW:
IANA maintains the "HTTP Content Coding Registry" at
.
Section 8.5., paragraph 2:
OLD:
The HTTP Content Codings Registry shall be updated with the
registrations below:
NEW:
The "HTTP Content Codings Registry" has been updated with the
registrations below:
Section 8.6., paragraph 1:
OLD:
The HTTP Upgrade Token Registry defines the name space for protocol-
name tokens used to identify protocols in the Upgrade header field.
The registry is maintained at
.
NEW:
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at
.
Section 8.6.2., paragraph 1:
OLD:
The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
with the registration below:
NEW:
The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
updated with the registration below:
Section 9.1., paragraph 3:
OLD:
When a registered name is used in the authority component, the "http"
URI scheme (Section 2.7.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address
mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.
NEW:
When a registered name is used in the authority component, the "http"
URI scheme (Section 2.7.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address
mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
improve authenticity.
Section 9.2., paragraph 1:
OLD:
By their very nature, HTTP intermediaries are men-in-the-middle, and
thus represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about
individual users and organizations, and proprietary information
belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks.
NEW:
By their very nature, HTTP intermediaries are men in the middle and,
thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about
individual users and organizations, and proprietary information
belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks.
Section 9.3., paragraph 4:
OLD:
Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values,
and body chunks. Failure to limit such processing can result in
buffer overflows, arithmetic overflows, or increased vulnerability to
denial of service attacks.
NEW:
Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values,
and body chunks. Failure to limit such processing can result in
buffer overflows, arithmetic overflows, or increased vulnerability to
denial-of-service attacks.
Section 9.6., paragraph 2:
OLD:
User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those
means can be enabled within environments for which integrity is
necessary. For example, a browser being used to view medical history
or drug interaction information needs to indicate to the user when
such information is detected by the protocol to be incomplete,
expired, or corrupted during transfer. Such mechanisms might be
selectively enabled via user agent extensions or the presence of
message integrity metadata in a response. At a minimum, user agents
ought to provide some indication that allows a user to distinguish
between a complete and incomplete response message (Section 3.4) when
such verification is desired.
NEW:
User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those
means can be enabled within environments for which integrity is
necessary. For example, a browser being used to view medical history
or drug interaction information needs to indicate to the user when
such information is detected by the protocol to be incomplete,
expired, or corrupted during transfer. Such mechanisms might be
selectively enabled via user-agent extensions or the presence of
message integrity metadata in a response. At a minimum, user agents
ought to provide some indication that allows a user to distinguish
between a complete and incomplete response message (Section 3.4) when
such verification is desired.
Section 9.8., paragraph 2:
OLD:
HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis.
Anonymization of personal information within individual entries
helps, but is generally not sufficient to prevent real log traces
from being re-identified based on correlation with other access
characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous.
NEW:
HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis.
Anonymization of personal information within individual entries
helps, but it is generally not sufficient to prevent real log traces
from being re-identified based on correlation with other access
characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous.
Section 10., paragraph 1:
OLD:
This edition of HTTP/1.1 builds on the many contributions that went
into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
substantial contributions made by the previous authors, editors, and
working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
and Paul J. Leach. Mark Nottingham oversaw this effort as working
group chair.
NEW:
This edition of HTTP/1.1 builds on the many contributions that went
into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
substantial contributions made by the previous authors, editors, and
Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
and Paul J. Leach. Mark Nottingham oversaw this effort as Working
Group Chair.
Section 11.1., paragraph 1:
OLD:
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.
NEW:
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.
Section 11.1., paragraph 7:
OLD:
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-latest (work in
progress), May 2014.
NEW:
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
RFC 7231, May 2014.
Section 11.1., paragraph 8:
OLD:
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-latest (work in
progress), May 2014.
NEW:
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests",
RFC 7232, May 2014.
Section 11.1., paragraph 9:
OLD:
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-latest (work in
progress), May 2014.
NEW:
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", RFC 7233, May 2014.
Section 11.1., paragraph 10:
OLD:
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress),
May 2014.
NEW:
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, May 2014.
Section 11.1., paragraph 11:
OLD:
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-latest (work in progress),
May 2014.
NEW:
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication",
RFC 7235, May 2014.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
Section 11.1., paragraph 13:
OLD:
[Welch] Welch, T., "A Technique for High Performance Data
Compression", IEEE Computer 17(6), June 1984.
NEW:
[Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984.
Appendix A., paragraph 1:
OLD:
HTTP has been in use since 1990. The first version, later referred
to as HTTP/0.9, was a simple protocol for hypertext data transfer
across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics.
However, HTTP/1.0 did not sufficiently take into consideration the
effects of hierarchical proxies, caching, the need for persistent
connections, or name-based virtual hosts. The proliferation of
incompletely-implemented applications calling themselves "HTTP/1.0"
further necessitated a protocol version change in order for two
communicating applications to determine each other's true
capabilities.
NEW:
HTTP has been in use since 1990. The first version, later referred
to as HTTP/0.9, was a simple protocol for hypertext data transfer
across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics.
However, HTTP/1.0 did not sufficiently take into consideration the
effects of hierarchical proxies, caching, the need for persistent
connections, or name-based virtual hosts. The proliferation of
incompletely implemented applications calling themselves "HTTP/1.0"
further necessitated a protocol version change in order for two
communicating applications to determine each other's true
capabilities.
Appendix A., paragraph 2:
OLD:
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those
features that can either be safely ignored by an HTTP/1.0 recipient
or only sent when communicating with a party advertising conformance
with HTTP/1.1.
NEW:
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those
features that can either be safely ignored by an HTTP/1.0 recipient
or only be sent when communicating with a party advertising
conformance with HTTP/1.1.
Appendix A., paragraph 7:
OLD:
A.1.1. Multi-homed Web Servers
NEW:
A.1.1. Multihomed Web Servers
Section 19.7.1, paragraph 8:
OLD:
HTTP's approach to error handling has been explained. (Section 2.5)
NEW:
HTTP's approach to error handling has been explained (Section 2.5).
Section 19.7.1, paragraph 9:
OLD:
The HTTP-version ABNF production has been clarified to be case-
sensitive. Additionally, version numbers has been restricted to
single digits, due to the fact that implementations are known to
handle multi-digit version numbers incorrectly. (Section 2.6)
NEW:
The HTTP-version ABNF production has been clarified to be case
sensitive. Additionally, version numbers have been restricted to
single digits, due to the fact that implementations are known to
handle multi-digit version numbers incorrectly (Section 2.6).
Section 19.7.1, paragraph 10:
OLD:
Userinfo (i.e., username and password) are now disallowed in HTTP and
HTTPS URIs, because of security issues related to their transmission
on the wire. (Section 2.7.1)
NEW:
Userinfo (i.e., username and password) are now disallowed in HTTP and
HTTPS URIs, because of security issues related to their transmission
on the wire (Section 2.7.1).
Section 19.7.1, paragraph 11:
OLD:
The HTTPS URI scheme is now defined by this specification;
previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it
implies end-to-end security. (Section 2.7.2)
NEW:
The HTTPS URI scheme is now defined by this specification;
previously, it was defined in Section 2.4 of [RFC2818]. Furthermore,
it implies end-to-end security (Section 2.7.2).
Section 19.7.1, paragraph 12:
OLD:
HTTP messages can be (and often are) buffered by implementations;
despite it sometimes being available as a stream, HTTP is
fundamentally a message-oriented protocol. Minimum supported sizes
for various protocol elements have been suggested, to improve
interoperability. (Section 3)
NEW:
HTTP messages can be (and often are) buffered by implementations;
despite it sometimes being available as a stream, HTTP is
fundamentally a message-oriented protocol. Minimum supported sizes
for various protocol elements have been suggested, to improve
interoperability (Section 3).
Section 19.7.1, paragraph 13:
OLD:
Invalid whitespace around field-names is now required to be rejected,
because accepting it represents a security vulnerability. The ABNF
productions defining header fields now only list the field value.
(Section 3.2)
NEW:
Invalid whitespace around field-names is now required to be rejected,
because accepting it represents a security vulnerability. The ABNF
productions defining header fields now only list the field value
(Section 3.2).
Section 19.7.1, paragraph 14:
OLD:
Rules about implicit linear whitespace between certain grammar
productions have been removed; now whitespace is only allowed where
specifically defined in the ABNF. (Section 3.2.3)
NEW:
Rules about implicit linear whitespace between certain grammar
productions have been removed; now whitespace is only allowed where
specifically defined in the ABNF (Section 3.2.3).
Section 19.7.1, paragraph 15:
OLD:
Header fields that span multiple lines ("line folding") are
deprecated. (Section 3.2.4)
The NUL octet is no longer allowed in comment and quoted-string text,
and handling of backslash-escaping in them has been clarified. The
quoted-pair rule no longer allows escaping control characters other
than HTAB. Non-ASCII content in header fields and the reason phrase
has been obsoleted and made opaque (the TEXT rule was removed).
(Section 3.2.6)
NEW:
Header fields that span multiple lines ("line folding") are
deprecated (Section 3.2.4).
The NUL octet is no longer allowed in comment and quoted-string text,
and handling of backslash-escaping in them has been clarified. The
quoted-pair rule no longer allows escaping control characters other
than HTAB. Non-US-ASCII content in header fields and the reason
phrase has been obsoleted and made opaque (the TEXT rule was removed)
(Section 3.2.6).
Section 19.7.1, paragraph 16:
OLD:
Bogus "Content-Length" header fields are now required to be handled
as errors by recipients. (Section 3.3.2)
NEW:
Bogus "Content-Length" header fields are now required to be handled
as errors by recipients (Section 3.3.2).
Section 19.7.1, paragraph 17:
OLD:
The algorithm for determining the message body length has been
clarified to indicate all of the special cases (e.g., driven by
methods or status codes) that affect it, and that new protocol
elements cannot define such special cases. CONNECT is a new, special
case in determining message body length. "multipart/byteranges" is no
longer a way of determining message body length detection.
(Section 3.3.3)
NEW:
The algorithm for determining the message body length has been
clarified to indicate all of the special cases (e.g., driven by
methods or status codes) that affect it, and that new protocol
elements cannot define such special cases. CONNECT is a new, special
case in determining message body length. "multipart/byteranges" is no
longer a way of determining message body length detection
(Section 3.3.3).
Section 19.7.1, paragraph 18:
OLD:
The "identity" transfer coding token has been removed. (Sections 3.3
and 4)
NEW:
The "identity" transfer coding token has been removed (Sections 3.3
and 4).
Section 19.7.1, paragraph 19:
OLD:
Chunk length does not include the count of the octets in the chunk
header and trailer. Line folding in chunk extensions is disallowed.
(Section 4.1)
NEW:
Chunk length does not include the count of the octets in the chunk
header and trailer. Line folding in chunk extensions is disallowed
(Section 4.1).
Section 19.7.1, paragraph 20:
OLD:
The meaning of the "deflate" content coding has been clarified.
(Section 4.2.2)
NEW:
The meaning of the "deflate" content coding has been clarified
(Section 4.2.2).
Section 19.7.1, paragraph 21:
OLD:
The segment + query components of RFC 3986 have been used to define
the request-target, instead of abs_path from RFC 1808. The asterisk-
form of the request-target is only allowed with the OPTIONS method.
(Section 5.3)
NEW:
The segment + query components of RFC 3986 have been used to define
the request-target, instead of abs_path from RFC 1808. The asterisk-
form of the request-target is only allowed with the OPTIONS method
(Section 5.3).
Section 19.7.1, paragraph 22:
OLD:
The term "Effective Request URI" has been introduced. (Section 5.5)
NEW:
The term "Effective Request URI" has been introduced (Section 5.5).
Section 19.7.1, paragraph 23:
OLD:
Gateways do not need to generate Via header fields anymore.
(Section 5.7.1)
NEW:
Gateways do not need to generate Via header fields anymore
(Section 5.7.1).
Section 19.7.1, paragraph 24:
OLD:
Exactly when "close" connection options have to be sent has been
clarified. Also, "hop-by-hop" header fields are required to appear
in the Connection header field; just because they're defined as hop-
by-hop in this specification doesn't exempt them. (Section 6.1)
NEW:
Exactly when "close" connection options have to be sent has been
clarified. Also, "hop-by-hop" header fields are required to appear
in the Connection header field; just because they're defined as hop-
by-hop in this specification doesn't exempt them (Section 6.1).
Section 19.7.1, paragraph 25:
OLD:
The limit of two connections per server has been removed. An
idempotent sequence of requests is no longer required to be retried.
The requirement to retry requests under certain circumstances when
the server prematurely closes the connection has been removed. Also,
some extraneous requirements about when servers are allowed to close
connections prematurely have been removed. (Section 6.3)
NEW:
The limit of two connections per server has been removed. An
idempotent sequence of requests is no longer required to be retried.
The requirement to retry requests under certain circumstances when
the server prematurely closes the connection has been removed. Also,
some extraneous requirements about when servers are allowed to close
connections prematurely have been removed (Section 6.3).
Section 19.7.1, paragraph 26:
OLD:
The semantics of the Upgrade header field is now defined in responses
other than 101 (this was incorporated from [RFC2817]). Furthermore,
the ordering in the field value is now significant. (Section 6.7)
NEW:
The semantics of the Upgrade header field is now defined in responses
other than 101 (this was incorporated from [RFC2817]). Furthermore,
the ordering in the field value is now significant (Section 6.7).
Section 19.7.1, paragraph 27:
OLD:
Empty list elements in list productions (e.g., a list header field
containing ", ,") have been deprecated. (Section 7)
NEW:
Empty list elements in list productions (e.g., a list header field
containing ", ,") have been deprecated (Section 7).
Section 19.7.1, paragraph 28:
OLD:
Registration of Transfer Codings now requires IETF Review
(Section 8.4)
NEW:
Registration of Transfer Codings now requires IETF Review
(Section 8.4).
Section 19.7.1, paragraph 29:
OLD:
This specification now defines the Upgrade Token Registry, previously
defined in Section 7.2 of [RFC2817]. (Section 8.6)
NEW:
This specification now defines the "HTTP Upgrade Tokens" registry,
previously defined in Section 7.2 of [RFC2817] (Section 8.6).
Section 19.7.1, paragraph 30:
OLD:
The expectation to support HTTP/0.9 requests has been removed.
(Appendix A)
NEW:
The expectation to support HTTP/0.9 requests has been removed
(Appendix A).
Section 19.7.1, paragraph 31:
OLD:
Issues with the Keep-Alive and Proxy-Connection header fields in
requests are pointed out, with use of the latter being discouraged
altogether. (Appendix A.1.2)
NEW:
Issues with the Keep-Alive and Proxy-Connection header fields in
requests are pointed out, with use of the latter being discouraged
altogether (Appendix A.1.2).
Appendix B., paragraph 7:
OLD:
URI-reference =
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
comment ] ) ] )
NEW:
URI-reference =
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
comment ] ) ] )
Appendix B., paragraph 15:
OLD:
partial-URI = relative-part [ "?" query ]
path-abempty =
port =
protocol = protocol-name [ "/" protocol-version ]
protocol-name = token
protocol-version = token
pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
query =
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
NEW:
partial-URI = relative-part [ "?" query ]
path-abempty =
port =
protocol = protocol-name [ "/" protocol-version ]
protocol-name = token
protocol-version = token
pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
query =
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
Appendix B., paragraph 20:
OLD:
Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since RFC 2616
Changes up to the IETF Last Call draft are summarized in .
C.2. Since draft-ietf-httpbis-p1-messaging-24
Closed issues:
o : "APPSDIR
review of draft-ietf-httpbis-p1-messaging-24"
o : "integer value
parsing"
o : "move IANA
registrations to correct draft"
C.3. Since draft-ietf-httpbis-p1-messaging-25
Closed issues:
o : "check media
type registration templates"
o : "Redundant
rule quoted-str-nf"
o : "IESG ballot
on draft-ietf-httpbis-p1-messaging-25"
o : "add
'stateless' to Abstract"
o : "clarify ABNF
layering"
o : "use of 'word'
ABNF production"
o : "improve
introduction of list rule"
o : "moving 2616/
2068/2145 to historic"
o : "augment
security considerations with pointers to current research"
o :
"intermediaries handling trailers"
o : "allow privacy
proxies to be conformant"
C.4. Since draft-ietf-httpbis-p1-messaging-26
None yet.
Index
NEW:
Index
Appendix B., paragraph 24:
OLD:
D
deflate (Coding Format) 38
Delimiters 26
downstream 9
NEW:
D
deflate (Coding Format) 38
Delimiters 26
downstream 10
Appendix B., paragraph 26:
OLD:
G
gateway 10
Grammar
absolute-form 41-42
absolute-path 16
absolute-URI 16
ALPHA 6
asterisk-form 41-42
authority 16
authority-form 41-42
BWS 24
chunk 35
chunk-data 35
chunk-ext 35-36
chunk-ext-name 36
chunk-ext-val 36
chunk-size 35
chunked-body 35-36
comment 27
Connection 51
connection-option 51
Content-Length 30
CR 6
CRLF 6
ctext 27
CTL 6
DIGIT 6
DQUOTE 6
field-content 22
field-name 22, 39
field-value 22
field-vchar 22
fragment 16
header-field 22, 36
HEXDIG 6
Host 43
HTAB 6
HTTP-message 19
HTTP-name 13
http-URI 16
HTTP-version 13
https-URI 18
last-chunk 35
LF 6
message-body 27
method 21
obs-fold 22
obs-text 27
OCTET 6
origin-form 41
OWS 24
partial-URI 16
port 16
protocol-name 47
protocol-version 47
pseudonym 47
qdtext 27
query 16
quoted-pair 27
quoted-string 27
rank 38
reason-phrase 22
received-by 47
received-protocol 47
request-line 21
request-target 41
RWS 24
scheme 16
segment 16
SP 6
start-line 20
status-code 22
status-line 22
t-codings 38
t-ranking 38
tchar 27
TE 38
token 27
Trailer 39
trailer-part 35-36
transfer-coding 35
Transfer-Encoding 28
transfer-extension 35
transfer-parameter 35
Upgrade 56
uri-host 16
URI-reference 16
VCHAR 6
Via 47
gzip (Coding Format) 38
NEW:
G
gateway 10
Grammar
absolute-form 41-42
absolute-path 16
absolute-URI 16
ALPHA 6
asterisk-form 41-42
authority 16
authority-form 41-42
BWS 24
chunk 35
chunk-data 35
chunk-ext 35-36
chunk-ext-name 36
chunk-ext-val 36
chunk-size 35
chunked-body 35-36
comment 27
Connection 51
connection-option 51
Content-Length 30
CR 6
CRLF 6
ctext 27
CTL 6
DIGIT 6
DQUOTE 6
field-content 22
field-name 22, 39
field-value 22
field-vchar 22
fragment 16
header-field 22, 36
HEXDIG 6
Host 43
HTAB 6
HTTP-message 19
HTTP-name 14
http-URI 16
HTTP-version 14
https-URI 18
last-chunk 35
LF 6
message-body 27
method 21
obs-fold 22
obs-text 27
OCTET 6
origin-form 41
OWS 24
partial-URI 16
port 16
protocol-name 47
protocol-version 47
pseudonym 47
qdtext 27
query 16
quoted-pair 27
quoted-string 27
rank 38
reason-phrase 22
received-by 47
received-protocol 47
request-line 21
request-target 41
RWS 24
scheme 16
segment 16
SP 6
start-line 20
status-code 22
status-line 22
t-codings 38
t-ranking 38
tchar 27
TE 38
token 27
Trailer 39
trailer-part 35-36
transfer-coding 35
Transfer-Encoding 28
transfer-extension 35
transfer-parameter 35
Upgrade 56
uri-host 16
URI-reference 16
VCHAR 6
Via 47
gzip (Coding Format) 38
Appendix B., paragraph 28:
OLD:
I
inbound 9
interception proxy 11
intermediary 9
NEW:
I
inbound 10
interception proxy 11
intermediary 9
Appendix B., paragraph 31:
OLD:
O
origin server 7
origin-form (of request-target) 41
outbound 9
NEW:
O
origin server 7
origin-form (of request-target) 41
outbound 10
Appendix B., paragraph 36:
OLD:
U
Upgrade header field 56
upstream 9
URI scheme
http 16
https 18
user agent 7
NEW:
U
Upgrade header field 56
upstream 10
URI scheme
http 16
https 18
user agent 7
Section 345, paragraph 1:
OLD:
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
NEW:
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany