draft-ietf-httpbis-messaging-08.txt   draft-ietf-httpbis-messaging-09.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: November 27, 2020 J. Reschke, Ed. Expires: January 12, 2021 J. Reschke, Ed.
greenbytes greenbytes
May 26, 2020 July 11, 2020
HTTP/1.1 Messaging HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-08 draft-ietf-httpbis-messaging-09
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.9. The changes in this draft are summarized in Appendix D.10.
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 November 27, 2020. This Internet-Draft will expire on January 12, 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . 16 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16
6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18
6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23
7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24
7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 24 7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 24
7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25
7.2. Transfer Codings for Compression . . . . . . . . . . . . 25 7.2. Transfer Codings for Compression . . . . . . . . . . . . 26
7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26
7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28
9. Connection Management . . . . . . . . . . . . . . . . . . . . 28 9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Associating a Response to a Request . . . . . . . . . . . 30 9.3. Associating a Response to a Request . . . . . . . . . . . 31
9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31
9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32 9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32
9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32 9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33 9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33
9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33 9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35 9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35
9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 38 9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 38
9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38 9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 39
10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 39 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 40
10.1. Media Type message/http . . . . . . . . . . . . . . . . 39 10.1. Media Type message/http . . . . . . . . . . . . . . . . 40
10.2. Media Type application/http . . . . . . . . . . . . . . 40 10.2. Media Type application/http . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42
11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43
11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43
11.4. Message Confidentiality . . . . . . . . . . . . . . . . 43 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12.1. Field Name Registration . . . . . . . . . . . . . . . . 44 12.1. Field Name Registration . . . . . . . . . . . . . . . . 44
12.2. Media Type Registration . . . . . . . . . . . . . . . . 44 12.2. Media Type Registration . . . . . . . . . . . . . . . . 44
12.3. Transfer Coding Registration . . . . . . . . . . . . . . 44 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 45
12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 44 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 45
12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 44 12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 46 13.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 48 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 49
Appendix B. Differences between HTTP and MIME . . . . . . . . . 49 Appendix B. Differences between HTTP and MIME . . . . . . . . . 50
B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 50 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 51
B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 50 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 51
B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 50 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 51
B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 51 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 52
B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 51 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 52
B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 51 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 52
Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 51 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 52
C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 52 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 53
C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 52 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 53
C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 53 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 54
C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 53 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 54
C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 53 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 54
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 54 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 55
D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 54 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 55
D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 54 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 56
D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 55 D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 56
D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 56 D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 57
D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 56 D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 57
D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 56 D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 57
D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 56 D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 57
D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 57 D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 58
D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 57 D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 58
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 59
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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 5, line 29 skipping to change at page 5, line 29
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 3 of [Semantics]. defined in Section 3 of [Semantics].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 4.5 of [Semantics], It also uses a list extension, defined in Section 5.5 of [Semantics],
that allows for compact definition of comma-separated lists using a that allows for compact definition of comma-separated lists using a
'#' operator (similar to how the '*' operator indicates repetition). '#' operator (similar to how the '*' operator indicates repetition).
Appendix A shows the collected grammar with all list operators Appendix A shows the collected grammar with all list operators
expanded to standard ABNF notation. expanded to standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. "obsolete" grammar rules that appear for historical reasons.
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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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.2.1>
OWS = <OWS, see [Semantics], Section 1.2.1> OWS = <OWS, see [Semantics], Section 1.2.1>
RWS = <RWS, see [Semantics], Section 1.2.1> RWS = <RWS, see [Semantics], Section 1.2.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 4.4.1.3> comment = <comment, see [Semantics], Section 5.4.1.3>
field-name = <field-name, see [Semantics], Section 4.3> field-name = <field-name, see [Semantics], Section 5.3>
field-value = <field-value, see [Semantics], Section 4.4> field-value = <field-value, see [Semantics], Section 5.4>
obs-text = <obs-text, see [Semantics], Section 4.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 4.4.1.2> quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>
token = <token, see [Semantics], Section 4.4.1.1> token = <token, see [Semantics], Section 5.4.1.1>
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
2. Message 2. Message
2.1. Message Format 2.1. Message Format
An HTTP/1.1 message consists of a start-line followed by a CRLF and a An HTTP/1.1 message consists of a start-line followed by a CRLF and a
sequence of octets in a format similar to the Internet Message Format sequence of octets in a format similar to the Internet Message Format
[RFC5322]: zero or more header field lines (collectively referred to [RFC5322]: zero or more header field lines (collectively referred to
as the "headers" or the "header section"), an empty line indicating as the "headers" or the "header section"), an empty line indicating
skipping to change at page 7, line 30 skipping to change at page 7, line 30
multibyte character sequences that contain the octet LF (%x0A). multibyte character sequences that contain the octet LF (%x0A).
String-based parsers can only be safely used within protocol elements String-based parsers can only be safely used within protocol elements
after the element has been extracted from the message, such as within after the element has been extracted from the message, such as within
a header field line value after message parsing has delineated the a header field line value after message parsing has delineated the
individual field lines. individual field lines.
Although the line terminator for the start-line and header fields is Although the line terminator for the start-line and header fields is
the sequence CRLF, a recipient MAY recognize a single LF as a line the sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR. terminator and ignore any preceding CR.
A sender MUST NOT generate a bare CR (a CR character not immediately
followed by LF) within any protocol elements other than the payload
body. A recipient of such a bare CR MUST consider that element to be
invalid or replace each bare CR with SP before processing the element
or forwarding the message.
Older HTTP/1.0 user agent implementations might send an extra CRLF Older HTTP/1.0 user agent implementations might send an extra CRLF
after a POST request as a workaround for some early server after a POST request as a workaround for some early server
applications that failed to read message body content that was not applications that failed to read message body content that was not
terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
or follow a request with an extra CRLF. If terminating the request or follow a request with an extra CRLF. If terminating the request
message body with a line-ending is desired, then the user agent MUST message body with a line-ending is desired, then the user agent MUST
count the terminating CRLF octets as part of the message body length. count the terminating CRLF octets as part of the message body length.
In the interest of robustness, a server that is expecting to receive In the interest of robustness, a server that is expecting to receive
and parse a request-line SHOULD ignore at least one empty line (CRLF) and parse a request-line SHOULD ignore at least one empty line (CRLF)
skipping to change at page 8, line 19 skipping to change at page 8, line 25
When a server listening only for HTTP request messages, or processing When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message, what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server grammar aside from the robustness exceptions listed above, the server
SHOULD respond with a 400 (Bad Request) response. SHOULD respond with a 400 (Bad Request) response.
2.3. HTTP Version 2.3. HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". of the protocol. This specification defines version "1.1".
Section 3.5 of [Semantics] specifies the semantics of HTTP version Section 4.2 of [Semantics] specifies the semantics of HTTP version
numbers. numbers.
The version of an HTTP/1.x message is indicated by an HTTP-version The version of an HTTP/1.x message is indicated by an HTTP-version
field in the start-line. HTTP-version is case-sensitive. field in the start-line. HTTP-version is case-sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %s"HTTP" HTTP-name = %s"HTTP"
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
skipping to change at page 9, line 35 skipping to change at page 9, line 42
(%x0C), or bare CR. However, lenient parsing can result in request (%x0C), or bare CR. However, lenient parsing can result in request
smuggling security vulnerabilities if there are multiple recipients smuggling security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of of the message and each has its own unique interpretation of
robustness (see Section 11.2). robustness (see Section 11.2).
HTTP does not place a predefined limit on the length of a request- HTTP does not place a predefined limit on the length of a request-
line, as described in Section 3 of [Semantics]. A server that line, as described in Section 3 of [Semantics]. A server that
receives a method longer than any that it implements SHOULD respond receives a method longer than any that it implements SHOULD respond
with a 501 (Not Implemented) status code. A server that receives a with a 501 (Not Implemented) status code. A server that receives a
request-target longer than any URI it wishes to parse MUST respond request-target longer than any URI it wishes to parse MUST respond
with a 414 (URI Too Long) status code (see Section 9.5.15 of with a 414 (URI Too Long) status code (see Section 10.5.15 of
[Semantics]). [Semantics]).
Various ad hoc limitations on request-line length are found in Various ad hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets. support, at a minimum, request-line lengths of 8000 octets.
3.1. Method 3.1. Method
The method token indicates the request method to be performed on the The method token indicates the request method to be performed on the
target resource. The request method is case-sensitive. target resource. The request method is case-sensitive.
method = token method = token
The request methods defined by this specification can be found in The request methods defined by this specification can be found in
Section 7 of [Semantics], along with information regarding the HTTP Section 8 of [Semantics], along with information regarding the HTTP
method registry and considerations for defining new methods. method registry and considerations for defining new methods.
3.2. Request Target 3.2. Request Target
The request-target identifies the target resource upon which to apply The request-target identifies the target resource upon which to apply
the request. The client derives a request-target from its desired the request. The client derives a request-target from its desired
target URI. There are four distinct formats for the request-target, target URI. There are four distinct formats for the request-target,
depending on both the method being requested and whether the request depending on both the method being requested and whether the request
is to a proxy. is to a proxy.
skipping to change at page 10, line 42 skipping to change at page 11, line 5
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 5.6 of [Semantics]. Section 6.6 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 22 skipping to change at page 11, line 33
When making a request to a proxy, other than a CONNECT or server-wide When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target. URI in absolute-form as the request-target.
absolute-form = absolute-URI absolute-form = absolute-URI
The proxy is requested to either service that request from a valid The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.7 of [Semantics]. "forwarding" of messages are defined in Section 6.7 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 12, line 8 skipping to change at page 12, line 20
case. case.
To allow for transition to the absolute-form for all requests in some To allow for transition to the absolute-form for all requests in some
future version of HTTP, a server MUST accept the absolute-form in future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in requests, even though HTTP/1.1 clients will only send them in
requests to proxies. requests to proxies.
3.2.3. authority-form 3.2.3. authority-form
The authority-form of request-target is only used for CONNECT The authority-form of request-target is only used for CONNECT
requests (Section 7.3.6 of [Semantics]). requests (Section 8.3.6 of [Semantics]).
authority-form = authority authority-form = authority
When making a CONNECT request to establish a tunnel through one or When making a CONNECT request to establish a tunnel through one or
more proxies, a client MUST send only the target URI's authority more proxies, a client MUST send only the target URI's authority
component (excluding any userinfo and its "@" delimiter) as the component (excluding any userinfo and its "@" delimiter) as the
request-target. For example, request-target. For example,
CONNECT www.example.com:80 HTTP/1.1 CONNECT www.example.com:80 HTTP/1.1
3.2.4. asterisk-form 3.2.4. asterisk-form
The asterisk-form of request-target is only used for a server-wide The asterisk-form of request-target is only used for a server-wide
OPTIONS request (Section 7.3.7 of [Semantics]). OPTIONS request (Section 8.3.7 of [Semantics]).
asterisk-form = "*" asterisk-form = "*"
When a client wishes to request OPTIONS for the server as a whole, as When a client wishes to request OPTIONS for the server as a whole, as
opposed to a specific named resource of that server, the client MUST opposed to a specific named resource of that server, the client MUST
send only "*" (%x2A) as the request-target. For example, send only "*" (%x2A) as the request-target. For example,
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
If a proxy receives an OPTIONS request with an absolute-form of If a proxy receives an OPTIONS request with an absolute-form of
skipping to change at page 13, line 9 skipping to change at page 13, line 16
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org:8001 Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org". after connecting to port 8001 of host "www.example.org".
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 5.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 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 TLS-secured TCP
connection, the target URI's scheme is "https"; if not, the scheme connection, the target URI's scheme is "https"; if not, the scheme
is "http". is "http".
skipping to change at page 14, line 44 skipping to change at page 14, line 50
includes one or more of the following octets: SP, HTAB, VT (%x0B), FF includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
(%x0C), or bare CR. However, lenient parsing can result in response (%x0C), or bare CR. However, lenient parsing can result in response
splitting security vulnerabilities if there are multiple recipients splitting security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of of the message and each has its own unique interpretation of
robustness (see Section 11.1). robustness (see Section 11.1).
The status-code element is a 3-digit integer code describing the The status-code element is a 3-digit integer code describing the
result of the server's attempt to understand and satisfy the client's result of the server's attempt to understand and satisfy the client's
corresponding request. The rest of the response message is to be corresponding request. The rest of the response message is to be
interpreted in light of the semantics defined for that status code. interpreted in light of the semantics defined for that status code.
See Section 9 of [Semantics] for information about the semantics of See Section 10 of [Semantics] for information about the semantics of
status codes, including the classes of status code (indicated by the status codes, including the classes of status code (indicated by the
first digit), the status codes defined by this specification, first digit), the status codes defined by this specification,
considerations for the definition of new status codes, and the IANA considerations for the definition of new status codes, and the IANA
registry. registry.
status-code = 3DIGIT status-code = 3DIGIT
The reason-phrase element exists for the sole purpose of providing a The reason-phrase element exists for the sole purpose of providing a
textual description associated with the numeric status code, mostly textual description associated with the numeric status code, mostly
out of deference to earlier Internet application protocols that were out of deference to earlier Internet application protocols that were
skipping to change at page 15, line 29 skipping to change at page 15, line 34
5. Field Syntax 5. Field Syntax
Each field line consists of a case-insensitive field name followed by Each field line consists of a case-insensitive field name followed by
a colon (":"), optional leading whitespace, the field line value, and a colon (":"), optional leading whitespace, the field line value, and
optional trailing whitespace. optional trailing whitespace.
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 4 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 | Reference |
+-------------------+----------+---------------+ +-------------------+----------+---------------+
| Connection | standard | Section 9.1 | | Connection | standard | Section 9.1 |
| MIME-Version | standard | Appendix B.1 | | MIME-Version | standard | Appendix B.1 |
skipping to change at page 16, line 5 skipping to change at page 16, line 9
| Transfer-Encoding | standard | Section 6.1 | | Transfer-Encoding | standard | Section 6.1 |
| Upgrade | standard | Section 9.9 | | 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 9.1).
+-------------------+----------+----------+------------+ +------------+----------+------------+-------------+
| Header Field Name | Protocol | Status | Reference | | Field Name | Status | Reference | Comments |
+-------------------+----------+----------+------------+ +------------+----------+------------+-------------+
| Close | http | reserved | Section 5 | | Close | standard | Section 5 | (reserved) |
+-------------------+----------+----------+------------+ +------------+----------+------------+-------------+
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).
No whitespace is allowed between the field name and colon. In the No whitespace is allowed between the field name and colon. In the
past, differences in the handling of such whitespace have led to past, differences in the handling of such whitespace have led to
skipping to change at page 17, line 28 skipping to change at page 17, line 30
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received obs- not within a message/http container MUST replace each received obs-
fold with one or more SP octets prior to interpreting the field fold with one or more SP octets prior to interpreting the field
value. value.
6. Message Body 6. Message Body
The message body (if any) of an HTTP message is used to carry the The message body (if any) of an HTTP message is used to carry the
payload body (Section 6.3.3 of [Semantics]) of that request or payload body (Section 7.3.3 of [Semantics]) of that request or
response. The message body is identical to the payload body unless a response. The message body is identical to the payload body unless a
transfer coding has been applied, as described in Section 6.1. transfer coding has been applied, as described in Section 6.1.
message-body = *OCTET message-body = *OCTET
The rules for determining when a message body is present in an The rules for determining when a message body is present in an
HTTP/1.1 message differ for requests and responses. HTTP/1.1 message differ for requests and responses.
The presence of a message body in a request is signaled by a Content- The presence of a message body in a request is signaled by a Content-
Length or Transfer-Encoding header field. Request message framing is Length or Transfer-Encoding header field. Request message framing is
independent of method semantics, even if the method does not define independent of method semantics, even if the method does not define
any use for a message body. any use for a message body.
The presence of a message body in a response depends on both the The presence of a message body in a response depends on both the
request method to which it is responding and the response status code request method to which it is responding and the response status code
(Section 4), and corresponds to when a payload body is allowed; see (Section 4), and corresponds to when a payload body is allowed; see
Section 6.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 = 1#transfer-coding
skipping to change at page 18, line 36 skipping to change at page 18, line 43
by closing the connection. by closing the connection.
For example, For example,
Transfer-Encoding: gzip, chunked Transfer-Encoding: gzip, chunked
indicates that the payload body has been compressed using the gzip indicates that the payload body has been compressed using the gzip
coding and then chunked using the chunked coding while forming the coding and then chunked using the chunked coding while forming the
message body. message body.
Unlike Content-Encoding (Section 6.1.2 of [Semantics]), Transfer- Unlike Content-Encoding (Section 7.1.2 of [Semantics]), Transfer-
Encoding is a property of the message, not of the representation, and Encoding is a property of the message, not of the representation, and
any recipient along the request/response chain MAY decode the any recipient along the request/response chain MAY decode the
received transfer coding(s) or apply additional transfer coding(s) to received transfer coding(s) or apply additional transfer coding(s) to
the message body, assuming that corresponding changes are made to the the message body, assuming that corresponding changes are made to the
Transfer-Encoding field value. Additional information about the Transfer-Encoding field value. Additional information about the
encoding parameters can be provided by other header fields not encoding parameters can be provided by other header fields not
defined by this specification. defined by this specification.
Transfer-Encoding MAY be sent in a response to a HEAD request or in a Transfer-Encoding MAY be sent in a response to a HEAD request or in a
304 (Not Modified) response (Section 9.4.5 of [Semantics]) to a GET 304 (Not Modified) response (Section 10.4.5 of [Semantics]) to a GET
request, neither of which includes a message body, to indicate that request, neither of which includes a message body, to indicate that
the origin server would have applied a transfer coding to the message the origin server would have applied a transfer coding to the message
body if the request had been an unconditional GET. This indication body if the request had been an unconditional GET. This indication
is not required, however, because any recipient on the response chain is not required, however, because any recipient on the response chain
(including the origin server) can remove transfer codings when they (including the origin server) can remove transfer codings when they
are not needed. are not needed.
A server MUST NOT send a Transfer-Encoding header field in any A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No response with a status code of 1xx (Informational) or 204 (No
Content). A server MUST NOT send a Transfer-Encoding header field in Content). A server MUST NOT send a Transfer-Encoding header field in
any 2xx (Successful) response to a CONNECT request (Section 7.3.6 of any 2xx (Successful) response to a CONNECT request (Section 8.3.6 of
[Semantics]). [Semantics]).
Transfer-Encoding was added in HTTP/1.1. It is generally assumed Transfer-Encoding was added in HTTP/1.1. It is generally assumed
that implementations advertising only HTTP/1.0 support will not that implementations advertising only HTTP/1.0 support will not
understand how to process a transfer-encoded payload. A client MUST understand how to process a transfer-encoded payload. A client MUST
NOT send a request containing Transfer-Encoding unless it knows the NOT send a request containing Transfer-Encoding unless it knows the
server will handle HTTP/1.1 requests (or later minor revisions); such server will handle HTTP/1.1 requests (or later minor revisions); such
knowledge might be in the form of specific user configuration or by knowledge might be in the form of specific user configuration or by
remembering the version of a prior received response. A server MUST remembering the version of a prior received response. A server MUST
NOT send a response containing Transfer-Encoding unless the NOT send a response containing Transfer-Encoding unless the
skipping to change at page 19, line 33 skipping to change at page 19, line 42
6.2. Content-Length 6.2. Content-Length
When a message does not have a Transfer-Encoding header field, a When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body. For messages decimal number of octets, for a potential payload body. For messages
that do include a payload body, the Content-Length field value that do include a payload body, the Content-Length field value
provides the framing information necessary for determining where the provides the framing information necessary for determining where the
body (and message) ends. For messages that do not include a payload body (and message) ends. For messages that do not include a payload
body, the Content-Length indicates the size of the selected body, the Content-Length indicates the size of the selected
representation (Section 6.2.4 of [Semantics]). representation (Section 7.2.4 of [Semantics]).
Note: HTTP's use of Content-Length for message framing differs Note: HTTP's use of Content-Length for message framing differs
significantly from the same field's use in MIME, where it is an significantly from the same field's use in MIME, where it is an
optional field used only within the "message/external-body" media- optional field used only within the "message/external-body" media-
type. type.
6.3. Message Body Length 6.3. Message Body Length
The length of a message body is determined by one of the following The length of a message body is determined by one of the following
(in order of precedence): (in order of precedence):
skipping to change at page 20, line 34 skipping to change at page 20, line 48
Content-Length. Such a message might indicate an attempt to Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 11.2) or response splitting perform request smuggling (Section 11.2) or response splitting
(Section 11.1) and ought to be handled as an error. A sender (Section 11.1) and ought to be handled as an error. A sender
MUST remove the received Content-Length field prior to forwarding MUST remove the received Content-Length field prior to forwarding
such a message downstream. such a message downstream.
4. If a message is received without Transfer-Encoding and with an 4. If a message is received without Transfer-Encoding and with an
invalid Content-Length header field, then the message framing is invalid Content-Length header field, then the message framing is
invalid and the recipient MUST treat it as an unrecoverable invalid and the recipient MUST treat it as an unrecoverable
error, unless the field value can be successfully parsed as a error, unless the field value can be successfully parsed as a
comma-separated list (Section 4.5 of [Semantics]), all values in comma-separated list (Section 5.5 of [Semantics]), all values in
the list are valid, and all values in the list are the same. If the list are valid, and all values in the list are the same. If
this is a request message, the server MUST respond with a 400 this is a request message, the server MUST respond with a 400
(Bad Request) status code and then close the connection. If this (Bad Request) status code and then close the connection. If this
is a response message received by a proxy, the proxy MUST close is a response message received by a proxy, the proxy MUST close
the connection to the server, discard the received response, and the connection to the server, discard the received response, and
send a 502 (Bad Gateway) response to the client. If this is a send a 502 (Bad Gateway) response to the client. If this is a
response message received by a user agent, the user agent MUST response message received by a user agent, the user agent MUST
close the connection to the server and discard the received close the connection to the server and discard the received
response. response.
skipping to change at page 24, line 21 skipping to change at page 25, line 6
parts of a message, and generate an appropriate 4xx (Client Error) parts of a message, and generate an appropriate 4xx (Client Error)
response if that amount is exceeded. response if that amount is exceeded.
7.1.2. Chunked Trailer Section 7.1.2. Chunked Trailer Section
A trailer section allows the sender to include additional fields at A trailer section allows the sender to include additional fields at
the end of a chunked message in order to supply metadata that might the end of a chunked message in order to supply metadata that might
be dynamically generated while the message body is sent, such as a be dynamically generated while the message body is sent, such as a
message integrity check, digital signature, or post-processing message integrity check, digital signature, or post-processing
status. The proper use and limitations of trailer fields are defined status. The proper use and limitations of trailer fields are defined
in Section 4.6 of [Semantics]. in Section 5.6 of [Semantics].
trailer-section = *( field-line CRLF ) trailer-section = *( field-line CRLF )
A recipient that decodes and removes the chunked encoding from a A recipient that decodes and removes the chunked encoding from a
message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST
discard any received trailer fields, store/forward them separately discard any received trailer fields, store/forward them separately
from the header fields, or selectively merge into the header section from the header fields, or selectively merge into the header section
only those trailer fields corresponding to header field definitions only those trailer fields corresponding to header field definitions
that are understood by the recipient to explicitly permit and define that are understood by the recipient to explicitly permit and define
how their corresponding trailer field value can be safely merged. how their corresponding trailer field value can be safely merged.
skipping to change at page 25, line 36 skipping to change at page 26, line 11
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields Remove Trailer from existing header fields
7.2. Transfer Codings for Compression 7.2. Transfer Codings for Compression
The following transfer coding names for compression are defined by The following transfer coding names for compression are defined by
the same algorithm as their corresponding content coding: the same algorithm as their corresponding content coding:
compress (and x-compress) compress (and x-compress)
See Section 6.1.2.1 of [Semantics]. See Section 7.1.2.1 of [Semantics].
deflate deflate
See Section 6.1.2.2 of [Semantics]. See Section 7.1.2.2 of [Semantics].
gzip (and x-gzip) gzip (and x-gzip)
See Section 6.1.2.3 of [Semantics]. See Section 7.1.2.3 of [Semantics].
The compression codings do not define any parameters. Their presence The compression codings do not define any parameters. Their presence
SHOULD be treated as an error. SHOULD be treated as an error.
7.3. Transfer Coding Registry 7.3. Transfer Coding Registry
The "HTTP Transfer Coding Registry" defines the namespace for The "HTTP Transfer Coding Registry" defines the namespace for
transfer coding names. It is maintained at transfer coding names. It is maintained at
<https://www.iana.org/assignments/http-parameters>. <https://www.iana.org/assignments/http-parameters>.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 6.1.2 of [Semantics]) unless the encoding codings (Section 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 7.4) uses a pseudo parameter named "q"
as rank value when multiple transfer codings are acceptable. Future as rank value when multiple transfer codings are acceptable. Future
registrations of transfer codings SHOULD NOT define parameters called registrations of transfer codings SHOULD NOT define parameters called
"q" (case-insensitively) in order to avoid ambiguities. "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
skipping to change at page 27, line 12 skipping to change at page 27, line 33
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,
Section 6.4.4 of [Semantics]). The rank value is a real number in Section 7.4.4 of [Semantics]). The rank value is a real number in
the range 0 through 1, where 0.001 is the least preferred and 1 is the range 0 through 1, where 0.001 is the least preferred and 1 is
the most preferred; a value of 0 means "not acceptable". the most preferred; a value of 0 means "not acceptable".
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 4.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 9.1) in order to prevent the TE
field from being forwarded by intermediaries that do not support its field from being forwarded by intermediaries that do not support its
semantics. 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
skipping to change at page 28, line 17 skipping to change at page 28, line 42
9. Connection Management 9. Connection Management
HTTP messaging is independent of the underlying transport- or HTTP messaging is independent of the underlying transport- or
session-layer connection protocol(s). HTTP only presumes a reliable session-layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport response structures onto the data units of an underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
As described in Section 5.3 of [Semantics], the specific connection As described in Section 6.3 of [Semantics], the specific connection
protocols to be used for an HTTP interaction are determined by client protocols to be used for an HTTP interaction are determined by client
configuration and the target URI. For example, the "http" URI scheme configuration and the target URI. For example, the "http" URI scheme
(Section 2.5.1 of [Semantics]) indicates a default connection of TCP (Section 2.5.1 of [Semantics]) indicates a default connection of TCP
over IP, with a default TCP port of 80, but the client might be over IP, with a default TCP port of 80, but the client might be
configured to use a proxy via some other connection, port, or configured to use a proxy via some other connection, port, or
protocol. protocol.
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,
skipping to change at page 29, line 18 skipping to change at page 29, line 40
recipients on the chain ("end-to-end"), enabling the message to be recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by to be deployed without fear that they will be blindly forwarded by
older intermediaries. older intermediaries.
Furthermore, intermediaries SHOULD remove or replace field(s) whose Furthermore, intermediaries SHOULD remove or replace field(s) whose
semantics are known to require removal before forwarding, whether or semantics are known to require removal before forwarding, whether or
not they appear as a Connection option, after applying those fields' not they appear as a Connection option, after applying those fields'
semantics. This includes but is not limited to: semantics. This includes but is not limited to:
o Proxy-Connection Appendix C.1.2 o Proxy-Connection (Appendix C.1.2)
o Keep-Alive Section 19.7.1 of [RFC2068]
o TE Section 7.4 o Keep-Alive (Section 19.7.1 of [RFC2068])
o Trailer Section 4.6.3 of [Semantics] o TE (Section 7.4)
o Transfer-Encoding Section 6.1 o Trailer (Section 5.6.3 of [Semantics])
o Upgrade Section 9.9 o Transfer-Encoding (Section 6.1)
o Upgrade (Section 9.9)
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
Connection = 1#connection-option Connection = 1#connection-option
connection-option = token connection-option = token
Connection options are case-insensitive. Connection options are case-insensitive.
A sender MUST NOT send a connection option corresponding to a field A sender MUST NOT send a connection option corresponding to a field
that is intended for all recipients of the payload. For example, that is intended for all recipients of the payload. For example,
Cache-Control is never appropriate as a connection option Cache-Control is never appropriate as a connection option
skipping to change at page 30, line 5 skipping to change at page 30, line 27
the message, since a connection-specific field might not be needed if the message, since a connection-specific field might not be needed if
there are no parameters associated with a connection option. In there are no parameters associated with a connection option. In
contrast, a connection-specific field that is received without a contrast, a connection-specific field that is received without a
corresponding connection option usually indicates that the field has corresponding connection option usually indicates that the field has
been improperly forwarded by an intermediary and ought to be ignored been improperly forwarded by an intermediary and ought to be ignored
by the recipient. by the recipient.
When defining new connection options, specification authors ought to When defining new connection options, specification authors ought to
document it as reserved field name and register that definition in document it as reserved field name and register that definition in
the Hypertext Transfer Protocol (HTTP) Field Name Registry the Hypertext Transfer Protocol (HTTP) Field Name Registry
(Section 4.3.2 of [Semantics]), to avoid collisions. (Section 5.3.2 of [Semantics]), to avoid collisions.
The "close" connection option is defined for a sender to signal that The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For this connection will be closed after completion of the response. For
example, example,
Connection: close Connection: close
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the sender is going to close the connection after the current the sender is going to close the connection after the current
request/response is complete (Section 9.7). request/response is complete (Section 9.7).
skipping to change at page 30, line 37 skipping to change at page 31, line 12
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.3. 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 Section 9.2 occurs when one or more informational responses (1xx, see
of [Semantics]) precede a final response to the same request. Section 10.2 of [Semantics]) precede a final response to the same
request.
A client that has more than one outstanding request on a connection A client that has more than one outstanding request on a connection
MUST maintain a list of outstanding requests in the order sent and MUST maintain a list of outstanding requests in the order sent and
MUST associate each received response message on that connection to MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final (non- the highest ordered request that has not yet received a final (non-
1xx) response. 1xx) response.
If an HTTP/1.1 client receives data on a connection that doesn't have If an HTTP/1.1 client receives data on a connection that doesn't have
any outstanding requests, it MUST NOT consider them to be a response any outstanding requests, it MUST NOT consider them to be a response
to a not-yet-issued request; it SHOULD close the connection, since to a not-yet-issued request; it SHOULD close the connection, since
skipping to change at page 32, line 11 skipping to change at page 32, line 32
See Appendix C.1.2 for more information on backwards compatibility See Appendix C.1.2 for more information on backwards compatibility
with HTTP/1.0 clients. with HTTP/1.0 clients.
9.4.1. Retrying Requests 9.4.1. Retrying Requests
Connections can be closed at any time, with or without intention. Connections can be closed at any time, with or without intention.
Implementations ought to anticipate the need to recover from Implementations ought to anticipate the need to recover from
asynchronous close events. 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 7.2.2 of [Semantics]. Section 8.2.2 of [Semantics].
9.4.2. Pipelining 9.4.2. Pipelining
A client that supports persistent connections MAY "pipeline" its A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 7.2.1 of parallel if they all have safe methods (Section 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.7).
Idempotent methods (Section 7.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
skipping to change at page 38, line 11 skipping to change at page 38, line 36
field (Section 9.1) that contains an "upgrade" connection option, in field (Section 9.1) that contains an "upgrade" connection option, in
order to prevent Upgrade from being accidentally forwarded by order to prevent Upgrade from being accidentally forwarded by
intermediaries that might not implement the listed protocols. A intermediaries that might not implement the listed protocols. A
server MUST ignore an Upgrade header field that is received in an server MUST ignore an Upgrade header field that is received in an
HTTP/1.0 request. HTTP/1.0 request.
A client cannot begin using an upgraded protocol on the connection A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client until it has completely sent the request message (i.e., the client
can't change the protocol it is sending in the middle of a message). can't change the protocol it is sending in the middle of a message).
If a server receives both an Upgrade and an Expect header field with If a server receives both an Upgrade and an Expect header field with
the "100-continue" expectation (Section 8.1.1 of [Semantics]), the the "100-continue" expectation (Section 9.1.1 of [Semantics]), the
server MUST send a 100 (Continue) response before sending a 101 server MUST send a 100 (Continue) response before sending a 101
(Switching Protocols) response. (Switching Protocols) response.
The Upgrade header field only applies to switching protocols on top The Upgrade header field only applies to switching protocols on top
of the existing connection; it cannot be used to switch the of the existing connection; it cannot be used to switch the
underlying connection (transport) protocol, nor to switch the underlying connection (transport) protocol, nor to switch the
existing communication to a different connection. For those existing communication to a different connection. For those
purposes, it is more appropriate to use a 3xx (Redirection) response purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 9.4 of [Semantics]). (Section 10.4 of [Semantics]).
9.9.1. Upgrade Protocol Names 9.9.1. Upgrade Protocol Names
This specification only defines the protocol name "HTTP" for use by This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 3.5 of [Semantics] and future updates to version rules of Section 4.2 of [Semantics] and future updates to
this specification. Additional protocol names ought to be registered this specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 9.9.2. using the registration procedure defined in Section 9.9.2.
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
| Name | Description | Expected Version | Reference | | Name | Description | Expected Version | Reference |
| | | Tokens | | | | | Tokens | |
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
| HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of | | HTTP | Hypertext | any DIGIT.DIGIT | Section 4.2 of |
| | Transfer Protocol | (e.g, "2.0") | [Semantics] | | | Transfer Protocol | (e.g, "2.0") | [Semantics] |
+------+-------------------+--------------------+-------------------+ +------+-------------------+--------------------+-------------------+
9.9.2. Upgrade Token Registry 9.9.2. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at protocols in the Upgrade header field. The registry is maintained at
<https://www.iana.org/assignments/http-upgrade-tokens>. <https://www.iana.org/assignments/http-upgrade-tokens>.
skipping to change at page 45, line 17 skipping to change at page 45, line 38
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e | (this | | HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e | (this |
| | 0x31 ("http/1.1") | specification) | | | 0x31 ("http/1.1") | specification) |
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
13. References 13. References
13.1. Normative References 13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-08 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-09 (work in
progress), May 2020. progress), July 2020.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 46, line 15 skipping to change at page 46, line 39
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
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. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-08 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-09
(work in progress), May 2020. (work in progress), July 2020.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
13.2. Informative References 13.2. Informative References
skipping to change at page 48, line 8 skipping to change at page 49, line 8
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[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 4.5 of [Semantics]. Section 5.5.1 of [Semantics].
BWS = <BWS, see [Semantics], Section 1.2.1> BWS = <BWS, see [Semantics], Section 1.2.1>
Connection = [ connection-option ] *( OWS "," OWS [ connection-option 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.2.1>
RWS = <RWS, see [Semantics], Section 1.2.1> RWS = <RWS, see [Semantics], Section 1.2.1>
TE = [ t-codings ] *( OWS "," OWS [ t-codings ] ) TE = [ t-codings *( OWS "," OWS t-codings ) ]
Transfer-Encoding = [ transfer-coding ] *( OWS "," OWS [ Transfer-Encoding = transfer-coding *( OWS "," OWS transfer-coding )
transfer-coding ] )
Upgrade = [ protocol ] *( OWS "," OWS [ protocol ] ) Upgrade = protocol *( OWS "," OWS protocol )
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = <absolute-path, see [Semantics], Section 2.4> absolute-path = <absolute-path, see [Semantics], Section 2.4>
asterisk-form = "*" asterisk-form = "*"
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
authority-form = authority authority-form = authority
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET chunk-data = 1*OCTET
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 4.4.1.3> comment = <comment, see [Semantics], Section 5.4.1.3>
connection-option = token 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 4.3> field-name = <field-name, see [Semantics], Section 5.3>
field-value = <field-value, see [Semantics], Section 4.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 4.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 = protocol-name [ "/" protocol-version ]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 4.4.1.2> quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
request-line = method SP request-target SP HTTP-version 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-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank t-ranking = OWS ";" OWS "q=" rank
token = <token, see [Semantics], Section 4.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
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
skipping to change at page 50, line 24 skipping to change at page 51, line 24
MIME protocol was used to construct the message. Use of the MIME- MIME protocol was used to construct the message. Use of the MIME-
Version header field indicates that the message is in full Version header field indicates that the message is in full
conformance with the MIME protocol (as defined in [RFC2045]). conformance with the MIME protocol (as defined in [RFC2045]).
Senders are responsible for ensuring full conformance (where Senders are responsible for ensuring full conformance (where
possible) when exporting HTTP messages to strict MIME environments. possible) when exporting HTTP messages to strict MIME environments.
B.2. Conversion to Canonical Form B.2. Conversion to Canonical Form
MIME requires that an Internet mail body part be converted to MIME requires that an Internet mail body part be converted to
canonical form prior to being transferred, as described in Section 4 canonical form prior to being transferred, as described in Section 4
of [RFC2049]. Section 6.1.1.2 of [Semantics] describes the forms of [RFC2049]. Section 7.1.1.2 of [Semantics] describes the forms
allowed for subtypes of the "text" media type when transmitted over allowed for subtypes of the "text" media type when transmitted over
HTTP. [RFC2046] requires that content with a type of "text" HTTP. [RFC2046] requires that content with a type of "text"
represent line breaks as CRLF and forbids the use of CR or LF outside represent line breaks as CRLF and forbids the use of CR or LF outside
of line break sequences. HTTP allows CRLF, bare CR, and bare LF to of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
indicate a line break within text content. indicate a line break within text content.
A proxy or gateway from HTTP to a strict MIME environment ought to A proxy or gateway from HTTP to a strict MIME environment ought to
translate all line breaks within text media types to the RFC 2049 translate all line breaks within text media types to the RFC 2049
canonical form of CRLF. Note, however, this might be complicated by canonical form of CRLF. Note, however, this might be complicated by
the presence of a Content-Encoding and by the fact that HTTP allows the presence of a Content-Encoding and by the fact that HTTP allows
the use of some charsets that do not use octets 13 and 10 to the use of some charsets that do not use octets 13 and 10 to
represent CR and LF, respectively. represent CR and LF, respectively.
Conversion will break any cryptographic checksums applied to the Conversion will break any cryptographic checksums applied to the
original content unless the original content is already in canonical original content unless the original content is already in canonical
form. Therefore, the canonical form is recommended for any content form. Therefore, the canonical form is recommended for any content
that uses such checksums in HTTP. that uses such checksums in HTTP.
B.3. Conversion of Date Formats B.3. Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (Section 10.1.1.1 of HTTP/1.1 uses a restricted set of date formats (Section 5.4.1.5 of
[Semantics]) to simplify the process of date comparison. Proxies and [Semantics]) to simplify the process of date comparison. Proxies and
gateways from other protocols ought to ensure that any Date header gateways from other protocols ought to ensure that any Date header
field present in a message conforms to one of the HTTP/1.1 formats field present in a message conforms to one of the HTTP/1.1 formats
and rewrite the date if necessary. and rewrite the date if necessary.
B.4. Conversion of Content-Encoding B.4. Conversion of Content-Encoding
MIME does not include any concept equivalent to HTTP/1.1's Content- MIME does not include any concept equivalent to HTTP/1.1's Content-
Encoding header field. Since this acts as a modifier on the media Encoding header field. Since this acts as a modifier on the media
type, proxies and gateways from HTTP to MIME-compliant protocols type, proxies and gateways from HTTP to MIME-compliant protocols
skipping to change at page 51, line 41 skipping to change at page 52, line 41
B.6. MHTML and Line Length Limitations B.6. MHTML and Line Length Limitations
HTTP implementations that share code with MHTML [RFC2557] HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type payload and, aside from the "multipart/byteranges" type
(Section 6.3.5 of [Semantics]), does not interpret the content or any (Section 7.3.5 of [Semantics]), does not interpret the content or any
MIME header lines that might be contained therein. MIME header lines that might be contained therein.
Appendix C. HTTP Version History Appendix C. HTTP Version History
HTTP has been in use since 1990. The first version, later referred HTTP has been in use since 1990. The first version, later referred
to as HTTP/0.9, was a simple protocol for hypertext data transfer to as HTTP/0.9, was a simple protocol for hypertext data transfer
across the Internet, using only a single request method (GET) and no across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics. transferred and modifiers placed on the request/response semantics.
skipping to change at page 52, line 40 skipping to change at page 53, 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 5.6 of [Semantics]), report an error if it is missing field (Section 6.6 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 54, line 5 skipping to change at page 55, line 5
message over a MIME-compliant protocol. message over a MIME-compliant protocol.
C.2. Changes from RFC 7230 C.2. Changes from RFC 7230
Most of the sections introducing HTTP's design goals, history, Most of the sections introducing HTTP's design goals, history,
architecture, conformance criteria, protocol versioning, URIs, architecture, conformance criteria, protocol versioning, URIs,
message routing, and header fields have been moved to [Semantics]. message routing, and header fields have been moved to [Semantics].
This document has been reduced to just the messaging syntax and This document has been reduced to just the messaging syntax and
connection management requirements specific to HTTP/1.1. connection management requirements specific to HTTP/1.1.
Prohibited generation of bare CRs outside of payload body.
(Section 2.2)
In the ABNF for chunked extensions, re-introduced (bad) whitespace In the ABNF for chunked extensions, re-introduced (bad) whitespace
around ";" and "=". Whitespace was removed in [RFC7230], but that around ";" and "=". Whitespace was removed in [RFC7230], but that
change was found to break existing implementations (see [Err4667]). change was found to break existing implementations (see [Err4667]).
(Section 7.1.1) (Section 7.1.1)
Trailer field semantics now transcend the specifics of chunked Trailer field semantics now transcend the specifics of chunked
encoding. The decoding algorithm for chunked (Section 7.1.3) has encoding. The decoding algorithm for chunked (Section 7.1.3) has
been updated to encourage storage/forwarding of trailer fields been updated to encourage storage/forwarding of trailer fields
separately from the header section, to only allow merging into the separately from the header section, to only allow merging into the
header section if the recipient knows the corresponding field header section if the recipient knows the corresponding field
skipping to change at page 57, line 45 skipping to change at page 59, line 5
o In Section 6.3, adjust requirements for handling multiple content- o In Section 6.3, adjust requirements for handling multiple content-
length values (<https://github.com/httpwg/http-core/issues/59>) length values (<https://github.com/httpwg/http-core/issues/59>)
o Throughout, replace "effective request URI" with "target URI" o Throughout, replace "effective request URI" with "target URI"
(<https://github.com/httpwg/http-core/issues/259>) (<https://github.com/httpwg/http-core/issues/259>)
o In Section 6.1, don't claim Transfer-Encoding is supported by o In Section 6.1, don't claim Transfer-Encoding is supported by
HTTP/2 or later (<https://github.com/httpwg/http-core/issues/297>) HTTP/2 or later (<https://github.com/httpwg/http-core/issues/297>)
D.10. Since draft-ietf-httpbis-messaging-08
o In Section 2.2, disallow bare CRs (<https://github.com/httpwg/
http-core/issues/31>)
o Appendix A now uses the sender variant of the "#" list expansion
(<https://github.com/httpwg/http-core/issues/192>)
o In Section 5, adjust IANA "Close" entry for new registry format
(<https://github.com/httpwg/http-core/issues/273>)
Index Index
A A
absolute-form (of request-target) 11 absolute-form (of request-target) 11
application/http Media Type 40 application/http Media Type 41
asterisk-form (of request-target) 12 asterisk-form (of request-target) 12
authority-form (of request-target) 12 authority-form (of request-target) 12
C C
Connection header field 28, 34 Connection header field 29, 34
Content-Length header field 19 Content-Length header field 19
Content-Transfer-Encoding header field 51 Content-Transfer-Encoding header field 52
chunked (Coding Format) 17, 19 chunked (Coding Format) 18, 20
chunked (transfer coding) 22 chunked (transfer coding) 23
close 28, 34 close 29, 34
compress (transfer coding) 25 compress (transfer coding) 26
D D
deflate (transfer coding) 25 deflate (transfer coding) 26
F F
Fields Fields
Connection 28 Connection 29
MIME-Version 50 MIME-Version 51
TE 26 TE 27
Transfer-Encoding 17 Transfer-Encoding 18
Upgrade 36 Upgrade 36
G G
Grammar Grammar
absolute-form 10-11 absolute-form 10-11
ALPHA 5 ALPHA 5
asterisk-form 10, 12 asterisk-form 10, 12
authority-form 10, 12 authority-form 10, 12
chunk 23 chunk 23
chunk-data 23 chunk-data 23
chunk-ext 23 chunk-ext 23-24
chunk-ext-name 23 chunk-ext-name 24
chunk-ext-val 23 chunk-ext-val 24
chunk-size 23 chunk-size 23
chunked-body 23 chunked-body 23
Connection 29 Connection 30
connection-option 29 connection-option 30
CR 5 CR 5
CRLF 5 CRLF 5
CTL 5 CTL 5
DIGIT 5 DIGIT 5
DQUOTE 5 DQUOTE 5
field-line 15, 24 field-line 15, 25
field-name 15 field-name 15
field-value 15 field-value 15
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
HTTP-message 6 HTTP-message 6
HTTP-name 8 HTTP-name 8
HTTP-version 8 HTTP-version 8
last-chunk 23 last-chunk 23
LF 5 LF 5
message-body 17 message-body 17
method 9 method 10
obs-fold 16 obs-fold 16
OCTET 5 OCTET 5
origin-form 10 origin-form 10
rank 26 rank 27
reason-phrase 15 reason-phrase 15
request-line 9 request-line 9
request-target 10 request-target 10
SP 5 SP 5
start-line 6 start-line 6
status-code 14 status-code 15
status-line 14 status-line 14
t-codings 26 t-codings 27
t-ranking 26 t-ranking 27
TE 26 TE 27
trailer-section 23-24 trailer-section 23, 25
transfer-coding 22 transfer-coding 22
Transfer-Encoding 18 Transfer-Encoding 18
transfer-parameter 22 transfer-parameter 22
Upgrade 36 Upgrade 37
VCHAR 5 VCHAR 5
gzip (transfer coding) 25 gzip (transfer coding) 26
H H
Header Fields Header Fields
Connection 28 Connection 29
MIME-Version 50 MIME-Version 51
TE 26 TE 27
Transfer-Encoding 17 Transfer-Encoding 18
Upgrade 36 Upgrade 36
header line 6 header line 6
header section 6 header section 6
headers 6 headers 6
M M
MIME-Version header field 50 MIME-Version header field 51
Media Type Media Type
application/http 40 application/http 41
message/http 39 message/http 40
message/http Media Type 39 message/http Media Type 40
method 9 method 10
O O
origin-form (of request-target) 10 origin-form (of request-target) 10
R R
request-target 10 request-target 10
T T
TE header field 26 TE header field 27
Transfer-Encoding header field 17 Transfer-Encoding header field 18
U U
Upgrade header field 36 Upgrade header field 36
X X
x-compress (transfer coding) 25 x-compress (transfer coding) 26
x-gzip (transfer coding) 25 x-gzip (transfer coding) 26
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
 End of changes. 97 change blocks. 
169 lines changed or deleted 189 lines changed or added

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