draft-ietf-httpbis-messaging-03.txt   draft-ietf-httpbis-messaging-04.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7230 (if approved) M. Nottingham, Ed. Obsoletes: 7230 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Fastly Intended status: Standards Track Fastly
Expires: April 21, 2019 J. Reschke, Ed. Expires: September 10, 2019 J. Reschke, Ed.
greenbytes greenbytes
October 18, 2018 March 9, 2019
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-03 draft-ietf-httpbis-messaging-04
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document specifies the HTTP/1.1 message syntax, systems. This document specifies the HTTP/1.1 message syntax,
message parsing, connection management, and related security message parsing, connection management, and related security
concerns. concerns.
This document obsoletes portions of RFC 7230. This document obsoletes portions of RFC 7230.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix D.4. The changes in this draft are summarized in Appendix D.5.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2019. This Internet-Draft will expire on September 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 16 skipping to change at page 3, line 16
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15 5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 22
7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23 7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
7.2. Transfer Codings for Compression . . . . . . . . . . . . 25 7.2. Transfer Codings for Compression . . . . . . . . . . . . 24
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 27
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29
9.3. Associating a Response to a Request . . . . . . . . . . . 30 9.3. Associating a Response to a Request . . . . . . . . . . . 29
9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30 9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31 9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32 9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33 9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37 9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36
9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37 9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 38 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37
10.1. Media Type message/http . . . . . . . . . . . . . . . . 38 10.1. Media Type message/http . . . . . . . . . . . . . . . . 38
10.2. Media Type application/http . . . . . . . . . . . . . . 39 10.2. Media Type application/http . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 41
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
12.1. Header Field Registration . . . . . . . . . . . . . . . 43 12.1. Header Field Registration . . . . . . . . . . . . . . . 42
12.2. Media Type Registration . . . . . . . . . . . . . . . . 43 12.2. Media Type Registration . . . . . . . . . . . . . . . . 42
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 47 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46
Appendix B. Differences between HTTP and MIME . . . . . . . . . 48 Appendix B. Differences between HTTP and MIME . . . . . . . . . 47
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 49 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 48
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 49 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 48
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 49 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 50 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 49
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 50 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 49
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 50 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 49
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 50 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 49
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 51 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 50
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 51 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 50
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 52 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 51
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 52 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 51
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 53 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 51
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 52
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 53 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 52
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 53 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 52
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 54 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 53
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 55 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 53
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 54
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" [Semantics] o "HTTP Semantics" [Semantics]
skipping to change at page 5, line 17 skipping to change at page 5, line 17
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 3 of [Semantics]. defined in Section 3 of [Semantics].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with a list extension, defined in Section 11 of notation of [RFC5234], extended with the notation for case-
[Semantics], that allows for compact definition of comma-separated sensitivity in strings defined in [RFC7405].
lists using a '#' operator (similar to how the '*' operator indicates
repetition). Appendix A shows the collected grammar with all list It also uses a list extension, defined in Section 11 of [Semantics],
operators expanded to standard ABNF notation. that allows for compact definition of comma-separated lists using a
'#' operator (similar to how the '*' operator indicates repetition).
Appendix A shows the collected grammar with all list operators
expanded to standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. "obsolete" grammar rules that appear for historical reasons.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character). visible [USASCII] character).
skipping to change at page 6, line 49 skipping to change at page 6, line 49
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". of the protocol. This specification defines version "1.1".
Section 3.5 of [Semantics] specifies the semantics of HTTP version Section 3.5 of [Semantics] specifies the semantics of HTTP version
numbers. numbers.
The version of an HTTP/1.x message is indicated by an HTTP-version The version of an HTTP/1.x message is indicated by an HTTP-version
field in the start-line. HTTP-version is case-sensitive. field in the start-line. HTTP-version is case-sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive HTTP-name = %s"HTTP"
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0 constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1. the recipient supports HTTP/1.1.
skipping to change at page 14, line 44 skipping to change at page 14, line 40
header-field = field-name ":" OWS field-value OWS header-field = field-name ":" OWS field-value OWS
Most HTTP field names and the rules for parsing within field values Most HTTP field names and the rules for parsing within field values
are defined in Section 4 of [Semantics]. This section covers the are defined in Section 4 of [Semantics]. This section covers the
generic syntax for header field inclusion within, and extraction generic syntax for header field inclusion within, and extraction
from, HTTP/1.1 messages. In addition, the following header fields from, HTTP/1.1 messages. In addition, the following header fields
are defined by this document because they are specific to HTTP/1.1 are defined by this document because they are specific to HTTP/1.1
message processing: message processing:
+-------------------+----------+----------+---------------+ +-------------------+----------+---------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Status | Reference |
+-------------------+----------+----------+---------------+ +-------------------+----------+---------------+
| Connection | http | standard | Section 9.1 | | Connection | standard | Section 9.1 |
| MIME-Version | http | standard | Appendix B.1 | | MIME-Version | standard | Appendix B.1 |
| TE | http | standard | Section 7.4 | | TE | standard | Section 7.4 |
| Transfer-Encoding | http | standard | Section 6.1 | | Transfer-Encoding | standard | Section 6.1 |
| Upgrade | http | standard | Section 9.8 | | Upgrade | standard | Section 9.8 |
+-------------------+----------+----------+---------------+ +-------------------+----------+---------------+
Furthermore, the field name "Close" is reserved, since using that Furthermore, the field name "Close" is reserved, since using that
name as an HTTP header field might conflict with the "close" name as an HTTP header field might conflict with the "close"
connection option of the Connection header field (Section 9.1). connection option of the Connection header field (Section 9.1).
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
| Close | http | reserved | Section 5 | | Close | http | reserved | Section 5 |
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
skipping to change at page 21, line 19 skipping to change at page 21, line 19
7. Transfer Codings 7. Transfer Codings
Transfer coding names are used to indicate an encoding transformation Transfer coding names are used to indicate an encoding transformation
that has been, can be, or might need to be applied to a payload body that has been, can be, or might need to be applied to a payload body
in order to ensure "safe transport" through the network. This in order to ensure "safe transport" through the network. This
differs from a content coding in that the transfer coding is a differs from a content coding in that the transfer coding is a
property of the message rather than a property of the representation property of the message rather than a property of the representation
that is being transferred. that is being transferred.
transfer-coding = "chunked" ; Section 7.1 transfer-coding = token *( OWS ";" OWS transfer-parameter )
/ "compress" ; [Semantics], Section 6.1.2.1
/ "deflate" ; [Semantics], Section 6.1.2.2
/ "gzip" ; [Semantics], Section 6.1.2.3
/ transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name=value pair. Parameters are in the form of a name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the HTTP Transfer Coding registry, as defined in
Section 7.3. They are used in the TE (Section 7.4) and Transfer- Section 7.3. They are used in the TE (Section 7.4) and Transfer-
Encoding (Section 6.1) header fields. Encoding (Section 6.1) header fields.
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| chunked | Transfer in a series of chunks | Section 7 | | chunked | Transfer in a series of chunks | Section |
| | | .1 | | | | 7.1 |
| compress | UNIX "compress" data format [Welch] | Section 7 | | compress | UNIX "compress" data format [Welch] | Section |
| | | .2 | | | | 7.2 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 7 | | deflate | "deflate" compressed data ([RFC1951]) | Section |
| | inside the "zlib" data format | .2 | | | inside the "zlib" data format | 7.2 |
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 7 | | gzip | GZIP file format [RFC1952] | Section |
| | | .2 | | | | 7.2 |
| trailers | (reserved) | Section 7 | | trailers | (reserved) | Section 7 |
| x-compress | Deprecated (alias for compress) | Section 7 | | x-compress | Deprecated (alias for compress) | Section |
| | | .2 | | | | 7.2 |
| x-gzip | Deprecated (alias for gzip) | Section 7 | | x-gzip | Deprecated (alias for gzip) | Section |
| | | .2 | | | | 7.2 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Note: the coding name "trailers" is reserved because it would Note: the coding name "trailers" is reserved because it would
clash with the use of the keyword "trailers" in the TE header clash with the use of the keyword "trailers" in the TE header
field (Section 7.4). field (Section 7.4).
7.1. Chunked Transfer Coding 7.1. Chunked Transfer Coding
The chunked transfer coding wraps the payload body in order to The chunked transfer coding wraps the payload body in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
skipping to change at page 23, line 10 skipping to change at page 22, line 35
chunk-data = 1*OCTET ; a sequence of chunk-size octets chunk-data = 1*OCTET ; a sequence of chunk-size octets
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked transfer coding is complete the chunk-data in octets. The chunked transfer coding is complete
when a chunk with a chunk-size of zero is received, possibly followed when a chunk with a chunk-size of zero is received, possibly followed
by a trailer, and finally terminated by an empty line. by a trailer, and finally terminated by an empty line.
A recipient MUST be able to parse and decode the chunked transfer A recipient MUST be able to parse and decode the chunked transfer
coding. coding.
The chunked encoding does not define any parameters. Their presence
SHOULD be treated as an error.
7.1.1. Chunk Extensions 7.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
extensions, immediately following the chunk-size, for the sake of extensions, immediately following the chunk-size, for the sake of
supplying per-chunk metadata (such as a signature or hash), mid- supplying per-chunk metadata (such as a signature or hash), mid-
message control information, or randomization of message body size. message control information, or randomization of message body size.
chunk-ext = *( BWS ";" BWS chunk-ext-name chunk-ext = *( BWS ";" BWS chunk-ext-name
[ BWS "=" BWS chunk-ext-val ] ) [ BWS "=" BWS chunk-ext-val ] )
skipping to change at page 25, line 38 skipping to change at page 25, line 6
compress (and x-compress) compress (and x-compress)
See Section 6.1.2.1 of [Semantics]. See Section 6.1.2.1 of [Semantics].
deflate deflate
See Section 6.1.2.2 of [Semantics]. See Section 6.1.2.2 of [Semantics].
gzip (and x-gzip) gzip (and x-gzip)
See Section 6.1.2.3 of [Semantics]. See Section 6.1.2.3 of [Semantics].
The compression codings do not define any parameters. Their presence
SHOULD be treated as an error.
7.3. Transfer Coding Registry 7.3. Transfer Coding Registry
The "HTTP Transfer Coding Registry" defines the namespace for The "HTTP Transfer Coding Registry" defines the namespace for
transfer coding names. It is maintained at transfer coding names. It is maintained at
<https://www.iana.org/assignments/http-parameters>. <https://www.iana.org/assignments/http-parameters>.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
skipping to change at page 30, line 31 skipping to change at page 29, line 49
same connection. More than one response message per request only same connection. More than one response message per request only
occurs when one or more informational responses (1xx, see Section 9.2 occurs when one or more informational responses (1xx, see Section 9.2
of [Semantics]) precede a final response to the same request. of [Semantics]) precede a final response to the same request.
A client that has more than one outstanding request on a connection A client that has more than one outstanding request on a connection
MUST maintain a list of outstanding requests in the order sent and MUST maintain a list of outstanding requests in the order sent and
MUST associate each received response message on that connection to MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final (non- the highest ordered request that has not yet received a final (non-
1xx) response. 1xx) response.
If an HTTP/1.1 client receives data on a connection that doesn't have
any outstanding requests, it MUST NOT consider them to be a response
to a not-yet-issued request; it SHOULD close the connection, since
message delimitation is now ambiguous, unless the data consists only
of one or more CRLF (which can be discarded, as per Section 2.3).
9.4. Persistence 9.4. Persistence
HTTP/1.1 defaults to the use of "persistent connections", allowing HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. The "close" connection option is used to signal that a connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections. implementations SHOULD support persistent connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
based on the most recently received message's protocol version and based on the most recently received message's protocol version and
skipping to change at page 43, line 7 skipping to change at page 42, line 38
confidential connection, as described in Section 2.5.2 of confidential connection, as described in Section 2.5.2 of
[Semantics]. [Semantics].
12. IANA Considerations 12. IANA Considerations
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
12.1. Header Field Registration 12.1. Header Field Registration
Please update the "Message Headers" registry of "Permanent Message Please update the "Hypertext Transfer Protocol (HTTP) Header Field
Header Field Names" at <https://www.iana.org/assignments/message- Registry" registry at <https://www.iana.org/assignments/http-headers>
headers> with the header field names listed in the two tables of with the header field names listed in the two tables of Section 5.
Section 5.
12.2. Media Type Registration 12.2. Media Type Registration
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 10.1 and Section 10.2 for the media types information in Section 10.1 and Section 10.2 for the media types
"message/http" and "application/http", respectively. "message/http" and "application/http", respectively.
12.3. Transfer Coding Registration 12.3. Transfer Coding Registration
skipping to change at page 43, line 38 skipping to change at page 43, line 24
Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token
Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>
with the registration procedure of Section 9.8.2 and the upgrade with the registration procedure of Section 9.8.2 and the upgrade
token names summarized in the table of Section 9.8.1. token names summarized in the table of Section 9.8.1.
13. References 13. References
13.1. Normative References 13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-03 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-04 (work in
progress), October 2018. progress), March 2019.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 44, line 25 skipping to change at page 44, line 10
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-03 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-04
(work in progress), October 2018. (work in progress), March 2019.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
13.2. Informative References 13.2. Informative References
skipping to change at page 48, line 35 skipping to change at page 47, line 35
asterisk-form asterisk-form
start-line = request-line / status-line start-line = request-line / status-line
status-code = 3DIGIT status-code = 3DIGIT
status-line = HTTP-version SP status-code SP reason-phrase CRLF status-line = HTTP-version SP status-code SP reason-phrase CRLF
t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank t-ranking = OWS ";" OWS "q=" rank
token = <token, see [Semantics], Section 4.2.3> token = <token, see [Semantics], Section 4.2.3>
trailer-part = *( header-field CRLF ) trailer-part = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
Appendix B. Differences between HTTP and MIME Appendix B. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for the Internet Message HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open [RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible header fields. variety of representations and with extensible header fields.
skipping to change at page 55, line 13 skipping to change at page 54, line 5
registry (<https://github.com/httpwg/http-core/issues/108>) registry (<https://github.com/httpwg/http-core/issues/108>)
D.4. Since draft-ietf-httpbis-messaging-02 D.4. Since draft-ietf-httpbis-messaging-02
o In Section 4, explain why the reason phrase should be ignored by o In Section 4, explain why the reason phrase should be ignored by
clients (<https://github.com/httpwg/http-core/issues/60>). clients (<https://github.com/httpwg/http-core/issues/60>).
o Add Section 9.3 to explain how request/response correlation is o Add Section 9.3 to explain how request/response correlation is
performed (<https://github.com/httpwg/http-core/issues/145>) performed (<https://github.com/httpwg/http-core/issues/145>)
D.5. Since draft-ietf-httpbis-messaging-03
o In Section 9.3, caution against treating data on a connection as
part of a not-yet-issued request (<https://github.com/httpwg/http-
core/issues/26>)
o In Section 7, remove the predefined codings from the ABNF and make
it generic instead (<https://github.com/httpwg/http-core/
issues/66>)
o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>)
Index Index
A A
absolute-form (of request-target) 10 absolute-form (of request-target) 10
application/http Media Type 39 application/http Media Type 39
asterisk-form (of request-target) 11 asterisk-form (of request-target) 11
authority-form (of request-target) 11 authority-form (of request-target) 11
C C
Connection header field 28, 34 Connection header field 28, 33
Content-Length header field 18 Content-Length header field 18
Content-Transfer-Encoding header field 50 Content-Transfer-Encoding header field 49
chunked (Coding Format) 17, 19 chunked (Coding Format) 17, 19
chunked (transfer coding) 22 chunked (transfer coding) 22
close 28, 34 close 28, 33
compress (transfer coding) 25 compress (transfer coding) 24
D D
deflate (transfer coding) 25 deflate (transfer coding) 24
E E
effective request URI 12 effective request URI 12
G G
Grammar Grammar
absolute-form 9-10 absolute-form 9-10
ALPHA 5 ALPHA 5
asterisk-form 9, 11 asterisk-form 9, 11
authority-form 9, 11 authority-form 9, 11
chunk 22 chunk 22
chunk-data 22 chunk-data 22
chunk-ext 22-23 chunk-ext 22
chunk-ext-name 23 chunk-ext-name 22
chunk-ext-val 23 chunk-ext-val 22
chunk-size 22 chunk-size 22
chunked-body 22-23 chunked-body 22
Connection 29 Connection 28
connection-option 29 connection-option 28
CR 5 CR 5
CRLF 5 CRLF 5
CTL 5 CTL 5
DIGIT 5 DIGIT 5
DQUOTE 5 DQUOTE 5
field-name 14 field-name 14
field-value 14 field-value 14
header-field 14, 23 header-field 14, 23
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
skipping to change at page 56, line 36 skipping to change at page 55, line 41
SP 5 SP 5
start-line 6 start-line 6
status-code 14 status-code 14
status-line 13 status-line 13
t-codings 26 t-codings 26
t-ranking 26 t-ranking 26
TE 26 TE 26
trailer-part 22-23 trailer-part 22-23
transfer-coding 21 transfer-coding 21
Transfer-Encoding 17 Transfer-Encoding 17
transfer-extension 21
transfer-parameter 21 transfer-parameter 21
Upgrade 35 Upgrade 35
VCHAR 5 VCHAR 5
gzip (transfer coding) 25 gzip (transfer coding) 24
H H
header field 6 header field 6
header section 6 header section 6
headers 6 headers 6
M M
MIME-Version header field 49 MIME-Version header field 48
Media Type Media Type
application/http 39 application/http 39
message/http 38 message/http 38
message/http Media Type 38 message/http Media Type 38
method 9 method 9
O O
origin-form (of request-target) 10 origin-form (of request-target) 10
R R
request-target 9 request-target 9
T T
skipping to change at page 57, line 15 skipping to change at page 56, line 18
message/http Media Type 38 message/http Media Type 38
method 9 method 9
O O
origin-form (of request-target) 10 origin-form (of request-target) 10
R R
request-target 9 request-target 9
T T
TE header field 26 TE header field 25
Transfer-Encoding header field 17 Transfer-Encoding header field 17
U U
Upgrade header field 35 Upgrade header field 34
X X
x-compress (transfer coding) 25 x-compress (transfer coding) 24
x-gzip (transfer coding) 25 x-gzip (transfer coding) 24
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
 End of changes. 45 change blocks. 
107 lines changed or deleted 130 lines changed or added

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