draft-ietf-httpbis-messaging-10.txt   draft-ietf-httpbis-messaging-11.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 13, 2021 J. F. Reschke, Ed. Expires: February 28, 2021 J. F. Reschke, Ed.
greenbytes greenbytes
July 12, 2020 August 27, 2020
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-10 draft-ietf-httpbis-messaging-11
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.11. The changes in this draft are summarized in Appendix D.12.
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 13, 2021. This Internet-Draft will expire on February 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 50 skipping to change at page 2, line 50
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. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7 2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7
2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8 2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8
3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12
3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12
3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13 3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13
4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16 5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16
5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 17 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 17
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24
7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 25 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 25
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25
7.2. Transfer Codings for Compression . . . . . . . . . . . . 26 7.2. Transfer Codings for Compression . . . . . . . . . . . . 26
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.4. Negotiating Transfer Codings . . . . . . . . . . . . . . 27
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Associating a Response to a Request . . . . . . . . . . . 29
9.3. Associating a Response to a Request . . . . . . . . . . . 31 9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29
9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31 9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30
9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32 9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 30
9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32 9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33 9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 34 9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 32
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 34
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 34
9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 35
9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 39 10.1. Media Type message/http . . . . . . . . . . . . . . . . 35
9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 39 10.2. Media Type application/http . . . . . . . . . . . . . . 36
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10.1. Media Type message/http . . . . . . . . . . . . . . . . 40 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 37
10.2. Media Type application/http . . . . . . . . . . . . . . 41 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 38
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 38
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 39
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43 12.1. Field Name Registration . . . . . . . . . . . . . . . . 39
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 44 12.2. Media Type Registration . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 40
12.1. Field Name Registration . . . . . . . . . . . . . . . . 44 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 40
12.2. Media Type Registration . . . . . . . . . . . . . . . . 44 12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 40
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 40
12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 Appendix B. Differences between HTTP and MIME . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 46 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 45
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 48 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 45
Appendix B. Differences between HTTP and MIME . . . . . . . . . 50 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 45
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 50 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 46
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 50 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 46
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 51 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 46
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 51 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 46
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 51 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 47
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 51 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 47
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 52 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 48
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 52 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 48
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 53 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 49
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 53 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 49
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 54 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 49
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 54 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 50
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 54 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 50
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 55 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 51
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 55 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 51
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 55 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 51
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 56 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 52
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 56 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 52
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 56 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 52
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 57 D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 53
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 57 D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 53
D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 58 D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 53
D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 58 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" [Semantics] o "HTTP Semantics" [Semantics]
skipping to change at page 6, line 5 skipping to change at page 6, line 5
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character). visible [USASCII] character).
The rules below are defined in [Semantics]: The rules below are defined in [Semantics]:
BWS = <BWS, see [Semantics], Section 1.2.1> BWS = <BWS, see [Semantics], Section 1.6.1>
OWS = <OWS, see [Semantics], Section 1.2.1> OWS = <OWS, see [Semantics], Section 1.6.1>
RWS = <RWS, see [Semantics], Section 1.2.1> RWS = <RWS, see [Semantics], Section 1.6.1>
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-path = <absolute-path, see [Semantics], Section 2.4> absolute-path = <absolute-path, see [Semantics], Section 2.4>
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
comment = <comment, see [Semantics], Section 5.4.1.3> comment = <comment, see [Semantics], Section 5.4.1.3>
field-name = <field-name, see [Semantics], Section 5.3> field-name = <field-name, see [Semantics], Section 5.3>
field-value = <field-value, see [Semantics], Section 5.4> field-value = <field-value, see [Semantics], Section 5.4>
obs-text = <obs-text, see [Semantics], Section 5.4.1.2> obs-text = <obs-text, see [Semantics], Section 5.4.1.2>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2> quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>
skipping to change at page 10, line 41 skipping to change at page 10, line 41
hypertext references, resulting in those disallowed characters being hypertext references, resulting in those disallowed characters being
sent as the request-target in a malformed request-line. sent as the request-target in a malformed request-line.
Recipients of an invalid request-line SHOULD respond with either a Recipients of an invalid request-line SHOULD respond with either a
400 (Bad Request) error or a 301 (Moved Permanently) redirect with 400 (Bad Request) error or a 301 (Moved Permanently) redirect with
the request-target properly encoded. A recipient SHOULD NOT attempt the request-target properly encoded. A recipient SHOULD NOT attempt
to autocorrect and then process the request without a redirect, since to autocorrect and then process the request without a redirect, since
the invalid request-line might be deliberately crafted to bypass the invalid request-line might be deliberately crafted to bypass
security filters along the request chain. security filters along the request chain.
A client MUST send a Host header field in all HTTP/1.1 request
messages. If the target URI includes an authority component, then a
client MUST send a field value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its "@"
delimiter (Section 2.5.1 of [Semantics]). If the authority component
is missing or undefined for the target URI, then a client MUST send a
Host header field with an empty field value.
A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field value.
3.2.1. origin-form 3.2.1. origin-form
The most common form of request-target is the origin-form. The most common form of request-target is the origin-form.
origin-form = absolute-path [ "?" query ] origin-form = absolute-path [ "?" query ]
When making a request directly to an origin server, other than a When making a request directly to an origin server, other than a
CONNECT or server-wide OPTIONS request (as detailed below), a client CONNECT or server-wide OPTIONS request (as detailed below), a client
MUST send only the absolute path and query components of the target MUST send only the absolute path and query components of the target
URI as the request-target. If the target URI's path component is URI as the request-target. If the target URI's path component is
empty, the client MUST send "/" as the path within the origin-form of empty, the client MUST send "/" as the path within the origin-form of
request-target. A Host header field is also sent, as defined in request-target. A Host header field is also sent, as defined in
Section 6.6 of [Semantics]. Section 6.5 of [Semantics].
For example, a client wishing to retrieve a representation of the For example, a client wishing to retrieve a representation of the
resource identified as resource identified as
http://www.example.org/where?q=now http://www.example.org/where?q=now
directly from the origin server would open (or reuse) a TCP directly from the origin server would open (or reuse) a TCP
connection to port 80 of the host "www.example.org" and send the connection to port 80 of the host "www.example.org" and send the
lines: lines:
skipping to change at page 11, line 39 skipping to change at page 11, line 45
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 6.7 of [Semantics]. "forwarding" of messages are defined in Section 6.6 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
A client MUST send a Host header field in an HTTP/1.1 request even if A client MUST send a Host header field in an HTTP/1.1 request even if
the request-target is in the absolute-form, since this allows the the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host. that might not have implemented Host.
skipping to change at page 13, line 26 skipping to change at page 13, line 33
3.3. Reconstructing the Target URI 3.3. Reconstructing the Target URI
Since the request-target often contains only part of the user agent's Since the request-target often contains only part of the user agent's
target URI, a server constructs its value to properly service the target URI, a server constructs its value to properly service the
request (Section 6.1 of [Semantics]). request (Section 6.1 of [Semantics]).
If the request-target is in absolute-form, the target URI is the same If the request-target is in absolute-form, the target URI is the same
as the request-target. Otherwise, the target URI is constructed as as the request-target. Otherwise, the target URI is constructed as
follows: follows:
If the server's configuration (or outbound gateway) provides a o If the server's configuration (or outbound gateway) provides a
fixed URI scheme, that scheme is used for the target URI. fixed URI scheme, that scheme is used for the target URI.
Otherwise, if the request is received over a TLS-secured TCP Otherwise, if the request is received over a secured connection,
connection, the target URI's scheme is "https"; if not, the scheme the target URI's scheme is "https"; if not, the scheme is "http".
is "http".
If the server's configuration (or outbound gateway) provides a o If the server's configuration (or outbound gateway) provides a
fixed URI authority component, that authority is used for the fixed URI authority component, that authority is used for the
target URI. If not, then if the request-target is in target URI. If not, then if the request-target is in
authority-form, the target URI's authority component is the same authority-form, the target URI's authority component is the same
as the request-target. If not, then if a Host header field is as the request-target. If not, then if a Host header field is
supplied with a non-empty field-value, the authority component is supplied with a non-empty field-value, the authority component is
the same as the Host field-value. Otherwise, the authority the same as the Host field-value. Otherwise, the authority
component is assigned the default name configured for the server component is assigned the default name configured for the server
and, if the connection's incoming TCP port number differs from the and, if the connection's incoming TCP port number differs from the
default port for the target URI's scheme, then a colon (":") and default port for the target URI's scheme, then a colon (":") and
the incoming port number (in decimal form) are appended to the the incoming port number (in decimal form) are appended to the
authority component. authority component.
If the request-target is in authority-form or asterisk-form, the o If the request-target is in authority-form or asterisk-form, the
target URI's combined path and query component is empty. target URI's combined path and query component is empty.
Otherwise, the combined path and query component is the same as Otherwise, the combined path and query component is the same as
the request-target. the request-target.
The components of the target URI, once determined as above, can be o The components of the target URI, once determined as above, can be
combined into absolute-URI form by concatenating the scheme, combined into absolute-URI form by concatenating the scheme,
"://", authority, and combined path and query component. "://", authority, and combined path and query component.
Example 1: the following message received over an insecure TCP Example 1: the following message received over an insecure TCP
connection connection
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080 Host: www.example.org:8080
has a target URI of has a target URI of
http://www.example.org:8080/pub/WWW/TheProject.html http://www.example.org:8080/pub/WWW/TheProject.html
Example 2: the following message received over a TLS-secured TCP Example 2: the following message received over a secured connection
connection
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org Host: www.example.org
has a target URI of has a target URI of
https://www.example.org https://www.example.org
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
skipping to change at page 16, line 5 skipping to change at page 16, line 5
field-line = field-name ":" OWS field-value OWS field-line = field-name ":" OWS field-value OWS
Most HTTP field names and the rules for parsing within field values Most HTTP field names and the rules for parsing within field values
are defined in Section 5 of [Semantics]. This section covers the are defined in Section 5 of [Semantics]. This section covers the
generic syntax for header field inclusion within, and extraction generic syntax for header field inclusion within, and extraction
from, HTTP/1.1 messages. In addition, the following header fields from, HTTP/1.1 messages. In addition, the following header fields
are defined by this document because they are specific to HTTP/1.1 are defined by this document because they are specific to HTTP/1.1
message processing: message processing:
+-------------------+----------+--------------+ ------------------- ---------- ------
| Field Name | Status | Reference | Field Name Status Ref.
| Connection | standard | Section 9.1 | ------------------- ---------- ------
| MIME-Version | standard | Appendix B.1 | MIME-Version standard B.1
| TE | standard | Section 7.4 | Transfer-Encoding standard 6.1
| Transfer-Encoding | standard | Section 6.1 | ------------------- ---------- ------
| Upgrade | standard | Section 9.9 |
+-------------------+----------+--------------+
Table 1 Table 1
Furthermore, the field name "Close" is reserved, since using that Furthermore, the field name "Close" is reserved, since using that
name as an HTTP header field might conflict with the "close" name as an HTTP header field might conflict with the "close"
connection option of the Connection header field (Section 9.1). connection option of the Connection header field (Section 6.8 of
[Semantics]).
+------------+----------+-----------+------------+ ------------ ---------- ----------- ------------
| Field Name | Status | Reference | Comments | Field Name Status Reference Comments
| Close | standard | Section 5 | (reserved) | ------------ ---------- ----------- ------------
+------------+----------+-----------+------------+ Close standard Section 5 (reserved)
------------ ---------- ----------- ------------
Table 2 Table 2
5.1. Field Line Parsing 5.1. Field Line Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual field names. The contents within a given field line value individual field names. The contents within a given field line value
are not parsed until a later stage of message interpretation (usually are not parsed until a later stage of message interpretation (usually
after the message's entire header section has been processed). after the message's entire header section has been processed).
skipping to change at page 18, line 22 skipping to change at page 18, line 22
(Section 4), and corresponds to when a payload body is allowed; see (Section 4), and corresponds to when a payload body is allowed; see
Section 7.3.3 of [Semantics]. Section 7.3.3 of [Semantics].
6.1. Transfer-Encoding 6.1. Transfer-Encoding
The Transfer-Encoding header field lists the transfer coding names The Transfer-Encoding header field lists the transfer coding names
corresponding to the sequence of transfer codings that have been (or corresponding to the sequence of transfer codings that have been (or
will be) applied to the payload body in order to form the message will be) applied to the payload body in order to form the message
body. Transfer codings are defined in Section 7. body. Transfer codings are defined in Section 7.
Transfer-Encoding = 1#transfer-coding Transfer-Encoding = #transfer-coding
Transfer-Encoding is analogous to the Content-Transfer-Encoding field Transfer-Encoding is analogous to the Content-Transfer-Encoding field
of MIME, which was designed to enable safe transport of binary data of MIME, which was designed to enable safe transport of binary data
over a 7-bit transport service ([RFC2045], Section 6). However, safe over a 7-bit transport service ([RFC2045], Section 6). However, safe
transport has a different focus for an 8bit-clean transfer protocol. transport has a different focus for an 8bit-clean transfer protocol.
In HTTP's case, Transfer-Encoding is primarily intended to accurately In HTTP's case, Transfer-Encoding is primarily intended to accurately
delimit a dynamically generated payload and to distinguish payload delimit a dynamically generated payload and to distinguish payload
encodings that are only applied for transport efficiency or security encodings that are only applied for transport efficiency or security
from those that are characteristics of the selected resource. from those that are characteristics of the selected resource.
skipping to change at page 21, line 31 skipping to change at page 21, line 31
6. If this is a request message and none of the above are true, then 6. If this is a request message and none of the above are true, then
the message body length is zero (no message body is present). the message body length is zero (no message body is present).
7. Otherwise, this is a response message without a declared message 7. Otherwise, this is a response message without a declared message
body length, so the message body length is determined by the body length, so the message body length is determined by the
number of octets received prior to the server closing the number of octets received prior to the server closing the
connection. connection.
Since there is no way to distinguish a successfully completed, close- Since there is no way to distinguish a successfully completed, close-
delimited message from a partially received message interrupted by delimited response message from a partially received message
network failure, a server SHOULD generate encoding or length- interrupted by network failure, a server SHOULD generate encoding or
delimited messages whenever possible. The close-delimiting feature length-delimited messages whenever possible. The close-delimiting
exists primarily for backwards compatibility with HTTP/1.0. feature exists primarily for backwards compatibility with HTTP/1.0.
| *Note:* Request messages are never close-delimited because they
| are always explicitly framed by length or transfer coding, with
| the absence of both implying the request ends immediately after
| the header section.
A server MAY reject a request that contains a message body but not a A server MAY reject a request that contains a message body but not a
Content-Length by responding with 411 (Length Required). Content-Length by responding with 411 (Length Required).
Unless a transfer coding other than chunked has been applied, a Unless a transfer coding other than chunked has been applied, a
client that sends a request containing a message body SHOULD use a client that sends a request containing a message body SHOULD use a
valid Content-Length header field if the message body length is known valid Content-Length header field if the message body length is known
in advance, rather than the chunked transfer coding, since some in advance, rather than the chunked transfer coding, since some
existing services respond to chunked with a 411 (Length Required) existing services respond to chunked with a 411 (Length Required)
status code even though they understand the chunked transfer coding. status code even though they understand the chunked transfer coding.
skipping to change at page 22, line 37 skipping to change at page 22, line 48
that is being transferred. that is being transferred.
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name=value pair. Parameters are in the form of a name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the HTTP Transfer Coding registry, as defined in
Section 7.3. They are used in the TE (Section 7.4) and Section 7.3. They are used in the TE (Section 5.6.5 of [Semantics])
Transfer-Encoding (Section 6.1) header fields. and Transfer-Encoding (Section 6.1) header fields.
+------------+-------------------------------+-----------+ ------------ ------------------------------- -----------
| Name | Description | Reference | Name Description Reference
| chunked | Transfer in a series of | Section | ------------ ------------------------------- -----------
| | chunks | 7.1 | chunked Transfer in a series of Section
| compress | UNIX "compress" data format | Section | chunks 7.1
| | [Welch] | 7.2 | compress UNIX "compress" data format Section
| deflate | "deflate" compressed data | Section | [Welch] 7.2
| | ([RFC1951]) inside the "zlib" | 7.2 | deflate "deflate" compressed data Section
| | data format ([RFC1950]) | | ([RFC1951]) inside the "zlib" 7.2
| gzip | GZIP file format [RFC1952] | Section | data format ([RFC1950])
| | | 7.2 | gzip GZIP file format [RFC1952] Section
| trailers | (reserved) | Section 7 | 7.2
| x-compress | Deprecated (alias for | Section | trailers (reserved) Section 7
| | compress) | 7.2 | x-compress Deprecated (alias for Section
| x-gzip | Deprecated (alias for gzip) | Section | compress) 7.2
| | | 7.2 | x-gzip Deprecated (alias for gzip) Section
+------------+-------------------------------+-----------+ 7.2
------------ ------------------------------- -----------
Table 3 Table 3
| *Note:* the coding name "trailers" is reserved because its use | *Note:* the coding name "trailers" is reserved because its use
| would conflict with the keyword "trailers" in the TE header | would conflict with the keyword "trailers" in the TE header
| field (Section 7.4). | field (Section 5.6.5 of [Semantics]).
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 section containing trailer fields. followed by an OPTIONAL trailer section containing trailer fields.
Chunked enables content streams of unknown size to be transferred as Chunked enables content streams of unknown size to be transferred as
a sequence of length-delimited buffers, which enables the sender to a sequence of length-delimited buffers, which enables the sender to
retain connection persistence and the recipient to know when it has retain connection persistence and the recipient to know when it has
received the entire message. received the entire message.
skipping to change at page 26, line 41 skipping to change at page 26, line 41
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 7.1.2 of [Semantics]) unless the encoding codings (Section 7.1.2 of [Semantics]) unless the encoding
transformation is identical, as is the case for the compression transformation is identical, as is the case for the compression
codings defined in Section 7.2. codings defined in Section 7.2.
The TE header field (Section 7.4) uses a pseudo parameter named "q" The TE header field (Section 5.6.5 of [Semantics]) uses a pseudo
as rank value when multiple transfer codings are acceptable. Future parameter named "q" as rank value when multiple transfer codings are
registrations of transfer codings SHOULD NOT define parameters called acceptable. Future registrations of transfer codings SHOULD NOT
"q" (case-insensitively) in order to avoid ambiguities. define parameters called "q" (case-insensitively) in order to avoid
ambiguities.
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
Section 4.8 of [RFC8126]), and MUST conform to the purpose of Section 4.8 of [RFC8126]), and MUST conform to the purpose of
transfer coding defined in this specification. transfer coding defined in this specification.
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
7.4. TE 7.4. Negotiating Transfer Codings
The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a
chunked transfer coding.
The TE field-value consists of a list of transfer coding names, each The TE field (Section 5.6.5 of [Semantics]) is used in HTTP/1.1 to
allowing for optional parameters (as described in Section 7), and/or indicate what transfer-codings, besides chunked, the client is
the keyword "trailers". A client MUST NOT send the chunked transfer willing to accept in the response, and whether or not the client is
coding name in TE; chunked is always acceptable for HTTP/1.1 willing to accept trailer fields in a chunked transfer coding.
recipients.
TE = #t-codings A client MUST NOT send the chunked transfer coding name in TE;
t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) chunked is always acceptable for HTTP/1.1 recipients.
t-ranking = OWS ";" OWS "q=" rank
rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
Three examples of TE use are below. Three examples of TE use are below.
TE: deflate TE: deflate
TE: TE:
TE: trailers, deflate;q=0.5 TE: trailers, deflate;q=0.5
When multiple transfer codings are acceptable, the client MAY rank When multiple transfer codings are acceptable, the client MAY rank
the codings by preference using a case-insensitive "q" parameter the codings by preference using a case-insensitive "q" parameter
(similar to the qvalues used in content negotiation fields, (similar to the qvalues used in content negotiation fields,
skipping to change at page 27, line 46 skipping to change at page 27, line 37
If the TE field value is empty or if no TE field is present, the only If the TE field value is empty or if no TE field is present, the only
acceptable transfer coding is chunked. A message with no transfer acceptable transfer coding is chunked. A message with no transfer
coding is always acceptable. coding is always acceptable.
The keyword "trailers" indicates that the sender will not discard The keyword "trailers" indicates that the sender will not discard
trailer fields, as described in Section 5.6 of [Semantics]. trailer fields, as described in Section 5.6 of [Semantics].
Since the TE header field only applies to the immediate connection, a Since the TE header field only applies to the immediate connection, a
sender of TE MUST also send a "TE" connection option within the sender of TE MUST also send a "TE" connection option within the
Connection header field (Section 9.1) in order to prevent the TE Connection header field (Section 6.8 of [Semantics]) in order to
field from being forwarded by intermediaries that do not support its prevent the TE field from being forwarded by intermediaries that do
semantics. not support its semantics.
8. Handling Incomplete Messages 8. Handling Incomplete Messages
A server that receives an incomplete request message, usually due to A server that receives an incomplete request message, usually due to
a canceled request or a triggered timeout exception, MAY send an a canceled request or a triggered timeout exception, MAY send an
error response prior to closing the connection. error response prior to closing the connection.
A client that receives an incomplete response message, which can A client that receives an incomplete response message, which can
occur when a connection is closed prematurely or when decoding a occur when a connection is closed prematurely or when decoding a
supposedly chunked transfer coding fails, MUST record the message as supposedly chunked transfer coding fails, MUST record the message as
skipping to change at page 29, line 11 skipping to change at page 28, line 48
HTTP implementations are expected to engage in connection management, HTTP implementations are expected to engage in connection management,
which includes maintaining the state of current connections, which includes maintaining the state of current connections,
establishing a new connection or reusing an existing connection, establishing a new connection or reusing an existing connection,
processing messages received on a connection, detecting connection processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable of concurrent connections, while controlling request queues to enable
fair use and detect denial-of-service attacks. fair use and detect denial-of-service attacks.
9.1. Connection 9.1. Establishment
The "Connection" header field allows the sender to list desired
control options for the current connection.
When a field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list
the corresponding field name within the Connection header field.
Intermediaries MUST parse a received Connection header field before a
message is forwarded and, for each connection-option in this field,
remove any header or trailer field(s) from the message with the same
name as the connection-option, and then remove the Connection header
field itself (or replace it with the intermediary's own connection
options for the forwarded message).
Hence, the Connection header field provides a declarative way of
distinguishing fields that are only intended for the immediate
recipient ("hop-by-hop") from those fields that are intended for all
recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by
older intermediaries.
Furthermore, intermediaries SHOULD remove or replace field(s) whose
semantics are known to require removal before forwarding, whether or
not they appear as a Connection option, after applying those fields'
semantics. This includes but is not limited to:
o Proxy-Connection (Appendix C.1.2)
o Keep-Alive (Section 19.7.1 of [RFC2068])
o TE (Section 7.4)
o Trailer (Section 5.6.3 of [Semantics])
o Transfer-Encoding (Section 6.1)
o Upgrade (Section 9.9)
The Connection header field's value has the following grammar:
Connection = 1#connection-option
connection-option = token
Connection options are case-insensitive.
A sender MUST NOT send a connection option corresponding to a field
that is intended for all recipients of the payload. For example,
Cache-Control is never appropriate as a connection option
(Section 5.2 of [Caching]).
The connection options do not always correspond to a field present in
the message, since a connection-specific field might not be needed if
there are no parameters associated with a connection option. In
contrast, a connection-specific field that is received without a
corresponding connection option usually indicates that the field has
been improperly forwarded by an intermediary and ought to be ignored
by the recipient.
When defining new connection options, specification authors ought to
document it as reserved field name and register that definition in
the Hypertext Transfer Protocol (HTTP) Field Name Registry
(Section 5.3.2 of [Semantics]), to avoid collisions.
The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For
example,
Connection: close
in either the request or the response header fields indicates that
the sender is going to close the connection after the current
request/response is complete (Section 9.7).
A client that does not support persistent connections MUST send the
"close" connection option in every request message.
A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not
have a 1xx (Informational) status code.
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. Associating a Response to a Request 9.2. Associating a Response to a Request
HTTP/1.1 does not include a request identifier for associating a HTTP/1.1 does not include a request identifier for associating a
given request message with its corresponding one or more response given request message with its corresponding one or more response
messages. Hence, it relies on the order of response arrival to messages. Hence, it relies on the order of response arrival to
correspond exactly to the order in which requests are made on the correspond exactly to the order in which requests are made on the
same connection. More than one response message per request only same connection. More than one response message per request only
occurs when one or more informational responses (1xx, see occurs when one or more informational responses (1xx, see
Section 10.2 of [Semantics]) precede a final response to the same Section 10.2 of [Semantics]) precede a final response to the same
request. request.
skipping to change at page 31, line 28 skipping to change at page 29, line 28
MUST associate each received response message on that connection to MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final (non- the highest ordered request that has not yet received a final (non-
1xx) response. 1xx) response.
If an HTTP/1.1 client receives data on a connection that doesn't have If an HTTP/1.1 client receives data on a connection that doesn't have
any outstanding requests, it MUST NOT consider them to be a response any outstanding requests, it MUST NOT consider them to be a response
to a not-yet-issued request; it SHOULD close the connection, since to a not-yet-issued request; it SHOULD close the connection, since
message delimitation is now ambiguous, unless the data consists only message delimitation is now ambiguous, unless the data consists only
of one or more CRLF (which can be discarded, as per Section 2.2). of one or more CRLF (which can be discarded, as per Section 2.2).
9.4. Persistence 9.3. 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 (Section 6.8 of [Semantics]), if any:
o If the "close" connection option is present, the connection will o If the "close" connection option is present, the connection will
not persist after the current response; else, not persist after the current response; else,
o If the received protocol is HTTP/1.1 (or later), the connection o If the received protocol is HTTP/1.1 (or later), the connection
will persist after the current response; else, will persist after the current response; else,
o If the received protocol is HTTP/1.0, the "keep-alive" connection o If the received protocol is HTTP/1.0, the "keep-alive" connection
option is present, either the recipient is not a proxy or the option is present, either the recipient is not a proxy or the
message is a response, and the recipient wishes to honor the message is a response, and the recipient wishes to honor the
HTTP/1.0 "keep-alive" mechanism, the connection will persist after HTTP/1.0 "keep-alive" mechanism, the connection will persist after
the current response; otherwise, the current response; otherwise,
o The connection will close after the current response. o The connection will close after the current response.
A client that does not support persistent connections MUST send the
"close" connection option in every request message.
A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not
have a 1xx (Informational) status code.
A client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a "close" connection option or receives an until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to In order to remain persistent, all messages on a connection need to
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 6. A server MUST read of the connection), as described in Section 6. A server MUST read
the entire request message body or close the connection after sending the entire request message body or close the connection after sending
its response, since otherwise the remaining data on a persistent its response, since otherwise the remaining data on a persistent
connection would be misinterpreted as the next request. Likewise, a connection would be misinterpreted as the next request. Likewise, a
skipping to change at page 32, line 26 skipping to change at page 30, line 33
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.4.1. Retrying Requests 9.3.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. The conditions under which a client can asynchronous close events. The conditions under which a client can
automatically retry a sequence of outstanding requests are defined in automatically retry a sequence of outstanding requests are defined in
Section 8.2.2 of [Semantics]. Section 8.2.2 of [Semantics].
9.4.2. Pipelining 9.3.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 8.2.1 of parallel if they all have safe methods (Section 8.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.7). connection (see the TCP reset problem described in Section 9.6).
Idempotent methods (Section 8.2.2 of [Semantics]) are significant to Idempotent methods (Section 8.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.5. Concurrency 9.4. 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 34, line 5 skipping to change at page 32, line 5
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.6. Failures and Timeouts 9.5. 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 34, line 40 skipping to change at page 32, line 40
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.7. Tear-down 9.6. Tear-down
The Connection header field (Section 9.1) provides a "close" The Connection header field (Section 6.8 of [Semantics]) provides a
connection option that a sender SHOULD send when it wishes to close "close" connection option that a sender SHOULD send when it wishes to
the connection after the current request/response pair. close 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.
A server that receives a "close" connection option MUST initiate a A server that receives a "close" connection option MUST initiate a
close of the connection (see below) after it sends the final response close of the connection (see below) after it sends the final response
to the request that contained "close". The server SHOULD send a to the request that contained "close". The server SHOULD send a
"close" connection option in its final response on that connection. "close" connection option in its final response on that connection.
skipping to change at page 35, line 45 skipping to change at page 33, line 45
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.
Note that a TCP connection that is half-closed by the client does not
delimit a request message, nor does it imply that the client is no
longer interested in a response. In general, transport signals
cannot be relied upon to signal edge cases, since HTTP/1.1 is
independent of transport.
9.7. TLS Connection Initiation
Conceptually, HTTP/TLS is simply sending HTTP messages over a
connection secured via TLS [RFC8446].
The HTTP client also acts as the TLS client. It initiates a
connection to the server on the appropriate port and sends the TLS
ClientHello to begin the TLS handshake. When the TLS handshake has
finished, the client may then initiate the first HTTP request. All
HTTP data MUST be sent as TLS "application data", but is otherwise
treated like a normal connection for HTTP (including potential reuse
as a persistent connection).
9.8. TLS Connection Closure 9.8. TLS Connection Closure
TLS provides a facility for secure connection closure. When a valid TLS provides a facility for secure connection closure. When a valid
closure alert is received, an implementation can be assured that no closure alert is received, an implementation can be assured that no
further data will be received on that connection. TLS further data will be received on that connection. TLS
implementations MUST initiate an exchange of closure alerts before implementations MUST initiate an exchange of closure alerts before
closing a connection. A TLS implementation MAY, after sending a closing a connection. A TLS implementation MAY, after sending a
closure alert, close the connection without waiting for the peer to closure alert, close the connection without waiting for the peer to
send its closure alert, generating an "incomplete close". Note that send its closure alert, generating an "incomplete close". Note that
an implementation which does this MAY choose to reuse the session. an implementation which does this MAY choose to reuse the session.
skipping to change at page 36, line 42 skipping to change at page 35, line 15
Servers SHOULD be prepared to receive an incomplete close from the Servers SHOULD be prepared to receive an incomplete close from the
client, since the client can often determine when the end of server client, since the client can often determine when the end of server
data is. Servers SHOULD be willing to resume TLS sessions closed in data is. Servers SHOULD be willing to resume TLS sessions closed in
this fashion. this fashion.
Servers MUST attempt to initiate an exchange of closure alerts with Servers MUST attempt to initiate an exchange of closure alerts with
the client before closing the connection. Servers MAY close the the client before closing the connection. Servers MAY close the
connection after sending the closure alert, thus generating an connection after sending the closure alert, thus generating an
incomplete close on the client side. incomplete close on the client side.
9.9. Upgrade
The "Upgrade" header field is intended to provide a simple mechanism
for transitioning from HTTP/1.1 to some other protocol on the same
connection.
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
header field if it wishes to continue using the current protocol on
that connection. Upgrade cannot be used to insist on a protocol
change.
Upgrade = 1#protocol
protocol = protocol-name ["/" protocol-version]
protocol-name = 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
Upgrade header field to indicate the new protocol(s) to which the
connection is being switched; if multiple protocol layers are being
switched, the sender MUST list the protocols in layer-ascending
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
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
the nature of the request or the current load on the server.
A server that sends a 426 (Upgrade Required) response MUST send an
Upgrade header field to indicate the acceptable protocols, in order
of descending preference.
A server MAY send an Upgrade header field in any other response to
advertise that it implements support for upgrading to the listed
protocols, in order of descending preference, when appropriate for a
future request.
The following is a hypothetical example sent by a client:
GET /hello HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: websocket, IRC/6.9, RTA/x11
The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101
(Switching Protocols) response, the server is expected to continue
responding to the original request as if it had received its
equivalent within the new protocol (i.e., the server still has an
outstanding request to satisfy after the protocol has been changed,
and is expected to do so without requiring the request to be
repeated).
For example, if the Upgrade header field is received in a GET request
and the server decides to switch protocols, it first responds with a
101 (Switching Protocols) message in HTTP/1.1 and then immediately
follows that with the new protocol's equivalent of a response to a
GET on the target resource. This allows a connection to be upgraded
to protocols with the same semantics as HTTP without the latency cost
of an additional round trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol.
The following is an example response to the above hypothetical
request:
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: websocket
[... data stream switches to websocket with an appropriate response
(as defined by new protocol) to the "GET /hello" request ...]
When Upgrade is sent, the sender MUST also send a Connection header
field (Section 9.1) that contains an "upgrade" connection option, in
order to prevent Upgrade from being accidentally forwarded by
intermediaries that might not implement the listed protocols. A
server MUST ignore an Upgrade header field that is received in an
HTTP/1.0 request.
A client cannot begin using an upgraded protocol on the connection
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).
If a server receives both an Upgrade and an Expect header field with
the "100-continue" expectation (Section 9.1.1 of [Semantics]), the
server MUST send a 100 (Continue) response before sending a 101
(Switching Protocols) response.
The Upgrade header field only applies to switching protocols on top
of the existing connection; it cannot be used to switch the
underlying connection (transport) protocol, nor to switch the
existing communication to a different connection. For those
purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 10.4 of [Semantics]).
9.9.1. Upgrade Protocol Names
This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 4.2 of [Semantics] and future updates to
this specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 9.9.2.
+------+-------------------+-----------------+----------------+
| Name | Description | Expected | Reference |
| | | Version Tokens | |
| HTTP | Hypertext | any DIGIT.DIGIT | Section 4.2 of |
| | Transfer Protocol | (e.g, "2.0") | [Semantics] |
+------+-------------------+-----------------+----------------+
Table 4
9.9.2. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at
<https://www.iana.org/assignments/http-upgrade-tokens>.
Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection
will be processed after it has been upgraded.
Registrations happen on a "First Come First Served" basis (see
Section 4.4 of [RFC8126]) and are subject to the following rules:
1. A protocol-name token, once registered, stays registered forever.
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.
4. The registration MUST name a point of contact.
5. The registration MAY name a set of specifications associated with
that token. Such specifications need not be publicly available.
6. The registration SHOULD name a set of expected "protocol-version"
tokens associated with that token at the time of registration.
7. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them
available upon request.
8. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party
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
skipping to change at page 45, line 16 skipping to change at page 40, line 16
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.9.2 and the upgrade with the registration procedure of Section 6.7.2 of [Semantics] and
token names summarized in the table of Section 9.9.1. the upgrade token names summarized in the table of Section 6.7.1 of
[Semantics].
12.5. ALPN Protocol ID Registration 12.5. ALPN Protocol ID Registration
Please update the "TLS Application-Layer Protocol Negotiation (ALPN) Please update the "TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs" registry at <https://www.iana.org/assignments/tls- Protocol IDs" registry at <https://www.iana.org/assignments/tls-
extensiontype-values/tls-extensiontype-values.xhtml> with the extensiontype-values/tls-extensiontype-values.xhtml> with the
registration below: registration below:
+----------+-----------------------------+----------------+ ---------- ----------------------------- ----------------
| Protocol | Identification Sequence | Reference | Protocol Identification Sequence Reference
| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | (this | ---------- ----------------------------- ----------------
| | 0x31 0x2e 0x31 ("http/1.1") | specification) | HTTP/1.1 0x68 0x74 0x74 0x70 0x2f (this
+----------+-----------------------------+----------------+ 0x31 0x2e 0x31 ("http/1.1") specification)
---------- ----------------------------- ----------------
Table 5 Table 4
13. References 13. References
13.1. Normative References 13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP Caching", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cache-10, July 12, 2020, draft-ietf-httpbis-cache-11, August 27, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-10>. <https://tools.ietf.org/html/draft-ietf-httpbis-cache-11>.
[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, Format 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 46, line 40 skipping to change at page 41, line 40
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP Semantics", Work in Progress, Internet-Draft, Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
draft-ietf-httpbis-semantics-10, July 12, 2020, draft-ietf-httpbis-semantics-11, August 27, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
10>. 11>.
[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., "A Technique for High-Performance Data [Welch] Welch, T. A., "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 48, line 25 skipping to change at page 43, line 25
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 5.5.1 of [Semantics]. Section 5.5.1 of [Semantics].
BWS = <BWS, see [Semantics], Section 1.2.1> BWS = <BWS, see [Semantics], Section 1.6.1>
Connection = connection-option *( OWS "," OWS connection-option )
HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [ HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [
message-body ] 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 1.2.1> OWS = <OWS, see [Semantics], Section 1.6.1>
RWS = <RWS, see [Semantics], Section 1.2.1>
TE = [ t-codings *( OWS "," OWS t-codings ) ] RWS = <RWS, see [Semantics], Section 1.6.1>
Transfer-Encoding = transfer-coding *( OWS "," OWS transfer-coding )
Upgrade = protocol *( OWS "," OWS protocol ) Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding
) ]
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = <absolute-path, see [Semantics], Section 2.4> absolute-path = <absolute-path, see [Semantics], Section 2.4>
asterisk-form = "*" asterisk-form = "*"
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
authority-form = authority authority-form = authority
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET chunk-data = 1*OCTET
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val
] ) ] )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token / quoted-string chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-section CRLF chunked-body = *chunk last-chunk trailer-section CRLF
comment = <comment, see [Semantics], Section 5.4.1.3> comment = <comment, see [Semantics], Section 5.4.1.3>
connection-option = token
field-line = field-name ":" OWS field-value OWS field-line = field-name ":" OWS field-value OWS
field-name = <field-name, see [Semantics], Section 5.3> field-name = <field-name, see [Semantics], Section 5.3>
field-value = <field-value, see [Semantics], Section 5.4> field-value = <field-value, see [Semantics], Section 5.4>
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 = OWS CRLF RWS obs-fold = OWS CRLF RWS
obs-text = <obs-text, see [Semantics], Section 5.4.1.2> obs-text = <obs-text, see [Semantics], Section 5.4.1.2>
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-name = 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 5.4.1.2> quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
request-line = method SP request-target SP HTTP-version request-line = method SP request-target SP HTTP-version
request-target = origin-form / absolute-form / authority-form / request-target = origin-form / absolute-form / authority-form /
asterisk-form asterisk-form
start-line = request-line / status-line start-line = request-line / status-line
status-code = 3DIGIT status-code = 3DIGIT
status-line = HTTP-version SP status-code SP [ reason-phrase ] status-line = HTTP-version SP status-code SP [ reason-phrase ]
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
token = <token, see [Semantics], Section 5.4.1.1> token = <token, see [Semantics], Section 5.4.1.1>
trailer-section = *( field-line CRLF ) trailer-section = *( field-line CRLF )
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
Appendix B. Differences between HTTP and MIME Appendix B. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for the Internet Message HTTP/1.1 uses many of the constructs defined for the Internet Message
skipping to change at page 53, line 8 skipping to change at page 47, line 40
properly encode the request-target. properly encode the request-target.
C.1. Changes from HTTP/1.0 C.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
C.1.1. Multihomed Web Servers C.1.1. Multihomed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 6.6 of [Semantics]), report an error if it is missing field (Section 6.5 of [Semantics]), report an error if it is missing
from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are
among the most important changes defined by HTTP/1.1. among the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
introduced during the development of HTTP/1.1 and, though it was introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional quickly implemented by most HTTP/1.0 browsers, additional
requirements were placed on all HTTP/1.1 requests in order to ensure requirements were placed on all HTTP/1.1 requests in order to ensure
skipping to change at page 56, line 13 skipping to change at page 50, line 46
<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.4, clarify statement about HTTP/1.0 keep-alive o In Section 9.3, 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 D.4. Since draft-ietf-httpbis-messaging-02
o In Section 4, explain why the reason phrase should be ignored by o In Section 4, explain why the reason phrase should be ignored by
clients (<https://github.com/httpwg/http-core/issues/60>). clients (<https://github.com/httpwg/http-core/issues/60>).
o Add Section 9.3 to explain how request/response correlation is o Add Section 9.2 to explain how request/response correlation is
performed (<https://github.com/httpwg/http-core/issues/145>) performed (<https://github.com/httpwg/http-core/issues/145>)
D.5. Since draft-ietf-httpbis-messaging-03 D.5. Since draft-ietf-httpbis-messaging-03
o In Section 9.3, caution against treating data on a connection as o In Section 9.2, caution against treating data on a connection as
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 D.6. Since draft-ietf-httpbis-messaging-04
o In Section 9.9, clarify that protocol-name is to be matched case-
insensitively (<https://github.com/httpwg/http-core/issues/8>) o In Section 6.7 of [Semantics], 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 o In Section 5.2, add leading optional whitespace to obs-fold ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o In Section 4, add clarifications about empty reason phrases o In Section 4, add clarifications about empty reason phrases
(<https://github.com/httpwg/http-core/issues/197>) (<https://github.com/httpwg/http-core/issues/197>)
o Move discussion of retries from Section 9.4.1 into [Semantics] o Move discussion of retries from Section 9.3.1 into [Semantics]
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
D.7. Since draft-ietf-httpbis-messaging-05 D.7. Since draft-ietf-httpbis-messaging-05
o In Section 7.1.2, the trailer part has been renamed the trailer o In Section 7.1.2, the trailer part has been renamed the trailer
section (for consistency with the header section) and trailers are section (for consistency with the header section) and trailers are
no longer merged as header fields by default, but rather can be no longer merged as header fields by default, but rather can be
discarded, kept separate from header fields, or merged with header discarded, kept separate from header fields, or merged with header
fields only if understood and defined as being mergeable fields only if understood and defined as being mergeable
(<https://github.com/httpwg/http-core/issues/16>) (<https://github.com/httpwg/http-core/issues/16>)
o In Section 2.1 and related Sections, move the trailing CRLF from o In Section 2.1 and related Sections, move the trailing CRLF from
the line grammars into the message format the line grammars into the message format
(<https://github.com/httpwg/http-core/issues/62>) (<https://github.com/httpwg/http-core/issues/62>)
o Moved Section 2.3 down (<https://github.com/httpwg/http-core/ o Moved Section 2.3 down (<https://github.com/httpwg/http-core/
issues/68>) issues/68>)
o In Section 9.9, use 'websocket' instead of 'HTTP/2.0' in examples o In Section 6.7 of [Semantics], use 'websocket' instead of
(<https://github.com/httpwg/http-core/issues/112>) 'HTTP/2.0' in examples (<https://github.com/httpwg/http-core/
issues/112>)
o Move version non-specific text from Section 6 into semantics as o Move version non-specific text from Section 6 into semantics as
"payload body" (<https://github.com/httpwg/http-core/issues/159>) "payload body" (<https://github.com/httpwg/http-core/issues/159>)
o In Section 9.8, add text from RFC 2818 o In Section 9.8, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
D.8. Since draft-ietf-httpbis-messaging-06 D.8. Since draft-ietf-httpbis-messaging-06
o In Section 12.5, update the APLN protocol id for HTTP/1.1 o In Section 12.5, update the APLN protocol id for HTTP/1.1
(<https://github.com/httpwg/http-core/issues/49>) (<https://github.com/httpwg/http-core/issues/49>)
o In Section 5, align with updates to field terminology in semantics o In Section 5, align with updates to field terminology in semantics
(<https://github.com/httpwg/http-core/issues/111>) (<https://github.com/httpwg/http-core/issues/111>)
o In Section 9.1, clarify that new connection options indeed need to o In Section 6.8 of [Semantics], clarify that new connection options
be registered (<https://github.com/httpwg/http-core/issues/285>) indeed need to be registered (<https://github.com/httpwg/http-
core/issues/285>)
o In Section 1.1, reference RFC 8174 as well o In Section 1.1, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>) (<https://github.com/httpwg/http-core/issues/303>)
D.9. Since draft-ietf-httpbis-messaging-07 D.9. Since draft-ietf-httpbis-messaging-07
o Move TE: trailers into [Semantics] (<https://github.com/httpwg/ o Move TE: trailers into [Semantics] (<https://github.com/httpwg/
http-core/issues/18>) http-core/issues/18>)
o In Section 6.3, adjust requirements for handling multiple content- o In Section 6.3, adjust requirements for handling multiple content-
skipping to change at page 58, line 38 skipping to change at page 53, line 27
(<https://github.com/httpwg/http-core/issues/192>) (<https://github.com/httpwg/http-core/issues/192>)
o In Section 5, adjust IANA "Close" entry for new registry format o In Section 5, adjust IANA "Close" entry for new registry format
(<https://github.com/httpwg/http-core/issues/273>) (<https://github.com/httpwg/http-core/issues/273>)
D.11. Since draft-ietf-httpbis-messaging-09 D.11. Since draft-ietf-httpbis-messaging-09
o Switch to xml2rfc v3 mode for draft generation o Switch to xml2rfc v3 mode for draft generation
(<https://github.com/httpwg/http-core/issues/394>) (<https://github.com/httpwg/http-core/issues/394>)
D.12. Since draft-ietf-httpbis-messaging-10
o In Section 6.3, note that TCP half-close does not delimit a
request; talk about corresponding server-side behaviour in
Section 9.6 (<https://github.com/httpwg/http-core/issues/22>)
o Moved requirements specific to HTTP/1.1 from [Semantics] into
Section 3.2 (<https://github.com/httpwg/http-core/issues/182>)
o In Section 6.1 (Transfer-Encoding), adjust ABNF to allow empty
lists (<https://github.com/httpwg/http-core/issues/210>)
o In Section 9.7, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>)
o Moved definitions of "TE" and "Upgrade" into [Semantics]
(<https://github.com/httpwg/http-core/issues/392>)
o Moved definition of "Connection" into [Semantics]
(<https://github.com/httpwg/http-core/issues/407>)
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
skipping to change at page 59, line 4 skipping to change at page 54, line 15
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
United States of America United States of America
Email: fielding@gbiv.com Email: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
Prahran VIC
Australia
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
48155 Münster 48155 Münster
Germany Germany
 End of changes. 71 change blocks. 
433 lines changed or deleted 246 lines changed or added

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