draft-ietf-httpbis-messaging-02.txt   draft-ietf-httpbis-messaging-latest.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7230 (if approved) M. Nottingham, Ed. Obsoletes: 7230 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Fastly Intended status: Standards Track Fastly
Expires: January 3, 2019 J. Reschke, Ed. Expires: April 19, 2019 J. Reschke, Ed.
greenbytes greenbytes
July 2, 2018 October 16, 2018
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-02 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.3. The changes in this draft are summarized in Appendix D.4.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on April 19, 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 8 skipping to change at page 3, line 8
3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 9 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 10 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 10
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11
3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12 3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Field Parsing . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Header 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 . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . 25 7.2. Transfer Codings for Compression . . . . . . . . . . . . 25
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30 9.3. Associating a Response to a Request . . . . . . . . . . . 30
9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31 9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31 9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33 9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33 9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
9.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
9.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37 9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37 9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 38
10.1. Media Type message/http . . . . . . . . . . . . . . . . 38 10.1. Media Type message/http . . . . . . . . . . . . . . . . 38
10.2. Media Type application/http . . . . . . . . . . . . . . 39 10.2. Media Type application/http . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 41 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
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 . . . . . . . . . . . . . . 42 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 44
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 . . . . . . . . . . . . . . . . . . 52 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 53
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
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 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 11, line 6 skipping to change at page 11, line 6
When making a request to a proxy, other than a CONNECT or server-wide When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target. URI in absolute-form as the request-target.
absolute-form = absolute-URI absolute-form = absolute-URI
The proxy is requested to either service that request from a valid The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.6 of [Semantics]. "forwarding" of messages are defined in Section 5.5 of [Semantics].
An example absolute-form of request-line would be: An example absolute-form of request-line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to the absolute-form for all requests in some To allow for transition to the absolute-form for all requests in some
future version of HTTP, a server MUST accept the absolute-form in future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in requests, even though HTTP/1.1 clients will only send them in
requests to proxies. requests to proxies.
skipping to change at page 14, line 20 skipping to change at page 14, line 20
status codes, including the classes of status code (indicated by the status codes, including the classes of status code (indicated by the
first digit), the status codes defined by this specification, first digit), the status codes defined by this specification,
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. A client SHOULD more frequently used with interactive text clients.
ignore the reason-phrase content.
A client SHOULD ignore the reason-phrase content because it is not a
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 ) 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
skipping to change at page 14, line 47 skipping to change at page 14, line 51
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.8 |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
Furthermore, the field name "Close" is reserved, since using that Furthermore, the field name "Close" is reserved, since using that
name as an HTTP header field might conflict with the "close" name as an HTTP header field might conflict with the "close"
connection option of the Connection header field (Section 9.1). connection option of the Connection header field (Section 9.1).
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
| Close | http | reserved | Section 5 | | Close | http | reserved | Section 5 |
+-------------------+----------+----------+------------+ +-------------------+----------+----------+------------+
5.1. Field Parsing 5.1. Header Field Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field individual 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
skipping to change at page 15, line 45 skipping to change at page 15, line 48
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 = CRLF 1*( SP / HTAB )
; 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
explaining that obsolete line folding is unacceptable, or replace explaining that obsolete line folding is unacceptable, or replace
skipping to change at page 29, line 49 skipping to change at page 29, line 49
that field-name for anything else. that field-name for anything else.
The "close" connection option is defined for a sender to signal that The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For this connection will be closed after completion of the response. For
example, example,
Connection: close Connection: close
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the sender is going to close the connection after the current the sender is going to close the connection after the current
request/response is complete (Section 9.6). request/response is complete (Section 9.7).
A client that does not support persistent connections MUST send the A client that does not support persistent connections MUST send the
"close" connection option in every request message. "close" connection option in every request message.
A server that does not support persistent connections MUST send the A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not "close" connection option in every response message that does not
have a 1xx (Informational) status code. have a 1xx (Informational) status code.
9.2. Establishment 9.2. Establishment
It is beyond the scope of this specification to describe how It is beyond the scope of this specification to describe how
connections are established via various transport- or session-layer connections are established via various transport- or session-layer
protocols. Each connection applies to only one transport link. protocols. Each connection applies to only one transport link.
9.3. Persistence 9.3. Associating a Response to a Request
HTTP/1.1 does not include a request identifier for associating a
given request message with its corresponding one or more response
messages. Hence, it relies on the order of response arrival to
correspond exactly to the order in which requests are made on the
same connection. More than one response message per request only
occurs when one or more informational responses (1xx, see Section 9.2
of [Semantics]) precede a final response to the same request.
A client that has more than one outstanding request on a connection
MUST maintain a list of outstanding requests in the order sent and
MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final (non-
1xx) response.
9.4. Persistence
HTTP/1.1 defaults to the use of "persistent connections", allowing HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. The "close" connection option is used to signal that a connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections. implementations SHOULD support persistent connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
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):
skipping to change at page 31, line 13 skipping to change at page 31, line 30
reuse the same connection for a subsequent request. reuse the same connection for a subsequent request.
A proxy server MUST NOT maintain a persistent connection with an A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
See Appendix C.1.2 for more information on backwards compatibility See Appendix C.1.2 for more information on backwards compatibility
with HTTP/1.0 clients. with HTTP/1.0 clients.
9.3.1. Retrying Requests 9.4.1. Retrying Requests
Connections can be closed at any time, with or without intention. Connections can be closed at any time, with or without intention.
Implementations ought to anticipate the need to recover from Implementations ought to anticipate the need to recover from
asynchronous close events. asynchronous close events.
When an inbound connection is closed prematurely, a client MAY open a When an inbound connection is closed prematurely, a client MAY open a
new connection and automatically retransmit an aborted sequence of new connection and automatically retransmit an aborted sequence of
requests if all of those requests have idempotent methods requests if all of those requests have idempotent methods
(Section 7.2.2 of [Semantics]). A proxy MUST NOT automatically retry (Section 7.2.2 of [Semantics]). A proxy MUST NOT automatically retry
non-idempotent requests. non-idempotent requests.
skipping to change at page 31, line 40 skipping to change at page 32, line 9
that a POST request to a given resource is safe can repeat that that a POST request to a given resource is safe can repeat that
request automatically. Likewise, a user agent designed specifically request automatically. Likewise, a user agent designed specifically
to operate on a version control repository might be able to recover to operate on a version control repository might be able to recover
from partial failure conditions by checking the target resource from partial failure conditions by checking the target resource
revision(s) after a failed connection, reverting or fixing any revision(s) after a failed connection, reverting or fixing any
changes that were partially applied, and then automatically retrying changes that were partially applied, and then automatically retrying
the requests that failed. the requests that failed.
A client SHOULD NOT automatically retry a failed automatic retry. A client SHOULD NOT automatically retry a failed automatic retry.
9.3.2. Pipelining 9.4.2. Pipelining
A client that supports persistent connections MAY "pipeline" its A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 7.2.1 of parallel if they all have safe methods (Section 7.2.1 of
[Semantics]), but it MUST send the corresponding responses in the [Semantics]), but it MUST send the corresponding responses in the
same order that the requests were received. same order that the requests were received.
A client that pipelines requests SHOULD retry unanswered requests if A client that pipelines requests SHOULD retry unanswered requests if
the connection closes before it receives all of the corresponding the connection closes before it receives all of the corresponding
responses. When retrying pipelined requests after a failed responses. When retrying pipelined requests after a failed
connection (a connection not explicitly closed by the server in its connection (a connection not explicitly closed by the server in its
last complete response), a client MUST NOT pipeline immediately after last complete response), a client MUST NOT pipeline immediately after
connection establishment, since the first remaining request in the connection establishment, since the first remaining request in the
prior pipeline might have caused an error response that can be lost prior pipeline might have caused an error response that can be lost
again if multiple requests are sent on a prematurely closed again if multiple requests are sent on a prematurely closed
connection (see the TCP reset problem described in Section 9.6). connection (see the TCP reset problem described in Section 9.7).
Idempotent methods (Section 7.2.2 of [Semantics]) are significant to Idempotent methods (Section 7.2.2 of [Semantics]) are significant to
pipelining because they can be automatically retried after a pipelining because they can be automatically retried after a
connection failure. A user agent SHOULD NOT pipeline requests after connection failure. A user agent SHOULD NOT pipeline requests after
a non-idempotent method, until the final response status code for a non-idempotent method, until the final response status code for
that method has been received, unless the user agent has a means to that method has been received, unless the user agent has a means to
detect and recover from partial failure conditions involving the detect and recover from partial failure conditions involving the
pipelined sequence. pipelined sequence.
An intermediary that receives pipelined requests MAY pipeline those An intermediary that receives pipelined requests MAY pipeline those
requests when forwarding them inbound, since it can rely on the requests when forwarding them inbound, since it can rely on the
outbound user agent(s) to determine what requests can be safely outbound user agent(s) to determine what requests can be safely
pipelined. If the inbound connection fails before receiving a pipelined. If the inbound connection fails before receiving a
response, the pipelining intermediary MAY attempt to retry a sequence response, the pipelining intermediary MAY attempt to retry a sequence
of requests that have yet to receive a response if the requests all of requests that have yet to receive a response if the requests all
have idempotent methods; otherwise, the pipelining intermediary have idempotent methods; otherwise, the pipelining intermediary
SHOULD forward any received responses and then close the SHOULD forward any received responses and then close the
corresponding outbound connection(s) so that the outbound user corresponding outbound connection(s) so that the outbound user
agent(s) can recover accordingly. agent(s) can recover accordingly.
9.4. Concurrency 9.5. Concurrency
A client ought to limit the number of simultaneous open connections A client ought to limit the number of simultaneous open connections
that it maintains to a given server. that it maintains to a given server.
Previous revisions of HTTP gave a specific number of connections as a Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications. ceiling, but this was found to be impractical for many applications.
As a result, this specification does not mandate a particular maximum As a result, this specification does not mandate a particular maximum
number of connections but, instead, encourages clients to be number of connections but, instead, encourages clients to be
conservative when opening multiple connections. conservative when opening multiple connections.
skipping to change at page 33, line 5 skipping to change at page 33, line 22
blocking" problem, wherein a request that takes significant server- blocking" problem, wherein a request that takes significant server-
side processing and/or has a large payload blocks subsequent requests side processing and/or has a large payload blocks subsequent requests
on the same connection. However, each connection consumes server on the same connection. However, each connection consumes server
resources. Furthermore, using multiple connections can cause resources. Furthermore, using multiple connections can cause
undesirable side effects in congested networks. undesirable side effects in congested networks.
Note that a server might reject traffic that it deems abusive or Note that a server might reject traffic that it deems abusive or
characteristic of a denial-of-service attack, such as an excessive characteristic of a denial-of-service attack, such as an excessive
number of open connections from a single client. number of open connections from a single client.
9.5. Failures and Timeouts 9.6. Failures and Timeouts
Servers will usually have some timeout value beyond which they will Servers will usually have some timeout value beyond which they will
no longer maintain an inactive connection. Proxy servers might make no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
more connections through the same proxy server. The use of more connections through the same proxy server. The use of
persistent connections places no requirements on the length (or persistent connections places no requirements on the length (or
existence) of this timeout for either the client or the server. existence) of this timeout for either the client or the server.
A client or server that wishes to time out SHOULD issue a graceful A client or server that wishes to time out SHOULD issue a graceful
close on the connection. Implementations SHOULD constantly monitor close on the connection. Implementations SHOULD constantly monitor
skipping to change at page 33, line 40 skipping to change at page 34, line 8
expectation that clients will retry. The latter technique can expectation that clients will retry. The latter technique can
exacerbate network congestion. exacerbate network congestion.
A client sending a message body SHOULD monitor the network connection A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
9.6. Tear-down 9.7. Tear-down
The Connection header field (Section 9.1) provides a "close" The Connection header field (Section 9.1) provides a "close"
connection option that a sender SHOULD send when it wishes to close connection option that a sender SHOULD send when it wishes to close
the connection after the current request/response pair. the connection after the current request/response pair.
A client that sends a "close" connection option MUST NOT send further A client that sends a "close" connection option MUST NOT send further
requests on that connection (after the one containing "close") and requests on that connection (after the one containing "close") and
MUST close the connection after reading the final response message MUST close the connection after reading the final response message
corresponding to this request. corresponding to this request.
skipping to change at page 34, line 42 skipping to change at page 35, line 11
the write side of the read/write connection. The server then the write side of the read/write connection. The server then
continues to read from the connection until it receives a continues to read from the connection until it receives a
corresponding close by the client, or until the server is reasonably corresponding close by the client, or until the server is reasonably
certain that its own TCP stack has received the client's certain that its own TCP stack has received the client's
acknowledgement of the packet(s) containing the server's last acknowledgement of the packet(s) containing the server's last
response. Finally, the server fully closes the connection. response. Finally, the server fully closes the connection.
It is unknown whether the reset problem is exclusive to TCP or might It is unknown whether the reset problem is exclusive to TCP or might
also be found in other transport connection protocols. also be found in other transport connection protocols.
9.7. 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. A client MAY send a list of protocols in the Upgrade
header field of a request to invite the server to switch to one or header field of a request to invite the server to switch to one or
more of those protocols, in order of descending preference, before more of those 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.
skipping to change at page 36, line 32 skipping to change at page 37, line 4
When Upgrade is sent, the sender MUST also send a Connection header When Upgrade is sent, the sender MUST also send a Connection header
field (Section 9.1) that contains an "upgrade" connection option, in field (Section 9.1) that contains an "upgrade" connection option, in
order to prevent Upgrade from being accidentally forwarded by order to prevent Upgrade from being accidentally forwarded by
intermediaries that might not implement the listed protocols. A intermediaries that might not implement the listed protocols. A
server MUST ignore an Upgrade header field that is received in an server MUST ignore an Upgrade header field that is received in an
HTTP/1.0 request. HTTP/1.0 request.
A client cannot begin using an upgraded protocol on the connection A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client until it has completely sent the request message (i.e., the client
can't change the protocol it is sending in the middle of a message). can't change the protocol it is sending in the middle of a message).
If a server receives both an Upgrade and an Expect header field with If a server receives both an Upgrade and an Expect header field with
the "100-continue" expectation (Section 8.1.1 of [Semantics]), the the "100-continue" expectation (Section 8.1.1 of [Semantics]), the
server MUST send a 100 (Continue) response before sending a 101 server MUST send a 100 (Continue) response before sending a 101
(Switching Protocols) response. (Switching Protocols) response.
The Upgrade header field only applies to switching protocols on top The Upgrade header field only applies to switching protocols on top
of the existing connection; it cannot be used to switch the of the existing connection; it cannot be used to switch the
underlying connection (transport) protocol, nor to switch the underlying connection (transport) protocol, nor to switch the
existing communication to a different connection. For those existing communication to a different connection. For those
purposes, it is more appropriate to use a 3xx (Redirection) response purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 9.4 of [Semantics]). (Section 9.4 of [Semantics]).
9.7.1. Upgrade Protocol Names 9.8.1. Upgrade Protocol Names
This specification only defines the protocol name "HTTP" for use by This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 3.5 of [Semantics] and future updates to version rules of Section 3.5 of [Semantics] and future updates to
this specification. Additional protocol names ought to be registered this specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 9.7.2. using the registration procedure defined in Section 9.8.2.
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
| Name | Description | Expected Version | Reference | | Name | Description | Expected Version | Reference |
| | | Tokens | | | | | Tokens | |
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
| HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of | | HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of |
| | Transfer Protocol | (e.g, "2.0") | [Semantics] | | | Transfer Protocol | (e.g, "2.0") | [Semantics] |
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
9.7.2. Upgrade Token Registry 9.8.2. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at protocols in the Upgrade header field. The registry is maintained at
<https://www.iana.org/assignments/http-upgrade-tokens>. <https://www.iana.org/assignments/http-upgrade-tokens>.
Each registered protocol name is associated with contact information Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection and an optional set of specifications that details how the connection
will be processed after it has been upgraded. will be processed after it has been upgraded.
skipping to change at page 43, line 9 skipping to change at page 43, line 30
Please update the "HTTP Transfer Coding Registry" at Please update the "HTTP Transfer Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 7.3 and the content coding names registration procedure of Section 7.3 and the content coding names
summarized in the table of Section 7. summarized in the table of Section 7.
12.4. Upgrade Token Registration 12.4. Upgrade Token Registration
Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token
Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>
with the registration procedure of Section 9.7.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.7.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-02 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-latest (work
progress), July 2018. in progress), October 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 51 skipping to change at page 44, line 27
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-02 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-latest
(work in progress), July 2018. (work in progress), October 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
skipping to change at page 53, line 34 skipping to change at page 54, line 34
<https://www.rfc-editor.org/errata/eid4839>) <https://www.rfc-editor.org/errata/eid4839>)
o Resolved erratum 4225, no change needed here o Resolved erratum 4225, no change needed here
(<https://github.com/httpwg/http-core/issues/90>, (<https://github.com/httpwg/http-core/issues/90>,
<https://www.rfc-editor.org/errata/eid4225>) <https://www.rfc-editor.org/errata/eid4225>)
o Replace "response code" with "response status code" o Replace "response code" with "response status code"
(<https://github.com/httpwg/http-core/issues/94>, (<https://github.com/httpwg/http-core/issues/94>,
<https://www.rfc-editor.org/errata/eid4050>) <https://www.rfc-editor.org/errata/eid4050>)
o In Section 9.3, clarify statement about HTTP/1.0 keep-alive o In Section 9.4, clarify statement about HTTP/1.0 keep-alive
(<https://github.com/httpwg/http-core/issues/96>, (<https://github.com/httpwg/http-core/issues/96>,
<https://www.rfc-editor.org/errata/eid4205>) <https://www.rfc-editor.org/errata/eid4205>)
o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "=" o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="
(<https://github.com/httpwg/http-core/issues/101>, (<https://github.com/httpwg/http-core/issues/101>,
<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc- <https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-
editor.org/errata/eid4825>) editor.org/errata/eid4825>)
o In Section 7.3, state that transfer codings should not use o In Section 7.3, state that transfer codings should not use
parameters named "q" (<https://github.com/httpwg/http-core/ parameters named "q" (<https://github.com/httpwg/http-core/
issues/15>, <https://www.rfc-editor.org/errata/eid4683>) issues/15>, <https://www.rfc-editor.org/errata/eid4683>)
o In Section 7, mark coding name "trailers" as reserved in the IANA o In Section 7, mark coding name "trailers" as reserved in the IANA
registry (<https://github.com/httpwg/http-core/issues/108>) registry (<https://github.com/httpwg/http-core/issues/108>)
D.4. Since draft-ietf-httpbis-messaging-02
o In Section 4, explain why the reason phrase should be ignored by
clients (<https://github.com/httpwg/http-core/issues/60>).
o Add Section 9.3 to explain how request/response correlation is
performed (<https://github.com/httpwg/http-core/issues/145>)
Index Index
A A
absolute-form (of request-target) 10 absolute-form (of request-target) 10
application/http Media Type 39 application/http Media Type 39
asterisk-form (of request-target) 11 asterisk-form (of request-target) 11
authority-form (of request-target) 11 authority-form (of request-target) 11
C C
Connection header field 28, 33 Connection header field 28, 34
Content-Length header field 18 Content-Length header field 18
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 28, 34
compress (transfer coding) 25 compress (transfer coding) 25
D D
deflate (transfer coding) 25 deflate (transfer coding) 25
E E
effective request URI 12 effective request URI 12
G G
Grammar Grammar
skipping to change at page 55, line 40 skipping to change at page 56, line 48
Upgrade 35 Upgrade 35
VCHAR 5 VCHAR 5
gzip (transfer coding) 25 gzip (transfer coding) 25
H H
header field 6 header field 6
header section 6 header section 6
headers 6 headers 6
M M
MIME-Version header field 48 MIME-Version header field 49
Media Type Media Type
application/http 39 application/http 39
message/http 38 message/http 38
message/http Media Type 38 message/http Media Type 38
method 9 method 9
O O
origin-form (of request-target) 10 origin-form (of request-target) 10
R R
request-target 9 request-target 9
T T
TE header field 26 TE header field 26
Transfer-Encoding header field 17 Transfer-Encoding header field 17
U U
Upgrade header field 34 Upgrade header field 35
X X
x-compress (transfer coding) 25 x-compress (transfer coding) 25
x-gzip (transfer coding) 25 x-gzip (transfer coding) 25
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Authors' Addresses Authors' Addresses
 End of changes. 40 change blocks. 
72 lines changed or deleted 103 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/