draft-ietf-httpbis-messaging-01.txt   draft-ietf-httpbis-messaging-02.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: December 2, 2018 J. Reschke, Ed. Expires: January 3, 2019 J. Reschke, Ed.
greenbytes greenbytes
May 31, 2018 July 2, 2018
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-01 draft-ietf-httpbis-messaging-02
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.2. The changes in this draft are summarized in Appendix D.3.
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 December 2, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 16 skipping to change at page 3, line 16
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Field Parsing . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Field Parsing . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 22 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23
7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23 7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
7.2. Transfer Codings for Compression . . . . . . . . . . . . 24 7.2. Transfer Codings for Compression . . . . . . . . . . . . 25
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 27 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30 9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31 9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32 9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33 9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
9.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36 9.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36
9.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 36 9.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37
10.1. Media Type message/http . . . . . . . . . . . . . . . . 37 10.1. Media Type message/http . . . . . . . . . . . . . . . . 38
10.2. Media Type application/http . . . . . . . . . . . . . . 38 10.2. Media Type application/http . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 39 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 40 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 40 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 41
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 41 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
12.1. Header Field Registration . . . . . . . . . . . . . . . 41 12.1. Header Field Registration . . . . . . . . . . . . . . . 42
12.2. Media Type Registration . . . . . . . . . . . . . . . . 42 12.2. Media Type Registration . . . . . . . . . . . . . . . . 42
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 42 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 42
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 42 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46
Appendix B. Differences between HTTP and MIME . . . . . . . . . 46 Appendix B. Differences between HTTP and MIME . . . . . . . . . 47
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 47 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 48
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 47 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 48
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 47 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 48 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 49
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 48 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 49
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 48 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 49
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 48 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 49
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 49 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 50
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 49 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 50
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 50 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 51
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 50 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 51
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 50 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 52
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 51 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 52
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 51 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 52
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 51 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 52
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" [Semantics] o "HTTP Semantics" [Semantics]
skipping to change at page 6, line 34 skipping to change at page 6, line 34
for determining the length of the message body (Section 6). for 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.
[[CREF1: Although HTTP makes use of some protocol elements similar to Although HTTP makes use of some protocol elements similar to the
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. HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". of the protocol. This specification defines version "1.1".
Section 3.5 of [Semantics] specifies the semantics of HTTP version Section 3.5 of [Semantics] specifies the semantics of HTTP version
numbers. numbers.
The version of an HTTP/1.x message is indicated by an HTTP-version The version of an HTTP/1.x message is indicated by an HTTP-version
field in the start-line. HTTP-version is case-sensitive. field in the start-line. HTTP-version is case-sensitive.
skipping to change at page 14, line 33 skipping to change at page 14, line 33
reason-phrase = *( HTAB / SP / VCHAR / obs-text ) reason-phrase = *( HTAB / SP / VCHAR / obs-text )
5. Header Fields 5. Header Fields
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
[[CREF2: Most HTTP field names and the rules for parsing within field Most HTTP field names and the rules for parsing within field values
values are defined in Section 4 of [Semantics]. This section covers are defined in Section 4 of [Semantics]. This section covers the
the generic syntax for header field inclusion within, and extraction generic syntax for header field inclusion within, and extraction
from, HTTP/1.1 messages. In addition, the following header fields from, HTTP/1.1 messages. In addition, the following header fields
are defined by this document because they are specific to HTTP/1.1 are defined by this document because they are specific to HTTP/1.1
message processing: ]] message processing:
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
| Connection | http | standard | Section 9.1 | | Connection | http | standard | Section 9.1 |
| MIME-Version | http | standard | Appendix B.1 | | MIME-Version | http | standard | Appendix B.1 |
| TE | http | standard | Section 7.4 | | TE | http | standard | Section 7.4 |
| Transfer-Encoding | http | standard | Section 6.1 | | Transfer-Encoding | http | standard | Section 6.1 |
| Upgrade | http | standard | Section 9.7 | | Upgrade | http | standard | Section 9.7 |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
skipping to change at page 15, line 23 skipping to change at page 15, line 23
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field individual header field names. The contents within a given field
value are not parsed until a later stage of message interpretation value are not parsed until a later stage of message interpretation
(usually after the message's entire header section has been (usually after the message's entire header section has been
processed). processed).
No whitespace is allowed between the header field-name and colon. In No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to the past, differences in the handling of such whitespace have led to
security vulnerabilities in request routing and response handling. A security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains server MUST reject any received request message that contains
whitespace between a header field-name and colon with a response code whitespace between a header field-name and colon with a response
of 400 (Bad Request). A proxy MUST remove any such whitespace from a status code of 400 (Bad Request). A proxy MUST remove any such
response message before forwarding the message downstream. whitespace from a response message before forwarding the message
downstream.
A field value might be preceded and/or followed by optional A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans. The field value does not for consistent readability by humans. The field value does not
include any leading or trailing whitespace: OWS occurring before the include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last non- first non-whitespace octet of the field value or after the last non-
whitespace octet of the field value ought to be excluded by parsers whitespace octet of the field value ought to be excluded by parsers
when extracting the field value from a header field. when extracting the field value from a header field.
5.2. Obsolete Line Folding 5.2. Obsolete Line Folding
skipping to change at page 21, line 26 skipping to change at page 21, line 26
property of the message rather than a property of the representation property of the message rather than a property of the representation
that is being transferred. that is being transferred.
transfer-coding = "chunked" ; Section 7.1 transfer-coding = "chunked" ; Section 7.1
/ "compress" ; [Semantics], Section 6.1.2.1 / "compress" ; [Semantics], Section 6.1.2.1
/ "deflate" ; [Semantics], Section 6.1.2.2 / "deflate" ; [Semantics], Section 6.1.2.2
/ "gzip" ; [Semantics], Section 6.1.2.3 / "gzip" ; [Semantics], Section 6.1.2.3
/ transfer-extension / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name or name=value pair. Parameters are in the form of a name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the HTTP Transfer Coding registry, as defined in
Section 7.3. They are used in the TE (Section 7.4) and Transfer- Section 7.3. They are used in the TE (Section 7.4) and Transfer-
Encoding (Section 6.1) header fields. Encoding (Section 6.1) header fields.
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| chunked | Transfer in a series of chunks | Section 7 | | chunked | Transfer in a series of chunks | Section 7 |
| | | .1 | | | | .1 |
| compress | UNIX "compress" data format [Welch] | Section 7 | | compress | UNIX "compress" data format [Welch] | Section 7 |
| | | .2 | | | | .2 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 7 | | deflate | "deflate" compressed data ([RFC1951]) | Section 7 |
| | inside the "zlib" data format | .2 | | | inside the "zlib" data format | .2 |
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 7 | | gzip | GZIP file format [RFC1952] | Section 7 |
| | | .2 | | | | .2 |
| trailers | (reserved) | Section 7 |
| x-compress | Deprecated (alias for compress) | Section 7 | | x-compress | Deprecated (alias for compress) | Section 7 |
| | | .2 | | | | .2 |
| x-gzip | Deprecated (alias for gzip) | Section 7 | | x-gzip | Deprecated (alias for gzip) | Section 7 |
| | | .2 | | | | .2 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Note: the coding name "trailers" is reserved because it would
clash with the use of the keyword "trailers" in the TE header
field (Section 7.4).
7.1. Chunked Transfer Coding 7.1. Chunked Transfer Coding
The chunked transfer coding wraps the payload body in order to The chunked transfer coding wraps the payload body in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing header fields. Chunked followed by an OPTIONAL trailer containing header fields. Chunked
enables content streams of unknown size to be transferred as a enables content streams of unknown size to be transferred as a
sequence of length-delimited buffers, which enables the sender to 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.
skipping to change at page 22, line 42 skipping to change at page 23, line 17
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.
7.1.1. Chunk Extensions 7.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
extensions, immediately following the chunk-size, for the sake of extensions, immediately following the chunk-size, for the sake of
supplying per-chunk metadata (such as a signature or hash), mid- supplying per-chunk metadata (such as a signature or hash), mid-
message control information, or randomization of message body size. message control information, or randomization of message body size.
chunk-ext = *( ";" chunk-ext-name [ "=" 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
The chunked encoding is specific to each connection and is likely to The chunked encoding is specific to each connection and is likely to
be removed or recoded by each recipient (including intermediaries) be removed or recoded by each recipient (including intermediaries)
before any higher-level application would have a chance to inspect before any higher-level application would have a chance to inspect
the extensions. Hence, use of chunk extensions is generally limited the extensions. Hence, use of chunk extensions is generally limited
to specialized HTTP services such as "long polling" (where client and to specialized HTTP services such as "long polling" (where client and
server can have shared expectations regarding the use of chunk server can have shared expectations regarding the use of chunk
skipping to change at page 25, line 18 skipping to change at page 26, line 4
transfer coding names. It is maintained at transfer coding names. It is maintained at
<https://www.iana.org/assignments/http-parameters>. <https://www.iana.org/assignments/http-parameters>.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 6.1.2 of [Semantics]) unless the encoding codings (Section 6.1.2 of [Semantics]) unless the encoding
transformation is identical, as is the case for the compression transformation is identical, as is the case for the compression
codings defined in Section 7.2. codings defined in Section 7.2.
The TE header field (Section 7.4) uses a pseudo parameter named "q"
as rank value when multiple transfer codings are acceptable. Future
registrations of transfer codings SHOULD NOT define parameters called
"q" (case-insensitively) in order to avoid ambiguities.
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of Section 4.8 of [RFC8126]), and MUST conform to the purpose of
transfer coding defined in this specification. transfer coding defined in this specification.
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
7.4. TE 7.4. TE
The "TE" header field in a request indicates what transfer codings, The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a whether or not the client is willing to accept trailer fields in a
skipping to change at page 29, line 47 skipping to change at page 30, line 34
based on the most recently received message's protocol version and based on the most recently received message's protocol version and
Connection header field (if any): Connection header field (if any):
o If the "close" connection option is present, the connection will o If the "close" connection option is present, the connection will
not persist after the current response; else, not persist after the current response; else,
o If the received protocol is HTTP/1.1 (or later), the connection o If the received protocol is HTTP/1.1 (or later), the connection
will persist after the current response; else, will persist after the current response; else,
o If the received protocol is HTTP/1.0, the "keep-alive" connection o If the received protocol is HTTP/1.0, the "keep-alive" connection
option is present, the recipient is not a proxy, and the recipient option is present, either the recipient is not a proxy or the
wishes to honor the HTTP/1.0 "keep-alive" mechanism, the message is a response, and the recipient wishes to honor the
connection will persist after the current response; otherwise, HTTP/1.0 "keep-alive" mechanism, the connection will persist after
the current response; otherwise,
o The connection will close after the current response. o The connection will close after the current response.
A client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a "close" connection option or receives an until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to In order to remain persistent, all messages on a connection need to
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 6. A server MUST read of the connection), as described in Section 6. A server MUST read
skipping to change at page 36, line 36 skipping to change at page 37, line 25
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.
Registrations happen on a "First Come First Served" basis (see Registrations happen on a "First Come First Served" basis (see
Section 4.1 of [RFC5226]) and are subject to the following rules: Section 4.4 of [RFC8126]) and are subject to the following rules:
1. A protocol-name token, once registered, stays registered forever. 1. A protocol-name token, once registered, stays registered forever.
2. The registration MUST name a responsible party for the 2. The registration MUST name a responsible party for the
registration. registration.
3. The registration MUST name a point of contact. 3. The registration MUST name a point of contact.
4. The registration MAY name a set of specifications associated with 4. The registration MAY name a set of specifications associated with
that token. Such specifications need not be publicly available. that token. Such specifications need not be publicly available.
skipping to change at page 41, line 38 skipping to change at page 42, line 26
can be used over many different forms of encrypted connection, with can be used over many different forms of encrypted connection, with
the selection of such transports being identified by the choice of the selection of such transports being identified by the choice of
URI scheme or within user agent configuration. URI scheme or within user agent configuration.
The "https" scheme can be used to identify resources that require a The "https" scheme can be used to identify resources that require a
confidential connection, as described in Section 2.5.2 of confidential connection, as described in Section 2.5.2 of
[Semantics]. [Semantics].
12. IANA Considerations 12. IANA Considerations
This section is to be removed before publishing as an RFC.
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
12.1. Header Field Registration 12.1. Header Field Registration
Please update the "Message Headers" registry of "Permanent Message Please update the "Message Headers" registry of "Permanent Message
Header Field Names" at <https://www.iana.org/assignments/message- Header Field Names" at <https://www.iana.org/assignments/message-
headers> with the header field names listed in the two tables of headers> with the header field names listed in the two tables of
Section 5. Section 5.
skipping to change at page 42, line 31 skipping to change at page 43, line 17
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.7.2 and the upgrade with the registration procedure of Section 9.7.2 and the upgrade
token names summarized in the table of Section 9.7.1. token names summarized in the table of Section 9.7.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-01 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-02 (work in
progress), May 2018. progress), July 2018.
[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 43, line 17 skipping to change at page 43, line 51
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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-01 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-02
(work in progress), May 2018. (work in progress), July 2018.
[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
[Err4667] RFC Errata, Erratum ID 4667, RFC 7230,
<https://www.rfc-editor.org/errata/eid4667>.
[Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting, [Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,
Web Cache Poisoning Attacks, and Related Topics", March Web Cache Poisoning Attacks, and Related Topics", March
2004, <http://packetstormsecurity.com/papers/general/ 2004, <http://packetstormsecurity.com/papers/general/
whitepaper_httpresponse.pdf>. whitepaper_httpresponse.pdf>.
[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
Request Smuggling", June 2005, Request Smuggling", June 2005,
<http://www.watchfire.com/news/whitepapers.aspx>. <http://www.watchfire.com/news/whitepapers.aspx>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
skipping to change at page 44, line 20 skipping to change at page 45, line 10
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, DOI 10.17487/RFC2068, January 1997, RFC 2068, DOI 10.17487/RFC2068, January 1997,
<https://www.rfc-editor.org/info/rfc2068>. <https://www.rfc-editor.org/info/rfc2068>.
[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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[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, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <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
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<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 11 of [Semantics].
BWS = <BWS, see [Semantics], Section 4.3> BWS = <BWS, see [Semantics], Section 4.3>
Connection = *( "," OWS ) connection-option *( OWS "," [ OWS Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
connection-option ] ) connection-option ] )
skipping to change at page 45, line 39 skipping to change at page 46, line 39
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = <absolute-path, see [Semantics], Section 2.4> absolute-path = <absolute-path, see [Semantics], Section 2.4>
asterisk-form = "*" asterisk-form = "*"
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 = *( ";" chunk-ext-name [ "=" 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-part 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>
skipping to change at page 51, line 5 skipping to change at page 52, line 13
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 field values have been moved to
[Semantics]. This document has been reduced to just the messaging [Semantics]. This document has been reduced to just the messaging
syntax and connection management requirements specific to HTTP/1.1. syntax and connection management requirements specific to HTTP/1.1.
Furthermore:
In the ABNF for chunked extensions, re-introduce (bad) whitespace
around ";" and "=". Whitespace was removed in [RFC7230], but later
this change was found to break existing implementations (see
[Err4667]). (Section 7.1.1)
Disallow transfer coding parameters called "q" in order to avoid
conflicts with the use of ranks in the TE header field.
(Section 7.3)
Appendix D. Change Log Appendix D. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
D.1. Between RFC7230 and draft 00 D.1. Between RFC7230 and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
skipping to change at page 51, line 43 skipping to change at page 53, line 13
from RFC 7230 (Messaging) to semantics [Semantics]. from RFC 7230 (Messaging) to semantics [Semantics].
o Moved discussion of MIME differences from RFC 7231 (Semantics) to o Moved discussion of MIME differences from RFC 7231 (Semantics) to
Appendix B since they mostly cover transforming 1.1 messages. Appendix B since they mostly cover transforming 1.1 messages.
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
D.3. Since draft-ietf-httpbis-messaging-01
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>)
o Resolved erratum 4779, no change needed here
(<https://github.com/httpwg/http-core/issues/87>,
<https://www.rfc-editor.org/errata/eid4779>)
o In Section 7, fixed prose claiming transfer parameters allow bare
names (<https://github.com/httpwg/http-core/issues/88>,
<https://www.rfc-editor.org/errata/eid4839>)
o Resolved erratum 4225, no change needed here
(<https://github.com/httpwg/http-core/issues/90>,
<https://www.rfc-editor.org/errata/eid4225>)
o Replace "response code" with "response status code"
(<https://github.com/httpwg/http-core/issues/94>,
<https://www.rfc-editor.org/errata/eid4050>)
o In Section 9.3, clarify statement about HTTP/1.0 keep-alive
(<https://github.com/httpwg/http-core/issues/96>,
<https://www.rfc-editor.org/errata/eid4205>)
o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="
(<https://github.com/httpwg/http-core/issues/101>,
<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-
editor.org/errata/eid4825>)
o In Section 7.3, state that transfer codings should not use
parameters named "q" (<https://github.com/httpwg/http-core/
issues/15>, <https://www.rfc-editor.org/errata/eid4683>)
o In Section 7, mark coding name "trailers" as reserved in the IANA
registry (<https://github.com/httpwg/http-core/issues/108>)
Index Index
A A
absolute-form (of request-target) 10 absolute-form (of request-target) 10
application/http Media Type 38 application/http Media Type 39
asterisk-form (of request-target) 11 asterisk-form (of request-target) 11
authority-form (of request-target) 11 authority-form (of request-target) 11
C C
Connection header field 27, 33 Connection header field 28, 33
Content-Length header field 18 Content-Length header field 18
Content-Transfer-Encoding header field 48 Content-Transfer-Encoding header field 49
chunked (Coding Format) 17, 19 chunked (Coding Format) 17, 19
chunked (transfer coding) 22 chunked (transfer coding) 22
close 27, 33 close 28, 33
compress (transfer coding) 24 compress (transfer coding) 25
D D
deflate (transfer coding) 24 deflate (transfer coding) 25
E E
effective request URI 12 effective request URI 12
G G
Grammar Grammar
absolute-form 9-10 absolute-form 9-10
ALPHA 5 ALPHA 5
asterisk-form 9, 11 asterisk-form 9, 11
authority-form 9, 11 authority-form 9, 11
chunk 22 chunk 22
chunk-data 22 chunk-data 22
chunk-ext 22 chunk-ext 22-23
chunk-ext-name 22 chunk-ext-name 23
chunk-ext-val 22 chunk-ext-val 23
chunk-size 22 chunk-size 22
chunked-body 22 chunked-body 22-23
Connection 28 Connection 29
connection-option 28 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 14 field-name 14
field-value 14 field-value 14
header-field 14, 23 header-field 14, 23
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
HTTP-message 6 HTTP-message 6
HTTP-name 6 HTTP-name 6
HTTP-version 6 HTTP-version 6
last-chunk 22 last-chunk 22
LF 5 LF 5
message-body 16 message-body 16
method 9 method 9
obs-fold 15 obs-fold 15
OCTET 5 OCTET 5
origin-form 9-10 origin-form 9-10
rank 25 rank 26
reason-phrase 14 reason-phrase 14
request-line 8 request-line 8
request-target 9 request-target 9
SP 5 SP 5
start-line 6 start-line 6
status-code 14 status-code 14
status-line 13 status-line 13
t-codings 25 t-codings 26
t-ranking 25 t-ranking 26
TE 25 TE 26
trailer-part 22-23 trailer-part 22-23
transfer-coding 21 transfer-coding 21
Transfer-Encoding 17 Transfer-Encoding 17
transfer-extension 21 transfer-extension 21
transfer-parameter 21 transfer-parameter 21
Upgrade 34 Upgrade 35
VCHAR 5 VCHAR 5
gzip (transfer coding) 24 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 47 MIME-Version header field 48
Media Type Media Type
application/http 38 application/http 39
message/http 37 message/http 38
message/http Media Type 37 message/http Media Type 38
method 9 method 9
O O
origin-form (of request-target) 10 origin-form (of request-target) 10
R R
request-target 9 request-target 9
T T
TE header field 25 TE header field 26
Transfer-Encoding header field 17 Transfer-Encoding header field 17
U U
Upgrade header field 34 Upgrade header field 34
X X
x-compress (transfer coding) 24 x-compress (transfer coding) 25
x-gzip (transfer coding) 24 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
 End of changes. 49 change blocks. 
105 lines changed or deleted 168 lines changed or added

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