draft-ietf-httpbis-messaging-05.txt   draft-ietf-httpbis-messaging-latest.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: April 20, 2020 J. Reschke, Ed.
greenbytes greenbytes
July 8, 2019 October 18, 2019
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-05 draft-ietf-httpbis-messaging-latest
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 April 20, 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 Fields . . . . . . . . . . . . . . . . . . . . . . . . 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 Part . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 25
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Associating a Response to a Request . . . . . . . . . . . 30 9.3. Associating a Response to a Request . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . 33
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37 9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37
9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38 9.8.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 . . . . . . . . . . . . . . . . . . . 40
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 41 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 42 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41
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 . . . . . . . . . . . . . . . . . . . . . 42
12.1. Header Field Registration . . . . . . . . . . . . . . . 43 12.1. Header Field 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
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 44
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 24 skipping to change at page 4, line 24
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 . . . . . . . . . . 54
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 6, line 25 skipping to change at page 6, line 25
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>
token = <token, see [Semantics], Section 4.2.3> token = <token, see [Semantics], Section 4.2.3>
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 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 31, line 5 skipping to change at page 30, line 35
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 41
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 36, line 18 skipping to change at page 35, line 44
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 36, line 26
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 44, line 11 skipping to change at page 43, line 38
Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>
with the registration procedure of Section 9.8.2 and the upgrade with the registration procedure of Section 9.8.2 and the upgrade
token names summarized in the table of Section 9.8.1. token names summarized in the table of Section 9.8.1.
13. References 13. References
13.1. Normative References 13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-latest (work Ed., "HTTP Caching", draft-ietf-httpbis-cache-latest (work
in progress), July 2019. in progress), October 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 49 skipping to change at page 44, line 27
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>.
[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-latest Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-latest
(work in progress), July 2019. (work in progress), October 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 47, line 15 skipping to change at page 47, line 15
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 11 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 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-part = *( 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>
skipping to change at page 55, line 33 skipping to change at page 55, line 33
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 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.8, 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>)
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) 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) 25
D D
deflate (transfer coding) 25 deflate (transfer coding) 25
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 29
connection-option 29 connection-option 29
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-part 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) 25
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 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
T T
TE header field 26 TE header field 26
Transfer-Encoding header field 17 Transfer-Encoding header field 17
U U
Upgrade header field 35 Upgrade header field 34
X X
x-compress (transfer coding) 25 x-compress (transfer coding) 25
x-gzip (transfer coding) 25 x-gzip (transfer coding) 25
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Authors' Addresses Authors' Addresses
skipping to change at page 58, line 4 skipping to change at page 58, line 21
X X
x-compress (transfer coding) 25 x-compress (transfer coding) 25
x-gzip (transfer coding) 25 x-gzip (transfer coding) 25
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 USA
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. 60 change blocks. 
155 lines changed or deleted 161 lines changed or added

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