draft-ietf-httpbis-messaging-06.txt   draft-ietf-httpbis-messaging-07.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: May 7, 2020 J. Reschke, Ed. Expires: September 8, 2020 J. Reschke, Ed.
greenbytes greenbytes
November 4, 2019 March 7, 2020
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-06 draft-ietf-httpbis-messaging-07
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.7. The changes in this draft are summarized in Appendix D.8.
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 May 7, 2020. This Internet-Draft will expire on September 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 7 skipping to change at page 3, line 7
3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11
3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12 3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Header Field Syntax . . . . . . . . . . . . . . . . . . . . . 14 5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15 5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 15
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 23
7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 23 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 23
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 36 skipping to change at page 3, line 36
9.3. Associating a Response to a Request . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . 31 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32 9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32 9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 34 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 34
9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37 9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37
9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38 9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 38 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 38
10.1. Media Type message/http . . . . . . . . . . . . . . . . 38 10.1. Media Type message/http . . . . . . . . . . . . . . . . 38
10.2. Media Type application/http . . . . . . . . . . . . . . 40 10.2. Media Type application/http . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 41 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 41
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 42 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 42
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 43 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12.1. Header Field Registration . . . . . . . . . . . . . . . 43 12.1. Field Name Registration . . . . . . . . . . . . . . . . 43
12.2. Media Type Registration . . . . . . . . . . . . . . . . 43 12.2. Media Type Registration . . . . . . . . . . . . . . . . 43
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43
12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 47 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 47
Appendix B. Differences between HTTP and MIME . . . . . . . . . 48 Appendix B. Differences between HTTP and MIME . . . . . . . . . 48
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 49 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 49
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 49 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 49
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 49 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 49
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 50 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 50
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 50 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 50
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 50 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 50
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 50 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 50
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 51 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 51
skipping to change at page 4, line 27 skipping to change at page 4, line 27
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 52 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 52
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 52 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 52
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 53 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 53
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 53 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 53
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 54 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 54
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 55 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 55
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 55 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 55
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 55 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 55
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 55 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 55
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 56
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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 13 skipping to change at page 5, line 13
forwarding intermediaries. forwarding intermediaries.
This document obsoletes the portions of RFC 7230 related to HTTP/1.1 This document obsoletes the portions of RFC 7230 related to HTTP/1.1
messaging and connection management, with the changes being messaging and connection management, with the changes being
summarized in Appendix C.2. The other parts of RFC 7230 are summarized in Appendix C.2. The other parts of RFC 7230 are
obsoleted by "HTTP Semantics" [Semantics]. obsoleted by "HTTP Semantics" [Semantics].
1.1. Requirements Notation 1.1. Requirements Notation
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 12 of [Semantics], It also uses a list extension, defined in Section 4.5 of [Semantics],
that allows for compact definition of comma-separated lists using a that allows for compact definition of comma-separated lists using a
'#' operator (similar to how the '*' operator indicates repetition). '#' operator (similar to how the '*' operator indicates repetition).
Appendix A shows the collected grammar with all list operators Appendix A shows the collected grammar with all list operators
expanded to standard ABNF notation. 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).
The rules below are defined in [Semantics]: The rules below are defined in [Semantics]:
BWS = <BWS, see [Semantics], Section 11.1> BWS = <BWS, see [Semantics], Section 1.2.1>
OWS = <OWS, see [Semantics], Section 11.1> OWS = <OWS, see [Semantics], Section 1.2.1>
RWS = <RWS, see [Semantics], Section 11.1> RWS = <RWS, see [Semantics], Section 1.2.1>
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-path = <absolute-path, see [Semantics], Section 2.4> absolute-path = <absolute-path, see [Semantics], Section 2.4>
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
comment = <comment, see [Semantics], Section 4.2.3.3> comment = <comment, see [Semantics], Section 4.4.1.3>
field-name = <field-name, see [Semantics], Section 4.1> field-name = <field-name, see [Semantics], Section 4.3>
field-value = <field-value, see [Semantics], Section 4.2> field-value = <field-value, see [Semantics], Section 4.4>
obs-text = <obs-text, see [Semantics], Section 4.2.3.2> obs-text = <obs-text, see [Semantics], Section 4.4.1.2>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3.2> quoted-string = <quoted-string, see [Semantics], Section 4.4.1.2>
token = <token, see [Semantics], Section 4.2.3.1> token = <token, see [Semantics], Section 4.4.1.1>
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
2. Message 2. Message
2.1. Message Format 2.1. Message Format
An HTTP/1.1 message consists of a start-line followed by a CRLF and a An HTTP/1.1 message consists of a start-line followed by a CRLF and a
sequence of octets in a format similar to the Internet Message Format sequence of octets in a format similar to the Internet Message Format
[RFC5322]: zero or more header fields (collectively referred to as [RFC5322]: zero or more header field lines (collectively referred to
the "headers" or the "header section"), an empty line indicating the as the "headers" or the "header section"), an empty line indicating
end of the header section, and an optional message body. the end of the header section, and an optional message body.
HTTP-message = start-line CRLF HTTP-message = start-line CRLF
*( header-field CRLF ) *( field-line CRLF )
CRLF CRLF
[ message-body ] [ message-body ]
A message can be either a request from client to server or a response A message can be either a request from client to server or a response
from server to client. Syntactically, the two types of message from server to client. Syntactically, the two types of message
differ only in the start-line, which is either a request-line (for 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 requests) or a status-line (for responses), and in the algorithm for
determining the length of the message body (Section 6). determining the length of the message body (Section 6).
start-line = request-line / status-line start-line = request-line / status-line
skipping to change at page 7, line 8 skipping to change at page 7, line 8
response is interpreted as an unknown or invalid request method) and response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response. clients are implemented to only expect a response.
Although HTTP makes use of some protocol elements similar to the Although HTTP makes use of some protocol elements similar to the
Multipurpose Internet Mail Extensions (MIME) [RFC2045], see Multipurpose Internet Mail Extensions (MIME) [RFC2045], see
Appendix B for the differences between HTTP and MIME messages. Appendix B for the differences between HTTP and MIME messages.
2.2. Message Parsing 2.2. Message Parsing
The normal procedure for parsing an HTTP message is to read the The normal procedure for parsing an HTTP message is to read the
start-line into a structure, read each header field into a hash table start-line into a structure, read each header field line into a hash
by field name until the empty line, and then use the parsed data to table by field name until the empty line, and then use the parsed
determine if a message body is expected. If a message body has been data to determine if a message body is expected. If a message body
indicated, then it is read as a stream until an amount of octets has been indicated, then it is read as a stream until an amount of
equal to the message body length is read or the connection is closed. octets equal to the message body length is read or the connection is
closed.
A recipient MUST parse an HTTP message as a sequence of octets in an A recipient MUST parse an HTTP message as a sequence of octets in an
encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
message as a stream of Unicode characters, without regard for the message as a stream of Unicode characters, without regard for the
specific encoding, creates security vulnerabilities due to the specific encoding, creates security vulnerabilities due to the
varying ways that string processing libraries handle invalid varying ways that string processing libraries handle invalid
multibyte character sequences that contain the octet LF (%x0A). multibyte character sequences that contain the octet LF (%x0A).
String-based parsers can only be safely used within protocol elements String-based parsers can only be safely used within protocol elements
after the element has been extracted from the message, such as within after the element has been extracted from the message, such as within
a header field-value after message parsing has delineated the a header field line value after message parsing has delineated the
individual fields. individual field lines.
Although the line terminator for the start-line and header fields is Although the line terminator for the start-line and header fields is
the sequence CRLF, a recipient MAY recognize a single LF as a line the sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR. terminator and ignore any preceding CR.
Older HTTP/1.0 user agent implementations might send an extra CRLF Older HTTP/1.0 user agent implementations might send an extra CRLF
after a POST request as a workaround for some early server after a POST request as a workaround for some early server
applications that failed to read message body content that was not applications that failed to read message body content that was not
terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
or follow a request with an extra CRLF. If terminating the request or follow a request with an extra CRLF. If terminating the request
skipping to change at page 7, line 50 skipping to change at page 7, line 51
A sender MUST NOT send whitespace between the start-line and the A sender MUST NOT send whitespace between the start-line and the
first header field. A recipient that receives whitespace between the first header field. A recipient that receives whitespace between the
start-line and the first header field MUST either reject the message start-line and the first header field MUST either reject the message
as invalid or consume each whitespace-preceded line without further as invalid or consume each whitespace-preceded line without further
processing of it (i.e., ignore the entire line, along with any processing of it (i.e., ignore the entire line, along with any
subsequent lines preceded by whitespace, until a properly formed subsequent lines preceded by whitespace, until a properly formed
header field is received or the header section is terminated). header field is received or the header section is terminated).
The presence of such whitespace in a request might be an attempt to The presence of such whitespace in a request might be an attempt to
trick a server into ignoring that field or processing the line after trick a server into ignoring that field line or processing the line
it as a new request, either of which might result in a security after it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or such whitespace in a response might be ignored by some clients or
cause others to cease parsing. cause others to cease parsing.
When a server listening only for HTTP request messages, or processing When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message, what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server grammar aside from the robustness exceptions listed above, the server
SHOULD respond with a 400 (Bad Request) response. SHOULD respond with a 400 (Bad Request) response.
skipping to change at page 10, line 42 skipping to change at page 10, line 42
The most common form of request-target is the origin-form. The most common form of request-target is the origin-form.
origin-form = absolute-path [ "?" query ] origin-form = absolute-path [ "?" query ]
When making a request directly to an origin server, other than a When making a request directly to an origin server, other than a
CONNECT or server-wide OPTIONS request (as detailed below), a client CONNECT or server-wide OPTIONS request (as detailed below), a client
MUST send only the absolute path and query components of the target MUST send only the absolute path and query components of the target
URI as the request-target. If the target URI's path component is URI as the request-target. If the target URI's path component is
empty, the client MUST send "/" as the path within the origin-form of empty, the client MUST send "/" as the path within the origin-form of
request-target. A Host header field is also sent, as defined in request-target. A Host header field is also sent, as defined in
Section 5.4 of [Semantics]. Section 5.6 of [Semantics].
For example, a client wishing to retrieve a representation of the For example, a client wishing to retrieve a representation of the
resource identified as resource identified as
http://www.example.org/where?q=now http://www.example.org/where?q=now
directly from the origin server would open (or reuse) a TCP directly from the origin server would open (or reuse) a TCP
connection to port 80 of the host "www.example.org" and send the connection to port 80 of the host "www.example.org" and send the
lines: lines:
skipping to change at page 11, line 22 skipping to change at page 11, line 22
When making a request to a proxy, other than a CONNECT or server-wide When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target. URI in absolute-form as the request-target.
absolute-form = absolute-URI absolute-form = absolute-URI
The proxy is requested to either service that request from a valid The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.5 of [Semantics]. "forwarding" of messages are defined in Section 5.7 of [Semantics].
An example absolute-form of request-line would be: An example absolute-form of request-line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to the absolute-form for all requests in some To allow for transition to the absolute-form for all requests in some
future version of HTTP, a server MUST accept the absolute-form in future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in requests, even though HTTP/1.1 clients will only send them in
requests to proxies. requests to proxies.
skipping to change at page 12, line 32 skipping to change at page 12, line 32
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org:8001 Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org". after connecting to port 8001 of host "www.example.org".
3.3. Effective Request URI 3.3. Effective Request URI
Since the request-target often contains only part of the user agent's Since the request-target often contains only part of the user agent's
target URI, a server reconstructs the intended target as an effective target URI, a server reconstructs the intended target as an effective
request URI to properly service the request (Section 5.3 of request URI to properly service the request (Section 5.5 of
[Semantics]). [Semantics]).
If the request-target is in absolute-form, the effective request URI If the request-target is in absolute-form, the effective request URI
is the same as the request-target. Otherwise, the effective request is the same as the request-target. Otherwise, the effective request
URI is constructed as follows: URI is constructed as follows:
If the server's configuration (or outbound gateway) provides a If the server's configuration (or outbound gateway) provides a
fixed URI scheme, that scheme is used for the effective request fixed URI scheme, that scheme is used for the effective request
URI. Otherwise, if the request is received over a TLS-secured TCP URI. Otherwise, if the request is received over a TLS-secured TCP
connection, the effective request URI's scheme is "https"; if not, connection, the effective request URI's scheme is "https"; if not,
skipping to change at page 14, line 43 skipping to change at page 14, line 43
reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
A client SHOULD ignore the reason-phrase content because it is not a A client SHOULD ignore the reason-phrase content because it is not a
reliable channel for information (it might be translated for a given reliable channel for information (it might be translated for a given
locale, overwritten by intermediaries, or discarded when the message locale, overwritten by intermediaries, or discarded when the message
is forwarded via other versions of HTTP). A server MUST send the is forwarded via other versions of HTTP). A server MUST send the
space that separates status-code from the reason-phrase even when the space that separates status-code from the reason-phrase even when the
reason-phrase is absent (i.e., the status-line would end with the reason-phrase is absent (i.e., the status-line would end with the
three octets SP CR LF). three octets SP CR LF).
5. Header Field Syntax 5. Field Syntax
Each header field consists of a case-insensitive field name followed Each field line consists of a case-insensitive field name followed by
by a colon (":"), optional leading whitespace, the field value, and a colon (":"), optional leading whitespace, the field line value, and
optional trailing whitespace. optional trailing whitespace.
header-field = field-name ":" OWS field-value OWS field-line = 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 | Status | Reference | | Field Name | Status | Reference |
+-------------------+----------+---------------+ +-------------------+----------+---------------+
| Connection | standard | Section 9.1 | | Connection | standard | Section 9.1 |
| MIME-Version | standard | Appendix B.1 | | MIME-Version | standard | Appendix B.1 |
| TE | standard | Section 7.4 | | TE | standard | Section 7.4 |
| Transfer-Encoding | standard | Section 6.1 | | Transfer-Encoding | standard | Section 6.1 |
| Upgrade | standard | Section 9.9 | | Upgrade | standard | Section 9.9 |
+-------------------+----------+---------------+ +-------------------+----------+---------------+
Table 1 Table 1
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 |
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
5.1. Header Field Parsing 5.1. Field Line Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field individual field names. The contents within a given field line value
value are not parsed until a later stage of message interpretation are not parsed until a later stage of message interpretation (usually
(usually after the message's entire header section has been after the message's entire header section has been processed).
processed).
No whitespace is allowed between the header field-name and colon. In No whitespace is allowed between the field name and colon. In the
the past, differences in the handling of such whitespace have led to past, differences in the handling of such whitespace have led to
security vulnerabilities in request routing and response handling. A security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains server MUST reject any received request message that contains
whitespace between a header field-name and colon with a response whitespace between a header field name and colon with a response
status code of 400 (Bad Request). A proxy MUST remove any such status code of 400 (Bad Request). A proxy MUST remove any such
whitespace from a response message before forwarding the message whitespace from a response message before forwarding the message
downstream. downstream.
A field value might be preceded and/or followed by optional A field line value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred whitespace (OWS); a single SP preceding the field line value is
for consistent readability by humans. The field value does not preferred for consistent readability by humans. The field line value
include any leading or trailing whitespace: OWS occurring before the does not include any leading or trailing whitespace: OWS occurring
first non-whitespace octet of the field value or after the last non- before the first non-whitespace octet of the field line value or
whitespace octet of the field value ought to be excluded by parsers after the last non-whitespace octet of the field line value ought to
when extracting the field value from a header field. be excluded by parsers when extracting the field line value from a
header field line.
5.2. Obsolete Line Folding 5.2. Obsolete Line Folding
Historically, HTTP header field values could be extended over Historically, HTTP header field line values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type line folding except within the message/http media type
(Section 10.1). (Section 10.1).
obs-fold = OWS CRLF RWS obs-fold = OWS CRLF RWS
; obsolete line folding ; obsolete line folding
A sender MUST NOT generate a message that includes line folding A sender MUST NOT generate a message that includes line folding
(i.e., that has any field-value that contains a match to the obs-fold (i.e., that has any field line value that contains a match to the
rule) unless the message is intended for packaging within the obs-fold rule) unless the message is intended for packaging within
message/http media type. the message/http media type.
A server that receives an obs-fold in a request message that is not A server that receives an obs-fold in a request message that is not
within a message/http container MUST either reject the message by within a message/http container MUST either reject the message by
sending a 400 (Bad Request), preferably with a representation sending a 400 (Bad Request), preferably with a representation
explaining that obsolete line folding is unacceptable, or replace explaining that obsolete line folding is unacceptable, or replace
each received obs-fold with one or more SP octets prior to each received obs-fold with one or more SP octets prior to
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
A proxy or gateway that receives an obs-fold in a response message A proxy or gateway that receives an obs-fold in a response message
that is not within a message/http container MUST either discard the that is not within a message/http container MUST either discard the
skipping to change at page 18, line 14 skipping to change at page 18, line 14
indicates that the payload body has been compressed using the gzip indicates that the payload body has been compressed using the gzip
coding and then chunked using the chunked coding while forming the coding and then chunked using the chunked coding while forming the
message body. message body.
Unlike Content-Encoding (Section 6.1.2 of [Semantics]), Transfer- Unlike Content-Encoding (Section 6.1.2 of [Semantics]), Transfer-
Encoding is a property of the message, not of the representation, and Encoding is a property of the message, not of the representation, and
any recipient along the request/response chain MAY decode the any recipient along the request/response chain MAY decode the
received transfer coding(s) or apply additional transfer coding(s) to received transfer coding(s) or apply additional transfer coding(s) to
the message body, assuming that corresponding changes are made to the the message body, assuming that corresponding changes are made to the
Transfer-Encoding field-value. Additional information about the Transfer-Encoding field value. Additional information about the
encoding parameters can be provided by other header fields not encoding parameters can be provided by other header fields not
defined by this specification. defined by this specification.
Transfer-Encoding MAY be sent in a response to a HEAD request or in a Transfer-Encoding MAY be sent in a response to a HEAD request or in a
304 (Not Modified) response (Section 9.4.5 of [Semantics]) to a GET 304 (Not Modified) response (Section 9.4.5 of [Semantics]) to a GET
request, neither of which includes a message body, to indicate that request, neither of which includes a message body, to indicate that
the origin server would have applied a transfer coding to the message the origin server would have applied a transfer coding to the message
body if the request had been an unconditional GET. This indication body if the request had been an unconditional GET. This indication
is not required, however, because any recipient on the response chain is not required, however, because any recipient on the response chain
(including the origin server) can remove transfer codings when they (including the origin server) can remove transfer codings when they
skipping to change at page 18, line 51 skipping to change at page 18, line 51
request indicates HTTP/1.1 (or later). request indicates HTTP/1.1 (or later).
A server that receives a request message with a transfer coding it A server that receives a request message with a transfer coding it
does not understand SHOULD respond with 501 (Not Implemented). does not understand SHOULD respond with 501 (Not Implemented).
6.2. Content-Length 6.2. Content-Length
When a message does not have a Transfer-Encoding header field, a When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body. For messages decimal number of octets, for a potential payload body. For messages
that do include a payload body, the Content-Length field-value that do include a payload body, the Content-Length field value
provides the framing information necessary for determining where the provides the framing information necessary for determining where the
body (and message) ends. For messages that do not include a payload body (and message) ends. For messages that do not include a payload
body, the Content-Length indicates the size of the selected body, the Content-Length indicates the size of the selected
representation (Section 6.2.4 of [Semantics]). representation (Section 6.2.4 of [Semantics]).
Note: HTTP's use of Content-Length for message framing differs Note: HTTP's use of Content-Length for message framing differs
significantly from the same field's use in MIME, where it is an significantly from the same field's use in MIME, where it is an
optional field used only within the "message/external-body" media- optional field used only within the "message/external-body" media-
type. type.
skipping to change at page 20, line 7 skipping to change at page 20, line 7
If a message is received with both a Transfer-Encoding and a If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 11.2) or response splitting perform request smuggling (Section 11.2) or response splitting
(Section 11.1) and ought to be handled as an error. A sender (Section 11.1) and ought to be handled as an error. A sender
MUST remove the received Content-Length field prior to forwarding MUST remove the received Content-Length field prior to forwarding
such a message downstream. such a message downstream.
4. If a message is received without Transfer-Encoding and with 4. If a message is received without Transfer-Encoding and with
either multiple Content-Length header fields having differing either multiple Content-Length header fields having differing
field-values or a single Content-Length header field having an field values or a single Content-Length header field having an
invalid value, then the message framing is invalid and the invalid value, then the message framing is invalid and the
recipient MUST treat it as an unrecoverable error. If this is a recipient MUST treat it as an unrecoverable error. If this is a
request message, the server MUST respond with a 400 (Bad Request) request message, the server MUST respond with a 400 (Bad Request)
status code and then close the connection. If this is a response status code and then close the connection. If this is a response
message received by a proxy, the proxy MUST close the connection message received by a proxy, the proxy MUST close the connection
to the server, discard the received response, and send a 502 (Bad to the server, discard the received response, and send a 502 (Bad
Gateway) response to the client. If this is a response message Gateway) response to the client. If this is a response message
received by a user agent, the user agent MUST close the received by a user agent, the user agent MUST close the
connection to the server and discard the received response. connection to the server and discard the received response.
skipping to change at page 23, line 51 skipping to change at page 23, line 51
parts of a message, and generate an appropriate 4xx (Client Error) parts of a message, and generate an appropriate 4xx (Client Error)
response if that amount is exceeded. response if that amount is exceeded.
7.1.2. Chunked Trailer Section 7.1.2. Chunked Trailer Section
A trailer section allows the sender to include additional fields at A trailer section allows the sender to include additional fields at
the end of a chunked message in order to supply metadata that might the end of a chunked message in order to supply metadata that might
be dynamically generated while the message body is sent, such as a be dynamically generated while the message body is sent, such as a
message integrity check, digital signature, or post-processing message integrity check, digital signature, or post-processing
status. The proper use and limitations of trailer fields are defined status. The proper use and limitations of trailer fields are defined
in Section 4.3 of [Semantics]. in Section 4.6 of [Semantics].
trailer-section = *( header-field CRLF ) trailer-section = *( field-line CRLF )
A recipient that decodes and removes the chunked encoding from a A recipient that decodes and removes the chunked encoding from a
message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST
discard any received trailer fields, store/forward them separately discard any received trailer fields, store/forward them separately
from the header fields, or selectively merge into the header section from the header fields, or selectively merge into the header section
only those trailer fields corresponding to header field definitions only those trailer fields corresponding to header field definitions
that are understood by the recipient to explicitly permit and define that are understood by the recipient to explicitly permit and define
how their corresponding trailer field value can be safely merged. how their corresponding trailer field value can be safely merged.
7.1.3. Decoding Chunked 7.1.3. Decoding Chunked
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
7.4. TE 7.4. TE
The "TE" header field in a request indicates what transfer codings, The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a whether or not the client is willing to accept trailer fields in a
chunked transfer coding. chunked transfer coding.
The TE field-value consists of a comma-separated list of transfer The TE field-value consists of a list of transfer coding names, each
coding names, each allowing for optional parameters (as described in allowing for optional parameters (as described in Section 7), and/or
Section 7), and/or the keyword "trailers". A client MUST NOT send the keyword "trailers". A client MUST NOT send the chunked transfer
the chunked transfer coding name in TE; chunked is always acceptable coding name in TE; chunked is always acceptable for HTTP/1.1
for HTTP/1.1 recipients. recipients.
TE = #t-codings TE = #t-codings
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
rank = ( "0" [ "." 0*3DIGIT ] ) rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
Three examples of TE use are below. Three examples of TE use are below.
TE: deflate TE: deflate
skipping to change at page 26, line 41 skipping to change at page 26, line 41
chunked response such that an intermediary can be assured of chunked response such that an intermediary can be assured of
buffering the entire response. buffering the entire response.
When multiple transfer codings are acceptable, the client MAY rank When multiple transfer codings are acceptable, the client MAY rank
the codings by preference using a case-insensitive "q" parameter the codings by preference using a case-insensitive "q" parameter
(similar to the qvalues used in content negotiation fields, (similar to the qvalues used in content negotiation fields,
Section 8.4.1 of [Semantics]). The rank value is a real number in Section 8.4.1 of [Semantics]). The rank value is a real number in
the range 0 through 1, where 0.001 is the least preferred and 1 is the range 0 through 1, where 0.001 is the least preferred and 1 is
the most preferred; a value of 0 means "not acceptable". the most preferred; a value of 0 means "not acceptable".
If the TE field-value is empty or if no TE field is present, the only If the TE field value is empty or if no TE field is present, the only
acceptable transfer coding is chunked. A message with no transfer acceptable transfer coding is chunked. A message with no transfer
coding is always acceptable. coding is always acceptable.
Since the TE header field only applies to the immediate connection, a Since the TE header field only applies to the immediate connection, a
sender of TE MUST also send a "TE" connection option within the sender of TE MUST also send a "TE" connection option within the
Connection header field (Section 9.1) in order to prevent the TE Connection header field (Section 9.1) in order to prevent the TE
field from being forwarded by intermediaries that do not support its field from being forwarded by intermediaries that do not support its
semantics. semantics.
8. Handling Incomplete Messages 8. Handling Incomplete Messages
skipping to change at page 27, line 42 skipping to change at page 27, line 42
9. Connection Management 9. Connection Management
HTTP messaging is independent of the underlying transport- or HTTP messaging is independent of the underlying transport- or
session-layer connection protocol(s). HTTP only presumes a reliable session-layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport response structures onto the data units of an underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
As described in Section 5.2 of [Semantics], the specific connection As described in Section 5.3 of [Semantics], the specific connection
protocols to be used for an HTTP interaction are determined by client protocols to be used for an HTTP interaction are determined by client
configuration and the target URI. For example, the "http" URI scheme configuration and the target URI. For example, the "http" URI scheme
(Section 2.5.1 of [Semantics]) indicates a default connection of TCP (Section 2.5.1 of [Semantics]) indicates a default connection of TCP
over IP, with a default TCP port of 80, but the client might be over IP, with a default TCP port of 80, but the client might be
configured to use a proxy via some other connection, port, or configured to use a proxy via some other connection, port, or
protocol. protocol.
HTTP implementations are expected to engage in connection management, HTTP implementations are expected to engage in connection management,
which includes maintaining the state of current connections, which includes maintaining the state of current connections,
establishing a new connection or reusing an existing connection, establishing a new connection or reusing an existing connection,
processing messages received on a connection, detecting connection processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable of concurrent connections, while controlling request queues to enable
fair use and detect denial-of-service attacks. fair use and detect denial-of-service attacks.
9.1. Connection 9.1. Connection
The "Connection" header field allows the sender to indicate desired The "Connection" header field allows the sender to list desired
control options for the current connection. In order to avoid control options for the current connection. In order to avoid
confusing downstream recipients, a proxy or gateway MUST remove or confusing downstream recipients, a proxy or gateway MUST remove or
replace any received connection options before forwarding the replace any received connection options before forwarding the
message. message.
When a header field aside from Connection is used to supply control When a field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list information for or about the current connection, the sender MUST list
the corresponding field-name within the Connection header field. A the corresponding field name within the Connection header field. A
proxy or gateway MUST parse a received Connection header field before proxy or gateway MUST parse a received Connection header field before
a message is forwarded and, for each connection-option in this field, a message is forwarded and, for each connection-option in this field,
remove any header field(s) from the message with the same name as the remove any header or trailer field(s) from the message with the same
connection-option, and then remove the Connection header field itself name as the connection-option, and then remove the Connection header
(or replace it with the intermediary's own connection options for the field itself (or replace it with the intermediary's own connection
forwarded message). options for the forwarded message).
Hence, the Connection header field provides a declarative way of Hence, the Connection header field provides a declarative way of
distinguishing header fields that are only intended for the immediate distinguishing fields that are only intended for the immediate
recipient ("hop-by-hop") from those fields that are intended for all recipient ("hop-by-hop") from those fields that are intended for all
recipients on the chain ("end-to-end"), enabling the message to be recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by to be deployed without fear that they will be blindly forwarded by
older intermediaries. older intermediaries.
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
Connection = 1#connection-option Connection = 1#connection-option
connection-option = token connection-option = token
Connection options are case-insensitive. Connection options are case-insensitive.
A sender MUST NOT send a connection option corresponding to a header A sender MUST NOT send a connection option corresponding to a field
field that is intended for all recipients of the payload. For that is intended for all recipients of the payload. For example,
example, Cache-Control is never appropriate as a connection option Cache-Control is never appropriate as a connection option
(Section 5.2 of [Caching]). (Section 5.2 of [Caching]).
The connection options do not always correspond to a header field The connection options do not always correspond to a field present in
present in the message, since a connection-specific header field the message, since a connection-specific field might not be needed if
might not be needed if there are no parameters associated with a there are no parameters associated with a connection option. In
connection option. In contrast, a connection-specific header field contrast, a connection-specific field that is received without a
that is received without a corresponding connection option usually corresponding connection option usually indicates that the field has
indicates that the field has been improperly forwarded by an been improperly forwarded by an intermediary and ought to be ignored
intermediary and ought to be ignored by the recipient. by the recipient.
When defining new connection options, specification authors ought to When defining new connection options, specification authors ought to
survey existing header field names and ensure that the new connection document it as reserved field name and register that definition in
option does not share the same name as an already deployed header the Hypertext Transfer Protocol (HTTP) Field Name Registry
field. Defining a new connection option essentially reserves that (Section 4.3.2 of [Semantics]), to avoid collisions.
potential field-name for carrying additional information related to
the connection option, since it would be unwise for senders to use
that field-name for anything else.
The "close" connection option is defined for a sender to signal that The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For this connection will be closed after completion of the response. For
example, example,
Connection: close Connection: close
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the sender is going to close the connection after the current the sender is going to close the connection after the current
request/response is complete (Section 9.7). request/response is complete (Section 9.7).
skipping to change at page 42, line 38 skipping to change at page 42, line 28
to reduce the effectiveness of request smuggling. to reduce the effectiveness of request smuggling.
11.3. Message Integrity 11.3. Message Integrity
HTTP does not define a specific mechanism for ensuring message HTTP does not define a specific mechanism for ensuring message
integrity, instead relying on the error-detection ability of integrity, instead relying on the error-detection ability of
underlying transport protocols and the use of length or chunk- underlying transport protocols and the use of length or chunk-
delimited framing to detect completeness. Additional integrity delimited framing to detect completeness. Additional integrity
mechanisms, such as hash functions or digital signatures applied to mechanisms, such as hash functions or digital signatures applied to
the content, can be selectively added to messages via extensible the content, can be selectively added to messages via extensible
metadata header fields. Historically, the lack of a single integrity metadata fields. Historically, the lack of a single integrity
mechanism has been justified by the informal nature of most HTTP mechanism has been justified by the informal nature of most HTTP
communication. However, the prevalence of HTTP as an information communication. However, the prevalence of HTTP as an information
access mechanism has resulted in its increasing use within access mechanism has resulted in its increasing use within
environments where verification of message integrity is crucial. environments where verification of message integrity is crucial.
User agents are encouraged to implement configurable means for User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those detecting and reporting failures of message integrity such that those
means can be enabled within environments for which integrity is means can be enabled within environments for which integrity is
necessary. For example, a browser being used to view medical history necessary. For example, a browser being used to view medical history
or drug interaction information needs to indicate to the user when or drug interaction information needs to indicate to the user when
skipping to change at page 43, line 26 skipping to change at page 43, line 17
The "https" scheme can be used to identify resources that require a The "https" scheme can be used to identify resources that require a
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. Field Name Registration
Please update the "Hypertext Transfer Protocol (HTTP) Header Field Please update the "Hypertext Transfer Protocol (HTTP) Field Name
Registry" registry at <https://www.iana.org/assignments/http-headers> Registry" at <https://www.iana.org/assignments/http-fields> with the
with the header field names listed in the two tables of Section 5. field names listed in the two tables of 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 44, line 5 skipping to change at page 43, line 44
registration procedure of Section 7.3 and the content coding names registration procedure of Section 7.3 and the content coding names
summarized in the table of Section 7. summarized in the table of Section 7.
12.4. Upgrade Token Registration 12.4. Upgrade Token Registration
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.9.2 and the upgrade with the registration procedure of Section 9.9.2 and the upgrade
token names summarized in the table of Section 9.9.1. token names summarized in the table of Section 9.9.1.
12.5. ALPN Protocol ID Registration
Please update the "TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs" registry at <https://www.iana.org/assignments/tls-
extensiontype-values/tls-extensiontype-values.xhtml> with the
registration below:
+----------+--------------------------------------+-----------------+
| Protocol | Identification Sequence | Reference |
+----------+--------------------------------------+-----------------+
| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e | (this |
| | 0x31 ("http/1.1") | specification) |
+----------+--------------------------------------+-----------------+
13. References 13. References
13.1. Normative References 13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-06 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-07 (work in
progress), November 2019. progress), March 2020.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 44, line 46 skipping to change at page 45, line 5
[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", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-06 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-07
(work in progress), November 2019. (work in progress), March 2020.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
13.2. Informative References 13.2. Informative References
skipping to change at page 47, line 8 skipping to change at page 47, line 8
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 12 of [Semantics]. Section 4.5 of [Semantics].
BWS = <BWS, see [Semantics], Section 4.3> BWS = <BWS, see [Semantics], Section 1.2.1>
Connection = [ connection-option ] *( OWS "," OWS [ connection-option Connection = [ connection-option ] *( OWS "," OWS [ connection-option
] ) ] )
HTTP-message = start-line CRLF *( header-field CRLF ) CRLF [ HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [
message-body ] message-body ]
HTTP-name = %x48.54.54.50 ; HTTP HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
OWS = <OWS, see [Semantics], Section 4.3> OWS = <OWS, see [Semantics], Section 1.2.1>
RWS = <RWS, see [Semantics], Section 4.3> RWS = <RWS, see [Semantics], Section 1.2.1>
TE = [ t-codings ] *( OWS "," OWS [ t-codings ] ) TE = [ t-codings ] *( OWS "," OWS [ t-codings ] )
Transfer-Encoding = [ transfer-coding ] *( OWS "," OWS [ Transfer-Encoding = [ transfer-coding ] *( OWS "," OWS [
transfer-coding ] ) transfer-coding ] )
Upgrade = [ protocol ] *( OWS "," OWS [ protocol ] ) Upgrade = [ protocol ] *( OWS "," OWS [ protocol ] )
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = <absolute-path, see [Semantics], Section 2.4> absolute-path = <absolute-path, see [Semantics], Section 2.4>
skipping to change at page 47, line 45 skipping to change at page 47, line 45
authority-form = authority authority-form = authority
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET chunk-data = 1*OCTET
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val
] ) ] )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token / quoted-string chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-section CRLF chunked-body = *chunk last-chunk trailer-section CRLF
comment = <comment, see [Semantics], Section 4.2.3> comment = <comment, see [Semantics], Section 4.4.1.3>
connection-option = token connection-option = token
field-name = <field-name, see [Semantics], Section 4.2> field-line = field-name ":" OWS field-value OWS
field-value = <field-value, see [Semantics], Section 4.2> field-name = <field-name, see [Semantics], Section 4.3>
field-value = <field-value, see [Semantics], Section 4.4>
header-field = field-name ":" OWS field-value OWS
last-chunk = 1*"0" [ chunk-ext ] CRLF last-chunk = 1*"0" [ chunk-ext ] CRLF
message-body = *OCTET message-body = *OCTET
method = token method = token
obs-fold = OWS CRLF RWS obs-fold = OWS CRLF RWS
obs-text = <obs-text, see [Semantics], Section 4.2.3> obs-text = <obs-text, see [Semantics], Section 4.4.1.2>
origin-form = absolute-path [ "?" query ] origin-form = absolute-path [ "?" query ]
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
protocol = protocol-name [ "/" protocol-version ] protocol = protocol-name [ "/" protocol-version ]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3> quoted-string = <quoted-string, see [Semantics], Section 4.4.1.2>
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
request-line = method SP request-target SP HTTP-version request-line = method SP request-target SP HTTP-version
request-target = origin-form / absolute-form / authority-form / request-target = origin-form / absolute-form / authority-form /
asterisk-form asterisk-form
start-line = request-line / status-line start-line = request-line / status-line
status-code = 3DIGIT status-code = 3DIGIT
status-line = HTTP-version SP status-code SP [ reason-phrase ] status-line = HTTP-version SP status-code SP [ reason-phrase ]
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.4.1.1>
trailer-section = *( header-field CRLF ) trailer-section = *( field-line CRLF )
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = 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 fields. However, RFC
However, RFC 2045 is focused only on email; applications of HTTP have 2045 is focused only on email; applications of HTTP have many
many characteristics that differ from email; hence, HTTP has features characteristics that differ from email; hence, HTTP has features that
that differ from MIME. These differences were carefully chosen to differ from MIME. These differences were carefully chosen to
optimize performance over binary connections, to allow greater optimize performance over binary connections, to allow greater
freedom in the use of new media types, to make date comparisons freedom in the use of new media types, to make date comparisons
easier, and to acknowledge the practice of some early HTTP servers easier, and to acknowledge the practice of some early HTTP servers
and clients. and clients.
This appendix describes specific areas where HTTP differs from MIME. This appendix describes specific areas where HTTP differs from MIME.
Proxies and gateways to and from strict MIME environments need to be Proxies and gateways to and from strict MIME environments need to be
aware of these differences and provide the appropriate conversions aware of these differences and provide the appropriate conversions
where necessary. where necessary.
skipping to change at page 51, line 40 skipping to change at page 51, line 40
properly encode the request-target. properly encode the request-target.
C.1. Changes from HTTP/1.0 C.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
C.1.1. Multihomed Web Servers C.1.1. Multihomed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 5.4 of [Semantics]), report an error if it is missing field (Section 5.6 of [Semantics]), report an error if it is missing
from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are
among the most important changes defined by HTTP/1.1. among the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
introduced during the development of HTTP/1.1 and, though it was introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional quickly implemented by most HTTP/1.0 browsers, additional
requirements were placed on all HTTP/1.1 requests in order to ensure requirements were placed on all HTTP/1.1 requests in order to ensure
skipping to change at page 53, line 5 skipping to change at page 53, line 5
message over a MIME-compliant protocol. message over a MIME-compliant protocol.
C.2. Changes from RFC 7230 C.2. Changes from RFC 7230
Most of the sections introducing HTTP's design goals, history, Most of the sections introducing HTTP's design goals, history,
architecture, conformance criteria, protocol versioning, URIs, architecture, conformance criteria, protocol versioning, URIs,
message routing, and header fields have been moved to [Semantics]. message routing, and header fields have been moved to [Semantics].
This document has been reduced to just the messaging syntax and This document has been reduced to just the messaging syntax and
connection management requirements specific to HTTP/1.1. connection management requirements specific to HTTP/1.1.
In the ABNF for chunked extensions, re-introduced (bad) whitespace
around ";" and "=". Whitespace was removed in [RFC7230], but that
change was found to break existing implementations (see [Err4667]).
(Section 7.1.1)
Trailer field semantics now transcend the specifics of chunked Trailer field semantics now transcend the specifics of chunked
encoding. The decoding algorithm for chunked (Section 7.1.3) has encoding. The decoding algorithm for chunked (Section 7.1.3) has
been updated to encourage storage/forwarding of trailer fields been updated to encourage storage/forwarding of trailer fields
separately from the header section, to only allow merging into the separately from the header section, to only allow merging into the
header section if the recipient knows the corresponding field header section if the recipient knows the corresponding field
definition permits and defines how to merge, and otherwise to discard definition permits and defines how to merge, and otherwise to discard
the trailer fields instead of merging. The trailer part is now the trailer fields instead of merging. The trailer part is now
called the trailer section to be more consistent with the header called the trailer section to be more consistent with the header
section and more distinct from a body part (Section 7.1.2). section and more distinct from a body part. (Section 7.1.2)
In the ABNF for chunked extensions, re-introduced (bad) whitespace
around ";" and "=" (Section 7.1.1). Whitespace was removed in
[RFC7230], but that change was found to break existing
implementations (see [Err4667]).
Disallowed transfer coding parameters called "q" in order to avoid Disallowed transfer coding parameters called "q" in order to avoid
conflicts with the use of ranks in the TE header field (Section 7.3). conflicts with the use of ranks in the TE header field.
(Section 7.3)
Appendix D. Change Log Appendix D. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
D.1. Between RFC7230 and draft 00 D.1. Between RFC7230 and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
skipping to change at page 56, line 17 skipping to change at page 56, line 17
o In Section 9.9, use 'websocket' instead of 'HTTP/2.0' in examples o In Section 9.9, use 'websocket' instead of 'HTTP/2.0' in examples
(<https://github.com/httpwg/http-core/issues/112>) (<https://github.com/httpwg/http-core/issues/112>)
o Move version non-specific text from Section 6 into semantics as o Move version non-specific text from Section 6 into semantics as
"payload body" (<https://github.com/httpwg/http-core/issues/159>) "payload body" (<https://github.com/httpwg/http-core/issues/159>)
o In Section 9.8, add text from RFC 2818 o In Section 9.8, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
D.8. Since draft-ietf-httpbis-messaging-06
o In Section 12.5, update the APLN protocol id for HTTP/1.1
(<https://github.com/httpwg/http-core/issues/49>)
o In Section 5, align with updates to field terminology in semantics
(<https://github.com/httpwg/http-core/issues/111>)
o In Section 9.1, clarify that new connection options indeed need to
be registered (<https://github.com/httpwg/http-core/issues/285>)
o In Section 1.1, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>)
Index Index
A A
absolute-form (of request-target) 11 absolute-form (of request-target) 11
application/http Media Type 40 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, 33 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 50
chunked (Coding Format) 17, 19 chunked (Coding Format) 17, 19
chunked (transfer coding) 22 chunked (transfer coding) 22
close 28, 33 close 28, 33
compress (transfer coding) 24 compress (transfer coding) 24
D D
deflate (transfer coding) 24 deflate (transfer coding) 24
E E
effective request URI 12 effective request URI 12
F
Fields
Connection 28
MIME-Version 49
TE 25
Transfer-Encoding 17
Upgrade 35
G G
Grammar Grammar
absolute-form 10-11 absolute-form 10-11
ALPHA 5 ALPHA 5
asterisk-form 10-11 asterisk-form 10-11
authority-form 10-11 authority-form 10-11
chunk 22 chunk 22
chunk-data 22 chunk-data 22
chunk-ext 22-23 chunk-ext 22-23
chunk-ext-name 23 chunk-ext-name 23
chunk-ext-val 23 chunk-ext-val 23
chunk-size 22 chunk-size 22
chunked-body 22 chunked-body 22
Connection 28 Connection 28
connection-option 28 connection-option 28
CR 5 CR 5
CRLF 5 CRLF 5
CTL 5 CTL 5
DIGIT 5 DIGIT 5
DQUOTE 5 DQUOTE 5
field-line 14, 24
field-name 14 field-name 14
field-value 14 field-value 14
header-field 14, 24
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
HTTP-message 6 HTTP-message 6
HTTP-name 8 HTTP-name 8
HTTP-version 8 HTTP-version 8
last-chunk 22 last-chunk 22
LF 5 LF 5
message-body 16 message-body 16
method 9 method 9
obs-fold 16 obs-fold 16
skipping to change at page 57, line 46 skipping to change at page 58, line 19
TE 26 TE 26
trailer-section 22, 24 trailer-section 22, 24
transfer-coding 21 transfer-coding 21
Transfer-Encoding 17 Transfer-Encoding 17
transfer-parameter 21 transfer-parameter 21
Upgrade 35 Upgrade 35
VCHAR 5 VCHAR 5
gzip (transfer coding) 24 gzip (transfer coding) 24
H H
header field 6 Header Fields
Connection 28
MIME-Version 49
TE 25
Transfer-Encoding 17
Upgrade 35
header line 6
header section 6 header section 6
headers 6 headers 6
M M
MIME-Version header field 49 MIME-Version header field 49
Media Type Media Type
application/http 40 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 10 request-target 10
 End of changes. 86 change blocks. 
142 lines changed or deleted 189 lines changed or added

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