draft-ietf-httpbis-semantics-01.txt   draft-ietf-httpbis-semantics-02.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7230,7231,7232,7233,7235 (if M. Nottingham, Ed. Obsoletes: 7230,7231,7232,7233,7235 (if M. Nottingham, Ed.
approved) Fastly approved) Fastly
Intended status: Standards Track J. Reschke, Ed. Intended status: Standards Track J. Reschke, Ed.
Expires: December 2, 2018 greenbytes Expires: January 3, 2019 greenbytes
May 31, 2018 July 2, 2018
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-01 draft-ietf-httpbis-semantics-02
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 G.2. The changes in this draft are summarized in Appendix G.3.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 2, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 23 skipping to change at page 4, line 23
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 68
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 69 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 69
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 70
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 72 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 72
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 72 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 72
7.4.2. Considerations for New Methods . . . . . . . . . . . 72 7.4.2. Considerations for New Methods . . . . . . . . . . . 72
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 73 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 73
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 73 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 73
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 73 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 74
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 76 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 76
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 76 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 76
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 77 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 77
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 78 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 78
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 80 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 80
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 81 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 81
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 82 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 82
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 83 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 83
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 84 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 85
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 86 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 87 8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 87
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 88 8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 88
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 88 8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 88
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 90 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 90
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 91 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 91
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 93 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 93
8.5. Authentication Credentials . . . . . . . . . . . . . . . 94 8.5. Authentication Credentials . . . . . . . . . . . . . . . 94
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 94 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 94
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 96 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 96
skipping to change at page 6, line 44 skipping to change at page 6, line 44
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 152 12.9. Disclosure of Fragment after Redirects . . . . . . . . . 152
12.10. Disclosure of Product Information . . . . . . . . . . . 153 12.10. Disclosure of Product Information . . . . . . . . . . . 153
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 153 12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 153
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 154 12.12. Validator Retention . . . . . . . . . . . . . . . . . . 154
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 154 12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 154
12.14. Authentication Considerations . . . . . . . . . . . . . 155 12.14. Authentication Considerations . . . . . . . . . . . . . 155
12.14.1. Confidentiality of Credentials . . . . . . . . . . 155 12.14.1. Confidentiality of Credentials . . . . . . . . . . 155
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 155 12.14.2. Credentials and Idle Clients . . . . . . . . . . . 155
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 156 12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 156
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 156 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 156
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 157 13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 156
13.2. Method Registration . . . . . . . . . . . . . . . . . . 157 13.2. Method Registration . . . . . . . . . . . . . . . . . . 157
13.3. Status Code Registration . . . . . . . . . . . . . . . . 157 13.3. Status Code Registration . . . . . . . . . . . . . . . . 157
13.4. Header Field Registration . . . . . . . . . . . . . . . 157 13.4. Header Field Registration . . . . . . . . . . . . . . . 157
13.5. Authentication Scheme Registration . . . . . . . . . . . 157 13.5. Authentication Scheme Registration . . . . . . . . . . . 157
13.6. Content Coding Registration . . . . . . . . . . . . . . 157 13.6. Content Coding Registration . . . . . . . . . . . . . . 157
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 157 13.7. Range Unit Registration . . . . . . . . . . . . . . . . 157
13.8. Media Type Registration . . . . . . . . . . . . . . . . 158 13.8. Media Type Registration . . . . . . . . . . . . . . . . 157
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 158 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 158
14.1. Normative References . . . . . . . . . . . . . . . . . . 158 14.1. Normative References . . . . . . . . . . . . . . . . . . 158
14.2. Informative References . . . . . . . . . . . . . . . . . 159 14.2. Informative References . . . . . . . . . . . . . . . . . 159
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 165 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 165
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 169 Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 169
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 170 Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 170
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 170 Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 170
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 170 Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 170
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 170 Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 170
Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 170 Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 170
G.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 170 G.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 170
G.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 170 G.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 170
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 G.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 171
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 179 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 179 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 180
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 180
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" (this document) o "HTTP Semantics" (this document)
skipping to change at page 8, line 42 skipping to change at page 8, line 42
codes to indicate a machine-readable response (Section 9), and the codes to indicate a machine-readable response (Section 9), and the
meaning of other control data and resource metadata that might be meaning of other control data and resource metadata that might be
given in response header fields (Section 10). given in response header fields (Section 10).
This document also defines representation metadata that describe how This document also defines representation metadata that describe how
a payload is intended to be interpreted by a recipient, the request a payload is intended to be interpreted by a recipient, the request
header fields that might influence content selection, and the various header fields that might influence content selection, and the various
selection algorithms that are collectively referred to as "content selection algorithms that are collectively referred to as "content
negotiation" (Section 6.4). negotiation" (Section 6.4).
This document defines HTTP/1.1 range requests, partial responses, and This document defines HTTP range requests, partial responses, and the
the multipart/byteranges media type. multipart/byteranges media type.
This document obsoletes the portions of RFC 7230 that are independent This document obsoletes the portions of RFC 7230 that are independent
of the HTTP/1.1 messaging syntax and connection management, with the of the HTTP/1.1 messaging syntax and connection management, with the
changes being summarized in Appendix B. The other parts of RFC 7230 changes being summarized in Appendix B. The other parts of RFC 7230
are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This document are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This document
also obsoletes RFC 7231 (see Appendix C), RFC 7232 (see Appendix D), also obsoletes RFC 7231 (see Appendix C), RFC 7232 (see Appendix D),
RFC 7233 (see Appendix E), and RFC 7235 (see Appendix F). RFC 7233 (see Appendix E), and RFC 7235 (see Appendix F).
1.1. Requirements Notation 1.1. Requirements Notation
skipping to change at page 9, line 31 skipping to change at page 9, line 31
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
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). [[CREF1: Range also uses VCHAR (any visible US-ASCII character).
CHAR, which is probably a bug.]]
The rules below are defined in [Messaging]: The rules below are defined in [Messaging]:
obs-fold = <obs-fold, see [Messaging], Section 5.2> obs-fold = <obs-fold, see [Messaging], Section 5.2>
protocol-name = <protocol-name, see [Messaging], Section 9.7> protocol-name = <protocol-name, see [Messaging], Section 9.7>
protocol-version = <protocol-version, see [Messaging], Section 9.7> protocol-version = <protocol-version, see [Messaging], Section 9.7>
request-target = <request-target, see [Messaging], Section 3.2> request-target = <request-target, see [Messaging], Section 3.2>
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
skipping to change at page 15, line 41 skipping to change at page 15, line 41
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 2.4. Section 2.4.
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 7) and a few request- semantics in the request method (Section 7) and a few request-
modifying header fields (Section 8). If there is a conflict between modifying header fields (Section 8). If there is a conflict between
the method semantics and any semantic implied by the URI itself, as the method semantics and any semantic implied by the URI itself, as
described in Section 7.2.1, the method semantics take precedence. described in Section 7.2.1, the method semantics take precedence.
IANA maintains the registry of URI Schemes [BCP115] at IANA maintains the registry of URI Schemes [BCP35] at
<https://www.iana.org/assignments/uri-schemes/>. [[CREF2: Although <https://www.iana.org/assignments/uri-schemes/>. Although requests
requests might target any URI scheme, the following schemes are might target any URI scheme, the following schemes are inherent to
inherent to HTTP servers:]] HTTP servers:
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
| URI Scheme | Description | Reference | | URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.5.1 | | http | Hypertext Transfer Protocol | Section 2.5.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.5.2 | | https | Hypertext Transfer Protocol Secure | Section 2.5.2 |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
2.5.1. http URI Scheme 2.5.1. http URI Scheme
skipping to change at page 21, line 18 skipping to change at page 21, line 18
The HTTP version number consists of two decimal digits separated by a The HTTP version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version") "." (period or decimal point). The first digit ("major version")
indicates the HTTP messaging syntax, whereas the second digit ("minor indicates the HTTP messaging syntax, whereas the second digit ("minor
version") indicates the highest minor version within that major version") indicates the highest minor version within that major
version to which the sender is conformant and able to understand for version to which the sender is conformant and able to understand for
future communication. future communication.
The protocol version as a whole indicates the sender's conformance The protocol version as a whole indicates the sender's conformance
with the set of requirements laid out in that version's corresponding with the set of requirements laid out in that version's corresponding
specification of HTTP. [[CREF3: For example, the version "HTTP/1.1" specification of HTTP. For example, the version "HTTP/1.1" is
is defined by the combined specifications of this document, "HTTP defined by the combined specifications of this document, "HTTP
Caching" [Caching], and "HTTP/1.1 Messaging" [Messaging]. ]] Caching" [Caching], and "HTTP/1.1 Messaging" [Messaging].
The minor version advertises the sender's communication capabilities The minor version advertises the sender's communication capabilities
even when the sender is only using a backwards-compatible subset of even when the sender is only using a backwards-compatible subset of
the protocol, thereby letting the recipient know that more advanced the protocol, thereby letting the recipient know that more advanced
features can be used in response (by servers) or in future requests features can be used in response (by servers) or in future requests
(by clients). (by clients).
A client SHOULD send a request version equal to the highest version A client SHOULD send a request version equal to the highest version
to which the client is conformant and whose major version is no to which the client is conformant and whose major version is no
higher than the highest version supported by the server, if this is higher than the highest version supported by the server, if this is
skipping to change at page 22, line 15 skipping to change at page 22, line 15
When an HTTP message is received with a major version number that the When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the recipient implements, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards-compatible to be safely processed by any
implementation of the same major version. implementation of the same major version.
[[CREF4: When a major version of HTTP does not define any minor [[CREF1: When a major version of HTTP does not define any minor
versions, the minor version "0" is implied and ought to be used when versions, the minor version "0" is implied and ought to be used when
referring to that protocol within a protocol element that requires referring to that protocol within a protocol element that requires
sending a minor version. ]] sending a minor version. ]]
4. Message Abstraction 4. Message Abstraction
[[CREF5: Each major version of HTTP defines its own syntax for the Each major version of HTTP defines its own syntax for the inclusion
inclusion of information in messages. Nevertheless, a common of information in messages. Nevertheless, a common abstraction is
abstraction is that a message includes some form of envelope/framing, that a message includes some form of envelope/framing, a potential
a potential set of named data fields, and a potential body. This set of named data fields, and a potential body. This section defines
section defines the abstraction for message fields as field-name and the abstraction for message fields as field-name and field-value
field-value pairs. ]] pairs.
4.1. Field Names 4.1. Field Names
Header fields are key:value pairs that can be used to communicate Header fields are key:value pairs that can be used to communicate
data about the message, its payload, the target resource, or the data about the message, its payload, the target resource, or the
connection (i.e., control data). connection (i.e., control data).
The requirements for header field names are defined in [BCP90]. The requirements for header field names are defined in [BCP90].
The field-name token labels the corresponding field-value as having The field-name token labels the corresponding field-value as having
skipping to change at page 26, line 20 skipping to change at page 26, line 20
registered field name, wherein the rule defines the valid grammar for registered field name, wherein the rule defines the valid grammar for
that field's corresponding field values (i.e., after the field-value that field's corresponding field values (i.e., after the field-value
has been extracted by a generic field parser). has been extracted by a generic field parser).
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). [[CREF6: This document assumes that or horizontal tab (obs-fold). [[CREF2: This document assumes that
any such obs-fold has been replaced with one or more SP octets prior any such obs-fold has been replaced with one or more SP octets prior
to interpreting the field value, as described in Section 5.2 of to interpreting the field value, as described in Section 5.2 of
[Messaging].]] [Messaging].]]
Historically, HTTP has allowed field content with text in the Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII]. field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field US-ASCII octets. A recipient SHOULD treat other octets in field
skipping to change at page 28, line 9 skipping to change at page 28, line 9
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except delimiters ; any VCHAR, except delimiters
A string of text is parsed as a single value if it is quoted using A string of text is parsed as a single value if it is quoted using
double-quote marks. double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF obs-text = %x80-FF
Comments can be included in some HTTP header fields by surrounding Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition. fields containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
The backslash octet ("\") can be used as a single-octet quoting The backslash octet ("\") can be used as a single-octet quoting
skipping to change at page 28, line 38 skipping to change at page 28, line 38
that string. A sender SHOULD NOT generate a quoted-pair in a comment that string. A sender SHOULD NOT generate a quoted-pair in a comment
except where necessary to quote parentheses ["(" and ")"] and except where necessary to quote parentheses ["(" and ")"] and
backslash octets occurring within that comment. backslash octets occurring within that comment.
4.2.4. Designing New Field Values 4.2.4. Designing New Field Values
New header field values typically have their syntax defined using New header field values typically have their syntax defined using
ABNF ([RFC5234]), using the extension defined in Section 11 as ABNF ([RFC5234]), using the extension defined in Section 11 as
necessary, and are usually constrained to the range of US-ASCII necessary, and are usually constrained to the range of US-ASCII
characters. Header fields needing a greater range of characters can characters. Header fields needing a greater range of characters can
use an encoding such as the one defined in [RFC5987]. use an encoding such as the one defined in [RFC8187].
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 5.1 of [Messaging]). Field definitions where field parsing (Section 5.1 of [Messaging]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
use a container syntax such as quoted-string (Section 4.2.3). use a container syntax such as quoted-string (Section 4.2.3).
Because commas (",") are used as a generic delimiter between field- Because commas (",") are used as a generic delimiter between field-
values, they need to be treated with care if they are allowed in the values, they need to be treated with care if they are allowed in the
field-value. Typically, components that might contain a comma are field-value. Typically, components that might contain a comma are
protected with double-quotes using the quoted-string ABNF production. protected with double-quotes using the quoted-string ABNF production.
skipping to change at page 30, line 7 skipping to change at page 30, line 7
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
; optional whitespace ; optional whitespace
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
; required whitespace ; required whitespace
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
4.4. Trailer 4.4. Trailer
[[CREF7: The "Trailer" header field in a message indicates fields [[CREF3: The "Trailer" header field in a message indicates fields
that the sender anticipates sending after the message header block that the sender anticipates sending after the message header block
(i.e., during or after the payload is sent). This is typically used (i.e., during or after the payload is sent). This is typically used
to supply metadata that might be dynamically generated while the data to supply metadata that might be dynamically generated while the data
is sent, such as a message integrity check, digital signature, or is sent, such as a message integrity check, digital signature, or
post-processing status. ]] post-processing status. ]]
Trailer = 1#field-name Trailer = 1#field-name
[[CREF8: How, where, and when trailer fields might be sent depends on [[CREF4: How, where, and when trailer fields might be sent depends on
both the protocol in use (HTTP version and/or transfer coding) and both the protocol in use (HTTP version and/or transfer coding) and
the semantics of each named header field. Many header fields cannot the semantics of each named header field. Many header fields cannot
be processed outside the header section because their evaluation is be processed outside the header section because their evaluation is
necessary for message routing, authentication, or configuration prior necessary for message routing, authentication, or configuration prior
to receiving the representation data. ]] to receiving the representation data. ]]
5. Message Routing 5. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
skipping to change at page 31, line 33 skipping to change at page 31, line 33
"https" (Section 2.5.2) schemes. "https" (Section 2.5.2) schemes.
HTTP requirements regarding connection management are defined in HTTP requirements regarding connection management are defined in
Section 9 of [Messaging]. Section 9 of [Messaging].
5.3. Effective Request URI 5.3. Effective Request URI
Once an inbound connection is obtained, the client sends an HTTP Once an inbound connection is obtained, the client sends an HTTP
request message (Section 2 of [Messaging]). request message (Section 2 of [Messaging]).
[[CREF9: Depending on the nature of the request, the client's target Depending on the nature of the request, the client's target URI might
URI might be split into components and transmitted (or implied) be split into components and transmitted (or implied) within various
within various parts of a request message. These parts are parts of a request message. These parts are recombined by each
recombined by each recipient, in accordance with their local recipient, in accordance with their local configuration and incoming
configuration and incoming connection context, to form an "effective connection context, to form an "effective request URI" for
request URI" for identifying the intended target resource with identifying the intended target resource with respect to that server.
respect to that server. Section 3.3 of [Messaging] defines how a Section 3.3 of [Messaging] defines how a server determines the
server determines the effective request URI for an HTTP/1.1 effective request URI for an HTTP/1.1 request.
request.]]
For a user agent, the effective request URI is the target URI. For a user agent, the effective request URI is the target URI.
Once the effective request URI has been constructed, an origin server Once the effective request URI has been constructed, an origin server
needs to decide whether or not to provide service for that URI via needs to decide whether or not to provide service for that URI via
the connection in which the request was received. For example, the the connection in which the request was received. For example, the
request might have been misdirected, deliberately or accidentally, request might have been misdirected, deliberately or accidentally,
such that the information within a received request-target or Host such that the information within a received request-target or Host
header field differs from the host or port upon which the connection header field differs from the host or port upon which the connection
has been made. If the connection is from a trusted gateway, that has been made. If the connection is from a trusted gateway, that
skipping to change at page 39, line 48 skipping to change at page 39, line 48
one or more representations within a single message body. All one or more representations within a single message body. All
multipart types share a common syntax, as defined in Section 5.1.1 of multipart types share a common syntax, as defined in Section 5.1.1 of
[RFC2046], and include a boundary parameter as part of the media type [RFC2046], and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender MUST value. The message body is itself a protocol element; a sender MUST
generate only CRLF to represent line breaks between body parts. generate only CRLF to represent line breaks between body parts.
HTTP message framing does not use the multipart boundary as an HTTP message framing does not use the multipart boundary as an
indicator of message body length, though it might be used by indicator of message body length, though it might be used by
implementations that generate or process the payload. For example, implementations that generate or process the payload. For example,
the "multipart/form-data" type is often used for carrying form data the "multipart/form-data" type is often used for carrying form data
in a request, as described in [RFC2388], and the "multipart/ in a request, as described in [RFC7578], and the "multipart/
byteranges" type is defined by this specification for use in some 206 byteranges" type is defined by this specification for use in some 206
(Partial Content) responses Section 9.3.7. (Partial Content) responses (see Section 9.3.7).
6.1.2. Content Codings 6.1.2. Content Codings
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are been or can be applied to a representation. Content codings are
primarily used to allow a representation to be compressed or primarily used to allow a representation to be compressed or
otherwise usefully transformed without losing the identity of its otherwise usefully transformed without losing the identity of its
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the final recipient. only decoded by the final recipient.
skipping to change at page 41, line 41 skipping to change at page 41, line 41
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (Section 7 of [Messaging]), unless the encoding codings (Section 7 of [Messaging]), 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 6.1.2). codings defined in Section 6.1.2).
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
Section 4.1 of [RFC5226]) and MUST conform to the purpose of content Section 4.8 of [RFC8126]) and MUST conform to the purpose of content
coding defined in Section 6.1.2. coding defined in Section 6.1.2.
6.1.3. Language Tags 6.1.3. Language Tags
A language tag, as defined in [RFC5646], identifies a natural A language tag, as defined in [RFC5646], identifies a natural
language spoken, written, or otherwise conveyed by human beings for language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer communication of information to other human beings. Computer
languages are explicitly excluded. languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content- HTTP uses language tags within the Accept-Language and Content-
skipping to change at page 45, line 9 skipping to change at page 45, line 9
maintained at <https://www.iana.org/assignments/http-parameters>. maintained at <https://www.iana.org/assignments/http-parameters>.
Registration of an HTTP Range Unit MUST include the following fields: Registration of an HTTP Range Unit MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC5226], Section 4.1). [RFC8126], Section 4.8).
6.2. Representation Metadata 6.2. Representation Metadata
Representation header fields provide metadata about the Representation header fields provide metadata about the
representation. When a message includes a payload body, the representation. When a message includes a payload body, the
representation header fields describe how to interpret the representation header fields describe how to interpret the
representation data enclosed in the payload body. In a response to a representation data enclosed in the payload body. In a response to a
HEAD request, the representation header fields describe the HEAD request, the representation header fields describe the
representation data that would have been enclosed in the payload body representation data that would have been enclosed in the payload body
if the same request had been a GET. if the same request had been a GET.
skipping to change at page 48, line 12 skipping to change at page 48, line 12
linguistic audiences. An example would be a beginner's language linguistic audiences. An example would be a beginner's language
primer, such as "A First Lesson in Latin", which is clearly intended primer, such as "A First Lesson in Latin", which is clearly intended
to be used by an English-literate audience. In this case, the to be used by an English-literate audience. In this case, the
Content-Language would properly only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
6.2.4. Content-Length 6.2.4. Content-Length
[[CREF10: The "Content-Length" header field indicates the number of [[CREF5: The "Content-Length" header field indicates the number of
data octets (body length) for the representation. In some cases, data octets (body length) for the representation. In some cases,
Content-Length is used to define or estimate message framing. ]] Content-Length is used to define or estimate message framing. ]]
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
skipping to change at page 53, line 31 skipping to change at page 53, line 31
byte-content-range = bytes-unit SP byte-content-range = bytes-unit SP
( byte-range-resp / unsatisfied-range ) ( byte-range-resp / unsatisfied-range )
byte-range-resp = byte-range "/" ( complete-length / "*" ) byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos byte-range = first-byte-pos "-" last-byte-pos
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
complete-length = 1*DIGIT complete-length = 1*DIGIT
other-content-range = other-range-unit SP other-range-resp other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR other-range-resp = *VCHAR
If a 206 (Partial Content) response contains a Content-Range header If a 206 (Partial Content) response contains a Content-Range header
field with a range unit (Section 6.1.4) that the recipient does not field with a range unit (Section 6.1.4) that the recipient does not
understand, the recipient MUST NOT attempt to recombine it with a understand, the recipient MUST NOT attempt to recombine it with a
stored representation. A proxy that receives such a message SHOULD stored representation. A proxy that receives such a message SHOULD
forward it downstream. forward it downstream.
For byte ranges, a sender SHOULD indicate the complete length of the For byte ranges, a sender SHOULD indicate the complete length of the
representation from which the range has been extracted, unless the representation from which the range has been extracted, unless the
complete length is unknown or difficult to determine. An asterisk complete length is unknown or difficult to determine. An asterisk
skipping to change at page 68, line 38 skipping to change at page 68, line 38
previously created using a PUT request, or identified via the previously created using a PUT request, or identified via the
Location header field after a 201 (Created) response to a POST Location header field after a 201 (Created) response to a POST
request, might allow a corresponding DELETE request to undo those request, might allow a corresponding DELETE request to undo those
actions. Similarly, custom user agent implementations that implement actions. Similarly, custom user agent implementations that implement
an authoring function, such as revision control clients using HTTP an authoring function, such as revision control clients using HTTP
for remote operations, might use DELETE based on an assumption that for remote operations, might use DELETE based on an assumption that
the server's URI space has been crafted to correspond to a version the server's URI space has been crafted to correspond to a version
repository. repository.
If a DELETE method is successfully applied, the origin server SHOULD If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed send
but has not yet been enacted, a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied, o a 202 (Accepted) status code if the action will likely succeed but
or a 200 (OK) status code if the action has been enacted and the has not yet been enacted,
response message includes a representation describing the status.
o a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or
o a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.
A payload within a DELETE request message has no defined semantics; A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing sending a payload body on a DELETE request might cause some existing
implementations to reject the request. implementations to reject the request.
Responses to the DELETE method are not cacheable. If a DELETE Responses to the DELETE method are not cacheable. If a DELETE
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
invalidated (see Section 4.4 of [Caching]). invalidated (see Section 4.4 of [Caching]).
skipping to change at page 72, line 31 skipping to change at page 72, line 35
o Method Name (see Section 7) o Method Name (see Section 7)
o Safe ("yes" or "no", see Section 7.2.1) o Safe ("yes" or "no", see Section 7.2.1)
o Idempotent ("yes" or "no", see Section 7.2.2) o Idempotent ("yes" or "no", see Section 7.2.2)
o Pointer to specification text o Pointer to specification text
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC5226], Section 4.1). [RFC8126], Section 4.8).
7.4.2. Considerations for New Methods 7.4.2. Considerations for New Methods
Standardized methods are generic; that is, they are potentially Standardized methods are generic; that is, they are potentially
applicable to any resource, not just one particular media type, kind applicable to any resource, not just one particular media type, kind
of resource, or application. As such, it is preferred that new of resource, or application. As such, it is preferred that new
methods be registered in a document that isn't specific to a single methods be registered in a document that isn't specific to a single
application or data format, since orthogonal technologies deserve application or data format, since orthogonal technologies deserve
orthogonal specification. orthogonal specification.
skipping to change at page 98, line 33 skipping to change at page 98, line 33
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Authentication Scheme Name o Authentication Scheme Name
o Pointer to specification text o Pointer to specification text
o Notes (optional) o Notes (optional)
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC5226], Section 4.1). [RFC8126], Section 4.8).
8.5.5.2. Considerations for New Authentication Schemes 8.5.5.2. Considerations for New Authentication Schemes
There are certain aspects of the HTTP Authentication framework that There are certain aspects of the HTTP Authentication framework that
put constraints on how new authentication schemes can work: put constraints on how new authentication schemes can work:
o HTTP authentication is presumed to be stateless: all of the o HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided information necessary to authenticate a request MUST be provided
in the request, rather than be dependent on the server remembering in the request, rather than be dependent on the server remembering
prior requests. Authentication based on, or bound to, the prior requests. Authentication based on, or bound to, the
skipping to change at page 103, line 21 skipping to change at page 103, line 21
Likewise, implementations are encouraged not to use the product Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. If a user with them, as this circumvents the purpose of the field. If a user
agent masquerades as a different user agent, recipients can assume agent masquerades as a different user agent, recipients can assume
that the user intentionally desires to see responses tailored for that the user intentionally desires to see responses tailored for
that identified user agent, even if they might not work as well for that identified user agent, even if they might not work as well for
the actual user agent being used. the actual user agent being used.
9. Response Status Codes 9. Response Status Codes
The status-code element is a three-digit integer code giving the The (response) status code is a three-digit integer code giving the
result of the attempt to understand and satisfy the request. result of the attempt to understand and satisfy the request.
HTTP status codes are extensible. HTTP clients are not required to HTTP status codes are extensible. HTTP clients are not required to
understand the meaning of all registered status codes, though such understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a the x00 status code of that class, with the exception that a
recipient MUST NOT cache a response with an unrecognized status code. recipient MUST NOT cache a response with an unrecognized status code.
For example, if an unrecognized status code of 471 is received by a For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 (Bad request and treat the response as if it had received a 400 (Bad
Request) status code. The response message will usually contain a Request) status code. The response message will usually contain a
representation that explains the status. representation that explains the status.
The first digit of the status-code defines the class of response. The first digit of the status code defines the class of response.
The last two digits do not have any categorization role. There are The last two digits do not have any categorization role. There are
five values for the first digit: five values for the first digit:
o 1xx (Informational): The request was received, continuing process o 1xx (Informational): The request was received, continuing process
o 2xx (Successful): The request was successfully received, o 2xx (Successful): The request was successfully received,
understood, and accepted understood, and accepted
o 3xx (Redirection): Further action needs to be taken in order to o 3xx (Redirection): Further action needs to be taken in order to
complete the request complete the request
skipping to change at page 110, line 23 skipping to change at page 110, line 23
indicate a zero-length payload for the response by including a indicate a zero-length payload for the response by including a
Transfer-Encoding header field with a value of chunked and a message Transfer-Encoding header field with a value of chunked and a message
body consisting of a single chunk of zero-length; or, c) close the body consisting of a single chunk of zero-length; or, c) close the
connection immediately after sending the blank line terminating the connection immediately after sending the blank line terminating the
header section. header section.
9.3.7. 206 Partial Content 9.3.7. 206 Partial Content
The 206 (Partial Content) status code indicates that the server is The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that transferring one or more parts of the selected representation.
correspond to the satisfiable ranges found in the request's Range
header field (Section 8.3).
When a 206 response is generated, the server MUST generate the When a 206 response is generated, the server MUST generate the
following header fields, in addition to those required in the following header fields, in addition to those required in the
subsections below, if the field would have been sent in a 200 (OK) subsections below, if the field would have been sent in a 200 (OK)
response to the same request: Date, Cache-Control, ETag, Expires, response to the same request: Date, Cache-Control, ETag, Expires,
Content-Location, and Vary. Content-Location, and Vary.
If a 206 is generated in response to a request with an If-Range If a 206 is generated in response to a request with an If-Range
header field, the sender SHOULD NOT generate other representation header field, the sender SHOULD NOT generate other representation
header fields beyond those required, because the client is understood header fields beyond those required, because the client is understood
skipping to change at page 113, line 31 skipping to change at page 113, line 31
(Partial Content) responses, each with one continuous range that is (Partial Content) responses, each with one continuous range that is
indicated by a Content-Range header field. indicated by a Content-Range header field.
9.4. Redirection 3xx 9.4. Redirection 3xx
The 3xx (Redirection) class of status code indicates that further The 3xx (Redirection) class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the action needs to be taken by the user agent in order to fulfill the
request. If a Location header field (Section 10.1.2) is provided, request. If a Location header field (Section 10.1.2) is provided,
the user agent MAY automatically redirect its request to the URI the user agent MAY automatically redirect its request to the URI
referenced by the Location field value, even if the specific status referenced by the Location field value, even if the specific status
code is not understood. Automatic redirection needs to done with code is not understood. Automatic redirection needs to be done with
care for methods not known to be safe, as defined in Section 7.2.1, care for methods not known to be safe, as defined in Section 7.2.1,
since the user might not wish to redirect an unsafe request. since the user might not wish to redirect an unsafe request.
There are several types of redirects: There are several types of redirects:
1. Redirects that indicate the resource might be available at a 1. Redirects that indicate the resource might be available at a
different URI, as provided by the Location field, as in the different URI, as provided by the Location field, as in the
status codes 301 (Moved Permanently), 302 (Found), and 307 status codes 301 (Moved Permanently), 302 (Found), and 307
(Temporary Redirect). (Temporary Redirect).
skipping to change at page 115, line 31 skipping to change at page 115, line 31
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
Note: The original proposal for the 300 status code defined the Note: The original proposal for the 300 status code defined the
URI header field as providing a list of alternative URI header field as providing a list of alternative
representations, such that it would be usable for 200, 300, and representations, such that it would be usable for 200, 300, and
406 responses and be transferred in responses to the HEAD method. 406 responses and be transferred in responses to the HEAD method.
However, lack of deployment and disagreement over syntax led to However, lack of deployment and disagreement over syntax led to
both URI and Alternates (a subsequent proposal) being dropped from both URI and Alternates (a subsequent proposal) being dropped from
this specification. It is possible to communicate the list using this specification. It is possible to communicate the list using
a set of Link header fields [RFC5988], each with a relationship of a set of Link header fields [RFC8288], each with a relationship of
"alternate", though deployment is a chicken-and-egg problem. "alternate", though deployment is a chicken-and-egg problem.
9.4.2. 301 Moved Permanently 9.4.2. 301 Moved Permanently
The 301 (Moved Permanently) status code indicates that the target The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link Clients with link-editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new references to the effective request URI to one or more of the new
references sent by the server, where possible. references sent by the server, where possible.
skipping to change at page 118, line 28 skipping to change at page 118, line 28
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response payload usually contains a short hypertext note with a response payload usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
Note: This status code is similar to 302 (Found), except that it Note: This status code is similar to 302 (Found), except that it
does not allow changing the request method from POST to GET. This does not allow changing the request method from POST to GET. This
specification defines no equivalent counterpart for 301 (Moved specification defines no equivalent counterpart for 301 (Moved
Permanently) ([RFC7238], however, defines the status code 308 Permanently) ([RFC7538], however, defines the status code 308
(Permanent Redirect) for this purpose). (Permanent Redirect) for this purpose).
9.5. Client Error 4xx 9.5. Client Error 4xx
The 4xx (Client Error) class of status code indicates that the client The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method. condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user. User agents SHOULD display any included representation to the user.
skipping to change at page 122, line 9 skipping to change at page 122, line 9
The 411 (Length Required) status code indicates that the server The 411 (Length Required) status code indicates that the server
refuses to accept the request without a defined Content-Length refuses to accept the request without a defined Content-Length
(Section 6.2.4). The client MAY repeat the request if it adds a (Section 6.2.4). The client MAY repeat the request if it adds a
valid Content-Length header field containing the length of the valid Content-Length header field containing the length of the
message body in the request message. message body in the request message.
9.5.13. 412 Precondition Failed 9.5.13. 412 Precondition Failed
The 412 (Precondition Failed) status code indicates that one or more The 412 (Precondition Failed) status code indicates that one or more
conditions given in the request header fields evaluated to false when conditions given in the request header fields evaluated to false when
tested on the server. This response code allows the client to place tested on the server. This response status code allows the client to
preconditions on the current resource state (its current place preconditions on the current resource state (its current
representations and metadata) and, thus, prevent the request method representations and metadata) and, thus, prevent the request method
from being applied if the target resource is in an unexpected state. from being applied if the target resource is in an unexpected state.
9.5.14. 413 Payload Too Large 9.5.14. 413 Payload Too Large
The 413 (Payload Too Large) status code indicates that the server is The 413 (Payload Too Large) status code indicates that the server is
refusing to process a request because the request payload is larger refusing to process a request because the request payload is larger
than the server is willing or able to process. The server MAY close than the server is willing or able to process. The server MAY close
the connection to prevent the client from continuing the request. the connection to prevent the client from continuing the request.
skipping to change at page 123, line 9 skipping to change at page 123, line 9
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated Content- The format problem might be due to the request's indicated Content-
Type or Content-Encoding, or as a result of inspecting the data Type or Content-Encoding, or as a result of inspecting the data
directly. directly.
9.5.17. 416 Range Not Satisfiable 9.5.17. 416 Range Not Satisfiable
The 416 (Range Not Satisfiable) status code indicates that none of The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 8.3) overlap the ranges in the request's Range header field (Section 8.3) overlap
the current extent of the selected resource or that the set of ranges the current extent of the selected representation or that the set of
requested has been rejected due to invalid ranges or an excessive ranges requested has been rejected due to invalid ranges or an
request of small or overlapping ranges. excessive request of small or overlapping ranges.
For byte ranges, failing to overlap the current extent means that the For byte ranges, failing to overlap the current extent means that the
first-byte-pos of all of the byte-range-spec values were greater than first-byte-pos of all of the byte-range-spec values were greater than
the current length of the selected representation. When this status the current length of the selected representation. When this status
code is generated in response to a byte-range request, the sender code is generated in response to a byte-range request, the sender
SHOULD generate a Content-Range header field specifying the current SHOULD generate a Content-Range header field specifying the current
length of the selected representation (Section 6.3.3). length of the selected representation (Section 6.3.3).
For example: For example:
skipping to change at page 125, line 47 skipping to change at page 125, line 47
Additional status codes, outside the scope of this specification, Additional status codes, outside the scope of this specification,
have been specified for use in HTTP. All such status codes ought to have been specified for use in HTTP. All such status codes ought to
be registered within the "Hypertext Transfer Protocol (HTTP) Status be registered within the "Hypertext Transfer Protocol (HTTP) Status
Code Registry". Code Registry".
9.7.1. Status Code Registry 9.7.1. Status Code Registry
The "Hypertext Transfer Protocol (HTTP) Status Code Registry", The "Hypertext Transfer Protocol (HTTP) Status Code Registry",
maintained by IANA at <https://www.iana.org/assignments/http-status- maintained by IANA at <https://www.iana.org/assignments/http-status-
codes>, registers status-code numbers. codes>, registers status code numbers.
A registration MUST include the following fields: A registration MUST include the following fields:
o Status Code (3 digits) o Status Code (3 digits)
o Short Description o Short Description
o Pointer to specification text o Pointer to specification text
Values to be added to the HTTP status code namespace require IETF Values to be added to the HTTP status code namespace require IETF
Review (see [RFC5226], Section 4.1). Review (see [RFC8126], Section 4.8).
9.7.2. Considerations for New Status Codes 9.7.2. Considerations for New Status Codes
When it is necessary to express semantics for a response that are not When it is necessary to express semantics for a response that are not
defined by current status codes, a new status code can be registered. defined by current status codes, a new status code can be registered.
Status codes are generic; they are potentially applicable to any Status codes are generic; they are potentially applicable to any
resource, not just one particular media type, kind of resource, or resource, not just one particular media type, kind of resource, or
application of HTTP. As such, it is preferred that new status codes application of HTTP. As such, it is preferred that new status codes
be registered in a document that isn't specific to a single be registered in a document that isn't specific to a single
application. application.
skipping to change at page 147, line 40 skipping to change at page 147, line 40
For example, given these ABNF productions: For example, given these ABNF productions:
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 4.2.3 example-list-elmt = token ; see Section 4.2.3
Then the following are valid values for example-list (not including Then the following are valid values for example-list (not including
the double quotes, which are present for delimitation only): the double quotes, which are present for delimitation only):
"foo,bar" "foo,bar"
"foo ,bar," "foo ,bar,"
"foo , ,bar,charlie " "foo , ,bar,charlie"
In contrast, the following values would be invalid, since at least In contrast, the following values would be invalid, since at least
one non-empty element is required by the example-list production: one non-empty element is required by the example-list production:
"" ""
"," ","
", ," ", ,"
Appendix A shows the collected ABNF for recipients after the list Appendix A shows the collected ABNF for recipients after the list
constructs have been expanded. constructs have been expanded.
skipping to change at page 156, line 43 skipping to change at page 156, line 43
This is of particular concern when an origin server hosts resources This is of particular concern when an origin server hosts resources
for multiple parties under the same canonical root URI for multiple parties under the same canonical root URI
(Section 8.5.2). Possible mitigation strategies include restricting (Section 8.5.2). Possible mitigation strategies include restricting
direct access to authentication credentials (i.e., not making the direct access to authentication credentials (i.e., not making the
content of the Authorization request header field available), and content of the Authorization request header field available), and
separating protection spaces by using a different host name (or port separating protection spaces by using a different host name (or port
number) for each party. number) for each party.
13. IANA Considerations 13. IANA Considerations
This section is to be removed before publishing as an RFC.
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
13.1. URI Scheme Registration 13.1. URI Scheme Registration
Please update the registry of URI Schemes [BCP115] at Please update the registry of URI Schemes [BCP35] at
<https://www.iana.org/assignments/uri-schemes/> with the permanent <https://www.iana.org/assignments/uri-schemes/> with the permanent
schemes listed in the first table of Section 2.5. schemes listed in the first table of Section 2.5.
13.2. Method Registration 13.2. Method Registration
Please update the "Hypertext Transfer Protocol (HTTP) Method Please update the "Hypertext Transfer Protocol (HTTP) Method
Registry" at <https://www.iana.org/assignments/http-methods> with the Registry" at <https://www.iana.org/assignments/http-methods> with the
registration procedure of Section 7.4.1 and the method names registration procedure of Section 7.4.1 and the method names
summarized in the table of Section 7.2. summarized in the table of Section 7.2.
skipping to change at page 158, line 17 skipping to change at page 158, line 10
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 6.3.4 for the media type "multipart/ information in Section 6.3.4 for the media type "multipart/
byteranges". byteranges".
14. References 14. References
14.1. Normative References 14.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-01 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-02 (work in
progress), May 2018. progress), July 2018.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-01 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-02
(work in progress), May 2018. (work in progress), July 2018.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[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>.
skipping to change at page 159, line 42 skipping to change at page 159, line 37
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>. <https://www.rfc-editor.org/info/rfc6365>.
[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),
DOI 10.1109/MC.1984.1659158, June 1984,
<https://ieeexplore.ieee.org/document/1659158/>.
14.2. Informative References 14.2. Informative References
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006,
<https://www.rfc-editor.org/info/bcp115>.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013, RFC 6838, January 2013,
<https://www.rfc-editor.org/info/bcp13>. <https://www.rfc-editor.org/info/bcp13>.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012, Application Protocols", BCP 178, RFC 6648, June 2012,
<https://www.rfc-editor.org/info/bcp178>. <https://www.rfc-editor.org/info/bcp178>.
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, June 2015,
<https://www.rfc-editor.org/info/bcp35>.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004, <https://www.rfc-editor.org/info/bcp90>. September 2004, <https://www.rfc-editor.org/info/bcp90>.
[Georgiev] [Georgiev]
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, "The Most Dangerous Code in the D., and V. Shmatikov, "The Most Dangerous Code in the
World: Validating SSL Certificates in Non-browser World: Validating SSL Certificates in Non-browser
Software", In Proceedings of the 2012 ACM Conference on Software", In Proceedings of the 2012 ACM Conference on
Computer and Communications Security (CCS '12), pp. 38-49, Computer and Communications Security (CCS '12), pp. 38-49,
skipping to change at page 161, line 29 skipping to change at page 161, line 24
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
and Interpretation of HTTP Version Numbers", RFC 2145, and Interpretation of HTTP Version Numbers", RFC 2145,
DOI 10.17487/RFC2145, May 1997, DOI 10.17487/RFC2145, May 1997,
<https://www.rfc-editor.org/info/rfc2145>. <https://www.rfc-editor.org/info/rfc2145>.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998, in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
<https://www.rfc-editor.org/info/rfc2295>. <https://www.rfc-editor.org/info/rfc2295>.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998,
<https://www.rfc-editor.org/info/rfc2388>.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML "MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
skipping to change at page 162, line 33 skipping to change at page 162, line 25
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>. <https://www.rfc-editor.org/info/rfc4559>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007, DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>. <https://www.rfc-editor.org/info/rfc4918>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010, RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>. <https://www.rfc-editor.org/info/rfc5789>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010,
<https://www.rfc-editor.org/info/rfc5987>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>. <https://www.rfc-editor.org/info/rfc6585>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
skipping to change at page 164, line 5 skipping to change at page 163, line 30
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP): Range Requests", "Hypertext Transfer Protocol (HTTP): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>. <https://www.rfc-editor.org/info/rfc7233>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7238, DOI 10.17487/RFC7238, 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
June 2014, <https://www.rfc-editor.org/info/rfc7238>. April 2015, <https://www.rfc-editor.org/info/rfc7538>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
<https://www.rfc-editor.org/info/rfc7578>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8187] Reschke, J., "Indicating Character Encoding and Language
for HTTP Header Field Parameters", RFC 8187,
DOI 10.17487/RFC8187, September 2017,
<https://www.rfc-editor.org/info/rfc8187>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 11. Section 11.
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
skipping to change at page 168, line 41 skipping to change at page 168, line 41
/ %x53.65.70 ; Sep / %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct / %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov / %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec / %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
obs-fold = <obs-fold, see [Messaging], Section 5.2> obs-fold = <obs-fold, see [Messaging], Section 5.2>
obs-text = %x80-FF obs-text = %x80-FF
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
other-content-range = other-range-unit SP other-range-resp other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR other-range-resp = *VCHAR
other-range-set = 1*VCHAR other-range-set = 1*VCHAR
other-range-unit = token other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set other-ranges-specifier = other-range-unit "=" other-range-set
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
skipping to change at page 171, line 22 skipping to change at page 171, line 22
o Merged entire content of RFC 7233 (Range Requests). o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework). o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
G.3. Since draft-ietf-httpbis-semantics-01
o Improve [Welch] citation (<https://github.com/httpwg/http-core/
issues/63>)
o Remove HTTP/1.1-ism about Range Requests
(<https://github.com/httpwg/http-core/issues/71>)
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>)
o Cite RFC 7538 instead of RFC 7238 (<https://github.com/httpwg/
http-core/issues/76>)
o Cite RFC 8288 instead of RFC 5988 (<https://github.com/httpwg/
http-core/issues/77>)
o Cite RFC 8187 instead of RFC 5987 (<https://github.com/httpwg/
http-core/issues/78>)
o Cite RFC 7578 instead of RFC 2388 (<https://github.com/httpwg/
http-core/issues/79>)
o Cite RFC 7595 instead of RFC 4395 (<https://github.com/httpwg/
http-core/issues/80>)
o improve ABNF readability for qdtext (<https://github.com/httpwg/
http-core/issues/81>, <https://www.rfc-editor.org/errata/eid4891>)
o Clarify "resource" vs "representation" in definition of status
code 416 (<https://github.com/httpwg/http-core/issues/83>,
<https://www.rfc-editor.org/errata/eid4664>)
o Resolved erratum 4072, no change needed here
(<https://github.com/httpwg/http-core/issues/84>,
<https://www.rfc-editor.org/errata/eid4072>)
o Clarify DELETE status code suggestions
(<https://github.com/httpwg/http-core/issues/85>,
<https://www.rfc-editor.org/errata/eid4436>)
o In Section 6.3.3, fix ABNF for "other-range-resp" to use VCHAR
instead of CHAR (<https://github.com/httpwg/http-core/issues/86>,
<https://www.rfc-editor.org/errata/eid4707>)
o Resolved erratum 5162, no change needed here
(<https://github.com/httpwg/http-core/issues/89>,
<https://www.rfc-editor.org/errata/eid5162>)
o Replace "response code" with "response status code" and "status-
code" (the ABNF production name from the HTTP/1.1 message format)
by "status code" (<https://github.com/httpwg/http-core/issues/94>,
<https://www.rfc-editor.org/errata/eid4050>)
o Added a missing word in Section 9.4 (<https://github.com/httpwg/
http-core/issues/98>, <https://www.rfc-editor.org/errata/eid4452>)
o In Section 11, fixed an example that had trailing whitespace where
it shouldn't (<https://github.com/httpwg/http-core/issues/104>,
<https://www.rfc-editor.org/errata/eid4169>)
o In Section 9.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>)
Index Index
1 1
100 Continue (status code) 106 100 Continue (status code) 106
100-continue (expect value) 73 100-continue (expect value) 74
101 Switching Protocols (status code) 106 101 Switching Protocols (status code) 106
1xx Informational (status code class) 106 1xx Informational (status code class) 106
2 2
200 OK (status code) 107 200 OK (status code) 107
201 Created (status code) 108 201 Created (status code) 108
202 Accepted (status code) 108 202 Accepted (status code) 108
203 Non-Authoritative Information (status code) 108 203 Non-Authoritative Information (status code) 108
204 No Content (status code) 109 204 No Content (status code) 109
205 Reset Content (status code) 109 205 Reset Content (status code) 109
skipping to change at page 173, line 29 skipping to change at page 174, line 49
D D
DELETE method 68 DELETE method 68
Date header field 130 Date header field 130
Delimiters 27 Delimiters 27
deflate (Coding Format) 40 deflate (Coding Format) 40
deflate (content coding) 40 deflate (content coding) 40
downstream 12 downstream 12
E E
ETag header field 139 ETag header field 139
Expect header field 73 Expect header field 74
effective request URI 31 effective request URI 31
F F
From header field 100 From header field 100
G G
GET method 63 GET method 63
Grammar Grammar
absolute-path 15 absolute-path 15
absolute-URI 15 absolute-URI 15
skipping to change at page 174, line 43 skipping to change at page 176, line 14
date1 129 date1 129
day 129 day 129
day-name 129 day-name 129
day-name-l 129 day-name-l 129
delay-seconds 133 delay-seconds 133
DIGIT 9 DIGIT 9
DQUOTE 9 DQUOTE 9
entity-tag 139 entity-tag 139
ETag 139 ETag 139
etagc 139 etagc 139
Expect 73 Expect 74
field-content 26 field-content 26
field-name 22, 30 field-name 22, 30
field-value 26 field-value 26
field-vchar 26 field-vchar 26
first-byte-pos 43 first-byte-pos 43
fragment 15 fragment 15
From 100 From 100
GMT 129 GMT 129
HEXDIG 9 HEXDIG 9
Host 32 Host 32
skipping to change at page 176, line 51 skipping to change at page 178, line 22
H H
HEAD method 63 HEAD method 63
Host header field 32 Host header field 32
http URI scheme 16 http URI scheme 16
https URI scheme 17 https URI scheme 17
I I
If-Match header field 80 If-Match header field 80
If-Modified-Since header field 82 If-Modified-Since header field 82
If-None-Match header field 81 If-None-Match header field 81
If-Range header field 84 If-Range header field 85
If-Unmodified-Since header field 83 If-Unmodified-Since header field 83
idempotent 62 idempotent 62
inbound 12 inbound 12
interception proxy 13 interception proxy 13
intermediary 11 intermediary 11
L L
Last-Modified header field 137 Last-Modified header field 137
Location header field 131 Location header field 131
 End of changes. 59 change blocks. 
112 lines changed or deleted 180 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/