draft-ietf-httpbis-messaging-05.txt   draft-ietf-httpbis-messaging-06.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: January 9, 2020 J. Reschke, Ed. Expires: May 7, 2020 J. Reschke, Ed.
greenbytes greenbytes
July 8, 2019 November 4, 2019
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-05 draft-ietf-httpbis-messaging-06
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.6. The changes in this draft are summarized in Appendix D.7.
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7
2.3. Message Parsing . . . . . . . . . . . . . . . . . . . . . 8 2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8
3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11
3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12 3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Header Field Syntax . . . . . . . . . . . . . . . . . . . . . 14
5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15 5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19 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 Part . . . . . . . . . . . . . . . . 24 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 23
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . 26 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 27
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32 9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33 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. TLS Connection Closure . . . . . . . . . . . . . . . . . 34
9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37 9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38 9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37
9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38
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 . . . . . . . . . . . . . . 40
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 . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12.1. Header Field Registration . . . . . . . . . . . . . . . 43 12.1. Header Field Registration . . . . . . . . . . . . . . . 43
skipping to change at page 4, line 21 skipping to change at page 4, line 23
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
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 51 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 51
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 52 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 52
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 . . . . . . . . . . 54 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
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 55
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 22 skipping to change at page 5, line 25
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 11 of [Semantics], It also uses a list extension, defined in Section 12 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 4.3> BWS = <BWS, see [Semantics], Section 11.1>
OWS = <OWS, see [Semantics], Section 4.3> OWS = <OWS, see [Semantics], Section 11.1>
RWS = <RWS, see [Semantics], Section 4.3> RWS = <RWS, see [Semantics], Section 11.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> comment = <comment, see [Semantics], Section 4.2.3.3>
field-name = <field-name, see [Semantics], Section 4.2> field-name = <field-name, see [Semantics], Section 4.1>
field-value = <field-value, see [Semantics], Section 4.2> field-value = <field-value, see [Semantics], Section 4.2>
obs-text = <obs-text, see [Semantics], Section 4.2.3> obs-text = <obs-text, see [Semantics], Section 4.2.3.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> quoted-string = <quoted-string, see [Semantics], Section 4.2.3.2>
token = <token, see [Semantics], Section 4.2.3> token = <token, see [Semantics], Section 4.2.3.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
All HTTP/1.1 messages consist of a start-line followed by a sequence An HTTP/1.1 message consists of a start-line followed by a CRLF and a
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 fields (collectively referred to as
the "headers" or the "header section"), an empty line indicating the the "headers" or the "header section"), an empty line indicating the
end of the header section, and an optional message body. end of the header section, and an optional message body.
HTTP-message = start-line HTTP-message = start-line CRLF
*( header-field CRLF ) *( header-field CRLF )
CRLF CRLF
[ message-body ] [ message-body ]
An HTTP message can be either a request from client to server or a A message can be either a request from client to server or a response
response from server to client. Syntactically, the two types of from server to client. Syntactically, the two types of message
message differ only in the start-line, which is either a request-line differ only in the start-line, which is either a request-line (for
(for requests) or a status-line (for responses), and in the algorithm requests) or a status-line (for responses), and in the algorithm for
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
In theory, a client could receive requests and a server could receive In theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats. responses, distinguishing them by their different start-line formats.
In practice, servers are implemented to only expect a request (a In practice, servers are implemented to only expect a request (a
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. HTTP Version 2.2. Message Parsing
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1".
Section 3.5 of [Semantics] specifies the semantics of HTTP version
numbers.
The version of an HTTP/1.x message is indicated by an HTTP-version
field in the start-line. HTTP-version is case-sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %s"HTTP"
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
constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1.
Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they are not allowed to
blindly forward the start-line without ensuring that the protocol
version in that message matches a version to which that intermediary
is conformant for both the receiving and sending of messages.
Forwarding an HTTP message without rewriting the HTTP-version might
result in communication errors when downstream recipients use the
message sender's version to determine what features are safe to use
for later communication with that sender.
A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it
is known or suspected that the client incorrectly implements the HTTP
specification and is incapable of correctly processing later version
responses, such as when a client fails to parse the version number
correctly or when an intermediary is known to blindly forward the
HTTP-version even when it doesn't conform to the given minor version
of the protocol. Such protocol downgrades SHOULD NOT be performed
unless triggered by specific client attributes, such as when one or
more of the request header fields (e.g., User-Agent) uniquely match
the values sent by a client known to be in error.
2.3. 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 into a hash table
by field name until the empty line, and then use the parsed data to by field name until the empty line, and then use the parsed data to
determine if a message body is expected. If a message body has been determine if a message body is expected. If a message body has been
indicated, then it is read as a stream until an amount of octets indicated, then it is read as a stream until an amount of octets
equal to the message body length is read or the connection is closed. 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
skipping to change at page 9, line 14 skipping to change at page 8, line 14
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.
2.3. HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1".
Section 3.5 of [Semantics] specifies the semantics of HTTP version
numbers.
The version of an HTTP/1.x message is indicated by an HTTP-version
field in the start-line. HTTP-version is case-sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %s"HTTP"
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
constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1.
Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they are not allowed to
blindly forward the start-line without ensuring that the protocol
version in that message matches a version to which that intermediary
is conformant for both the receiving and sending of messages.
Forwarding an HTTP message without rewriting the HTTP-version might
result in communication errors when downstream recipients use the
message sender's version to determine what features are safe to use
for later communication with that sender.
A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it
is known or suspected that the client incorrectly implements the HTTP
specification and is incapable of correctly processing later version
responses, such as when a client fails to parse the version number
correctly or when an intermediary is known to blindly forward the
HTTP-version even when it doesn't conform to the given minor version
of the protocol. Such protocol downgrades SHOULD NOT be performed
unless triggered by specific client attributes, such as when one or
more of the request header fields (e.g., User-Agent) uniquely match
the values sent by a client known to be in error.
3. Request Line 3. Request Line
A request-line begins with a method token, followed by a single space A request-line begins with a method token, followed by a single space
(SP), the request-target, another single space (SP), the protocol (SP), the request-target, another single space (SP), and ends with
version, and ends with CRLF. the protocol version.
request-line = method SP request-target SP HTTP-version CRLF request-line = method SP request-target SP HTTP-version
Although the request-line grammar rule requires that each of the Although the request-line grammar rule requires that each of the
component elements be separated by a single SP octet, recipients MAY component elements be separated by a single SP octet, recipients MAY
instead parse on whitespace-delimited word boundaries and, aside from instead parse on whitespace-delimited word boundaries and, aside from
the CRLF terminator, treat any form of whitespace as the SP separator the CRLF terminator, treat any form of whitespace as the SP separator
while ignoring preceding or trailing whitespace; such whitespace while ignoring preceding or trailing whitespace; such whitespace
includes one or more of the following octets: SP, HTAB, VT (%x0B), FF includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
(%x0C), or bare CR. However, lenient parsing can result in request (%x0C), or bare CR. However, lenient parsing can result in request
smuggling security vulnerabilities if there are multiple recipients smuggling security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of of the message and each has its own unique interpretation of
skipping to change at page 14, line 9 skipping to change at page 13, line 47
Recipients of an HTTP/1.0 request that lacks a Host header field Recipients of an HTTP/1.0 request that lacks a Host header field
might need to use heuristics (e.g., examination of the URI path for might need to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to guess the something unique to a particular host) in order to guess the
effective request URI's authority component. effective request URI's authority component.
4. Status Line 4. Status Line
The first line of a response message is the status-line, consisting The first line of a response message is the status-line, consisting
of the protocol version, a space (SP), the status code, another of the protocol version, a space (SP), the status code, another
space, an OPTIONAL textual phrase describing the status code, and space, and ending with an OPTIONAL textual phrase describing the
ending with CRLF. status code.
status-line = HTTP-version SP status-code SP [reason-phrase] CRLF status-line = HTTP-version SP status-code SP [reason-phrase]
Although the status-line grammar rule requires that each of the Although the status-line grammar rule requires that each of the
component elements be separated by a single SP octet, recipients MAY component elements be separated by a single SP octet, recipients MAY
instead parse on whitespace-delimited word boundaries and, aside from instead parse on whitespace-delimited word boundaries and, aside from
the line terminator, treat any form of whitespace as the SP separator the line terminator, treat any form of whitespace as the SP separator
while ignoring preceding or trailing whitespace; such whitespace while ignoring preceding or trailing whitespace; such whitespace
includes one or more of the following octets: SP, HTAB, VT (%x0B), FF includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
(%x0C), or bare CR. However, lenient parsing can result in response (%x0C), or bare CR. However, lenient parsing can result in response
splitting security vulnerabilities if there are multiple recipients splitting security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of of the message and each has its own unique interpretation of
skipping to change at page 15, line 5 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 Fields 5. Header Field Syntax
Each header field consists of a case-insensitive field name followed Each header field consists of a case-insensitive field name followed
by a colon (":"), optional leading whitespace, the field value, and by a colon (":"), optional leading whitespace, the field value, and
optional trailing whitespace. optional trailing whitespace.
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
skipping to change at page 15, line 27 skipping to change at page 15, line 16
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 | | Header 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.8 | | 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 |
skipping to change at page 17, line 10 skipping to change at page 16, line 47
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received obs- not within a message/http container MUST replace each received obs-
fold with one or more SP octets prior to interpreting the field fold with one or more SP octets prior to interpreting the field
value. value.
6. Message Body 6. Message Body
The message body (if any) of an HTTP message is used to carry the The message body (if any) of an HTTP message is used to carry the
payload body of that request or response. The message body is payload body (Section 6.3.3 of [Semantics]) of that request or
identical to the payload body unless a transfer coding has been response. The message body is identical to the payload body unless a
applied, as described in Section 6.1. transfer coding has been applied, as described in Section 6.1.
message-body = *OCTET message-body = *OCTET
The rules for when a message body is allowed in a message differ for The rules for determining when a message body is present in an
requests and responses. HTTP/1.1 message differ for requests and responses.
The presence of a message body in a request is signaled by a Content- The presence of a message body in a request is signaled by a Content-
Length or Transfer-Encoding header field. Request message framing is Length or Transfer-Encoding header field. Request message framing is
independent of method semantics, even if the method does not define independent of method semantics, even if the method does not define
any use for a message body. any use for a message body.
The presence of a message body in a response depends on both the The presence of a message body in a response depends on both the
request method to which it is responding and the response status code request method to which it is responding and the response status code
(Section 4). Responses to the HEAD request method (Section 7.3.2 of (Section 4), and corresponds to when a payload body is allowed; see
[Semantics]) never include a message body because the associated Section 6.3.3 of [Semantics].
response header fields (e.g., Transfer-Encoding, Content-Length,
etc.), if present, indicate only what their values would have been if
the request method had been GET (Section 7.3.1 of [Semantics]). 2xx
(Successful) responses to a CONNECT request method (Section 7.3.6 of
[Semantics]) switch to tunnel mode instead of having a message body.
All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
responses do not include a message body. All other responses do
include a message body, although the body might be of zero length.
6.1. Transfer-Encoding 6.1. Transfer-Encoding
The Transfer-Encoding header field lists the transfer coding names The Transfer-Encoding header field lists the transfer coding names
corresponding to the sequence of transfer codings that have been (or corresponding to the sequence of transfer codings that have been (or
will be) applied to the payload body in order to form the message will be) applied to the payload body in order to form the message
body. Transfer codings are defined in Section 7. body. Transfer codings are defined in Section 7.
Transfer-Encoding = 1#transfer-coding Transfer-Encoding = 1#transfer-coding
skipping to change at page 22, line 15 skipping to change at page 22, line 8
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 | | chunked | Transfer in a series of chunks | Section 7 |
| | | 7.1 | | | | .1 |
| compress | UNIX "compress" data format [Welch] | Section | | compress | UNIX "compress" data format [Welch] | Section 7 |
| | | 7.2 | | | | .2 |
| deflate | "deflate" compressed data ([RFC1951]) | Section | | deflate | "deflate" compressed data ([RFC1951]) | Section 7 |
| | inside the "zlib" data format | 7.2 | | | inside the "zlib" data format | .2 |
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section | | gzip | GZIP file format [RFC1952] | Section 7 |
| | | 7.2 | | | | .2 |
| trailers | (reserved) | Section 7 | | trailers | (reserved) | Section 7 |
| x-compress | Deprecated (alias for compress) | Section | | x-compress | Deprecated (alias for compress) | Section 7 |
| | | 7.2 | | | | .2 |
| x-gzip | Deprecated (alias for gzip) | Section | | x-gzip | Deprecated (alias for gzip) | Section 7 |
| | | 7.2 | | | | .2 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 2 Table 2
Note: the coding name "trailers" is reserved because it would Note: the coding name "trailers" is reserved because its use would
clash with the use of the keyword "trailers" in the TE header conflict with the keyword "trailers" in the TE header field
field (Section 7.4). (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,
followed by an OPTIONAL trailer containing header fields. Chunked followed by an OPTIONAL trailer section containing trailer fields.
enables content streams of unknown size to be transferred as a Chunked enables content streams of unknown size to be transferred as
sequence of length-delimited buffers, which enables the sender to a sequence of length-delimited buffers, which enables the sender to
retain connection persistence and the recipient to know when it has retain connection persistence and the recipient to know when it has
received the entire message. received the entire message.
chunked-body = *chunk chunked-body = *chunk
last-chunk last-chunk
trailer-part trailer-section
CRLF CRLF
chunk = chunk-size [ chunk-ext ] CRLF chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF chunk-data CRLF
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
last-chunk = 1*("0") [ chunk-ext ] CRLF last-chunk = 1*("0") [ chunk-ext ] CRLF
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 section, and finally terminated by an empty line.
A recipient MUST be able to parse and decode the chunked transfer A recipient MUST be able to parse and decode the chunked transfer
coding. coding.
The chunked encoding does not define any parameters. Their presence The chunked encoding does not define any parameters. Their presence
SHOULD be treated as an error. SHOULD be treated as an error.
7.1.1. Chunk Extensions 7.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
skipping to change at page 24, line 7 skipping to change at page 23, line 44
server can have shared expectations regarding the use of chunk server can have shared expectations regarding the use of chunk
extensions) or for padding within an end-to-end secured connection. extensions) or for padding within an end-to-end secured connection.
A recipient MUST ignore unrecognized chunk extensions. A server A recipient MUST ignore unrecognized chunk extensions. A server
ought to limit the total length of chunk extensions received in a ought to limit the total length of chunk extensions received in a
request to an amount reasonable for the services provided, in the request to an amount reasonable for the services provided, in the
same way that it applies length limitations and timeouts for other same way that it applies length limitations and timeouts for other
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 Part 7.1.2. Chunked Trailer Section
A trailer allows the sender to include additional fields at the end A trailer section allows the sender to include additional fields at
of a chunked message in order to supply metadata that might be the end of a chunked message in order to supply metadata that might
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 trailer fields are identical to header fields, except status. The proper use and limitations of trailer fields are defined
they are sent in a chunked trailer instead of the message's header in Section 4.3 of [Semantics].
section.
trailer-part = *( header-field CRLF )
A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., Transfer-Encoding and Content-Length),
routing (e.g., Host), request modifiers (e.g., controls and
conditionals in Section 8 of [Semantics]), authentication (e.g., see
Section 8.5 of [Semantics] and [RFC6265]), response control data
(e.g., see Section 10.1 of [Semantics]), or determining how to
process the payload (e.g., Content-Encoding, Content-Type, Content-
Range, and Trailer).
When a chunked message containing a non-empty trailer is received,
the recipient MAY process the fields (aside from those forbidden
above) as if they were appended to the message's header section. A
recipient MUST ignore (or consider as an error) any fields that are
forbidden to be sent in a trailer, since processing them as if they
were present in the header section might bypass external security
filters.
Unless the request includes a TE header field indicating "trailers" trailer-section = *( header-field CRLF )
is acceptable, as described in Section 7.4, a server SHOULD NOT
generate trailer fields that it believes are necessary for the user
agent to receive. Without a TE containing "trailers", the server
ought to assume that the trailer fields might be silently discarded
along the path to the user agent. This requirement allows
intermediaries to forward a de-chunked message to an HTTP/1.0
recipient without buffering the entire response.
When a message includes a message body encoded with the chunked A recipient that decodes and removes the chunked encoding from a
transfer coding and the sender desires to send metadata in the form message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST
of trailer fields at the end of the message, the sender SHOULD discard any received trailer fields, store/forward them separately
generate a Trailer header field before the message body to indicate from the header fields, or selectively merge into the header section
which fields will be present in the trailers. This allows the only those trailer fields corresponding to header field definitions
recipient to prepare for receipt of that metadata before it starts that are understood by the recipient to explicitly permit and define
processing the body, which is useful if the message is being streamed how their corresponding trailer field value can be safely merged.
and the recipient wishes to confirm an integrity check on the fly.
7.1.3. Decoding Chunked 7.1.3. Decoding Chunked
A process for decoding the chunked transfer coding can be represented A process for decoding the chunked transfer coding can be represented
in pseudo-code as: in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-ext (if any), and CRLF read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) { while (chunk-size > 0) {
read chunk-data and CRLF read chunk-data and CRLF
append chunk-data to decoded-body append chunk-data to decoded-body
length := length + chunk-size length := length + chunk-size
read chunk-size, chunk-ext (if any), and CRLF read chunk-size, chunk-ext (if any), and CRLF
} }
read trailer field read trailer field
while (trailer field is not empty) { while (trailer field is not empty) {
if (trailer field is allowed to be sent in a trailer) { if (trailer fields are stored/forwarded separately) {
append trailer field to existing header fields append trailer field to existing trailer fields
} }
read trailer-field else if (trailer field is understood and defined as mergeable) {
merge trailer field with existing header fields
}
else {
discard trailer field
}
read trailer field
} }
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields Remove Trailer from existing header fields
7.2. Transfer Codings for Compression 7.2. Transfer Codings for Compression
The following transfer coding names for compression are defined by The following transfer coding names for compression are defined by
the same algorithm as their corresponding content coding: the same algorithm as their corresponding content coding:
skipping to change at page 31, line 5 skipping to change at page 30, line 12
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 If an HTTP/1.1 client receives data on a connection that doesn't have
any outstanding requests, it MUST NOT consider them to be a response any outstanding requests, it MUST NOT consider them to be a response
to a not-yet-issued request; it SHOULD close the connection, since to a not-yet-issued request; it SHOULD close the connection, since
message delimitation is now ambiguous, unless the data consists only message delimitation is now ambiguous, unless the data consists only
of one or more CRLF (which can be discarded, as per Section 2.3). of one or more CRLF (which can be discarded, as per Section 2.2).
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
skipping to change at page 32, line 12 skipping to change at page 31, line 17
discussion of the problems with the Keep-Alive header field discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
See Appendix C.1.2 for more information on backwards compatibility See Appendix C.1.2 for more information on backwards compatibility
with HTTP/1.0 clients. with HTTP/1.0 clients.
9.4.1. Retrying Requests 9.4.1. Retrying Requests
Connections can be closed at any time, with or without intention. Connections can be closed at any time, with or without intention.
Implementations ought to anticipate the need to recover from Implementations ought to anticipate the need to recover from
asynchronous close events. asynchronous close events. The conditions under which a client can
automatically retry a sequence of outstanding requests are defined in
When an inbound connection is closed prematurely, a client MAY open a Section 7.2.2 of [Semantics].
new connection and automatically retransmit an aborted sequence of
requests if all of those requests have idempotent methods
(Section 7.2.2 of [Semantics]).
9.4.2. Pipelining 9.4.2. Pipelining
A client that supports persistent connections MAY "pipeline" its A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 7.2.1 of parallel if they all have safe methods (Section 7.2.1 of
[Semantics]), but it MUST send the corresponding responses in the [Semantics]), but it MUST send the corresponding responses in the
same order that the requests were received. same order that the requests were received.
skipping to change at page 35, line 20 skipping to change at page 34, line 23
the write side of the read/write connection. The server then the write side of the read/write connection. The server then
continues to read from the connection until it receives a continues to read from the connection until it receives a
corresponding close by the client, or until the server is reasonably corresponding close by the client, or until the server is reasonably
certain that its own TCP stack has received the client's certain that its own TCP stack has received the client's
acknowledgement of the packet(s) containing the server's last acknowledgement of the packet(s) containing the server's last
response. Finally, the server fully closes the connection. response. Finally, the server fully closes the connection.
It is unknown whether the reset problem is exclusive to TCP or might It is unknown whether the reset problem is exclusive to TCP or might
also be found in other transport connection protocols. also be found in other transport connection protocols.
9.8. Upgrade 9.8. TLS Connection Closure
TLS provides a facility for secure connection closure. When a valid
closure alert is received, an implementation can be assured that no
further data will be received on that connection. TLS
implementations MUST initiate an exchange of closure alerts before
closing a connection. A TLS implementation MAY, after sending a
closure alert, close the connection without waiting for the peer to
send its closure alert, generating an "incomplete close". Note that
an implementation which does this MAY choose to reuse the session.
This SHOULD only be done when the application knows (typically
through detecting HTTP message boundaries) that it has received all
the message data that it cares about.
As specified in [RFC8446], any implementation which receives a
connection close without first receiving a valid closure alert (a
"premature close") MUST NOT reuse that session. Note that a
premature close does not call into question the security of the data
already received, but simply indicates that subsequent data might
have been truncated. Because TLS is oblivious to HTTP request/
response boundaries, it is necessary to examine the HTTP data itself
(specifically the Content-Length header) to determine whether the
truncation occurred inside a message or between messages.
When encountering a premature close, a client SHOULD treat as
completed all requests for which it has received as much data as
specified in the Content-Length header.
A client detecting an incomplete close SHOULD recover gracefully. It
MAY resume a TLS session closed in this fashion.
Clients MUST send a closure alert before closing the connection.
Clients which are unprepared to receive any more data MAY choose not
to wait for the server's closure alert and simply close the
connection, thus generating an incomplete close on the server side.
Servers SHOULD be prepared to receive an incomplete close from the
client, since the client can often determine when the end of server
data is. Servers SHOULD be willing to resume TLS sessions closed in
this fashion.
Servers MUST attempt to initiate an exchange of closure alerts with
the client before closing the connection. Servers MAY close the
connection after sending the closure alert, thus generating an
incomplete close on the client side.
9.9. Upgrade
The "Upgrade" header field is intended to provide a simple mechanism The "Upgrade" header field is intended to provide a simple mechanism
for transitioning from HTTP/1.1 to some other protocol on the same for transitioning from HTTP/1.1 to some other protocol on the same
connection. connection.
A client MAY send a list of protocol names in the Upgrade header A client MAY send a list of protocol names in the Upgrade header
field of a request to invite the server to switch to one or more of field of a request to invite the server to switch to one or more of
the named protocols, in order of descending preference, before the named protocols, in order of descending preference, before
sending the final response. A server MAY ignore a received Upgrade sending the final response. A server MAY ignore a received Upgrade
header field if it wishes to continue using the current protocol on header field if it wishes to continue using the current protocol on
skipping to change at page 36, line 18 skipping to change at page 36, line 19
Upgrade header field to indicate the acceptable protocols, in order Upgrade header field to indicate the acceptable protocols, in order
of descending preference. of descending preference.
A server MAY send an Upgrade header field in any other response to A server MAY send an Upgrade header field in any other response to
advertise that it implements support for upgrading to the listed advertise that it implements support for upgrading to the listed
protocols, in order of descending preference, when appropriate for a protocols, in order of descending preference, when appropriate for a
future request. future request.
The following is a hypothetical example sent by a client: The following is a hypothetical example sent by a client:
GET /hello.txt HTTP/1.1 GET /hello HTTP/1.1
Host: www.example.com Host: www.example.com
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade: websocket, IRC/6.9, RTA/x11
The capabilities and nature of the application-level communication The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101 protocol(s) chosen. However, immediately after sending the 101
(Switching Protocols) response, the server is expected to continue (Switching Protocols) response, the server is expected to continue
responding to the original request as if it had received its responding to the original request as if it had received its
equivalent within the new protocol (i.e., the server still has an equivalent within the new protocol (i.e., the server still has an
outstanding request to satisfy after the protocol has been changed, outstanding request to satisfy after the protocol has been changed,
and is expected to do so without requiring the request to be and is expected to do so without requiring the request to be
repeated). repeated).
skipping to change at page 37, line 7 skipping to change at page 37, line 7
to protocols with the same semantics as HTTP without the latency cost to protocols with the same semantics as HTTP without the latency cost
of an additional round trip. A server MUST NOT switch protocols of an additional round trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol. protocol; an OPTIONS request can be honored by any protocol.
The following is an example response to the above hypothetical The following is an example response to the above hypothetical
request: request:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0 Upgrade: websocket
[... data stream switches to HTTP/2.0 with an appropriate response [... data stream switches to websocket with an appropriate response
(as defined by new protocol) to the "GET /hello.txt" request ...] (as defined by new protocol) to the "GET /hello" request ...]
When Upgrade is sent, the sender MUST also send a Connection header When Upgrade is sent, the sender MUST also send a Connection header
field (Section 9.1) that contains an "upgrade" connection option, in field (Section 9.1) that contains an "upgrade" connection option, in
order to prevent Upgrade from being accidentally forwarded by order to prevent Upgrade from being accidentally forwarded by
intermediaries that might not implement the listed protocols. A intermediaries that might not implement the listed protocols. A
server MUST ignore an Upgrade header field that is received in an server MUST ignore an Upgrade header field that is received in an
HTTP/1.0 request. HTTP/1.0 request.
A client cannot begin using an upgraded protocol on the connection A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client until it has completely sent the request message (i.e., the client
skipping to change at page 37, line 34 skipping to change at page 37, line 34
server MUST send a 100 (Continue) response before sending a 101 server MUST send a 100 (Continue) response before sending a 101
(Switching Protocols) response. (Switching Protocols) response.
The Upgrade header field only applies to switching protocols on top The Upgrade header field only applies to switching protocols on top
of the existing connection; it cannot be used to switch the of the existing connection; it cannot be used to switch the
underlying connection (transport) protocol, nor to switch the underlying connection (transport) protocol, nor to switch the
existing communication to a different connection. For those existing communication to a different connection. For those
purposes, it is more appropriate to use a 3xx (Redirection) response purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 9.4 of [Semantics]). (Section 9.4 of [Semantics]).
9.8.1. Upgrade Protocol Names 9.9.1. Upgrade Protocol Names
This specification only defines the protocol name "HTTP" for use by This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 3.5 of [Semantics] and future updates to version rules of Section 3.5 of [Semantics] and future updates to
this specification. Additional protocol names ought to be registered this specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 9.8.2. using the registration procedure defined in Section 9.9.2.
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
| Name | Description | Expected Version | Reference | | Name | Description | Expected Version | Reference |
| | | Tokens | | | | | Tokens | |
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
| HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of | | HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of |
| | Transfer Protocol | (e.g, "2.0") | [Semantics] | | | Transfer Protocol | (e.g, "2.0") | [Semantics] |
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
9.8.2. Upgrade Token Registry 9.9.2. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at protocols in the Upgrade header field. The registry is maintained at
<https://www.iana.org/assignments/http-upgrade-tokens>. <https://www.iana.org/assignments/http-upgrade-tokens>.
Each registered protocol name is associated with contact information Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection and an optional set of specifications that details how the connection
will be processed after it has been upgraded. will be processed after it has been upgraded.
skipping to change at page 43, line 50 skipping to change at page 43, line 50
Please update the "HTTP Transfer Coding Registry" at Please update the "HTTP Transfer Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 7.3 and the content coding names registration procedure of Section 7.3 and the content coding names
summarized in the table 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.8.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.8.1. token names summarized in the table of Section 9.9.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-05 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-06 (work in
progress), July 2019. progress), November 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 46 skipping to change at page 44, line 46
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<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-05 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-06
(work in progress), July 2019. (work in progress), November 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 46, line 14 skipping to change at page 46, line 19
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML "MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<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 11 of [Semantics]. Section 12 of [Semantics].
BWS = <BWS, see [Semantics], Section 4.3> BWS = <BWS, see [Semantics], Section 4.3>
Connection = [ connection-option ] *( OWS "," OWS [ connection-option Connection = [ connection-option ] *( OWS "," OWS [ connection-option
] ) ] )
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body HTTP-message = start-line CRLF *( header-field CRLF ) CRLF [
] 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 4.3>
RWS = <RWS, see [Semantics], Section 4.3> RWS = <RWS, see [Semantics], Section 4.3>
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 ] )
skipping to change at page 47, line 44 skipping to change at page 47, line 44
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
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-part CRLF chunked-body = *chunk last-chunk trailer-section CRLF
comment = <comment, see [Semantics], Section 4.2.3> comment = <comment, see [Semantics], Section 4.2.3>
connection-option = token connection-option = token
field-name = <field-name, see [Semantics], Section 4.2> field-name = <field-name, see [Semantics], Section 4.2>
field-value = <field-value, see [Semantics], Section 4.2> field-value = <field-value, see [Semantics], Section 4.2>
header-field = field-name ":" OWS field-value OWS 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
skipping to change at page 48, line 23 skipping to change at page 48, line 23
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.2.3>
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 CRLF 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 ] CRLF 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.2.3>
trailer-part = *( header-field CRLF ) trailer-section = *( header-field 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
skipping to change at page 50, line 41 skipping to change at page 50, line 41
B.6. MHTML and Line Length Limitations B.6. MHTML and Line Length Limitations
HTTP implementations that share code with MHTML [RFC2557] HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type payload and, aside from the "multipart/byteranges" type
(Section 6.3.4 of [Semantics]), does not interpret the content or any (Section 6.3.5 of [Semantics]), does not interpret the content or any
MIME header lines that might be contained therein. MIME header lines that might be contained therein.
Appendix C. HTTP Version History Appendix C. HTTP Version History
HTTP has been in use since 1990. The first version, later referred HTTP has been in use since 1990. The first version, later referred
to as HTTP/0.9, was a simple protocol for hypertext data transfer to as HTTP/0.9, was a simple protocol for hypertext data transfer
across the Internet, using only a single request method (GET) and no across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics. transferred and modifiers placed on the request/response semantics.
skipping to change at page 52, line 49 skipping to change at page 52, line 49
C.1.3. Introduction of Transfer-Encoding C.1.3. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field (Section 6.1). HTTP/1.1 introduces the Transfer-Encoding header field (Section 6.1).
Transfer codings need to be decoded prior to forwarding an HTTP Transfer codings need to be decoded prior to forwarding an HTTP
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 field values have been moved to message routing, and header fields have been moved to [Semantics].
[Semantics]. This document has been reduced to just the messaging This document has been reduced to just the messaging syntax and
syntax and connection management requirements specific to HTTP/1.1. connection management requirements specific to HTTP/1.1.
Furthermore: Trailer field semantics now transcend the specifics of chunked
encoding. The decoding algorithm for chunked (Section 7.1.3) has
been updated to encourage storage/forwarding of trailer fields
separately from the header section, to only allow merging into the
header section if the recipient knows the corresponding field
definition permits and defines how to merge, and otherwise to discard
the trailer fields instead of merging. The trailer part is now
called the trailer section to be more consistent with the header
section and more distinct from a body part (Section 7.1.2).
In the ABNF for chunked extensions, re-introduce (bad) whitespace In the ABNF for chunked extensions, re-introduced (bad) whitespace
around ";" and "=". Whitespace was removed in [RFC7230], but later around ";" and "=" (Section 7.1.1). Whitespace was removed in
this change was found to break existing implementations (see [RFC7230], but that change was found to break existing
[Err4667]). (Section 7.1.1) implementations (see [Err4667]).
Disallow 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. conflicts with the use of ranks in the TE header field (Section 7.3).
(Section 7.3)
Appendix D. Change Log Appendix D. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
D.1. Between RFC7230 and draft 00 D.1. Between RFC7230 and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
skipping to change at page 55, line 20 skipping to change at page 55, line 28
o In Section 7, remove the predefined codings from the ABNF and make o In Section 7, remove the predefined codings from the ABNF and make
it generic instead (<https://github.com/httpwg/http-core/ it generic instead (<https://github.com/httpwg/http-core/
issues/66>) issues/66>)
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
D.6. Since draft-ietf-httpbis-messaging-04 D.6. Since draft-ietf-httpbis-messaging-04
o In Section 9.8, clarify that protocol-name is to be matched case- o In Section 9.9, clarify that protocol-name is to be matched case-
insensitively (<https://github.com/httpwg/http-core/issues/8>) insensitively (<https://github.com/httpwg/http-core/issues/8>)
o In Section 5.2, add leading optional whitespace to obs-fold ABNF o In Section 5.2, add leading optional whitespace to obs-fold ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o In Section 4, add clarifications about empty reason phrases o In Section 4, add clarifications about empty reason phrases
(<https://github.com/httpwg/http-core/issues/197>) (<https://github.com/httpwg/http-core/issues/197>)
o Move discussion of retries from Section 9.4.1 into [Semantics] o Move discussion of retries from Section 9.4.1 into [Semantics]
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
D.7. Since draft-ietf-httpbis-messaging-05
o In Section 7.1.2, the trailer part has been renamed the trailer
section (for consistency with the header section) and trailers are
no longer merged as header fields by default, but rather can be
discarded, kept separate from header fields, or merged with header
fields only if understood and defined as being mergeable
(<https://github.com/httpwg/http-core/issues/16>)
o In Section 2.1 and related Sections, move the trailing CRLF from
the line grammars into the message format
(<https://github.com/httpwg/http-core/issues/62>)
o Moved Section 2.3 down (<https://github.com/httpwg/http-core/
issues/68>)
o In Section 9.9, use 'websocket' instead of 'HTTP/2.0' in examples
(<https://github.com/httpwg/http-core/issues/112>)
o Move version non-specific text from Section 6 into semantics as
"payload body" (<https://github.com/httpwg/http-core/issues/159>)
o In Section 9.8, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>)
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 40
asterisk-form (of request-target) 12 asterisk-form (of request-target) 11
authority-form (of request-target) 11 authority-form (of request-target) 11
C C
Connection header field 29, 34 Connection header field 28, 33
Content-Length header field 19 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 29, 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 10-11 absolute-form 10-11
ALPHA 5 ALPHA 5
asterisk-form 10, 12 asterisk-form 10-11
authority-form 10-11 authority-form 10-11
chunk 23 chunk 22
chunk-data 23 chunk-data 22
chunk-ext 23 chunk-ext 22-23
chunk-ext-name 23 chunk-ext-name 23
chunk-ext-val 23 chunk-ext-val 23
chunk-size 23 chunk-size 22
chunked-body 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 15 field-name 14
field-value 15 field-value 14
header-field 15, 24 header-field 14, 24
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
HTTP-message 6 HTTP-message 6
HTTP-name 7 HTTP-name 8
HTTP-version 7 HTTP-version 8
last-chunk 23 last-chunk 22
LF 5 LF 5
message-body 17 message-body 16
method 9 method 9
obs-fold 16 obs-fold 16
OCTET 5 OCTET 5
origin-form 10 origin-form 10
rank 27 rank 26
reason-phrase 14 reason-phrase 14
request-line 9 request-line 9
request-target 10 request-target 10
SP 5 SP 5
start-line 6 start-line 6
status-code 14 status-code 14
status-line 14 status-line 13
t-codings 27 t-codings 26
t-ranking 27 t-ranking 26
TE 27 TE 26
trailer-part 23-24 trailer-section 22, 24
transfer-coding 21 transfer-coding 21
Transfer-Encoding 17 Transfer-Encoding 17
transfer-parameter 22 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 49
Media Type Media Type
application/http 40 application/http 40
skipping to change at page 57, line 33 skipping to change at page 58, line 17
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
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 35
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
San Jose, CA 95110 San Jose, CA 95110
USA United States of America
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
EMail: mnot@mnot.net EMail: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/ URI: https://greenbytes.de/tech/webdav/
 End of changes. 95 change blocks. 
265 lines changed or deleted 312 lines changed or added

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