draft-ietf-httpbis-messaging-04.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: September 10, 2019 J. Reschke, Ed. Expires: November 17, 2019 J. Reschke, Ed.
greenbytes greenbytes
March 9, 2019 May 16, 2019
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-04 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.5. The changes in this draft are summarized in Appendix D.6.
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 September 10, 2019. This Internet-Draft will expire on November 17, 2019.
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 . . . . . . . . . . . . . . . . . . . . . . 6 2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7 2.3. Message Parsing . . . . . . . . . . . . . . . . . . . . . 8
3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 9 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 10 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12
3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12 3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15 5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . 24
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Associating a Response to a Request . . . . . . . . . . . 29 9.3. Associating a Response to a Request . . . . . . . . . . . 30
9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30 9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31
9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31 9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32
9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32 9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33
9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32 9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36 9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37
9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37 9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 39
10.1. Media Type message/http . . . . . . . . . . . . . . . . 38 10.1. Media Type message/http . . . . . . . . . . . . . . . . 39
10.2. Media Type application/http . . . . . . . . . . . . . . 39 10.2. Media Type application/http . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 41
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 42
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 41 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12.1. Header Field Registration . . . . . . . . . . . . . . . 42 12.1. Header Field Registration . . . . . . . . . . . . . . . 43
12.2. Media Type Registration . . . . . . . . . . . . . . . . 42 12.2. Media Type Registration . . . . . . . . . . . . . . . . 43
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 44
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 47
Appendix B. Differences between HTTP and MIME . . . . . . . . . 47 Appendix B. Differences between HTTP and MIME . . . . . . . . . 48
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 48 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 49
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 48 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 49
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 49
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 49 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 50
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 49 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 50
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 49 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 50
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 49 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 50
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 50 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 51
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 50 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 51
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 51 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 52
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 51 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 52
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 51 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 52
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 52 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 52 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 53
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 52 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 53
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 53 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 54
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 53 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 54
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 54 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 55
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 55
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
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 13, line 34 skipping to change at page 14, line 9
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, a possibly empty textual phrase describing the status code, space, an OPTIONAL textual phrase describing the status code, and
and ending with CRLF. ending with CRLF.
status-line = HTTP-version SP status-code SP reason-phrase CRLF status-line = HTTP-version SP status-code SP [reason-phrase] CRLF
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 14, line 18 skipping to change at page 14, line 42
considerations for the definition of new status codes, and the IANA considerations for the definition of new status codes, and the IANA
registry. registry.
status-code = 3DIGIT status-code = 3DIGIT
The reason-phrase element exists for the sole purpose of providing a The reason-phrase element exists for the sole purpose of providing a
textual description associated with the numeric status code, mostly textual description associated with the numeric status code, mostly
out of deference to earlier Internet application protocols that were out of deference to earlier Internet application protocols that were
more frequently used with interactive text clients. more frequently used with interactive text clients.
A client SHOULD ignore the reason-phrase content because it is not a reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
reliable channel for information (it might be discarded or
overwritten by intermediaries, and it is not transmitted in other
versions of HTTP).
reason-phrase = *( HTAB / SP / VCHAR / obs-text ) A client SHOULD ignore the reason-phrase content because it is not a
reliable channel for information (it might be translated for a given
locale, overwritten by intermediaries, or discarded when the message
is forwarded via other versions of HTTP). A server MUST send the
space that separates status-code from the reason-phrase even when the
reason-phrase is absent (i.e., the status-line would end with the
three octets SP CR LF).
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
Most HTTP field names and the rules for parsing within field values Most HTTP field names and the rules for parsing within field values
skipping to change at page 15, line 4 skipping to change at page 15, line 29
+-------------------+----------+---------------+ +-------------------+----------+---------------+
| Header Field Name | Status | Reference | | Header Field Name | Status | Reference |
+-------------------+----------+---------------+ +-------------------+----------+---------------+
| Connection | standard | Section 9.1 | | Connection | standard | Section 9.1 |
| MIME-Version | standard | Appendix B.1 | | MIME-Version | standard | Appendix B.1 |
| TE | standard | Section 7.4 | | TE | standard | Section 7.4 |
| Transfer-Encoding | standard | Section 6.1 | | Transfer-Encoding | standard | Section 6.1 |
| Upgrade | standard | Section 9.8 | | Upgrade | standard | Section 9.8 |
+-------------------+----------+---------------+ +-------------------+----------+---------------+
Table 1
Furthermore, the field name "Close" is reserved, since using that Furthermore, the field name "Close" is reserved, since using that
name as an HTTP header field might conflict with the "close" name as an HTTP header field might conflict with the "close"
connection option of the Connection header field (Section 9.1). connection option of the Connection header field (Section 9.1).
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
| Close | http | reserved | Section 5 | | Close | http | reserved | Section 5 |
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
skipping to change at page 15, line 47 skipping to change at page 16, line 26
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
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type line folding except within the message/http media type
(Section 10.1). (Section 10.1).
obs-fold = CRLF 1*( SP / HTAB ) obs-fold = OWS CRLF RWS
; obsolete line folding ; obsolete line folding
A sender MUST NOT generate a message that includes line folding A sender MUST NOT generate a message that includes line folding
(i.e., that has any field-value that contains a match to the obs-fold (i.e., that has any field-value that contains a match to the obs-fold
rule) unless the message is intended for packaging within the rule) unless the message is intended for packaging within the
message/http media type. message/http media type.
A server that receives an obs-fold in a request message that is not A server that receives an obs-fold in a request message that is not
within a message/http container MUST either reject the message by within a message/http container MUST either reject the message by
sending a 400 (Bad Request), preferably with a representation sending a 400 (Bad Request), preferably with a representation
skipping to change at page 21, line 49 skipping to change at page 22, line 31
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section | | gzip | GZIP file format [RFC1952] | Section |
| | | 7.2 | | | | 7.2 |
| trailers | (reserved) | Section 7 | | trailers | (reserved) | Section 7 |
| x-compress | Deprecated (alias for compress) | Section | | x-compress | Deprecated (alias for compress) | Section |
| | | 7.2 | | | | 7.2 |
| x-gzip | Deprecated (alias for gzip) | Section | | x-gzip | Deprecated (alias for gzip) | Section |
| | | 7.2 | | | | 7.2 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 2
Note: the coding name "trailers" is reserved because it would Note: the coding name "trailers" is reserved because it would
clash with the use of the keyword "trailers" in the TE header clash with the use of the keyword "trailers" in the TE header
field (Section 7.4). field (Section 7.4).
7.1. Chunked Transfer Coding 7.1. Chunked Transfer Coding
The chunked transfer coding wraps the payload body in order to The chunked transfer coding wraps the payload body in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
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
skipping to change at page 34, line 42 skipping to change at page 35, line 42
acknowledgement of the packet(s) containing the server's last acknowledgement of the packet(s) containing the server's last
response. Finally, the server fully closes the connection. response. Finally, the server fully closes the connection.
It is unknown whether the reset problem is exclusive to TCP or might It is unknown whether the reset problem is exclusive to TCP or might
also be found in other transport connection protocols. also be found in other transport connection protocols.
9.8. Upgrade 9.8. Upgrade
The "Upgrade" header field is intended to provide a simple mechanism The "Upgrade" header field is intended to provide a simple mechanism
for transitioning from HTTP/1.1 to some other protocol on the same for transitioning from HTTP/1.1 to some other protocol on the same
connection. A client MAY send a list of protocols in the Upgrade connection.
header field of a request to invite the server to switch to one or
more of those protocols, in order of descending preference, before A client MAY send a list of protocol names in the Upgrade header
field of a request to invite the server to switch to one or more of
the named protocols, in order of descending preference, before
sending the final response. A server MAY ignore a received Upgrade sending the final response. A server MAY ignore a received Upgrade
header field if it wishes to continue using the current protocol on header field if it wishes to continue using the current protocol on
that connection. Upgrade cannot be used to insist on a protocol that connection. Upgrade cannot be used to insist on a protocol
change. change.
Upgrade = 1#protocol Upgrade = 1#protocol
protocol = protocol-name ["/" protocol-version] protocol = protocol-name ["/" protocol-version]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
Although protocol names are registered with a preferred case,
recipients SHOULD use case-insensitive comparison when matching each
protocol-name to supported protocols.
A server that sends a 101 (Switching Protocols) response MUST send an A server that sends a 101 (Switching Protocols) response MUST send an
Upgrade header field to indicate the new protocol(s) to which the Upgrade header field to indicate the new protocol(s) to which the
connection is being switched; if multiple protocol layers are being connection is being switched; if multiple protocol layers are being
switched, the sender MUST list the protocols in layer-ascending switched, the sender MUST list the protocols in layer-ascending
order. A server MUST NOT switch to a protocol that was not indicated order. A server MUST NOT switch to a protocol that was not indicated
by the client in the corresponding request's Upgrade header field. A by the client in the corresponding request's Upgrade header field. A
server MAY choose to ignore the order of preference indicated by the server MAY choose to ignore the order of preference indicated by the
client and select the new protocol(s) based on other factors, such as client and select the new protocol(s) based on other factors, such as
the nature of the request or the current load on the server. the nature of the request or the current load on the server.
skipping to change at page 37, line 29 skipping to change at page 38, line 31
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.4 of [RFC8126]) 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. A protocol-name token is case-insensitive and registered with the
preferred case to be generated by senders.
3. The registration MUST name a responsible party for the
registration. registration.
3. The registration MUST name a point of contact. 4. The registration MUST name a point of contact.
4. The registration MAY name a set of specifications associated with 5. 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.
5. The registration SHOULD name a set of expected "protocol-version" 6. The registration SHOULD name a set of expected "protocol-version"
tokens associated with that token at the time of registration. tokens associated with that token at the time of registration.
6. The responsible party MAY change the registration at any time. 7. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them The IANA will keep a record of all such changes, and make them
available upon request. available upon request.
7. The IESG MAY reassign responsibility for a protocol token. This 8. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party will normally only be used in the case when a responsible party
cannot be contacted. cannot be contacted.
10. Enclosing Messages as Data 10. Enclosing Messages as Data
10.1. Media Type message/http 10.1. Media Type message/http
The message/http media type can be used to enclose a single HTTP The message/http media type can be used to enclose a single HTTP
request or response message, provided that it obeys the MIME request or response message, provided that it obeys the MIME
restrictions for all "message" types regarding line length and restrictions for all "message" types regarding line length and
encodings. encodings.
Type name: message Type name: message
Subtype name: http Subtype name: http
skipping to change at page 43, line 25 skipping to change at page 44, line 25
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), March 2019. in progress), May 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 17 skipping to change at page 45, line 17
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), March 2019. (work in progress), May 2019.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
13.2. Informative References 13.2. Informative References
skipping to change at page 46, line 12 skipping to change at page 47, line 12
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 11 of [Semantics]. Section 11 of [Semantics].
BWS = <BWS, see [Semantics], Section 4.3> BWS = <BWS, see [Semantics], Section 4.3>
Connection = *( "," OWS ) connection-option *( OWS "," [ OWS Connection = [ connection-option ] *( OWS "," OWS [ connection-option
connection-option ] ) ] )
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body HTTP-message = start-line *( 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 = *( "," OWS ) transfer-coding *( OWS "," [ OWS Transfer-Encoding = [ transfer-coding ] *( OWS "," OWS [
transfer-coding ] ) transfer-coding ] )
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) Upgrade = [ protocol ] *( OWS "," OWS [ protocol ] )
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = <absolute-path, see [Semantics], Section 2.4> absolute-path = <absolute-path, see [Semantics], Section 2.4>
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
skipping to change at page 47, line 9 skipping to change at page 48, line 9
field-name = <field-name, see [Semantics], Section 4.2> field-name = <field-name, see [Semantics], Section 4.2>
field-value = <field-value, see [Semantics], Section 4.2> field-value = <field-value, see [Semantics], Section 4.2>
header-field = field-name ":" OWS field-value OWS header-field = field-name ":" OWS field-value OWS
last-chunk = 1*"0" [ chunk-ext ] CRLF last-chunk = 1*"0" [ chunk-ext ] CRLF
message-body = *OCTET message-body = *OCTET
method = token method = token
obs-fold = CRLF 1*( SP / HTAB ) obs-fold = OWS CRLF RWS
obs-text = <obs-text, see [Semantics], Section 4.2.3> obs-text = <obs-text, see [Semantics], Section 4.2.3>
origin-form = absolute-path [ "?" query ] origin-form = absolute-path [ "?" query ]
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
protocol = protocol-name [ "/" protocol-version ] protocol = protocol-name [ "/" protocol-version ]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3> quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = *( 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 CRLF
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 ] CRLF
t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank t-ranking = OWS ";" OWS "q=" rank
token = <token, see [Semantics], Section 4.2.3> token = <token, see [Semantics], Section 4.2.3>
trailer-part = *( header-field CRLF ) trailer-part = *( header-field CRLF )
transfer-coding = 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 54, line 18 skipping to change at page 55, line 18
part of a not-yet-issued request (<https://github.com/httpwg/http- part of a not-yet-issued request (<https://github.com/httpwg/http-
core/issues/26>) core/issues/26>)
o In Section 7, remove the predefined codings from the ABNF and make o In Section 7, remove the predefined codings from the ABNF and make
it generic instead (<https://github.com/httpwg/http-core/ it generic instead (<https://github.com/httpwg/http-core/
issues/66>) issues/66>)
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
D.6. Since draft-ietf-httpbis-messaging-04
o In Section 9.8, clarify that protocol-name is to be matched case-
insensitively (<https://github.com/httpwg/http-core/issues/8>)
o In Section 5.2, add leading optional whitespace to obs-fold ABNF
(<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>)
o In Section 4, add clarifications about empty reason phrases
(<https://github.com/httpwg/http-core/issues/197>)
Index Index
A A
absolute-form (of request-target) 10 absolute-form (of request-target) 11
application/http Media Type 39 application/http Media Type 40
asterisk-form (of request-target) 11 asterisk-form (of request-target) 12
authority-form (of request-target) 11 authority-form (of request-target) 11
C C
Connection header field 28, 33 Connection header field 29, 34
Content-Length header field 18 Content-Length header field 19
Content-Transfer-Encoding header field 49 Content-Transfer-Encoding header field 50
chunked (Coding Format) 17, 19 chunked (Coding Format) 17, 19
chunked (transfer coding) 22 chunked (transfer coding) 22
close 28, 33 close 29, 34
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 10-11
ALPHA 5 ALPHA 5
asterisk-form 9, 11 asterisk-form 10, 12
authority-form 9, 11 authority-form 10-11
chunk 22 chunk 23
chunk-data 22 chunk-data 23
chunk-ext 22 chunk-ext 23
chunk-ext-name 22 chunk-ext-name 23
chunk-ext-val 22 chunk-ext-val 23
chunk-size 22 chunk-size 23
chunked-body 22 chunked-body 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 15
field-value 14 field-value 15
header-field 14, 23 header-field 15, 24
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
HTTP-message 6 HTTP-message 6
HTTP-name 6 HTTP-name 7
HTTP-version 6 HTTP-version 7
last-chunk 22 last-chunk 23
LF 5 LF 5
message-body 16 message-body 17
method 9 method 9
obs-fold 15 obs-fold 16
OCTET 5 OCTET 5
origin-form 9-10 origin-form 10
rank 26 rank 27
reason-phrase 14 reason-phrase 14
request-line 8 request-line 9
request-target 9 request-target 10
SP 5 SP 5
start-line 6 start-line 6
status-code 14 status-code 14
status-line 13 status-line 14
t-codings 26 t-codings 27
t-ranking 26 t-ranking 27
TE 26 TE 27
trailer-part 22-23 trailer-part 23-24
transfer-coding 21 transfer-coding 21
Transfer-Encoding 17 Transfer-Encoding 17
transfer-parameter 21 transfer-parameter 22
Upgrade 35 Upgrade 36
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 48 MIME-Version header field 49
Media Type Media Type
application/http 39 application/http 40
message/http 38 message/http 39
message/http Media Type 38 message/http Media Type 39
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 10
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 35
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
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)
 End of changes. 60 change blocks. 
154 lines changed or deleted 184 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/