draft-ietf-httpbis-semantics-19.txt   draft-ietf-httpbis-semantics-latest.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed. Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed.
7538, 7615, 7694 (if approved) Fastly 7538, 7615, 7694 (if approved) Fastly
Updates: 3864 (if approved) J. Reschke, Ed. Updates: 3864 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: March 14, 2022 September 10, 2021 Expires: August 1, 2022 January 28, 2022
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-19 draft-ietf-httpbis-semantics-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP, systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes. "https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232,
7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions 7233, 7235, 7538, 7615, 7694, and portions of 7230.
of RFC 7230.
Editorial Note Editorial Note
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 C.20. The changes in this draft are summarized in Appendix C.1.
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 March 14, 2022. This Internet-Draft will expire on August 1, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
skipping to change at page 2, line 48 skipping to change at page 2, line 43
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. History and Evolution . . . . . . . . . . . . . . . . . . 10 1.2. History and Evolution . . . . . . . . . . . . . . . . . . 10
1.3. Core Semantics . . . . . . . . . . . . . . . . . . . . . 11 1.3. Core Semantics . . . . . . . . . . . . . . . . . . . . . 10
1.4. Specifications Obsoleted by this Document . . . . . . . . 11 1.4. Specifications Obsoleted by This Document . . . . . . . . 11
2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 12 2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 12
2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 13 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 12
2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 14 2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 13
2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 14 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 14
2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15 2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15
3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16 3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 15
3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Representations . . . . . . . . . . . . . . . . . . . . . 16 3.2. Representations . . . . . . . . . . . . . . . . . . . . . 16
3.3. Connections, Clients and Servers . . . . . . . . . . . . 17 3.3. Connections, Clients, and Servers . . . . . . . . . . . . 17
3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 18
3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 19
3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 19 3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 19
3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22 3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22
4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 22 4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 22
4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23 4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23
4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 23 4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 23
4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 24 4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 24
4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 24 4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 24
4.2.3. http(s) Normalization and Comparison . . . . . . . . 25 4.2.3. http(s) Normalization and Comparison . . . . . . . . 25
4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 26 4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 26
4.2.5. http(s) References with Fragment Identifiers . . . . 27 4.2.5. http(s) References with Fragment Identifiers . . . . 27
4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 27 4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 27
4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 27 4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 27
4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 28 4.3.2. http Origins . . . . . . . . . . . . . . . . . . . . 28
4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 29 4.3.3. https Origins . . . . . . . . . . . . . . . . . . . . 29
4.3.4. https certificate verification . . . . . . . . . . . 30 4.3.4. https Certificate Verification . . . . . . . . . . . 30
4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 31 4.3.5. IP-ID Reference Identity . . . . . . . . . . . . . . 31
5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 32 5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 32
5.2. Field Lines and Combined Field Value . . . . . . . . . . 33 5.2. Field Lines and Combined Field Value . . . . . . . . . . 33
5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 33 5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 33
5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 34 5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 34
5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 34 5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 34
5.6. Common Rules for Defining Field Values . . . . . . . . . 36 5.6. Common Rules for Defining Field Values . . . . . . . . . 36
5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 36 5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 36
5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 37 5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 37
5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 37 5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 37
skipping to change at page 4, line 7 skipping to change at page 3, line 50
5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 40 5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 40
5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 40 5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 40
6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 42 6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 42
6.1. Framing and Completeness . . . . . . . . . . . . . . . . 43 6.1. Framing and Completeness . . . . . . . . . . . . . . . . 43
6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 44 6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 44
6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 45 6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 45
6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 46 6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 46
6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 47 6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 47
6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 48 6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 48
6.5.1. Limitations on use of Trailers . . . . . . . . . . . 48 6.5.1. Limitations on Use of Trailers . . . . . . . . . . . 48
6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 49 6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 49
6.6. Message Metadata . . . . . . . . . . . . . . . . . . . . 50 6.6. Message Metadata . . . . . . . . . . . . . . . . . . . . 50
6.6.1. Date . . . . . . . . . . . . . . . . . . . . . . . . 50 6.6.1. Date . . . . . . . . . . . . . . . . . . . . . . . . 50
6.6.2. Trailer . . . . . . . . . . . . . . . . . . . . . . . 51 6.6.2. Trailer . . . . . . . . . . . . . . . . . . . . . . . 51
7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 51 7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 51
7.1. Determining the Target Resource . . . . . . . . . . . . . 51 7.1. Determining the Target Resource . . . . . . . . . . . . . 51
7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 52 7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 52
7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 53 7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 53
7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 53 7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 53
7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 53 7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 53
7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 54 7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 54
skipping to change at page 8, line 4 skipping to change at page 7, line 47
16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 171 16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 171
16.1.2. Considerations for New Methods . . . . . . . . . . . 171 16.1.2. Considerations for New Methods . . . . . . . . . . . 171
16.2. Status Code Extensibility . . . . . . . . . . . . . . . 172 16.2. Status Code Extensibility . . . . . . . . . . . . . . . 172
16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 172 16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 172
16.2.2. Considerations for New Status Codes . . . . . . . . 173 16.2.2. Considerations for New Status Codes . . . . . . . . 173
16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 174 16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 174
16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 174 16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 174
16.3.2. Considerations for New Fields . . . . . . . . . . . 175 16.3.2. Considerations for New Fields . . . . . . . . . . . 175
16.3.2.1. Considerations for New Field Names . . . . . . . 176 16.3.2.1. Considerations for New Field Names . . . . . . . 176
16.3.2.2. Considerations for New Field Values . . . . . . 177 16.3.2.2. Considerations for New Field Values . . . . . . 177
16.4. Authentication Scheme Extensibility . . . . . . . . . . 178 16.4. Authentication Scheme Extensibility . . . . . . . . . . 178
16.4.1. Authentication Scheme Registry . . . . . . . . . . . 178 16.4.1. Authentication Scheme Registry . . . . . . . . . . . 178
16.4.2. Considerations for New Authentication Schemes . . . 178 16.4.2. Considerations for New Authentication Schemes . . . 178
16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 180 16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 180
16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 180 16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 180
16.5.2. Considerations for New Range Units . . . . . . . . . 180 16.5.2. Considerations for New Range Units . . . . . . . . . 180
16.6. Content Coding Extensibility . . . . . . . . . . . . . . 180 16.6. Content Coding Extensibility . . . . . . . . . . . . . . 180
16.6.1. Content Coding Registry . . . . . . . . . . . . . . 180 16.6.1. Content Coding Registry . . . . . . . . . . . . . . 180
16.6.2. Considerations for New Content Codings . . . . . . . 181 16.6.2. Considerations for New Content Codings . . . . . . . 181
16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 181 16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 181
17. Security Considerations . . . . . . . . . . . . . . . . . . . 182 17. Security Considerations . . . . . . . . . . . . . . . . . . . 182
17.1. Establishing Authority . . . . . . . . . . . . . . . . . 182 17.1. Establishing Authority . . . . . . . . . . . . . . . . . 182
17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 183 17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 183
17.3. Attacks Based on File and Path Names . . . . . . . . . . 184 17.3. Attacks Based on File and Path Names . . . . . . . . . . 184
17.4. Attacks Based on Command, Code, or Query Injection . . . 184 17.4. Attacks Based on Command, Code, or Query Injection . . . 184
17.5. Attacks via Protocol Element Length . . . . . . . . . . 185 17.5. Attacks via Protocol Element Length . . . . . . . . . . 185
17.6. Attacks using Shared-dictionary Compression . . . . . . 186 17.6. Attacks Using Shared-Dictionary Compression . . . . . . 186
17.7. Disclosure of Personal Information . . . . . . . . . . . 186 17.7. Disclosure of Personal Information . . . . . . . . . . . 186
17.8. Privacy of Server Log Information . . . . . . . . . . . 186 17.8. Privacy of Server Log Information . . . . . . . . . . . 186
17.9. Disclosure of Sensitive Information in URIs . . . . . . 187 17.9. Disclosure of Sensitive Information in URIs . . . . . . 187
17.10. Application Handling of Field Names . . . . . . . . . . 187 17.10. Application Handling of Field Names . . . . . . . . . . 187
17.11. Disclosure of Fragment after Redirects . . . . . . . . . 188 17.11. Disclosure of Fragment after Redirects . . . . . . . . . 188
17.12. Disclosure of Product Information . . . . . . . . . . . 189 17.12. Disclosure of Product Information . . . . . . . . . . . 189
17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 189 17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 189
17.14. Validator Retention . . . . . . . . . . . . . . . . . . 190 17.14. Validator Retention . . . . . . . . . . . . . . . . . . 190
17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 190 17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 190
17.16. Authentication Considerations . . . . . . . . . . . . . 191 17.16. Authentication Considerations . . . . . . . . . . . . . 191
skipping to change at page 8, line 47 skipping to change at page 8, line 41
18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 193 18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 193
18.2. Method Registration . . . . . . . . . . . . . . . . . . 193 18.2. Method Registration . . . . . . . . . . . . . . . . . . 193
18.3. Status Code Registration . . . . . . . . . . . . . . . . 193 18.3. Status Code Registration . . . . . . . . . . . . . . . . 193
18.4. Field Name Registration . . . . . . . . . . . . . . . . 195 18.4. Field Name Registration . . . . . . . . . . . . . . . . 195
18.5. Authentication Scheme Registration . . . . . . . . . . . 197 18.5. Authentication Scheme Registration . . . . . . . . . . . 197
18.6. Content Coding Registration . . . . . . . . . . . . . . 197 18.6. Content Coding Registration . . . . . . . . . . . . . . 197
18.7. Range Unit Registration . . . . . . . . . . . . . . . . 197 18.7. Range Unit Registration . . . . . . . . . . . . . . . . 197
18.8. Media Type Registration . . . . . . . . . . . . . . . . 198 18.8. Media Type Registration . . . . . . . . . . . . . . . . 198
18.9. Port Registration . . . . . . . . . . . . . . . . . . . 198 18.9. Port Registration . . . . . . . . . . . . . . . . . . . 198
18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 198 18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 198
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 198 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 199
19.1. Normative References . . . . . . . . . . . . . . . . . . 198 19.1. Normative References . . . . . . . . . . . . . . . . . . 199
19.2. Informative References . . . . . . . . . . . . . . . . . 200 19.2. Informative References . . . . . . . . . . . . . . . . . 201
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 207 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 207
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 211 Appendix B. Changes from Previous RFCs . . . . . . . . . . . . . 212
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 211 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 212
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 211 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 212
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 212 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 213
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 214 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 215
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 215 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 215
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 215 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 216
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 215 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 216
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 215 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 216
B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 215 B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 216
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 215 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 216
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 215 C.1. Since draft-ietf-httpbis-semantics-19 . . . . . . . . . . 216
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 216 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 217
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 216 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 218 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 229
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 219
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 219
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 220
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 221
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 223
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 224
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 225
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 225
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 227
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 227
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 229
C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 230
C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 232
C.18. Since draft-ietf-httpbis-semantics-16 . . . . . . . . . . 233
C.19. Since draft-ietf-httpbis-semantics-17 . . . . . . . . . . 233
C.20. Since draft-ietf-httpbis-semantics-18 . . . . . . . . . . 235
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 236
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 248
1. Introduction 1. Introduction
1.1. Purpose 1.1. Purpose
The Hypertext Transfer Protocol (HTTP) is a family of stateless, The Hypertext Transfer Protocol (HTTP) is a family of stateless,
application-level, request/response protocols that share a generic application-level, request/response protocols that share a generic
interface, extensible semantics, and self-descriptive messages to interface, extensible semantics, and self-descriptive messages to
enable flexible interaction with network-based hypertext information enable flexible interaction with network-based hypertext information
systems. systems.
skipping to change at page 10, line 43 skipping to change at page 10, line 25
and HTTP/1.0 (see [HTTP/1.0]). and HTTP/1.0 (see [HTTP/1.0]).
HTTP/1.1 was designed to refine the protocol's features while HTTP/1.1 was designed to refine the protocol's features while
retaining compatibility with the existing text-based messaging retaining compatibility with the existing text-based messaging
syntax, improving its interoperability, scalability, and robustness syntax, improving its interoperability, scalability, and robustness
across the Internet. This included length-based data delimiters for across the Internet. This included length-based data delimiters for
both fixed and dynamic (chunked) content, a consistent framework for both fixed and dynamic (chunked) content, a consistent framework for
content negotiation, opaque validators for conditional requests, content negotiation, opaque validators for conditional requests,
cache controls for better cache consistency, range requests for cache controls for better cache consistency, range requests for
partial updates, and default persistent connections. HTTP/1.1 was partial updates, and default persistent connections. HTTP/1.1 was
introduced in 1995 and published on the standards track in 1997 introduced in 1995 and published on the Standards Track in 1997
[RFC2068], revised in 1999 [RFC2616], and revised again in 2014 [RFC2068], revised in 1999 [RFC2616], and revised again in 2014
([RFC7230] - [RFC7235]). ([RFC7230] through [RFC7235]).
HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of
the existing TLS and TCP protocols for exchanging concurrent HTTP the existing TLS and TCP protocols for exchanging concurrent HTTP
messages with efficient field compression and server push. HTTP/3 messages with efficient field compression and server push. HTTP/3
([HTTP/3]) provides greater independence for concurrent messages by ([HTTP/3]) provides greater independence for concurrent messages by
using QUIC as a secure multiplexed transport over UDP instead of TCP. using QUIC as a secure multiplexed transport over UDP instead of TCP.
All three major versions of HTTP rely on the semantics defined by All three major versions of HTTP rely on the semantics defined by
this document. They have not obsoleted each other because each one this document. They have not obsoleted each other because each one
has specific benefits and limitations depending on the context of has specific benefits and limitations depending on the context of
skipping to change at page 11, line 45 skipping to change at page 11, line 27
request header fields, status codes that describe the response request header fields, status codes that describe the response
(Section 15), and other control data and resource metadata that might (Section 15), and other control data and resource metadata that might
be given in response fields. be given in response fields.
Semantics also include representation metadata that describe how Semantics also include representation metadata that describe how
content is intended to be interpreted by a recipient, request header content is intended to be interpreted by a recipient, request header
fields that might influence content selection, and the various 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 12). negotiation_ (Section 12).
1.4. Specifications Obsoleted by this Document 1.4. Specifications Obsoleted by This Document
This document obsoletes the following specifications: This document obsoletes the following specifications:
+--------------------------------------------+-----------+---------+ +--------------------------------------------+-----------+---------+
| Title | Reference | Changes | | Title | Reference | Changes |
+--------------------------------------------+-----------+---------+ +--------------------------------------------+-----------+---------+
| HTTP Over TLS | [RFC2818] | B.1 | | HTTP Over TLS | [RFC2818] | B.1 |
| HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 | | HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 |
| HTTP/1.1 Semantics and Content | [RFC7231] | B.3 | | HTTP/1.1 Semantics and Content | [RFC7231] | B.3 |
| HTTP/1.1 Conditional Requests | [RFC7232] | B.4 | | HTTP/1.1 Conditional Requests | [RFC7232] | B.4 |
skipping to change at page 12, line 41 skipping to change at page 12, line 19
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 5.6.1, that allows It also uses a list extension, defined in Section 5.6.1, that allows
for compact definition of comma-separated lists using a "#" operator for compact definition of comma-separated lists using a "#" operator
(similar to how the "*" operator indicates repetition). Appendix A (similar to how the "*" operator indicates repetition). Appendix A
shows the collected grammar with all list operators expanded to shows the collected grammar with all list operators expanded to
standard ABNF notation. standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote obsolete
"obsolete" grammar rules that appear for historical reasons. 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). VCHAR (any visible US-ASCII character).
Section 5.6 defines some generic syntactic components for field Section 5.6 defines some generic syntactic components for field
values. values.
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
[RFC6365]. Section 2 of [RFC6365].
2.2. Requirements Notation 2.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification targets conformance criteria according to the role This specification targets conformance criteria according to the role
skipping to change at page 15, line 22 skipping to change at page 15, line 8
Location header field doesn't parse according to the ABNF, whereas a Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to systems control client might consider any form of error recovery to
be dangerous. be dangerous.
Some requests can be automatically retried by a client in the event Some requests can be automatically retried by a client in the event
of an underlying connection failure, as described in Section 9.2.2. of an underlying connection failure, as described in Section 9.2.2.
2.5. Protocol Version 2.5. Protocol Version
HTTP's version number consists of two decimal digits separated by a HTTP's 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 messaging syntax, whereas the second digit ("minor indicates the 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 (able to understand for version to which the sender is conformant (able to understand for
future communication). future communication).
While HTTP's core semantics don't change between protocol versions, While HTTP's core semantics don't change between protocol versions,
the expression of them "on the wire" can change, and so the HTTP their expression "on the wire" can change, and so the HTTP version
version number changes when incompatible changes are made to the wire number changes when incompatible changes are made to the wire format.
format. Additionally, HTTP allows incremental, backwards-compatible Additionally, HTTP allows incremental, backwards-compatible changes
changes to be made to the protocol without changing its version to be made to the protocol without changing its version through the
through the use of defined extension points (Section 16). use of defined extension points (Section 16).
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. For example, the version "HTTP/1.1" is specification. For example, the version "HTTP/1.1" is defined by the
defined by the combined specifications of this document, "HTTP combined specifications of this document, "HTTP Caching" [CACHING],
Caching" [CACHING], and "HTTP/1.1" [HTTP/1.1]. and "HTTP/1.1" [HTTP/1.1].
HTTP's major version number is incremented when an incompatible HTTP's major version number is incremented when an incompatible
message syntax is introduced. The minor number is incremented when message syntax is introduced. The minor number is incremented when
changes made to the protocol have the effect of adding to the message changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender. semantics or implying additional capabilities of the sender.
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
skipping to change at page 17, line 24 skipping to change at page 17, line 15
A target resource might be provided with, or be capable of A target resource might be provided with, or be capable of
generating, multiple representations that are each intended to generating, multiple representations that are each intended to
reflect the resource's current state. An algorithm, usually based on reflect the resource's current state. An algorithm, usually based on
content negotiation (Section 12), would be used to select one of content negotiation (Section 12), would be used to select one of
those representations as being most applicable to a given request. those representations as being most applicable to a given request.
This _selected representation_ provides the data and metadata for This _selected representation_ provides the data and metadata for
evaluating conditional requests (Section 13) and constructing the evaluating conditional requests (Section 13) and constructing the
content for 200 (OK), 206 (Partial Content), and 304 (Not Modified) content for 200 (OK), 206 (Partial Content), and 304 (Not Modified)
responses to GET (Section 9.3.1). responses to GET (Section 9.3.1).
3.3. Connections, Clients and Servers 3.3. Connections, Clients, and Servers
HTTP is a client/server protocol that operates over a reliable HTTP is a client/server protocol that operates over a reliable
transport- or session-layer _connection_. transport- or session-layer _connection_.
An HTTP _client_ is a program that establishes a connection to a An HTTP _client_ is a program that establishes a connection to a
server for the purpose of sending one or more HTTP requests. An HTTP server for the purpose of sending one or more HTTP requests. An HTTP
_server_ is a program that accepts connections in order to service _server_ is a program that accepts connections in order to service
HTTP requests by sending HTTP responses. HTTP requests by sending HTTP responses.
The terms "client" and "server" refer only to the roles that these The terms client and server refer only to the roles that these
programs perform for a particular connection. The same program might programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. act as a client on some connections and a server on others.
HTTP is defined as a stateless protocol, meaning that each request HTTP is defined as a stateless protocol, meaning that each request
message's semantics can be understood in isolation, and that the message's semantics can be understood in isolation, and that the
relationship between connections and messages on them has no impact relationship between connections and messages on them has no impact
on the interpretation of those messages. For example, a CONNECT on the interpretation of those messages. For example, a CONNECT
request (Section 9.3.6) or a request with the Upgrade header field request (Section 9.3.6) or a request with the Upgrade header field
(Section 7.8) can occur at any time, not just in the first message on (Section 7.8) can occur at any time, not just in the first message on
a connection. Many implementations depend on HTTP's stateless design a connection. Many implementations depend on HTTP's stateless design
skipping to change at page 20, line 4 skipping to change at page 19, line 47
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
Figure 2 Figure 2
The figure above shows three intermediaries (A, B, and C) between the The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections. travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the endpoints of the with the nearest, non-tunnel neighbor, only to the endpoints of the
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple, is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's to servers other than C, at the same time that it is handling A's
request. Likewise, later requests might be sent through a different request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load path of connections, often based on dynamic configuration for load
balancing. balancing.
The terms _upstream_ and _downstream_ are used to describe The terms _upstream_ and _downstream_ are used to describe
directional requirements in relation to the message flow: all directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms "inbound" and messages flow from upstream to downstream. The terms inbound and
"outbound" are used to describe directional requirements in relation outbound are used to describe directional requirements in relation to
to the request route: _inbound_ means toward the origin server and the request route: _inbound_ means toward the origin server and
_outbound_ means toward the user agent. _outbound_ means toward the user agent.
A _proxy_ is a message-forwarding agent that is chosen by the client, A _proxy_ is a message-forwarding agent that is chosen by the client,
usually via local configuration rules, to receive requests for some usually via local configuration rules, to receive requests for some
type(s) of absolute URI and attempt to satisfy those requests via type(s) of absolute URI and attempt to satisfy those requests via
translation through the HTTP interface. Some translations are translation through the HTTP interface. Some translations are
minimal, such as for proxy requests for "http" URIs, whereas other minimal, such as for proxy requests for "http" URIs, whereas other
requests might require translation to and from entirely different requests might require translation to and from entirely different
application-level protocols. Proxies are often used to group an application-level protocols. Proxies are often used to group an
organization's HTTP requests through a common intermediary for the organization's HTTP requests through a common intermediary for the
skipping to change at page 24, line 43 skipping to change at page 24, line 43
subcomponent is empty or not given, TCP port 80 (the reserved port subcomponent is empty or not given, TCP port 80 (the reserved port
for WWW services) is the default. The origin determines who has the for WWW services) is the default. The origin determines who has the
right to respond authoritatively to requests that target the right to respond authoritatively to requests that target the
identified resource, as defined in Section 4.3.2. identified resource, as defined in Section 4.3.2.
A sender MUST NOT generate an "http" URI with an empty host A sender MUST NOT generate an "http" URI with an empty host
identifier. A recipient that processes such a URI reference MUST identifier. A recipient that processes such a URI reference MUST
reject it as invalid. reject it as invalid.
The hierarchical path component and optional query component identify The hierarchical path component and optional query component identify
the target resource within that origin server's name space. the target resource within that origin server's namespace.
4.2.2. https URI Scheme 4.2.2. https URI Scheme
The "https" URI scheme is hereby defined for minting identifiers The "https" URI scheme is hereby defined for minting identifiers
within the hierarchical namespace governed by a potential origin within the hierarchical namespace governed by a potential origin
server listening for TCP connections on a given port and capable of server listening for TCP connections on a given port and capable of
establishing a TLS ([TLS13]) connection that has been secured for establishing a TLS ([TLS13]) connection that has been secured for
HTTP communication. In this context, _secured_ specifically means HTTP communication. In this context, _secured_ specifically means
that the server has been authenticated as acting on behalf of the that the server has been authenticated as acting on behalf of the
identified authority and all HTTP communication with that server has identified authority and all HTTP communication with that server has
skipping to change at page 25, line 23 skipping to change at page 25, line 23
subcomponent is empty or not given, TCP port 443 (the reserved port subcomponent is empty or not given, TCP port 443 (the reserved port
for HTTP over TLS) is the default. The origin determines who has the for HTTP over TLS) is the default. The origin determines who has the
right to respond authoritatively to requests that target the right to respond authoritatively to requests that target the
identified resource, as defined in Section 4.3.3. identified resource, as defined in Section 4.3.3.
A sender MUST NOT generate an "https" URI with an empty host A sender MUST NOT generate an "https" URI with an empty host
identifier. A recipient that processes such a URI reference MUST identifier. A recipient that processes such a URI reference MUST
reject it as invalid. reject it as invalid.
The hierarchical path component and optional query component identify The hierarchical path component and optional query component identify
the target resource within that origin server's name space. the target resource within that origin server's namespace.
A client MUST ensure that its HTTP requests for an "https" resource A client MUST ensure that its HTTP requests for an "https" resource
are secured, prior to being communicated, and that it only accepts are secured, prior to being communicated, and that it only accepts
secured responses to those requests. Note that the definition of secured responses to those requests. Note that the definition of
what cryptographic mechanisms are acceptable to client and server are what cryptographic mechanisms are acceptable to client and server are
usually negotiated and can change over time. usually negotiated and can change over time.
Resources made available via the "https" scheme have no shared Resources made available via the "https" scheme have no shared
identity with the "http" scheme. They are distinct origins with identity with the "http" scheme. They are distinct origins with
separate namespaces. However, extensions to HTTP that are defined as separate namespaces. However, extensions to HTTP that are defined as
skipping to change at page 25, line 47 skipping to change at page 25, line 47
domains. Such extensions ought to be designed with great care to domains. Such extensions ought to be designed with great care to
prevent information obtained from a secured connection being prevent information obtained from a secured connection being
inadvertently exchanged within an unsecured context. inadvertently exchanged within an unsecured context.
4.2.3. http(s) Normalization and Comparison 4.2.3. http(s) Normalization and Comparison
The "http" and "https" URI are normalized and compared according to The "http" and "https" URI are normalized and compared according to
the methods defined in Section 6 of [URI], using the defaults the methods defined in Section 6 of [URI], using the defaults
described above for each scheme. described above for each scheme.
HTTP does not require use of a specific method for determining HTTP does not require the use of a specific method for determining
equivalence. For example, a cache key might be compared as a simple equivalence. For example, a cache key might be compared as a simple
string, after syntax-based normalization, or after scheme-based string, after syntax-based normalization, or after scheme-based
normalization. normalization.
Scheme-based normalization (Section 6.2.3 of [URI]) of "http" and Scheme-based normalization (Section 6.2.3 of [URI]) of "http" and
"https" URIs involves the following additional rules: "https" URIs involves the following additional rules:
o If the port is equal to the default port for a scheme, the normal o If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. form is to omit the port subcomponent.
skipping to change at page 28, line 15 skipping to change at page 28, line 15
which can also be described as the normalized URI prefix with port which can also be described as the normalized URI prefix with port
always present: always present:
https://example.com:443 https://example.com:443
Each origin defines its own namespace and controls how identifiers Each origin defines its own namespace and controls how identifiers
within that namespace are mapped to resources. In turn, how the within that namespace are mapped to resources. In turn, how the
origin responds to valid requests, consistently over time, determines origin responds to valid requests, consistently over time, determines
the semantics that users will associate with a URI, and the the semantics that users will associate with a URI, and the
usefulness of those semantics is what ultimately transforms these usefulness of those semantics is what ultimately transforms these
mechanisms into a "resource" for users to reference and access in the mechanisms into a resource for users to reference and access in the
future. future.
Two origins are distinct if they differ in scheme, host, or port. Two origins are distinct if they differ in scheme, host, or port.
Even when it can be verified that the same entity controls two Even when it can be verified that the same entity controls two
distinct origins, the two namespaces under those origins are distinct distinct origins, the two namespaces under those origins are distinct
unless explicitly aliased by a server authoritative for that origin. unless explicitly aliased by a server authoritative for that origin.
Origin is also used within HTML and related Web protocols, beyond the Origin is also used within HTML and related Web protocols, beyond the
scope of this document, as described in [RFC6454]. scope of this document, as described in [RFC6454].
4.3.2. http origins 4.3.2. http Origins
Although HTTP is independent of the transport protocol, the "http" Although HTTP is independent of the transport protocol, the "http"
scheme (Section 4.2.1) is specific to associating authority with scheme (Section 4.2.1) is specific to associating authority with
whomever controls the origin server listening for TCP connections on whomever controls the origin server listening for TCP connections on
the indicated port of whatever host is identified within the the indicated port of whatever host is identified within the
authority component. This is a very weak sense of authority because authority component. This is a very weak sense of authority because
it depends on both client-specific name resolution mechanisms and it depends on both client-specific name resolution mechanisms and
communication that might not be secured from an on-path attacker. communication that might not be secured from an on-path attacker.
Nevertheless, it is a sufficient minimum for binding "http" Nevertheless, it is a sufficient minimum for binding "http"
identifiers to an origin server for consistent resolution within a identifiers to an origin server for consistent resolution within a
skipping to change at page 29, line 17 skipping to change at page 29, line 17
considered an authoritative answer to the client's request. considered an authoritative answer to the client's request.
Note, however, that the above is not the only means for obtaining an Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative authoritative response, nor does it imply that an authoritative
response is always necessary (see [CACHING]). For example, the Alt- response is always necessary (see [CACHING]). For example, the Alt-
Svc header field [ALTSVC] allows an origin server to identify other Svc header field [ALTSVC] allows an origin server to identify other
services that are also authoritative for that origin. Access to services that are also authoritative for that origin. Access to
"http" identified resources might also be provided by protocols "http" identified resources might also be provided by protocols
outside the scope of this document. outside the scope of this document.
4.3.3. https origins 4.3.3. https Origins
The "https" scheme (Section 4.2.2) associates authority based on the The "https" scheme (Section 4.2.2) associates authority based on the
ability of a server to use the private key corresponding to a ability of a server to use the private key corresponding to a
certificate that the client considers to be trustworthy for the certificate that the client considers to be trustworthy for the
identified origin server. The client usually relies upon a chain of identified origin server. The client usually relies upon a chain of
trust, conveyed from some prearranged or configured trust anchor, to trust, conveyed from some prearranged or configured trust anchor, to
deem a certificate trustworthy (Section 4.3.4). deem a certificate trustworthy (Section 4.3.4).
In HTTP/1.1 and earlier, a client will only attribute authority to a In HTTP/1.1 and earlier, a client will only attribute authority to a
server when they are communicating over a successfully established server when they are communicating over a successfully established
skipping to change at page 29, line 47 skipping to change at page 29, line 47
client will make a DNS query to check that the origin's host contains client will make a DNS query to check that the origin's host contains
the same server IP address as the established connection. This the same server IP address as the established connection. This
restriction can be removed by the origin server sending an equivalent restriction can be removed by the origin server sending an equivalent
ORIGIN frame [RFC8336]. ORIGIN frame [RFC8336].
The request target's host and port value are passed within each HTTP The request target's host and port value are passed within each HTTP
request, identifying the origin and distinguishing it from other request, identifying the origin and distinguishing it from other
namespaces that might be controlled by the same server (Section 7.2). namespaces that might be controlled by the same server (Section 7.2).
It is the origin's responsibility to ensure that any services It is the origin's responsibility to ensure that any services
provided with control over its certificate's private key are equally provided with control over its certificate's private key are equally
responsible for managing the corresponding "https" namespaces, or at responsible for managing the corresponding "https" namespaces or at
least prepared to reject requests that appear to have been least prepared to reject requests that appear to have been
misdirected (Section 7.4). misdirected (Section 7.4).
An origin server might be unwilling to process requests for certain An origin server might be unwilling to process requests for certain
target URIs even when they have the authority to do so. For example, target URIs even when they have the authority to do so. For example,
when a host operates distinct services on different ports (e.g., 443 when a host operates distinct services on different ports (e.g., 443
and 8000), checking the target URI at the origin server is necessary and 8000), checking the target URI at the origin server is necessary
(even after the connection has been secured) because a network (even after the connection has been secured) because a network
attacker might cause connections for one port to be received at some attacker might cause connections for one port to be received at some
other port. Failing to check the target URI might allow such an other port. Failing to check the target URI might allow such an
skipping to change at page 30, line 40 skipping to change at page 30, line 40
target URI (Section 7.1). target URI (Section 7.1).
If the server responds to such a request with a non-interim HTTP If the server responds to such a request with a non-interim HTTP
response message, as described in Section 15, then that response is response message, as described in Section 15, then that response is
considered an authoritative answer to the client's request. considered an authoritative answer to the client's request.
Note, however, that the above is not the only means for obtaining an Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative authoritative response, nor does it imply that an authoritative
response is always necessary (see [CACHING]). response is always necessary (see [CACHING]).
4.3.4. https certificate verification 4.3.4. https Certificate Verification
To establish a secured connection to dereference a URI, a client MUST To establish a secured connection to dereference a URI, a client MUST
verify that the service's identity is an acceptable match for the verify that the service's identity is an acceptable match for the
URI's origin server. Certificate verification is used to prevent URI's origin server. Certificate verification is used to prevent
server impersonation by an on-path attacker or by an attacker that server impersonation by an on-path attacker or by an attacker that
controls name resolution. This process requires that a client be controls name resolution. This process requires that a client be
configured with a set of trust anchors. configured with a set of trust anchors.
In general, a client MUST verify the service identity using the In general, a client MUST verify the service identity using the
verification process defined in Section 6 of [RFC6125]. The client verification process defined in Section 6 of [RFC6125]. The client
MUST construct a reference identity from the service's host: if the MUST construct a reference identity from the service's host: if the
host is a literal IP address (Section 4.3.5), the reference identity host is a literal IP address (Section 4.3.5), the reference identity
is an IP-ID, otherwise the host is a name and the reference identity is an IP-ID, otherwise the host is a name and the reference identity
is a DNS-ID. is a DNS-ID.
A reference identity of type CN-ID MUST NOT be used by clients. As A reference identity of type CN-ID MUST NOT be used by clients. As
noted in Section 6.2.1 of [RFC6125] a reference identity of type CN- noted in Section 6.2.1 of [RFC6125], a reference identity of type CN-
ID might be used by older clients. ID might be used by older clients.
A client might be specially configured to accept an alternative form A client might be specially configured to accept an alternative form
of server identity verification. For example, a client might be of server identity verification. For example, a client might be
connecting to a server whose address and hostname are dynamic, with connecting to a server whose address and hostname are dynamic, with
an expectation that the service will present a specific certificate an expectation that the service will present a specific certificate
(or a certificate matching some externally defined reference (or a certificate matching some externally defined reference
identity) rather than one matching the target URI's origin. identity) rather than one matching the target URI's origin.
In special cases, it might be appropriate for a client to simply In special cases, it might be appropriate for a client to simply
skipping to change at page 31, line 36 skipping to change at page 31, line 36
If the certificate is not valid for the target URI's origin, a user If the certificate is not valid for the target URI's origin, a user
agent MUST either obtain confirmation from the user before proceeding agent MUST either obtain confirmation from the user before proceeding
(see Section 3.5) or terminate the connection with a bad certificate (see Section 3.5) or terminate the connection with a bad certificate
error. Automated clients MUST log the error to an appropriate audit error. Automated clients MUST log the error to an appropriate audit
log (if available) and SHOULD terminate the connection (with a bad log (if available) and SHOULD terminate the connection (with a bad
certificate error). Automated clients MAY provide a configuration certificate error). Automated clients MAY provide a configuration
setting that disables this check, but MUST provide a setting which setting that disables this check, but MUST provide a setting which
enables it. enables it.
4.3.5. IP-ID reference identity 4.3.5. IP-ID Reference Identity
A server that is identified using an IP address literal in the "host" A server that is identified using an IP address literal in the "host"
field of an "https" URI has a reference identity of type IP-ID. An field of an "https" URI has a reference identity of type IP-ID. An
IP version 4 address uses the "IPv4address" ABNF rule and an IP IP version 4 address uses the "IPv4address" ABNF rule, and an IP
version 6 address uses the "IP-literal" production with the version 6 address uses the "IP-literal" production with the
"IPv6address" option; see Section 3.2.2 of [URI]. A reference "IPv6address" option; see Section 3.2.2 of [URI]. A reference
identity of IP-ID contains the decoded bytes of the IP address. identity of IP-ID contains the decoded bytes of the IP address.
An IP version 4 address is 4 octets and an IP version 6 address is 16 An IP version 4 address is 4 octets, and an IP version 6 address is
octets. Use of IP-ID is not defined for any other IP version. The 16 octets. Use of IP-ID is not defined for any other IP version.
iPAddress choice in the certificate subjectAltName extension does not The iPAddress choice in the certificate subjectAltName extension does
explicitly include the IP version and so relies on the length of the not explicitly include the IP version and so relies on the length of
address to distinguish versions; see Section 4.2.1.6 of [RFC5280]. the address to distinguish versions; see Section 4.2.1.6 of
[RFC5280].
A reference identity of type IP-ID matches if the address is A reference identity of type IP-ID matches if the address is
identical to an iPAddress value of the subjectAltName extension of identical to an iPAddress value of the subjectAltName extension of
the certificate. the certificate.
5. Fields 5. Fields
HTTP uses _fields_ to provide data in the form of extensible key/ HTTP uses _fields_ to provide data in the form of extensible key/
value pairs with a registered key namespace. Fields are sent and value pairs with a registered key namespace. Fields are sent and
received within the header and trailer sections of messages received within the header and trailer sections of messages
skipping to change at page 33, line 44 skipping to change at page 33, line 44
(",") and optional whitespace (OWS, defined in Section 5.6.3). For (",") and optional whitespace (OWS, defined in Section 5.6.3). For
consistency, use comma SP. consistency, use comma SP.
The order in which field lines with the same name are received is The order in which field lines with the same name are received is
therefore significant to the interpretation of the field value; a therefore significant to the interpretation of the field value; a
proxy MUST NOT change the order of these field line values when proxy MUST NOT change the order of these field line values when
forwarding a message. forwarding a message.
This means that, aside from the well-known exception noted below, a This means that, aside from the well-known exception noted below, a
sender MUST NOT generate multiple field lines with the same name in a sender MUST NOT generate multiple field lines with the same name in a
message (whether in the headers or trailers), or append a field line message (whether in the headers or trailers) or append a field line
when a field line of the same name already exists in the message, when a field line of the same name already exists in the message,
unless that field's definition allows multiple field line values to unless that field's definition allows multiple field line values to
be recombined as a comma-separated list [i.e., at least one be recombined as a comma-separated list (i.e., at least one
alternative of the field's definition allows a comma-separated list, alternative of the field's definition allows a comma-separated list,
such as an ABNF rule of #(values) defined in Section 5.6.1]. such as an ABNF rule of #(values) defined in Section 5.6.1).
| *Note:* In practice, the "Set-Cookie" header field ([COOKIE]) | *Note:* In practice, the "Set-Cookie" header field ([COOKIE])
| often appears in a response message across multiple field lines | often appears in a response message across multiple field lines
| and does not use the list syntax, violating the above | and does not use the list syntax, violating the above
| requirements on multiple field lines with the same field name. | requirements on multiple field lines with the same field name.
| Since it cannot be combined into a single field value, | Since it cannot be combined into a single field value,
| recipients ought to handle "Set-Cookie" as a special case while | recipients ought to handle "Set-Cookie" as a special case while
| processing fields. (See Appendix A.2.3 of [Kri2001] for | processing fields. (See Appendix A.2.3 of [Kri2001] for
| details.) | details.)
skipping to change at page 42, line 36 skipping to change at page 42, line 36
two-digit year, MUST interpret a timestamp that appears to be more two-digit year, MUST interpret a timestamp that appears to be more
than 50 years in the future as representing the most recent year in than 50 years in the future as representing the most recent year in
the past that had the same last two digits. the past that had the same last two digits.
Recipients of timestamp values are encouraged to be robust in parsing Recipients of timestamp values are encouraged to be robust in parsing
timestamps unless otherwise restricted by the field definition. For timestamps unless otherwise restricted by the field definition. For
example, messages are occasionally forwarded over HTTP from a non- example, messages are occasionally forwarded over HTTP from a non-
HTTP source that might generate any of the date and time HTTP source that might generate any of the date and time
specifications defined by the Internet Message Format. specifications defined by the Internet Message Format.
| *Note:* HTTP requirements for the date/time stamp format apply | *Note:* HTTP requirements for the date/time format apply only
| only to their usage within the protocol stream. | to their usage within the protocol stream. Implementations are
| Implementations are not required to use these formats for user | not required to use these formats for user presentation,
| presentation, request logging, etc. | request logging, etc.
6. Message Abstraction 6. Message Abstraction
Each major version of HTTP defines its own syntax for communicating Each major version of HTTP defines its own syntax for communicating
messages. This section defines an abstract data type for HTTP messages. This section defines an abstract data type for HTTP
messages based on a generalization of those message characteristics, messages based on a generalization of those message characteristics,
common structure, and capacity for conveying semantics. This common structure, and capacity for conveying semantics. This
abstraction is used to define requirements on senders and recipients abstraction is used to define requirements on senders and recipients
that are independent of the HTTP version, such that a message in one that are independent of the HTTP version, such that a message in one
version can be relayed through other versions without changing its version can be relayed through other versions without changing its
skipping to change at page 43, line 35 skipping to change at page 43, line 35
unknown prior to sending the content. unknown prior to sending the content.
Messages are intended to be _self-descriptive_: everything a Messages are intended to be _self-descriptive_: everything a
recipient needs to know about the message can be determined by recipient needs to know about the message can be determined by
looking at the message itself, after decoding or reconstituting parts looking at the message itself, after decoding or reconstituting parts
that have been compressed or elided in transit, without requiring an that have been compressed or elided in transit, without requiring an
understanding of the sender's current application state (established understanding of the sender's current application state (established
via prior messages). However, a client MUST retain knowledge of the via prior messages). However, a client MUST retain knowledge of the
request when parsing, interpreting, or caching a corresponding request when parsing, interpreting, or caching a corresponding
response. For example, responses to the HEAD method look just like response. For example, responses to the HEAD method look just like
the beginning of a response to GET, but cannot be parsed in the same the beginning of a response to GET but cannot be parsed in the same
manner. manner.
Note that this message abstraction is a generalization across many Note that this message abstraction is a generalization across many
versions of HTTP, including features that might not be found in some versions of HTTP, including features that might not be found in some
versions. For example, trailers were introduced within the HTTP/1.1 versions. For example, trailers were introduced within the HTTP/1.1
chunked transfer coding as a trailer section after the content. An chunked transfer coding as a trailer section after the content. An
equivalent feature is present in HTTP/2 and HTTP/3 within the header equivalent feature is present in HTTP/2 and HTTP/3 within the header
block that terminates each stream. block that terminates each stream.
6.1. Framing and Completeness 6.1. Framing and Completeness
skipping to change at page 45, line 30 skipping to change at page 45, line 30
implements SHOULD process the message as if it were in the highest implements SHOULD process the message as if it were in the highest
minor version within that major version to which the recipient is minor version within that major version to which the recipient is
conformant. A recipient can assume that a message with a higher conformant. A recipient can assume that a message with a higher
minor version, when sent to a recipient that has not yet indicated minor version, when sent to a recipient that has not yet indicated
support for that higher version, is sufficiently backwards-compatible support for that higher version, is sufficiently backwards-compatible
to be safely processed by any implementation of the same major to be safely processed by any implementation of the same major
version. version.
6.3. Header Fields 6.3. Header Fields
Fields (Section 5) that are sent/received before the content are Fields (Section 5) that are sent or received before the content are
referred to as "header fields" (or just "headers", colloquially). referred to as "header fields" (or just "headers", colloquially).
The _header section_ of a message consists of a sequence of header The _header section_ of a message consists of a sequence of header
field lines. Each header field might modify or extend message field lines. Each header field might modify or extend message
semantics, describe the sender, define the content, or provide semantics, describe the sender, define the content, or provide
additional context. additional context.
| *Note:* We refer to named fields specifically as a "header | *Note:* We refer to named fields specifically as a "header
| field" when they are only allowed to be sent in the header | field" when they are only allowed to be sent in the header
| section. | section.
skipping to change at page 48, line 39 skipping to change at page 48, line 39
information. information.
Trailer fields ought to be processed and stored separately from the Trailer fields ought to be processed and stored separately from the
fields in the header section to avoid contradicting message semantics fields in the header section to avoid contradicting message semantics
known at the time the header section was complete. The presence or known at the time the header section was complete. The presence or
absence of certain header fields might impact choices made for the absence of certain header fields might impact choices made for the
routing or processing of the message as a whole before the trailers routing or processing of the message as a whole before the trailers
are received; those choices cannot be unmade by the later discovery are received; those choices cannot be unmade by the later discovery
of trailer fields. of trailer fields.
6.5.1. Limitations on use of Trailers 6.5.1. Limitations on Use of Trailers
A trailer section is only possible when supported by the version of A trailer section is only possible when supported by the version of
HTTP in use and enabled by an explicit framing mechanism. For HTTP in use and enabled by an explicit framing mechanism. For
example, the chunked coding in HTTP/1.1 allows a trailer section to example, the chunked coding in HTTP/1.1 allows a trailer section to
be sent after the content (Section 7.1.2 of [HTTP/1.1]). be sent after the content (Section 7.1.2 of [HTTP/1.1]).
Many fields cannot be processed outside the header section because Many fields cannot be processed outside the header section because
their evaluation is necessary prior to receiving the content, such as their evaluation is necessary prior to receiving the content, such as
those that describe message framing, routing, authentication, request those that describe message framing, routing, authentication, request
modifiers, response controls, or content format. A sender MUST NOT modifiers, response controls, or content format. A sender MUST NOT
skipping to change at page 55, line 22 skipping to change at page 55, line 22
The mechanism used to correlate between request and response messages The mechanism used to correlate between request and response messages
is version dependent; some versions of HTTP use implicit ordering of is version dependent; some versions of HTTP use implicit ordering of
messages, while others use an explicit identifier. messages, while others use an explicit identifier.
All responses, regardless of the status code (including interim All responses, regardless of the status code (including interim
responses) can be sent at any time after a request is received, even responses) can be sent at any time after a request is received, even
if the request is not yet complete. A response can complete before if the request is not yet complete. A response can complete before
its corresponding request is complete (Section 6.1). Likewise, its corresponding request is complete (Section 6.1). Likewise,
clients are not expected to wait any specific amount of time for a clients are not expected to wait any specific amount of time for a
response. Clients (including intermediaries) might abandon a request response. Clients (including intermediaries) might abandon a request
if the response is not forthcoming within a reasonable period of if the response is not received within a reasonable period of time.
time.
A client that receives a response while it is still sending the A client that receives a response while it is still sending the
associated request SHOULD continue sending that request, unless it associated request SHOULD continue sending that request unless it
receives an explicit indication to the contrary (see, e.g., receives an explicit indication to the contrary (see, e.g.,
Section 9.5 of [HTTP/1.1] and Section 6.4 of [HTTP/2]). Section 9.5 of [HTTP/1.1] and Section 6.4 of [HTTP/2]).
7.6. Message Forwarding 7.6. Message Forwarding
As described in Section 3.7, intermediaries can serve a variety of As described in Section 3.7, intermediaries can serve a variety of
roles in the processing of HTTP requests and responses. Some roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability. intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the intermediary can enhance (or interfere) with either direction of the
stream. stream.
Intermediaries are expected to forward messages even when protocol Intermediaries are expected to forward messages even when protocol
elements are not recognized (e.g., new methods, status codes, or elements are not recognized (e.g., new methods, status codes, or
field names), since that preserves extensibility for downstream field names) since that preserves extensibility for downstream
recipients. recipients.
An intermediary not acting as a tunnel MUST implement the Connection An intermediary not acting as a tunnel MUST implement the Connection
header field, as specified in Section 7.6.1, and exclude fields from header field, as specified in Section 7.6.1, and exclude fields from
being forwarded that are only intended for the incoming connection. being forwarded that are only intended for the incoming connection.
An intermediary MUST NOT forward a message to itself unless it is An intermediary MUST NOT forward a message to itself unless it is
protected from an infinite request loop. In general, an intermediary protected from an infinite request loop. In general, an intermediary
ought to recognize its own server names, including any aliases, local ought to recognize its own server names, including any aliases, local
variations, or literal IP addresses, and respond to such requests variations, or literal IP addresses, and respond to such requests
skipping to change at page 57, line 31 skipping to change at page 57, line 31
message, since a connection-specific field might not be needed if message, since a connection-specific field might not be needed if
there are no parameters associated with a connection option. In there are no parameters associated with a connection option. In
contrast, a connection-specific field received without a contrast, a connection-specific field received without a
corresponding connection option usually indicates that the field has corresponding connection option usually indicates that the field has
been improperly forwarded by an intermediary and ought to be ignored been improperly forwarded by an intermediary and ought to be ignored
by the recipient. by the recipient.
When defining a new connection option that does not correspond to a When defining a new connection option that does not correspond to a
field, specification authors ought to reserve the corresponding field field, specification authors ought to reserve the corresponding field
name anyway in order to avoid later collisions. Such reserved field name anyway in order to avoid later collisions. Such reserved field
names are registered in the Hypertext Transfer Protocol (HTTP) Field names are registered in the "Hypertext Transfer Protocol (HTTP) Field
Name Registry (Section 16.3.1). Name Registry" (Section 16.3.1).
7.6.2. Max-Forwards 7.6.2. Max-Forwards
The "Max-Forwards" header field provides a mechanism with the TRACE The "Max-Forwards" header field provides a mechanism with the TRACE
(Section 9.3.8) and OPTIONS (Section 9.3.7) request methods to limit (Section 9.3.8) and OPTIONS (Section 9.3.7) request methods to limit
the number of times that the request is forwarded by proxies. This the number of times that the request is forwarded by proxies. This
can be useful when the client is attempting to trace a request that can be useful when the client is attempting to trace a request that
appears to be failing or looping mid-chain. appears to be failing or looping mid-chain.
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
skipping to change at page 60, line 41 skipping to change at page 60, line 41
received when forwarding the request. A proxy MUST NOT change the received when forwarding the request. A proxy MUST NOT change the
host name if the target URI contains a fully qualified domain name. host name if the target URI contains a fully qualified domain name.
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received target URI when forwarding it to the next inbound server received target URI when forwarding it to the next inbound server
except as required by that forwarding protocol. For example, a proxy except as required by that forwarding protocol. For example, a proxy
forwarding a request to an origin server via HTTP/1.1 will replace an forwarding a request to an origin server via HTTP/1.1 will replace an
empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*" empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*"
(Section 3.2.4 of [HTTP/1.1]), depending on the request method. (Section 3.2.4 of [HTTP/1.1]), depending on the request method.
A proxy MUST NOT transform the content (Section 6.4) of a message A proxy MUST NOT transform the content (Section 6.4) of a response
that contains a no-transform cache-control response directive message that contains a "no-transform" cache response directive
(Section 5.2 of [CACHING]). Note that this does not include changes (Section 5.2.2.6 of [CACHING]). Note that this does not apply to
to the message body that do not affect the content, such as transfer message transformations that do not change the content, such as the
codings (Section 7 of [HTTP/1.1]). addition or removal of transfer codings (Section 7 of [HTTP/1.1]).
A proxy MAY transform the content of a message that does not contain A proxy MAY transform the content of a message that does not contain
a no-transform cache-control directive. A proxy that transforms the a "no-transform" cache directive. A proxy that transforms the
content of a 200 (OK) response can inform downstream recipients that content of a 200 (OK) response can inform downstream recipients that
a transformation has been applied by changing the response status a transformation has been applied by changing the response status
code to 203 (Non-Authoritative Information) (Section 15.3.4). code to 203 (Non-Authoritative Information) (Section 15.3.4).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the endpoints of the communication chain, the resource state, about the endpoints of the communication chain, the resource state,
or the selected representation (other than the content) unless the or the selected representation (other than the content) unless the
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
skipping to change at page 65, line 42 skipping to change at page 65, line 42
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
text/html;charset=UTF-8 text/html;charset=UTF-8
Media types ought to be registered with IANA according to the Media types ought to be registered with IANA according to the
procedures defined in [BCP13]. procedures defined in [BCP13].
8.3.2. Charset 8.3.2. Charset
HTTP uses _charset_ names to indicate or negotiate the character HTTP uses _charset_ names to indicate or negotiate the character
encoding scheme ([RFC6365], Section 1.3) of a textual representation. encoding scheme ([RFC6365], Section 2) of a textual representation.
In the fields defined by this document, charset names appear either In the fields defined by this document, charset names appear either
in parameters (Content-Type), or, for Accept-Encoding, in the form of in parameters (Content-Type), or, for Accept-Encoding, in the form of
a plain token. In both cases, charset names are matched case- a plain token. In both cases, charset names are matched case-
insensitively. insensitively.
Charset names ought to be registered in the IANA "Character Sets" Charset names ought to be registered in the IANA "Character Sets"
registry (<https://www.iana.org/assignments/character-sets>) registry (<https://www.iana.org/assignments/character-sets>)
according to the procedures defined in Section 2 of [RFC2978]. according to the procedures defined in Section 2 of [RFC2978].
| *Note:* In theory, charset names are defined by the "mime- | *Note:* In theory, charset names are defined by the "mime-
skipping to change at page 66, line 49 skipping to change at page 66, line 49
Content-Encoding = #content-coding Content-Encoding = #content-coding
An example of its use is An example of its use is
Content-Encoding: gzip Content-Encoding: gzip
If one or more encodings have been applied to a representation, the If one or more encodings have been applied to a representation, the
sender that applied the encodings MUST generate a Content-Encoding sender that applied the encodings MUST generate a Content-Encoding
header field that lists the content codings in the order in which header field that lists the content codings in the order in which
they were applied. Note that the coding named "identity" is reserved they were applied. Note that the coding named "identity" is reserved
for its special role in Accept-Encoding, and thus SHOULD NOT be for its special role in Accept-Encoding and thus SHOULD NOT be
included. included.
Additional information about the encoding parameters can be provided Additional information about the encoding parameters can be provided
by other header fields not defined by this specification. by other header fields not defined by this specification.
Unlike Transfer-Encoding (Section 6.1 of [HTTP/1.1]), the codings Unlike Transfer-Encoding (Section 6.1 of [HTTP/1.1]), the codings
listed in Content-Encoding are a characteristic of the listed in Content-Encoding are a characteristic of the
representation; the representation is defined in terms of the coded representation; the representation is defined in terms of the coded
form, and all other metadata about the representation is about the form, and all other metadata about the representation is about the
coded form unless otherwise noted in the metadata definition. coded form unless otherwise noted in the metadata definition.
skipping to change at page 70, line 14 skipping to change at page 70, line 14
8.6. Content-Length 8.6. Content-Length
The "Content-Length" header field indicates the associated The "Content-Length" header field indicates the associated
representation's data length as a decimal non-negative integer number representation's data length as a decimal non-negative integer number
of octets. When transferring a representation as content, Content- of octets. When transferring a representation as content, Content-
Length refers specifically to the amount of data enclosed so that it Length refers specifically to the amount of data enclosed so that it
can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In
other cases, Content-Length indicates the selected representation's other cases, Content-Length indicates the selected representation's
current length, which can be used by recipients to estimate transfer current length, which can be used by recipients to estimate transfer
time or compare to previously stored representations. time or to compare with previously stored representations.
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A user agent SHOULD send Content-Length in a request when the method A user agent SHOULD send Content-Length in a request when the method
defines a meaning for enclosed content and it is not sending defines a meaning for enclosed content and it is not sending
Transfer-Encoding. For example, a user agent normally sends Content- Transfer-Encoding. For example, a user agent normally sends Content-
skipping to change at page 71, line 24 skipping to change at page 71, line 24
If the message is forwarded by a downstream intermediary, a Content- If the message is forwarded by a downstream intermediary, a Content-
Length field value that is inconsistent with the received message Length field value that is inconsistent with the received message
framing might cause a security failure due to request smuggling or framing might cause a security failure due to request smuggling or
response splitting. response splitting.
As a result, a sender MUST NOT forward a message with a Content- As a result, a sender MUST NOT forward a message with a Content-
Length header field value that is known to be incorrect. Length header field value that is known to be incorrect.
Likewise, a sender MUST NOT forward a message with a Content-Length Likewise, a sender MUST NOT forward a message with a Content-Length
header field value that does not match the ABNF above, with one header field value that does not match the ABNF above, with one
exception: A recipient of a Content-Length header field value exception: a recipient of a Content-Length header field value
consisting of the same decimal value repeated as a comma-separated consisting of the same decimal value repeated as a comma-separated
list (e.g, "Content-Length: 42, 42"), MAY either reject the message list (e.g, "Content-Length: 42, 42") MAY either reject the message as
as invalid or replace that invalid field value with a single instance invalid or replace that invalid field value with a single instance of
of the decimal value, since this likely indicates that a duplicate the decimal value, since this likely indicates that a duplicate was
was generated or combined by an upstream message processor. generated or combined by an upstream message processor.
8.7. Content-Location 8.7. Content-Location
The "Content-Location" header field references a URI that can be used The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's content. In other words, if one representation in this message's content. In other words, if one
were to perform a GET request on this URI at the time of this were to perform a GET request on this URI at the time of this
message's generation, then a 200 (OK) response would contain the same message's generation, then a 200 (OK) response would contain the same
representation that is enclosed as content in this message. representation that is enclosed as content in this message.
skipping to change at page 78, line 37 skipping to change at page 78, line 37
ETag: W/"xyzzy" ETag: W/"xyzzy"
ETag: "" ETag: ""
An entity-tag can be either a weak or strong validator, with strong An entity-tag can be either a weak or strong validator, with strong
being the default. If an origin server provides an entity-tag for a being the default. If an origin server provides an entity-tag for a
representation and the generation of that entity-tag does not satisfy representation and the generation of that entity-tag does not satisfy
all of the characteristics of a strong validator (Section 8.8.1), all of the characteristics of a strong validator (Section 8.8.1),
then the origin server MUST mark the entity-tag as weak by prefixing then the origin server MUST mark the entity-tag as weak by prefixing
its opaque value with "W/" (case-sensitive). its opaque value with "W/" (case-sensitive).
A sender MAY send the Etag field in a trailer section (see A sender MAY send the ETag field in a trailer section (see
Section 6.5). However, since trailers are often ignored, it is Section 6.5). However, since trailers are often ignored, it is
preferable to send Etag as a header field unless the entity-tag is preferable to send ETag as a header field unless the entity-tag is
generated while sending the content. generated while sending the content.
8.8.3.1. Generation 8.8.3.1. Generation
The principle behind entity-tags is that only the service author The principle behind entity-tags is that only the service author
knows the implementation of a resource well enough to select the most knows the implementation of a resource well enough to select the most
accurate and efficient validation mechanism for that resource, and accurate and efficient validation mechanism for that resource, and
that any such mechanism can be mapped to a simple sequence of octets that any such mechanism can be mapped to a simple sequence of octets
for easy comparison. Since the value is opaque, there is no need for for easy comparison. Since the value is opaque, there is no need for
the client to be aware of how each entity-tag is constructed. the client to be aware of how each entity-tag is constructed.
skipping to change at page 85, line 8 skipping to change at page 85, line 8
automatically retry a POST request if the underlying transport automatically retry a POST request if the underlying transport
connection closed before any part of a response is received, connection closed before any part of a response is received,
particularly if an idle persistent connection was used. particularly if an idle persistent connection was used.
A proxy MUST NOT automatically retry non-idempotent requests. A A proxy MUST NOT automatically retry non-idempotent requests. A
client SHOULD NOT automatically retry a failed automatic retry. client SHOULD NOT automatically retry a failed automatic retry.
9.2.3. Methods and Caching 9.2.3. Methods and Caching
For a cache to store and use a response, the associated method needs For a cache to store and use a response, the associated method needs
to explicitly allow caching, and detail under what conditions a to explicitly allow caching and to detail under what conditions a
response can be used to satisfy subsequent requests; a method response can be used to satisfy subsequent requests; a method
definition which does not do so cannot be cached. For additional definition that does not do so cannot be cached. For additional
requirements see [CACHING]. requirements see [CACHING].
This specification defines caching semantics for GET, HEAD, and POST, This specification defines caching semantics for GET, HEAD, and POST,
although the overwhelming majority of cache implementations only although the overwhelming majority of cache implementations only
support GET and HEAD. support GET and HEAD.
9.3. Method Definitions 9.3. Method Definitions
9.3.1. GET 9.3.1. GET
skipping to change at page 90, line 21 skipping to change at page 90, line 21
of the resource state). of the resource state).
An origin server MUST NOT send a validator field (Section 8.8), such An origin server MUST NOT send a validator field (Section 8.8), such
as an ETag or Last-Modified field, in a successful response to PUT as an ETag or Last-Modified field, in a successful response to PUT
unless the request's representation data was saved without any unless the request's representation data was saved without any
transformation applied to the content (i.e., the resource's new transformation applied to the content (i.e., the resource's new
representation data is identical to the content received in the PUT representation data is identical to the content received in the PUT
request) and the validator field value reflects the new request) and the validator field value reflects the new
representation. This requirement allows a user agent to know when representation. This requirement allows a user agent to know when
the representation it sent (and retains in memory) is the result of the representation it sent (and retains in memory) is the result of
the PUT, and thus doesn't need to be retrieved again from the origin the PUT, and thus it doesn't need to be retrieved again from the
server. The new validator(s) received in the response can be used origin server. The new validator(s) received in the response can be
for future conditional requests in order to prevent accidental used for future conditional requests in order to prevent accidental
overwrites (Section 13.1). overwrites (Section 13.1).
The fundamental difference between the POST and PUT methods is The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation. highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics, enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server. effect is only known by the origin server.
skipping to change at page 95, line 33 skipping to change at page 95, line 33
such content. such content.
Responses to the OPTIONS method are not cacheable. Responses to the OPTIONS method are not cacheable.
9.3.8. TRACE 9.3.8. TRACE
The TRACE method requests a remote, application-level loop-back of The TRACE method requests a remote, application-level loop-back of
the request message. The final recipient of the request SHOULD the request message. The final recipient of the request SHOULD
reflect the message received, excluding some fields described below, reflect the message received, excluding some fields described below,
back to the client as the content of a 200 (OK) response. The back to the client as the content of a 200 (OK) response. The
"message/http" (Section 10.1 of [HTTP/1.1]) format is one way to do "message/http" format (Section 10.1 of [HTTP/1.1]) is one way to do
so. The final recipient is either the origin server or the first so. The final recipient is either the origin server or the first
server to receive a Max-Forwards value of zero (0) in the request server to receive a Max-Forwards value of zero (0) in the request
(Section 7.6.2). (Section 7.6.2).
A client MUST NOT generate fields in a TRACE request containing A client MUST NOT generate fields in a TRACE request containing
sensitive data that might be disclosed by the response. For example, sensitive data that might be disclosed by the response. For example,
it would be foolish for a user agent to send stored user credentials it would be foolish for a user agent to send stored user credentials
(Section 11) or cookies [COOKIE] in a TRACE request. The final (Section 11) or cookies [COOKIE] in a TRACE request. The final
recipient of the request SHOULD exclude any request fields that are recipient of the request SHOULD exclude any request fields that are
likely to contain sensitive data when that recipient generates the likely to contain sensitive data when that recipient generates the
skipping to change at page 98, line 45 skipping to change at page 98, line 45
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
An example is: An example is:
From: webmaster@example.org From: spider-admin@example.org
The From header field is rarely sent by non-robotic user agents. A The From header field is rarely sent by non-robotic user agents. A
user agent SHOULD NOT send a From header field without explicit user agent SHOULD NOT send a From header field without explicit
configuration by the user, since that might conflict with the user's configuration by the user, since that might conflict with the user's
privacy interests or their site's security policy. privacy interests or their site's security policy.
A robotic user agent SHOULD send a valid From header field so that A robotic user agent SHOULD send a valid From header field so that
the person responsible for running the robot can be contacted if the person responsible for running the robot can be contacted if
problems occur on servers, such as if the robot is sending excessive, problems occur on servers, such as if the robot is sending excessive,
unwanted, or invalid requests. unwanted, or invalid requests.
skipping to change at page 100, line 34 skipping to change at page 100, line 34
pseudonyms or truncating the query and/or path components. An pseudonyms or truncating the query and/or path components. An
intermediary SHOULD NOT modify or delete the Referer header field intermediary SHOULD NOT modify or delete the Referer header field
when the field value shares the same scheme and host as the target when the field value shares the same scheme and host as the target
URI. URI.
10.1.4. TE 10.1.4. TE
The "TE" header field describes capabilities of the client with The "TE" header field describes capabilities of the client with
regard to transfer encodings and trailer sections. regard to transfer encodings and trailer sections.
A TE field with a "trailers" member sent in a request indicates that As described in Section 6.5, a TE field with a "trailers" member sent
the client will not discard trailer fields, as described in in a request indicates that the client will not discard trailer
Section 6.5. fields.
TE is also used within HTTP/1.1 to advise servers about what transfer TE is also used within HTTP/1.1 to advise servers about which
codings the client is able to accept in a response. As of transfer codings the client is able to accept in a response. As of
publication, only HTTP/1.1 uses transfer codings (see Section 7 of publication, only HTTP/1.1 uses transfer codings (see Section 7 of
[HTTP/1.1]). [HTTP/1.1]).
The TE field value is a list of members, with each member (aside from The TE field value is a list of members, with each member (aside from
"trailers") consisting of a transfer coding name token with an "trailers") consisting of a transfer coding name token with an
optional weight indicating the client's relative preference for that optional weight indicating the client's relative preference for that
transfer coding (Section 12.4.2) and optional parameters for that transfer coding (Section 12.4.2) and optional parameters for that
transfer coding. transfer coding.
TE = #t-codings TE = #t-codings
skipping to change at page 105, line 45 skipping to change at page 105, line 45
11. HTTP Authentication 11. HTTP Authentication
11.1. Authentication Scheme 11.1. Authentication Scheme
HTTP provides a general framework for access control and HTTP provides a general framework for access control and
authentication, via an extensible set of challenge-response authentication, via an extensible set of challenge-response
authentication schemes, which can be used by a server to challenge a authentication schemes, which can be used by a server to challenge a
client request and by a client to provide authentication information. client request and by a client to provide authentication information.
It uses a case-insensitive token to identify the authentication It uses a case-insensitive token to identify the authentication
scheme scheme:
auth-scheme = token auth-scheme = token
Aside from the general framework, this document does not specify any Aside from the general framework, this document does not specify any
authentication schemes. New and existing authentication schemes are authentication schemes. New and existing authentication schemes are
specified independently and ought to be registered within the specified independently and ought to be registered within the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry". "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry".
For example, the "basic" and "digest" authentication schemes are For example, the "basic" and "digest" authentication schemes are
defined by RFC 7617 and RFC 7616, respectively. defined by RFC 7617 and RFC 7616, respectively.
skipping to change at page 109, line 48 skipping to change at page 109, line 48
value, as it might contain more than one challenge, and each value, as it might contain more than one challenge, and each
challenge can contain a comma-separated list of authentication challenge can contain a comma-separated list of authentication
parameters. Furthermore, the header field itself can occur multiple parameters. Furthermore, the header field itself can occur multiple
times. times.
For instance: For instance:
WWW-Authenticate: Basic realm="simple", Newauth realm="apps", WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
type=1, title="Login to \"apps\"" type=1, title="Login to \"apps\""
This header field contains two challenges; one for the "Basic" scheme This header field contains two challenges, one for the "Basic" scheme
with a realm value of "simple", and another for the "Newauth" scheme with a realm value of "simple" and another for the "Newauth" scheme
with a realm value of "apps", and two additional parameters "type" with a realm value of "apps". It also contains two additional
and "title". parameters, "type" and "title".
Some user agents do not recognise this form, however. As a result, Some user agents do not recognize this form, however. As a result,
sending a WWW-Authenticate field value with more than one member on sending a WWW-Authenticate field value with more than one member on
the same field line might not be interoperable. the same field line might not be interoperable.
| *Note:* The challenge grammar production uses the list syntax | *Note:* The challenge grammar production uses the list syntax
| as well. Therefore, a sequence of comma, whitespace, and comma | as well. Therefore, a sequence of comma, whitespace, and comma
| can be considered either as applying to the preceding | can be considered either as applying to the preceding
| challenge, or to be an empty entry in the list of challenges. | challenge, or to be an empty entry in the list of challenges.
| In practice, this ambiguity does not affect the semantics of | In practice, this ambiguity does not affect the semantics of
| the header field value and thus is harmless. | the header field value and thus is harmless.
skipping to change at page 110, line 39 skipping to change at page 110, line 39
require otherwise, such as credentials that vary according to a require otherwise, such as credentials that vary according to a
challenge value or using synchronized clocks). challenge value or using synchronized clocks).
A proxy forwarding a request MUST NOT modify any Authorization header A proxy forwarding a request MUST NOT modify any Authorization header
fields in that request. See Section 3.5 of [CACHING] for details of fields in that request. See Section 3.5 of [CACHING] for details of
and requirements pertaining to handling of the Authorization header and requirements pertaining to handling of the Authorization header
field by HTTP caches. field by HTTP caches.
11.6.3. Authentication-Info 11.6.3. Authentication-Info
HTTP authentication schemes can use the Authentication-Info response HTTP authentication schemes can use the "Authentication-Info"
field to communicate information after the client's authentication response field to communicate information after the client's
credentials have been accepted. This information can include a authentication credentials have been accepted. This information can
finalization message from the server (e.g., it can contain the server include a finalization message from the server (e.g., it can contain
authentication). the server authentication).
The field value is a list of parameters (name/value pairs), using the The field value is a list of parameters (name/value pairs), using the
"auth-param" syntax defined in Section 11.3. This specification only "auth-param" syntax defined in Section 11.3. This specification only
describes the generic format; authentication schemes using describes the generic format; authentication schemes using
Authentication-Info will define the individual parameters. The Authentication-Info will define the individual parameters. The
"Digest" Authentication Scheme, for instance, defines multiple "Digest" Authentication Scheme, for instance, defines multiple
parameters in Section 3.5 of [RFC7616]. parameters in Section 3.5 of [RFC7616].
Authentication-Info = #auth-param Authentication-Info = #auth-param
skipping to change at page 112, line 16 skipping to change at page 112, line 16
only to the next inbound proxy that demanded authentication using the only to the next inbound proxy that demanded authentication using the
Proxy-Authenticate header field. When multiple proxies are used in a Proxy-Authenticate header field. When multiple proxies are used in a
chain, the Proxy-Authorization header field is consumed by the first chain, the Proxy-Authorization header field is consumed by the first
inbound proxy that was expecting to receive credentials. A proxy MAY inbound proxy that was expecting to receive credentials. A proxy MAY
relay the credentials from the client request to the next proxy if relay the credentials from the client request to the next proxy if
that is the mechanism by which the proxies cooperatively authenticate that is the mechanism by which the proxies cooperatively authenticate
a given request. a given request.
11.7.3. Proxy-Authentication-Info 11.7.3. Proxy-Authentication-Info
The Proxy-Authentication-Info response header field is equivalent to The "Proxy-Authentication-Info" response header field is equivalent
Authentication-Info, except that it applies to proxy authentication to Authentication-Info, except that it applies to proxy
(Section 11.3) and its semantics are defined by the authentication authentication (Section 11.3) and its semantics are defined by the
scheme indicated by the Proxy-Authorization header field authentication scheme indicated by the Proxy-Authorization header
(Section 11.7.2) of the corresponding request: field (Section 11.7.2) of the corresponding request:
Proxy-Authentication-Info = #auth-param Proxy-Authentication-Info = #auth-param
However, unlike Authentication-Info, the Proxy-Authentication-Info However, unlike Authentication-Info, the Proxy-Authentication-Info
header field applies only to the next outbound client on the response header field applies only to the next outbound client on the response
chain. This is because only the client that chose a given proxy is chain. This is because only the client that chose a given proxy is
likely to have the credentials necessary for authentication. likely to have the credentials necessary for authentication.
However, when multiple proxies are used within the same However, when multiple proxies are used within the same
administrative domain, such as office and regional caching proxies administrative domain, such as office and regional caching proxies
within a large corporate network, it is common for credentials to be within a large corporate network, it is common for credentials to be
skipping to change at page 113, line 4 skipping to change at page 113, line 4
that information; for example, in different formats, languages, or that information; for example, in different formats, languages, or
encodings. Likewise, different users or user agents might have encodings. Likewise, different users or user agents might have
differing capabilities, characteristics, or preferences that could differing capabilities, characteristics, or preferences that could
influence which representation, among those available, would be best influence which representation, among those available, would be best
to deliver. For this reason, HTTP provides mechanisms for content to deliver. For this reason, HTTP provides mechanisms for content
negotiation. negotiation.
This specification defines three patterns of content negotiation that This specification defines three patterns of content negotiation that
can be made visible within the protocol: "proactive" negotiation, can be made visible within the protocol: "proactive" negotiation,
where the server selects the representation based upon the user where the server selects the representation based upon the user
agent's stated preferences, "reactive" negotiation, where the server agent's stated preferences; "reactive" negotiation, where the server
provides a list of representations for the user agent to choose from, provides a list of representations for the user agent to choose from;
and "request content" negotiation, where the user agent selects the and "request content" negotiation, where the user agent selects the
representation for a future request based upon the server's stated representation for a future request based upon the server's stated
preferences in past responses. preferences in past responses.
Other patterns of content negotiation include "conditional content", Other patterns of content negotiation include "conditional content",
where the representation consists of multiple parts that are where the representation consists of multiple parts that are
selectively rendered based on user agent parameters, "active selectively rendered based on user agent parameters, "active
content", where the representation contains a script that makes content", where the representation contains a script that makes
additional (more specific) requests based on the user agent additional (more specific) requests based on the user agent
characteristics, and "Transparent Content Negotiation" ([RFC2295]), characteristics, and "Transparent Content Negotiation" ([RFC2295]),
skipping to change at page 115, line 38 skipping to change at page 115, line 38
When content negotiation preferences are sent in a server's response, When content negotiation preferences are sent in a server's response,
the listed preferences are called _request content negotiation_ the listed preferences are called _request content negotiation_
because they intend to influence selection of an appropriate content because they intend to influence selection of an appropriate content
for subsequent requests to that resource. For example, the Accept for subsequent requests to that resource. For example, the Accept
(Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields (Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields
can be sent in a response to indicate preferred media types and can be sent in a response to indicate preferred media types and
content codings for subsequent requests to that resource. content codings for subsequent requests to that resource.
Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch" Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch"
response header field which allows discovery of which content types response header field, which allows discovery of which content types
are accepted in PATCH requests. are accepted in PATCH requests.
12.4. Content Negotiation Field Features 12.4. Content Negotiation Field Features
12.4.1. Absence 12.4.1. Absence
For each of the content negotiation fields, a request that does not For each of the content negotiation fields, a request that does not
contain the field implies that the sender has no preference on that contain the field implies that the sender has no preference on that
dimension of negotiation. dimension of negotiation.
skipping to change at page 116, line 45 skipping to change at page 116, line 45
12.4.3. Wildcard Values 12.4.3. Wildcard Values
Most of these header fields, where indicated, define a wildcard value Most of these header fields, where indicated, define a wildcard value
("*") to select unspecified values. If no wildcard is present, ("*") to select unspecified values. If no wildcard is present,
values that are not explicitly mentioned in the field are considered values that are not explicitly mentioned in the field are considered
unacceptable. Within Vary, the wildcard value means that the unacceptable. Within Vary, the wildcard value means that the
variance is unlimited. variance is unlimited.
| *Note:* In practice, using wildcards in content negotiation has | *Note:* In practice, using wildcards in content negotiation has
| limited practical value, because it is seldom useful to say, | limited practical value because it is seldom useful to say, for
| for example, "I prefer image/* more or less than (some other | example, "I prefer image/* more or less than (some other
| specific value)". Clients can explicitly request a 406 (Not | specific value)". By sending Accept: */*;q=0, clients can
| Acceptable) response if a more preferred format is not | explicitly request a 406 (Not Acceptable) response if a more
| available by sending Accept: */*;q=0, but they still need to be | preferred format is not available, but they still need to be
| able to handle a different response, since the server is | able to handle a different response since the server is allowed
| allowed to ignore their preference. | to ignore their preference.
12.5. Content Negotiation Fields 12.5. Content Negotiation Fields
12.5.1. Accept 12.5.1. Accept
The "Accept" header field can be used by user agents to specify their The "Accept" header field can be used by user agents to specify their
preferences regarding response media types. For example, Accept preferences regarding response media types. For example, Accept
header fields can be used to indicate that the request is header fields can be used to indicate that the request is
specifically limited to a small set of desired types, as in the case specifically limited to a small set of desired types, as in the case
of a request for an in-line image. of a request for an in-line image.
When sent by a server in a response, Accept provides information When sent by a server in a response, Accept provides information
about what content types are preferred in the content of a subsequent about which content types are preferred in the content of a
request to the same resource. subsequent request to the same resource.
Accept = #( media-range [ weight ] ) Accept = #( media-range [ weight ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) parameters ) parameters
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
skipping to change at page 119, line 49 skipping to change at page 119, line 49
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset header field, The special value "*", if present in the Accept-Charset header field,
matches every charset that is not mentioned elsewhere in the field. matches every charset that is not mentioned elsewhere in the field.
| *Note:* Accept-Charset is deprecated because UTF-8 has become | *Note:* Accept-Charset is deprecated because UTF-8 has become
| nearly ubiquitous and sending a detailed list of user-preferred | nearly ubiquitous and sending a detailed list of user-preferred
| charsets wastes bandwidth, increases latency, and makes passive | charsets wastes bandwidth, increases latency, and makes passive
| fingerprinting far too easy (Section 17.13). Most general- | fingerprinting far too easy (Section 17.13). Most general-
| purpose user agents do not send Accept-Charset, unless | purpose user agents do not send Accept-Charset unless
| specifically configured to do so. | specifically configured to do so.
12.5.3. Accept-Encoding 12.5.3. Accept-Encoding
The "Accept-Encoding" header field can be used to indicate The "Accept-Encoding" header field can be used to indicate
preferences regarding the use of content codings (Section 8.4.1). preferences regarding the use of content codings (Section 8.4.1).
When sent by a user agent in a request, Accept-Encoding indicates the When sent by a user agent in a request, Accept-Encoding indicates the
content codings acceptable in a response. content codings acceptable in a response.
When sent by a server in a response, Accept-Encoding provides When sent by a server in a response, Accept-Encoding provides
information about what content codings are preferred in the content information about which content codings are preferred in the content
of a subsequent request to the same resource. of a subsequent request to the same resource.
An "identity" token is used as a synonym for "no encoding" in order An "identity" token is used as a synonym for "no encoding" in order
to communicate when no encoding is preferred. to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value (weight) Each codings value MAY be given an associated quality value (weight)
representing the preference for that encoding, as defined in representing the preference for that encoding, as defined in
skipping to change at page 121, line 13 skipping to change at page 121, line 13
defined in Section 12.4.2, a qvalue of 0 means "not acceptable".) defined in Section 12.4.2, a qvalue of 0 means "not acceptable".)
A representation could be encoded with multiple content codings. A representation could be encoded with multiple content codings.
However, most content codings are alternative ways to accomplish the However, most content codings are alternative ways to accomplish the
same purpose (e.g., data compression). When selecting between same purpose (e.g., data compression). When selecting between
multiple content codings that have the same purpose, the acceptable multiple content codings that have the same purpose, the acceptable
content coding with the highest non-zero qvalue is preferred. content coding with the highest non-zero qvalue is preferred.
An Accept-Encoding header field with a field value that is empty An Accept-Encoding header field with a field value that is empty
implies that the user agent does not want any content coding in implies that the user agent does not want any content coding in
response. If an Accept-Encoding header field is present in a request response. If a non-empty Accept-Encoding header field is present in
and none of the available representations for the response have a a request and none of the available representations for the response
content coding that is listed as acceptable, the origin server SHOULD have a content coding that is listed as acceptable, the origin server
send a response without any content coding. SHOULD send a response without any content coding unless the identity
coding is indicated as unacceptable.
When the Accept-Encoding header field is present in a response, it When the Accept-Encoding header field is present in a response, it
indicates what content codings the resource was willing to accept in indicates what content codings the resource was willing to accept in
the associated request. The field value is evaluated the same way as the associated request. The field value is evaluated the same way as
in a request. in a request.
Note that this information is specific to the associated request; the Note that this information is specific to the associated request; the
set of supported encodings might be different for other resources on set of supported encodings might be different for other resources on
the same server and could change over time or depend on other aspects the same server and could change over time or depend on other aspects
of the request (such as the request method). of the request (such as the request method).
skipping to change at page 121, line 40 skipping to change at page 121, line 41
include an Accept-Encoding header field in that response, allowing include an Accept-Encoding header field in that response, allowing
clients to distinguish between issues related to content codings and clients to distinguish between issues related to content codings and
media types. In order to avoid confusion with issues related to media types. In order to avoid confusion with issues related to
media types, servers that fail a request with a 415 status for media types, servers that fail a request with a 415 status for
reasons unrelated to content codings MUST NOT include the Accept- reasons unrelated to content codings MUST NOT include the Accept-
Encoding header field. Encoding header field.
The most common use of Accept-Encoding is in responses with a 415 The most common use of Accept-Encoding is in responses with a 415
(Unsupported Media Type) status code, in response to optimistic use (Unsupported Media Type) status code, in response to optimistic use
of a content coding by clients. However, the header field can also of a content coding by clients. However, the header field can also
be used to indicate to clients that content codings are supported, to be used to indicate to clients that content codings are supported in
optimize future interactions. For example, a resource might include order to optimize future interactions. For example, a resource might
it in a 2xx (Successful) response when the request content was big include it in a 2xx (Successful) response when the request content
enough to justify use of a compression coding but the client failed was big enough to justify use of a compression coding but the client
do so. failed do so.
12.5.4. Accept-Language 12.5.4. Accept-Language
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 8.5.1. response. Language tags are defined in Section 8.5.1.
Accept-Language = #( language-range [ weight ] ) Accept-Language = #( language-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
skipping to change at page 124, line 21 skipping to change at page 124, line 21
Accept-Language header field. Accept-Language header field.
Vary might be elided when an origin server considers variance in Vary might be elided when an origin server considers variance in
content selection to be less significant than Vary's performance content selection to be less significant than Vary's performance
impact on caching, particularly when reuse is already limited by impact on caching, particularly when reuse is already limited by
Cache-Control response directives (Section 5.2 of [CACHING]). Cache-Control response directives (Section 5.2 of [CACHING]).
There is no need to send the Authorization field name in Vary because There is no need to send the Authorization field name in Vary because
reuse of that response for a different user is prohibited by the reuse of that response for a different user is prohibited by the
field definition (Section 11.6.2). Likewise, if the response content field definition (Section 11.6.2). Likewise, if the response content
has been selected or influenced by network region but the origin has been selected or influenced by network region, but the origin
server wants the cached response to be reused even if recipients move server wants the cached response to be reused even if recipients move
from one region to another, then there is no need for the origin from one region to another, then there is no need for the origin
server to indicate such variance in Vary. server to indicate such variance in Vary.
13. Conditional Requests 13. Conditional Requests
A conditional request is an HTTP request with one or more request A conditional request is an HTTP request with one or more request
header fields that indicate a precondition to be tested before header fields that indicate a precondition to be tested before
applying the request method to the target resource. Section 13.2 applying the request method to the target resource. Section 13.2
defines when to evaluate preconditions and their order of precedence defines when to evaluate preconditions and their order of precedence
skipping to change at page 126, line 14 skipping to change at page 126, line 14
If-Match is most often used with state-changing methods (e.g., POST, If-Match is most often used with state-changing methods (e.g., POST,
PUT, DELETE) to prevent accidental overwrites when multiple user PUT, DELETE) to prevent accidental overwrites when multiple user
agents might be acting in parallel on the same resource (i.e., to agents might be acting in parallel on the same resource (i.e., to
prevent the "lost update" problem). In general, it can be used with prevent the "lost update" problem). In general, it can be used with
any method that involves the selection or modification of a any method that involves the selection or modification of a
representation to abort the request if the selected representation's representation to abort the request if the selected representation's
current entity-tag is not a member within the If-Match field value. current entity-tag is not a member within the If-Match field value.
When an origin server receives a request that selects a When an origin server receives a request that selects a
representation and that request includes an If-Match header field, representation and that request includes an If-Match header field,
the origin server MUST evaluate the If-Match condition as per the origin server MUST evaluate the If-Match condition per
Section 13.2 prior to performing the method. Section 13.2 prior to performing the method.
To evaluate a received If-Match header field: To evaluate a received If-Match header field:
1. If the field value is "*", the condition is true if the origin 1. If the field value is "*", the condition is true if the origin
server has a current representation for the target resource. server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is 2. If the field value is a list of entity-tags, the condition is
true if any of the listed tags match the entity-tag of the true if any of the listed tags match the entity-tag of the
selected representation. selected representation.
skipping to change at page 127, line 8 skipping to change at page 127, line 8
collide and potentially lose important state transitions. For those collide and potentially lose important state transitions. For those
kinds of resources, an origin server is better off being stringent in kinds of resources, an origin server is better off being stringent in
sending 412 for every failed precondition on an unsafe method. In sending 412 for every failed precondition on an unsafe method. In
other cases, excluding the ETag field from a success response might other cases, excluding the ETag field from a success response might
encourage the user agent to perform a GET as its next request to encourage the user agent to perform a GET as its next request to
eliminate confusion about the resource's current state. eliminate confusion about the resource's current state.
A client MAY send an If-Match header field in a GET request to A client MAY send an If-Match header field in a GET request to
indicate that it would prefer a 412 (Precondition Failed) response if indicate that it would prefer a 412 (Precondition Failed) response if
the selected representation does not match. However, this is only the selected representation does not match. However, this is only
useful in range requests (Section 14), for completing a previously useful in range requests (Section 14) for completing a previously
received partial representation, when there is no desire for a new received partial representation when there is no desire for a new
representation. If-Range (Section 13.1.5) is better suited for range representation. If-Range (Section 13.1.5) is better suited for range
requests when the client prefers to receive a new representation. requests when the client prefers to receive a new representation.
A cache or intermediary MAY ignore If-Match because its A cache or intermediary MAY ignore If-Match because its
interoperability features are only necessary for an origin server. interoperability features are only necessary for an origin server.
Note that an If-Match header field with a list value containing "*" Note that an If-Match header field with a list value containing "*"
and other values (including other instances of "*") is syntactically and other values (including other instances of "*") is syntactically
invalid (therefore not allowed to be generated) and furthermore is invalid (therefore not allowed to be generated) and furthermore is
unlikely to be interoperable. unlikely to be interoperable.
skipping to change at page 128, line 15 skipping to change at page 128, line 15
If-None-Match can also be used with a value of "*" to prevent an If-None-Match can also be used with a value of "*" to prevent an
unsafe request method (e.g., PUT) from inadvertently modifying an unsafe request method (e.g., PUT) from inadvertently modifying an
existing representation of the target resource when the client existing representation of the target resource when the client
believes that the resource does not have a current representation believes that the resource does not have a current representation
(Section 9.2.1). This is a variation on the "lost update" problem (Section 9.2.1). This is a variation on the "lost update" problem
that might arise if more than one client attempts to create an that might arise if more than one client attempts to create an
initial representation for the target resource. initial representation for the target resource.
When an origin server receives a request that selects a When an origin server receives a request that selects a
representation and that request includes an If-None-Match header representation and that request includes an If-None-Match header
field, the origin server MUST evaluate the If-None-Match condition as field, the origin server MUST evaluate the If-None-Match condition
per Section 13.2 prior to performing the method. per Section 13.2 prior to performing the method.
To evaluate a received If-None-Match header field: To evaluate a received If-None-Match header field:
1. If the field value is "*", the condition is false if the origin 1. If the field value is "*", the condition is false if the origin
server has a current representation for the target resource. server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is 2. If the field value is a list of entity-tags, the condition is
false if one of the listed tags matches the entity-tag of the false if one of the listed tags matches the entity-tag of the
selected representation. selected representation.
skipping to change at page 130, line 8 skipping to change at page 130, line 8
window, a user agent will generate an If-Modified-Since field value window, a user agent will generate an If-Modified-Since field value
based on either its own clock or a Date header field received from based on either its own clock or a Date header field received from
the server in a prior response. Origin servers that choose an exact the server in a prior response. Origin servers that choose an exact
timestamp match based on the selected representation's Last-Modified timestamp match based on the selected representation's Last-Modified
header field will not be able to help the user agent limit its data header field will not be able to help the user agent limit its data
transfers to only those changed during the specified window. transfers to only those changed during the specified window.
When an origin server receives a request that selects a When an origin server receives a request that selects a
representation and that request includes an If-Modified-Since header representation and that request includes an If-Modified-Since header
field without an If-None-Match header field, the origin server SHOULD field without an If-None-Match header field, the origin server SHOULD
evaluate the If-Modified-Since condition as per Section 13.2 prior to evaluate the If-Modified-Since condition per Section 13.2 prior to
performing the method. performing the method.
To evaluate a received If-Modified-Since header field: To evaluate a received If-Modified-Since header field:
1. If the selected representation's last modification date is 1. If the selected representation's last modification date is
earlier or equal to the date provided in the field value, the earlier or equal to the date provided in the field value, the
condition is false. condition is false.
2. Otherwise, the condition is true. 2. Otherwise, the condition is true.
skipping to change at page 131, line 24 skipping to change at page 131, line 24
does not supply entity-tags with its representations (i.e., to does not supply entity-tags with its representations (i.e., to
prevent the "lost update" problem). In general, it can be used with prevent the "lost update" problem). In general, it can be used with
any method that involves the selection or modification of a any method that involves the selection or modification of a
representation to abort the request if the selected representation's representation to abort the request if the selected representation's
last modification date has changed since the date provided in the If- last modification date has changed since the date provided in the If-
Unmodified-Since field value. Unmodified-Since field value.
When an origin server receives a request that selects a When an origin server receives a request that selects a
representation and that request includes an If-Unmodified-Since representation and that request includes an If-Unmodified-Since
header field without an If-Match header field, the origin server MUST header field without an If-Match header field, the origin server MUST
evaluate the If-Unmodified-Since condition as per Section 13.2 prior evaluate the If-Unmodified-Since condition per Section 13.2 prior to
to performing the method. performing the method.
To evaluate a received If-Unmodified-Since header field: To evaluate a received If-Unmodified-Since header field:
1. If the selected representation's last modification date is 1. If the selected representation's last modification date is
earlier than or equal to the date provided in the field value, earlier than or equal to the date provided in the field value,
the condition is true. the condition is true.
2. Otherwise, the condition is false. 2. Otherwise, the condition is false.
An origin server that evaluates an If-Unmodified-Since condition MUST An origin server that evaluates an If-Unmodified-Since condition MUST
skipping to change at page 132, line 16 skipping to change at page 132, line 16
request appears to have already been applied is more efficient for request appears to have already been applied is more efficient for
many authoring use cases, but comes with some risk if multiple user many authoring use cases, but comes with some risk if multiple user
agents are making change requests that are very similar but not agents are making change requests that are very similar but not
cooperative. In those cases, an origin server is better off being cooperative. In those cases, an origin server is better off being
stringent in sending 412 for every failed precondition on an unsafe stringent in sending 412 for every failed precondition on an unsafe
method. method.
A client MAY send an If-Unmodified-Since header field in a GET A client MAY send an If-Unmodified-Since header field in a GET
request to indicate that it would prefer a 412 (Precondition Failed) request to indicate that it would prefer a 412 (Precondition Failed)
response if the selected representation has been modified. However, response if the selected representation has been modified. However,
this is only useful in range requests (Section 14), for completing a this is only useful in range requests (Section 14) for completing a
previously received partial representation, when there is no desire previously received partial representation when there is no desire
for a new representation. If-Range (Section 13.1.5) is better suited for a new representation. If-Range (Section 13.1.5) is better suited
for range requests when the client prefers to receive a new for range requests when the client prefers to receive a new
representation. representation.
A cache or intermediary MAY ignore If-Unmodified-Since because its A cache or intermediary MAY ignore If-Unmodified-Since because its
interoperability features are only necessary for an origin server. interoperability features are only necessary for an origin server.
13.1.5. If-Range 13.1.5. If-Range
The "If-Range" header field provides a special conditional request The "If-Range" header field provides a special conditional request
skipping to change at page 133, line 19 skipping to change at page 133, line 19
field received in a request for a target resource that does not field received in a request for a target resource that does not
support Range requests. support Range requests.
A client MUST NOT generate an If-Range header field containing an A client MUST NOT generate an If-Range header field containing an
entity-tag that is marked as weak. A client MUST NOT generate an If- entity-tag that is marked as weak. A client MUST NOT generate an If-
Range header field containing an HTTP-date unless the client has no Range header field containing an HTTP-date unless the client has no
entity-tag for the corresponding representation and the date is a entity-tag for the corresponding representation and the date is a
strong validator in the sense defined by Section 8.8.2.2. strong validator in the sense defined by Section 8.8.2.2.
A server that receives an If-Range header field on a Range request A server that receives an If-Range header field on a Range request
MUST evaluate the condition as per Section 13.2 prior to performing MUST evaluate the condition per Section 13.2 prior to performing the
the method. method.
To evaluate a received If-Range header field containing an HTTP-date: To evaluate a received If-Range header field containing an HTTP-date:
1. If the HTTP-date validator provided is not a strong validator in 1. If the HTTP-date validator provided is not a strong validator in
the sense defined by Section 8.8.2.2, the condition is false. the sense defined by Section 8.8.2.2, the condition is false.
2. If the HTTP-date validator provided exactly matches the 2. If the HTTP-date validator provided exactly matches the
Last-Modified field value for the selected representation, the Last-Modified field value for the selected representation, the
condition is true. condition is true.
skipping to change at page 133, line 47 skipping to change at page 133, line 47
field value for the selected representation using the strong field value for the selected representation using the strong
comparison function (Section 8.8.3.2), the condition is true. comparison function (Section 8.8.3.2), the condition is true.
2. Otherwise, the condition is false. 2. Otherwise, the condition is false.
A recipient of an If-Range header field MUST ignore the Range header A recipient of an If-Range header field MUST ignore the Range header
field if the If-Range condition evaluates to false. Otherwise, the field if the If-Range condition evaluates to false. Otherwise, the
recipient SHOULD process the Range header field as requested. recipient SHOULD process the Range header field as requested.
Note that the If-Range comparison is by exact match, including when Note that the If-Range comparison is by exact match, including when
the validator is an HTTP-date, and so differs from the "earlier than the validator is an HTTP-date, and so it differs from the "earlier
or equal to" comparison used when evaluating an If-Unmodified-Since than or equal to" comparison used when evaluating an
conditional. If-Unmodified-Since conditional.
13.2. Evaluation of Preconditions 13.2. Evaluation of Preconditions
13.2.1. When to Evaluate 13.2.1. When to Evaluate
Except when excluded below, a recipient cache or origin server MUST Except when excluded below, a recipient cache or origin server MUST
evaluate received request preconditions after it has successfully evaluate received request preconditions after it has successfully
performed its normal request checks and just before it would process performed its normal request checks and just before it would process
the request content (if any) or perform the action associated with the request content (if any) or perform the action associated with
the request method. A server MUST ignore all received preconditions the request method. A server MUST ignore all received preconditions
if its response to the same request without those conditions, prior if its response to the same request without those conditions, prior
skipping to change at page 134, line 31 skipping to change at page 134, line 31
specification, and it MUST forward them if the request is forwarded, specification, and it MUST forward them if the request is forwarded,
since the generating client intends that they be evaluated by a since the generating client intends that they be evaluated by a
server that can provide a current representation. Likewise, a server server that can provide a current representation. Likewise, a server
MUST ignore the conditional request header fields defined by this MUST ignore the conditional request header fields defined by this
specification when received with a request method that does not specification when received with a request method that does not
involve the selection or modification of a selected representation, involve the selection or modification of a selected representation,
such as CONNECT, OPTIONS, or TRACE. such as CONNECT, OPTIONS, or TRACE.
Note that protocol extensions can modify the conditions under which Note that protocol extensions can modify the conditions under which
preconditions are evaluated or the consequences of their evaluation. preconditions are evaluated or the consequences of their evaluation.
For example, the "immutable" cache directive (defined by [RFC8246]) For example, the "immutable" Cache-Control directive (defined by
instructs caches to forgo forwarding conditional requests when they [RFC8246]) instructs caches to forgo forwarding conditional requests
hold a fresh response. when they hold a fresh response.
Although conditional request header fields are defined as being Although conditional request header fields are defined as being
usable with the HEAD method (to keep HEAD's semantics consistent with usable with the HEAD method (to keep HEAD's semantics consistent with
those of GET), there is no point in sending a conditional HEAD those of GET), there is no point in sending a conditional HEAD
because a successful response is around the same size as a 304 (Not because a successful response is around the same size as a 304 (Not
Modified) response and more useful than a 412 (Precondition Failed) Modified) response and more useful than a 412 (Precondition Failed)
response. response.
13.2.2. Precedence of Preconditions 13.2.2. Precedence of Preconditions
skipping to change at page 136, line 34 skipping to change at page 136, line 34
recipients not implementing this feature (or not supporting it for recipients not implementing this feature (or not supporting it for
the target resource) can respond as if it is a normal GET request the target resource) can respond as if it is a normal GET request
without impacting interoperability. Partial responses are indicated without impacting interoperability. Partial responses are indicated
by a distinct status code to not be mistaken for full responses by by a distinct status code to not be mistaken for full responses by
caches that might not implement the feature. caches that might not implement the feature.
14.1. Range Units 14.1. Range Units
Representation data can be partitioned into subranges when there are Representation data can be partitioned into subranges when there are
addressable structural units inherent to that data's content coding addressable structural units inherent to that data's content coding
or media type. For example, octet (a.k.a., byte) boundaries are a or media type. For example, octet (a.k.a. byte) boundaries are a
structural unit common to all representation data, allowing structural unit common to all representation data, allowing
partitions of the data to be identified as a range of bytes at some partitions of the data to be identified as a range of bytes at some
offset from the start or end of that data. offset from the start or end of that data.
This general notion of a _range unit_ is used in the Accept-Ranges This general notion of a _range unit_ is used in the Accept-Ranges
(Section 14.3) response header field to advertise support for range (Section 14.3) response header field to advertise support for range
requests, the Range (Section 14.2) request header field to delineate requests, the Range (Section 14.2) request header field to delineate
the parts of a representation that are requested, and the the parts of a representation that are requested, and the
Content-Range (Section 14.4) header field to describe which part of a Content-Range (Section 14.4) header field to describe which part of a
representation is being transferred. representation is being transferred.
skipping to change at page 140, line 6 skipping to change at page 140, line 6
selected representation. selected representation.
Range = ranges-specifier Range = ranges-specifier
A server MAY ignore the Range header field. However, origin servers A server MAY ignore the Range header field. However, origin servers
and intermediate caches ought to support byte ranges when possible, and intermediate caches ought to support byte ranges when possible,
since they support efficient recovery from partially failed transfers since they support efficient recovery from partially failed transfers
and partial retrieval of large representations. and partial retrieval of large representations.
A server MUST ignore a Range header field received with a request A server MUST ignore a Range header field received with a request
method which is unrecognized or for which range handling is not method that is unrecognized or for which range handling is not
defined. For this specification, GET is the only method for which defined. For this specification, GET is the only method for which
range handling is defined. range handling is defined.
An origin server MUST ignore a Range header field that contains a An origin server MUST ignore a Range header field that contains a
range unit it does not understand. A proxy MAY discard a Range range unit it does not understand. A proxy MAY discard a Range
header field that contains a range unit it does not understand. header field that contains a range unit it does not understand.
A server that supports range requests MAY ignore or reject a Range A server that supports range requests MAY ignore or reject a Range
header field that consists of more than two overlapping ranges, or a header field that consists of more than two overlapping ranges, or a
set of many small ranges that are not listed in ascending order, set of many small ranges that are not listed in ascending order,
skipping to change at page 145, line 6 skipping to change at page 145, line 6
Implementation Notes: Implementation Notes:
1. Additional CRLFs might precede the first boundary string in the 1. Additional CRLFs might precede the first boundary string in the
body. body.
2. Although [RFC2046] permits the boundary string to be quoted, some 2. Although [RFC2046] permits the boundary string to be quoted, some
existing implementations handle a quoted boundary string existing implementations handle a quoted boundary string
incorrectly. incorrectly.
3. A number of clients and servers were coded to an early draft of 3. A number of clients and servers were coded to an early draft of
the byteranges specification that used a media type of multipart/ the byteranges specification that used a media type of
x-byteranges , which is almost (but not quite) compatible with "multipart/x-byteranges", which is almost (but not quite)
this type. compatible with this type.
Despite the name, the "multipart/byteranges" media type is not Despite the name, the "multipart/byteranges" media type is not
limited to byte ranges. The following example uses an "exampleunit" limited to byte ranges. The following example uses an "exampleunit"
range unit: range unit:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785 Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
skipping to change at page 145, line 50 skipping to change at page 145, line 50
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: see Section 17 Security considerations: see Section 17
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 14.6). Published specification: RFC 9110 (see Section 14.6)
Applications that use this media type: HTTP components supporting Applications that use this media type: HTTP components supporting
multiple ranges in a single request. multiple ranges in a single request
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Deprecated alias names for this type: N/A Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut Person and email address to contact for further information: See Aut
hors' Addresses section. hors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section
Change controller: IESG Change controller: IESG
15. Status Codes 15. Status Codes
The status code of a response is a three-digit integer code that The status code of a response is a three-digit integer code that
describes the result of the request and the semantics of the describes the result of the request and the semantics of the
response, including whether the request was successful and what response, including whether the request was successful and what
content is enclosed (if any). All valid status codes are within the content is enclosed (if any). All valid status codes are within the
range of 100 to 599, inclusive. range of 100 to 599, inclusive.
skipping to change at page 149, line 24 skipping to change at page 149, line 24
client's request was successfully received, understood, and accepted. client's request was successfully received, understood, and accepted.
15.3.1. 200 OK 15.3.1. 200 OK
The _200 (OK)_ status code indicates that the request has succeeded. The _200 (OK)_ status code indicates that the request has succeeded.
The content sent in a 200 response depends on the request method. The content sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning For the methods defined by this specification, the intended meaning
of the content can be summarized as: of the content can be summarized as:
+----------------+--------------------------------------------+ +----------------+--------------------------------------------+
| request method | response content is a representation of | | Request Method | Response content is a representation of: |
+----------------+--------------------------------------------+ +----------------+--------------------------------------------+
| GET | the target resource | | GET | the target resource |
| HEAD | the target resource, like GET, but without | | HEAD | the target resource, like GET, but without |
| | transferring the representation data | | | transferring the representation data |
| POST | the status of, or results obtained from, | | POST | the status of, or results obtained from, |
| | the action | | | the action |
| PUT, DELETE | the status of the action | | PUT, DELETE | the status of the action |
| OPTIONS | communication options for the target | | OPTIONS | communication options for the target |
| | resource | | | resource |
| TRACE | the request message as received by the | | TRACE | the request message as received by the |
skipping to change at page 153, line 7 skipping to change at page 153, line 7
Content-Location, and Vary. Content-Location, and Vary.
A Content-Length header field present in a 206 response indicates the A Content-Length header field present in a 206 response indicates the
number of octets in the content of this message, which is usually not number of octets in the content of this message, which is usually not
the complete length of the selected representation. Each the complete length of the selected representation. Each
Content-Range header field includes information about the selected Content-Range header field includes information about the selected
representation's complete length. representation's complete length.
A sender that generates a 206 response to a request with an If-Range A sender that generates a 206 response to a request with an If-Range
header field SHOULD NOT generate other representation header fields header field SHOULD NOT generate other representation header fields
beyond those required, because the client already has a prior beyond those required because the client already has a prior response
response containing those header fields. Otherwise, a sender MUST containing those header fields. Otherwise, a sender MUST generate
generate all of the representation header fields that would have been all of the representation header fields that would have been sent in
sent in a 200 (OK) response to the same request. a 200 (OK) response to the same request.
A 206 response is heuristically cacheable; i.e., unless otherwise A 206 response is heuristically cacheable; i.e., unless otherwise
indicated by explicit cache controls (see Section 4.2.2 of indicated by explicit cache controls (see Section 4.2.2 of
[CACHING]). [CACHING]).
15.3.7.1. Single Part 15.3.7.1. Single Part
If a single part is being transferred, the server generating the 206 If a single part is being transferred, the server generating the 206
response MUST generate a Content-Range header field, describing what response MUST generate a Content-Range header field, describing what
range of the selected representation is enclosed, and a content range of the selected representation is enclosed, and a content
skipping to change at page 156, line 32 skipping to change at page 156, line 32
| and 302 (Found) were originally defined as method-preserving | and 302 (Found) were originally defined as method-preserving
| ([HTTP/1.0], Section 9.3) to match their implementation at | ([HTTP/1.0], Section 9.3) to match their implementation at
| CERN; 303 (See Other) was defined for a redirection that | CERN; 303 (See Other) was defined for a redirection that
| changed its method to GET. However, early user agents split on | changed its method to GET. However, early user agents split on
| whether to redirect POST requests as POST (according to then- | whether to redirect POST requests as POST (according to then-
| current specification) or as GET (the safer alternative when | current specification) or as GET (the safer alternative when
| redirected to a different site). Prevailing practice | redirected to a different site). Prevailing practice
| eventually converged on changing the method to GET. 307 | eventually converged on changing the method to GET. 307
| (Temporary Redirect) and 308 (Permanent Redirect) [RFC7538] | (Temporary Redirect) and 308 (Permanent Redirect) [RFC7538]
| were later added to unambiguously indicate method-preserving | were later added to unambiguously indicate method-preserving
| redirects, and 301/302 have been adjusted to allow a POST | redirects, and status codes 301 and 302 have been adjusted to
| request to be redirected as GET. | allow a POST request to be redirected as GET.
If a Location header field (Section 10.2.2) is provided, the user If a Location header field (Section 10.2.2) is provided, the user
agent MAY automatically redirect its request to the URI referenced by agent MAY automatically redirect its request to the URI referenced by
the Location field value, even if the specific status code is not the Location field value, even if the specific status code is not
understood. Automatic redirection needs to be done with care for understood. Automatic redirection needs to be done with care for
methods not known to be safe, as defined in Section 9.2.1, since the methods not known to be safe, as defined in Section 9.2.1, since the
user might not wish to redirect an unsafe request. user might not wish to redirect an unsafe request.
When automatically following a redirected request, the user agent When automatically following a redirected request, the user agent
SHOULD resend the original request message with the following SHOULD resend the original request message with the following
skipping to change at page 157, line 15 skipping to change at page 157, line 15
1. Connection-specific header fields (see Section 7.6.1), 1. Connection-specific header fields (see Section 7.6.1),
2. Header fields specific to the client's proxy configuration, 2. Header fields specific to the client's proxy configuration,
including (but not limited to) Proxy-Authorization, including (but not limited to) Proxy-Authorization,
3. Origin-specific header fields (if any), including (but not 3. Origin-specific header fields (if any), including (but not
limited to) Host, limited to) Host,
4. Validating header fields that were added by the 4. Validating header fields that were added by the
implementation's cache (e.g., If-None-Match, implementation's cache (e.g., If-None-Match,
If-Modified-Since), If-Modified-Since), and
5. Resource-specific header fields, including (but not limited 5. Resource-specific header fields, including (but not limited
to) Referer, Origin, Authorization, and Cookie. to) Referer, Origin, Authorization, and Cookie.
3. Consider removing header fields that were not automatically 3. Consider removing header fields that were not automatically
generated by the implementation (i.e., those present in the generated by the implementation (i.e., those present in the
request because they were added by the calling context) where request because they were added by the calling context) where
there are security implications; this includes but is not limited there are security implications; this includes but is not limited
to Authorization and Cookie. to Authorization and Cookie.
skipping to change at page 162, line 16 skipping to change at page 162, line 16
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response content usually contains a short redirection. The server's response content usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
A 308 response is heuristically cacheable; i.e., unless otherwise A 308 response is heuristically cacheable; i.e., unless otherwise
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:* This status code is much younger (June 2014) than its | *Note:* This status code is much younger (June 2014) than its
| sibling codes, and thus might not be recognized everywhere. | sibling codes and thus might not be recognized everywhere. See
| See Section 4 of [RFC7538] for deployment considerations. | Section 4 of [RFC7538] for deployment considerations.
15.5. Client Error 4xx 15.5. Client Error 4xx
The _4xx (Client Error)_ class of status code indicates that the The _4xx (Client Error)_ class of status code indicates that the
client seems to have erred. Except when responding to a HEAD client seems to have erred. Except when responding to a HEAD
request, the server SHOULD send a representation containing an request, the server SHOULD send a representation containing an
explanation of the error situation, and whether it is a temporary or explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included request method. User agents SHOULD display any included
representation to the user. representation to the user.
skipping to change at page 164, line 39 skipping to change at page 164, line 39
Proxy-Authorization header field (Section 11.7.2). Proxy-Authorization header field (Section 11.7.2).
15.5.9. 408 Request Timeout 15.5.9. 408 Request Timeout
The _408 (Request Timeout)_ status code indicates that the server did The _408 (Request Timeout)_ status code indicates that the server did
not receive a complete request message within the time that it was not receive a complete request message within the time that it was
prepared to wait. prepared to wait.
If the client has an outstanding request in transit, it MAY repeat If the client has an outstanding request in transit, it MAY repeat
that request. If the current connection is not usable (e.g., as it that request. If the current connection is not usable (e.g., as it
would be in HTTP/1.1, because request delimitation is lost), a new would be in HTTP/1.1 because request delimitation is lost), a new
connection will be used. connection will be used.
15.5.10. 409 Conflict 15.5.10. 409 Conflict
The _409 (Conflict)_ status code indicates that the request could not The _409 (Conflict)_ status code indicates that the request could not
be completed due to a conflict with the current state of the target be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server able to resolve the conflict and resubmit the request. The server
SHOULD generate content that includes enough information for a user SHOULD generate content that includes enough information for a user
to recognize the source of the conflict. to recognize the source of the conflict.
skipping to change at page 166, line 24 skipping to change at page 166, line 24
Retry-After header field to indicate that it is temporary and after Retry-After header field to indicate that it is temporary and after
what time the client MAY try again. what time the client MAY try again.
15.5.15. 414 URI Too Long 15.5.15. 414 URI Too Long
The _414 (URI Too Long)_ status code indicates that the server is The _414 (URI Too Long)_ status code indicates that the server is
refusing to service the request because the target URI is longer than refusing to service the request because the target URI is longer than
the server is willing to interpret. This rare condition is only the server is willing to interpret. This rare condition is only
likely to occur when a client has improperly converted a POST request likely to occur when a client has improperly converted a POST request
to a GET request with long query information, when the client has to a GET request with long query information, when the client has
descended into a "black hole" of redirection (e.g., a redirected URI descended into an infinite loop of redirection (e.g., a redirected
prefix that points to a suffix of itself) or when the server is under URI prefix that points to a suffix of itself), or when the server is
attack by a client attempting to exploit potential security holes. under attack by a client attempting to exploit potential security
holes.
A 414 response is heuristically cacheable; i.e., unless otherwise A 414 response is heuristically cacheable; i.e., unless otherwise
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]).
15.5.16. 415 Unsupported Media Type 15.5.16. 415 Unsupported Media Type
The _415 (Unsupported Media Type)_ status code indicates that the The _415 (Unsupported Media Type)_ status code indicates that the
origin server is refusing to service the request because the content origin server is refusing to service the request because the content
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 The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the Content-Type or Content-Encoding, or as a result of inspecting the
data directly. data directly.
If the problem was caused by an unsupported content coding, the If the problem was caused by an unsupported content coding, the
Accept-Encoding response header field (Section 12.5.3) ought to be Accept-Encoding response header field (Section 12.5.3) ought to be
used to indicate what (if any) content codings would have been used to indicate which (if any) content codings would have been
accepted in the request. accepted in the request.
On the other hand, if the cause was an unsupported media type, the On the other hand, if the cause was an unsupported media type, the
Accept response header field (Section 12.5.1) can be used to indicate Accept response header field (Section 12.5.1) can be used to indicate
what media types would have been accepted in the request. which media types would have been accepted in the request.
15.5.17. 416 Range Not Satisfiable 15.5.17. 416 Range Not Satisfiable
The _416 (Range Not Satisfiable)_ status code indicates that the set The _416 (Range Not Satisfiable)_ status code indicates that the set
of ranges in the request's Range header field (Section 14.2) has been of ranges in the request's Range header field (Section 14.2) has been
rejected either because none of the requested ranges are satisfiable rejected either because none of the requested ranges are satisfiable
or because the client has requested an excessive number of small or or because the client has requested an excessive number of small or
overlapping ranges (a potential denial of service attack). overlapping ranges (a potential denial of service attack).
Each range unit defines what is required for its own range sets to be Each range unit defines what is required for its own range sets to be
skipping to change at page 167, line 46 skipping to change at page 167, line 46
15.5.18. 417 Expectation Failed 15.5.18. 417 Expectation Failed
The _417 (Expectation Failed)_ status code indicates that the The _417 (Expectation Failed)_ status code indicates that the
expectation given in the request's Expect header field expectation given in the request's Expect header field
(Section 10.1.1) could not be met by at least one of the inbound (Section 10.1.1) could not be met by at least one of the inbound
servers. servers.
15.5.19. 418 (Unused) 15.5.19. 418 (Unused)
[RFC2324] was an April 1 RFC that lampooned the various ways HTTP was [RFC2324] is an April 1st RFC that lampoons the various ways HTTP has
abused; one such abuse was the definition of an application-specific been abused; one such abuse is the definition of an application-
418 status code. In the intervening years, this status code has been specific 418 status code. In the intervening years, this status code
widely implemented as an "Easter Egg", and therefore is effectively has been widely implemented as an "Easter egg" and therefore is
consumed by this use. effectively consumed by this use.
Therefore, the 418 status code is reserved in the IANA HTTP Status Therefore, the 418 status code is reserved in the IANA HTTP Status
Code Registry. This indicates that the status code cannot be Code Registry. This indicates that the status code cannot be
assigned to other applications currently. If future circumstances assigned to other applications currently. If future circumstances
require its use (e.g., exhaustion of 4NN status codes), it can be re- require its use (e.g., exhaustion of 4NN status codes), it can be re-
assigned to another use. assigned to another use.
15.5.20. 421 Misdirected Request 15.5.20. 421 Misdirected Request
The 421 (Misdirected Request) status code indicates that the request The _421 (Misdirected Request)_ status code indicates that the
was directed at a server that is unable or unwilling to produce an request was directed at a server that is unable or unwilling to
authoritative response for the target URI. An origin server (or produce an authoritative response for the target URI. An origin
gateway acting on behalf of the origin server) sends 421 to reject a server (or gateway acting on behalf of the origin server) sends 421
target URI that does not match an origin for which the server has to reject a target URI that does not match an origin for which the
been configured (Section 4.3.1) or does not match the connection server has been configured (Section 4.3.1) or does not match the
context over which the request was received (Section 7.4). connection context over which the request was received (Section 7.4).
A client that receives a 421 (Misdirected Request) response MAY retry A client that receives a 421 (Misdirected Request) response MAY retry
the request, whether or not the request method is idempotent, over a the request, whether or not the request method is idempotent, over a
different connection, such as a fresh connection specific to the different connection, such as a fresh connection specific to the
target resource's origin, or via an alternative service [ALTSVC]. target resource's origin, or via an alternative service [ALTSVC].
A proxy MUST NOT generate a 421 response. A proxy MUST NOT generate a 421 response.
15.5.21. 422 Unprocessable Content 15.5.21. 422 Unprocessable Content
The 422 (Unprocessable Content) status code indicates that the server The _422 (Unprocessable Content)_ status code indicates that the
understands the content type of the request content (hence a 415 server understands the content type of the request content (hence a
(Unsupported Media Type) status code is inappropriate), and the 415 (Unsupported Media Type) status code is inappropriate), and the
syntax of the request content is correct, but was unable to process syntax of the request content is correct, but it was unable to
the contained instructions. For example, this status code can be process the contained instructions. For example, this status code
sent if an XML request content contains well-formed (i.e., can be sent if an XML request content contains well-formed (i.e.,
syntactically correct), but semantically erroneous XML instructions. syntactically correct), but semantically erroneous XML instructions.
15.5.22. 426 Upgrade Required 15.5.22. 426 Upgrade Required
The _426 (Upgrade Required)_ status code indicates that the server The _426 (Upgrade Required)_ status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 7.8). response to indicate the required protocol(s) (Section 7.8).
skipping to change at page 169, line 21 skipping to change at page 169, line 21
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
15.6. Server Error 5xx 15.6. Server Error 5xx
The _5xx (Server Error)_ class of status code indicates that the The _5xx (Server Error)_ class of status code indicates that the
server is aware that it has erred or is incapable of performing the server is aware that it has erred or is incapable of performing the
requested method. Except when responding to a HEAD request, the requested method. 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. A user agent SHOULD display any included representation condition. A user agent SHOULD display any included representation
to the user. These response codes are applicable to any request to the user. These status codes are applicable to any request
method. method.
15.6.1. 500 Internal Server Error 15.6.1. 500 Internal Server Error
The _500 (Internal Server Error)_ status code indicates that the The _500 (Internal Server Error)_ status code indicates that the
server encountered an unexpected condition that prevented it from server encountered an unexpected condition that prevented it from
fulfilling the request. fulfilling the request.
15.6.2. 501 Not Implemented 15.6.2. 501 Not Implemented
skipping to change at page 170, line 42 skipping to change at page 170, line 42
with this error message. The server SHOULD generate a representation with this error message. The server SHOULD generate a representation
for the 505 response that describes why that version is not supported for the 505 response that describes why that version is not supported
and what other protocols are supported by that server. and what other protocols are supported by that server.
16. Extending HTTP 16. Extending HTTP
HTTP defines a number of generic extension points that can be used to HTTP defines a number of generic extension points that can be used to
introduce capabilities to the protocol without introducing a new introduce capabilities to the protocol without introducing a new
version, including methods, status codes, field names, and further version, including methods, status codes, field names, and further
extensibility points within defined fields, such as authentication extensibility points within defined fields, such as authentication
schemes and cache-directives (see Cache-Control extensions in schemes and Cache-Control directives (see Cache-Control extensions in
Section 5.2.3 of [CACHING]). Because the semantics of HTTP are not Section 5.2.3 of [CACHING]). Because the semantics of HTTP are not
versioned, these extension points are persistent; the version of the versioned, these extension points are persistent; the version of the
protocol in use does not affect their semantics. protocol in use does not affect their semantics.
Version-independent extensions are discouraged from depending on or Version-independent extensions are discouraged from depending on or
interacting with the specific version of the protocol in use. When interacting with the specific version of the protocol in use. When
this is unavoidable, careful consideration needs to be given to how this is unavoidable, careful consideration needs to be given to how
the extension can interoperate across versions. the extension can interoperate across versions.
Additionally, specific versions of HTTP might have their own Additionally, specific versions of HTTP might have their own
extensibility points, such as transfer-codings in HTTP/1.1 extensibility points, such as transfer-codings in HTTP/1.1
(Section 6.1 of [HTTP/1.1]) and HTTP/2 ([HTTP/2]) SETTINGS or frame (Section 6.1 of [HTTP/1.1]) and HTTP/2 SETTINGS or frame types
types. These extension points are specific to the version of the ([HTTP/2]). These extension points are specific to the version of
protocol they occur within. the protocol they occur within.
Version-specific extensions cannot override or modify the semantics Version-specific extensions cannot override or modify the semantics
of a version-independent mechanism or extension point (like a method of a version-independent mechanism or extension point (like a method
or header field) without explicitly being allowed by that protocol or header field) without explicitly being allowed by that protocol
element. For example, the CONNECT method (Section 9.3.6) allows element. For example, the CONNECT method (Section 9.3.6) allows
this. this.
These guidelines assure that the protocol operates correctly and These guidelines assure that the protocol operates correctly and
predictably, even when parts of the path implement different versions predictably, even when parts of the path implement different versions
of HTTP. of HTTP.
skipping to change at page 173, line 39 skipping to change at page 173, line 39
The definition of a new status code ought to explain the request The definition of a new status code ought to explain the request
conditions that would cause a response containing that status code conditions that would cause a response containing that status code
(e.g., combinations of request header fields and/or method(s)) along (e.g., combinations of request header fields and/or method(s)) along
with any dependencies on response header fields (e.g., what fields with any dependencies on response header fields (e.g., what fields
are required, what fields can modify the semantics, and what field are required, what fields can modify the semantics, and what field
semantics are further refined when used with the new status code). semantics are further refined when used with the new status code).
By default, a status code applies only to the request corresponding By default, a status code applies only to the request corresponding
to the response it occurs within. If a status code applies to a to the response it occurs within. If a status code applies to a
larger scope of applicability -- for example, all requests to the larger scope of applicability -- for example, all requests to the
resource in question, or all requests to a server -- this must be resource in question or all requests to a server -- this must be
explicitly specified. When doing so, it should be noted that not all explicitly specified. When doing so, it should be noted that not all
clients can be expected to consistently apply a larger scope, because clients can be expected to consistently apply a larger scope because
they might not understand the new status code. they might not understand the new status code.
The definition of a new final status code ought to specify whether or The definition of a new final status code ought to specify whether or
not it is heuristically cacheable. Note that all final status codes not it is heuristically cacheable. Note that all final status codes
can be cached if the response they occur in has explicit freshness can be cached if the response they occur in has explicit freshness
information; however, those status codes that are defined as being information; however, those status codes that are defined as being
heuristically cacheable are allowed to be cached without explicit heuristically cacheable are allowed to be cached without explicit
freshness information. Likewise, the definition of a status code can freshness information. Likewise, the definition of a status code can
place constraints upon cache behavior, if the 'must-understand' cache place constraints upon cache behavior if the "must-understand" Cache-
directive is used. See [CACHING] for more information. Control directive is used. See [CACHING] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the content has any implied association with an identified whether the content has any implied association with an identified
resource (Section 6.4.2). resource (Section 6.4.2).
16.3. Field Extensibility 16.3. Field Extensibility
HTTP's most widely used extensibility point is the definition of new HTTP's most widely used extensibility point is the definition of new
header and trailer fields. header and trailer fields.
skipping to change at page 174, line 45 skipping to change at page 174, line 45
Any party can request registration of an HTTP field. See Any party can request registration of an HTTP field. See
Section 16.3.2 for considerations to take into account when creating Section 16.3.2 for considerations to take into account when creating
a new HTTP field. a new HTTP field.
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is
located at <https://www.iana.org/assignments/http-fields/>. located at <https://www.iana.org/assignments/http-fields/>.
Registration requests can be made by following the instructions Registration requests can be made by following the instructions
located there or by sending an email to the "ietf-http-wg@w3.org" located there or by sending an email to the "ietf-http-wg@w3.org"
mailing list. mailing list.
Field names are registered on the advice of a Designated Expert Field names are registered on the advice of a designated expert
(appointed by the IESG or their delegate). Fields with the status (appointed by the IESG or their delegate). Fields with the status
'permanent' are Specification Required ([RFC8126], Section 4.6). 'permanent' are Specification Required ([RFC8126], Section 4.6).
Registration requests consist of the following information: Registration requests consist of the following information:
Field name: Field name:
The requested field name. It MUST conform to the field-name The requested field name. It MUST conform to the field-name
syntax defined in Section 5.1, and SHOULD be restricted to just syntax defined in Section 5.1, and it SHOULD be restricted to just
letters, digits, and hyphen ('-') characters, with the first letters, digits, and hyphen ('-') characters, with the first
character being a letter. character being a letter.
Status: Status:
"permanent" or "provisional". "permanent", "provisional", "deprecated", or "obsoleted".
Specification document(s): Specification document(s):
Reference to the document that specifies the field, preferably Reference to the document that specifies the field, preferably
including a URI that can be used to retrieve a copy of the including a URI that can be used to retrieve a copy of the
document. Optional but encouraged for provisional registrations. document. Optional but encouraged for provisional registrations.
An indication of the relevant section(s) can also be included, but An indication of the relevant section(s) can also be included, but
is not required. is not required.
And, optionally: And optionally:
Comments: Additional information, such as about reserved entries. Comments: Additional information, such as about reserved entries.
The Expert(s) can define additional fields to be collected in the The expert(s) can define additional fields to be collected in the
registry, in consultation with the community. registry, in consultation with the community.
Standards-defined names have a status of "permanent". Other names Standards-defined names have a status of "permanent". Other names
can also be registered as permanent, if the Expert(s) find that they can also be registered as permanent if the expert(s) finds that they
are in use, in consultation with the community. Other names should are in use, in consultation with the community. Other names should
be registered as "provisional". be registered as "provisional".
Provisional entries can be removed by the Expert(s) if -- in Provisional entries can be removed by the expert(s) if -- in
consultation with the community -- the Expert(s) find that they are consultation with the community -- the expert(s) find that they are
not in use. The Experts can change a provisional entry's status to not in use. The expert(s) can change a provisional entry's status to
permanent at any time. permanent at any time.
Note that names can be registered by third parties (including the Note that names can be registered by third parties (including the
Expert(s)), if the Expert(s) determines that an unregistered name is expert(s)) if the expert(s) determines that an unregistered name is
widely deployed and not likely to be registered in a timely manner widely deployed and not likely to be registered in a timely manner
otherwise. otherwise.
16.3.2. Considerations for New Fields 16.3.2. Considerations for New Fields
HTTP header and trailer fields are a widely-used extension point for HTTP header and trailer fields are a widely used extension point for
the protocol. While they can be used in an ad hoc fashion, fields the protocol. While they can be used in an ad hoc fashion, fields
that are intended for wider use need to be carefully documented to that are intended for wider use need to be carefully documented to
ensure interoperability. ensure interoperability.
In particular, authors of specifications defining new fields are In particular, authors of specifications defining new fields are
advised to consider and, where appropriate, document the following advised to consider and, where appropriate, document the following
aspects: aspects:
o Under what conditions the field can be used; e.g., only in o Under what conditions the field can be used; e.g., only in
responses or requests, in all messages, only on responses to a responses or requests, in all messages, only on responses to a
skipping to change at page 176, line 35 skipping to change at page 176, line 35
(see Section 6.5.1). (see Section 6.5.1).
o Whether it is appropriate or even required to list the field name o Whether it is appropriate or even required to list the field name
in the Connection header field (i.e., if the field is to be hop- in the Connection header field (i.e., if the field is to be hop-
by-hop; see Section 7.6.1). by-hop; see Section 7.6.1).
o Whether the field introduces any additional security o Whether the field introduces any additional security
considerations, such as disclosure of privacy-related data. considerations, such as disclosure of privacy-related data.
Request header fields have additional considerations that need to be Request header fields have additional considerations that need to be
documented if the default behaviour is not appropriate: documented if the default behavior is not appropriate:
o If it is appropriate to list the field name in a Vary response o If it is appropriate to list the field name in a Vary response
header field (e.g., when the request header field is used by an header field (e.g., when the request header field is used by an
origin server's content selection algorithm; see Section 12.5.5). origin server's content selection algorithm; see Section 12.5.5).
o If the field is intended to be stored when received in a PUT o If the field is intended to be stored when received in a PUT
request (see Section 9.3.4). request (see Section 9.3.4).
o If the field ought to be removed when automatically redirecting a o If the field ought to be removed when automatically redirecting a
request, due to security concerns (see Section 15.4). request due to security concerns (see Section 15.4).
16.3.2.1. Considerations for New Field Names 16.3.2.1. Considerations for New Field Names
Authors of specifications defining new fields are advised to choose a Authors of specifications defining new fields are advised to choose a
short but descriptive field name. Short names avoid needless data short but descriptive field name. Short names avoid needless data
transmission; descriptive names avoid confusion and "squatting" on transmission; descriptive names avoid confusion and "squatting" on
names that might have broader uses. names that might have broader uses.
To that end, limited-use fields (such as a header confined to a To that end, limited-use fields (such as a header confined to a
single application or use case) are encouraged to use a name that single application or use case) are encouraged to use a name that
skipping to change at page 177, line 26 skipping to change at page 177, line 26
SHOULD begin with a letter. For example, the underscore ("_") SHOULD begin with a letter. For example, the underscore ("_")
character can be problematic when passed through non-HTTP gateway character can be problematic when passed through non-HTTP gateway
interfaces (see Section 17.10). interfaces (see Section 17.10).
Field names ought not be prefixed with "X-"; see [BCP178] for further Field names ought not be prefixed with "X-"; see [BCP178] for further
information. information.
Other prefixes are sometimes used in HTTP field names; for example, Other prefixes are sometimes used in HTTP field names; for example,
"Accept-" is used in many content negotiation headers, and "Content-" "Accept-" is used in many content negotiation headers, and "Content-"
is used as explained in Section 6.4. These prefixes are only an aid is used as explained in Section 6.4. These prefixes are only an aid
to recognizing the purpose of a field, and do not trigger automatic to recognizing the purpose of a field and do not trigger automatic
processing. processing.
16.3.2.2. Considerations for New Field Values 16.3.2.2. Considerations for New Field Values
A major task in the definition of a new HTTP field is the A major task in the definition of a new HTTP field is the
specification of the field value syntax: what senders should specification of the field value syntax: what senders should
generate, and how recipients should infer semantics from what is generate, and how recipients should infer semantics from what is
received. received.
Authors are encouraged (but not required) to use either the ABNF Authors are encouraged (but not required) to use either the ABNF
skipping to change at page 181, line 5 skipping to change at page 181, line 5
content-coding names. content-coding names.
Content coding registrations MUST include the following fields: Content coding registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (as per the "HTTP Transfer Coding registry", located at codings (per the "HTTP Transfer Coding Registry" located at
<https://www.iana.org/assignments/http-parameters/>), unless the <https://www.iana.org/assignments/http-parameters/>) unless the
encoding transformation is identical (as is the case for the encoding transformation is identical (as is the case for the
compression codings defined in Section 8.4.1). compression codings defined in Section 8.4.1).
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
Section 4.8 of [RFC8126]) and MUST conform to the purpose of content Section 4.8 of [RFC8126]) and MUST conform to the purpose of content
coding defined in Section 8.4.1. coding defined in Section 8.4.1.
16.6.2. Considerations for New Content Codings 16.6.2. Considerations for New Content Codings
New content codings ought to be self-descriptive whenever possible, New content codings ought to be self-descriptive whenever possible,
skipping to change at page 182, line 19 skipping to change at page 182, line 19
8. The IESG MAY reassign responsibility for a protocol token. This 8. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party will normally only be used in the case when a responsible party
cannot be contacted. cannot be contacted.
17. Security Considerations 17. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to caching are discussed in Section 7 of Considerations related to caching are discussed in Section 7 of
[CACHING] and considerations related to HTTP/1.1 message syntax and [CACHING], and considerations related to HTTP/1.1 message syntax and
parsing are discussed in Section 11 of [HTTP/1.1]. parsing are discussed in Section 11 of [HTTP/1.1].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of content received via HTTP, or secure use of the processing of content received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. The Internet in general, rather than security of the protocol. The
security considerations for URIs, which are fundamental to HTTP security considerations for URIs, which are fundamental to HTTP
operation, are discussed in Section 7 of [URI]. Various operation, are discussed in Section 7 of [URI]. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
skipping to change at page 186, line 5 skipping to change at page 186, line 5
(Section 15.5.14). Additional status codes related to capacity (Section 15.5.14). Additional status codes related to capacity
limits have been defined by extensions to HTTP [RFC6585]. limits have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request other protocol elements, including (but not limited to) request
methods, response status phrases, field names, numeric values, and methods, response status phrases, field names, numeric values, and
chunk lengths. Failure to limit such processing can result in chunk lengths. Failure to limit such processing can result in
arbitrary code execution due to buffer or arithmetic overflows, and arbitrary code execution due to buffer or arithmetic overflows, and
increased vulnerability to denial-of-service attacks. increased vulnerability to denial-of-service attacks.
17.6. Attacks using Shared-dictionary Compression 17.6. Attacks Using Shared-Dictionary Compression
Some attacks on encrypted protocols use the differences in size Some attacks on encrypted protocols use the differences in size
created by dynamic compression to reveal confidential information; created by dynamic compression to reveal confidential information;
for example, [BREACH]. These attacks rely on creating a redundancy for example, [BREACH]. These attacks rely on creating a redundancy
between attacker-controlled content and the confidential information, between attacker-controlled content and the confidential information,
such that a dynamic compression algorithm using the same dictionary such that a dynamic compression algorithm using the same dictionary
for both content will compress more efficiently when the attacker- for both content will compress more efficiently when the attacker-
controlled content matches parts of the confidential content. controlled content matches parts of the confidential content.
HTTP messages can be compressed in a number of ways, including using HTTP messages can be compressed in a number of ways, including using
skipping to change at page 187, line 32 skipping to change at page 187, line 32
When an application uses client-side mechanisms to construct a target When an application uses client-side mechanisms to construct a target
URI out of user-provided information, such as the query fields of a URI out of user-provided information, such as the query fields of a
form using GET, potentially sensitive data might be provided that form using GET, potentially sensitive data might be provided that
would not be appropriate for disclosure within a URI. POST is often would not be appropriate for disclosure within a URI. POST is often
preferred in such cases because it usually doesn't construct a URI; preferred in such cases because it usually doesn't construct a URI;
instead, POST of a form transmits the potentially sensitive data in instead, POST of a form transmits the potentially sensitive data in
the request content. However, this hinders caching and uses an the request content. However, this hinders caching and uses an
unsafe method for what would otherwise be a safe request. unsafe method for what would otherwise be a safe request.
Alternative workarounds include transforming the user-provided data Alternative workarounds include transforming the user-provided data
prior to constructing the URI, or filtering the data to only include prior to constructing the URI or filtering the data to only include
common values that are not sensitive. Likewise, redirecting the common values that are not sensitive. Likewise, redirecting the
result of a query to a different (server-generated) URI can remove result of a query to a different (server-generated) URI can remove
potentially sensitive data from later links and provide a cacheable potentially sensitive data from later links and provide a cacheable
response for later reuse. response for later reuse.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in URI. Limitations on the Referer header field are described in
skipping to change at page 193, line 7 skipping to change at page 193, line 7
specific parameters; this will have to be considered in the specific parameters; this will have to be considered in the
definitions of these schemes. definitions of these schemes.
18. IANA Considerations 18. IANA Considerations
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".
18.1. URI Scheme Registration 18.1. URI Scheme Registration
Please update the registry of URI Schemes [BCP35] at IANA has updated the "Uniform Resource Identifier (URI) Schemes"
<https://www.iana.org/assignments/uri-schemes/> with the permanent registry [BCP35] at <https://www.iana.org/assignments/uri-schemes/>
schemes listed in the table in Section 4.2. with the permanent schemes listed in Table 2 in Section 4.2.
18.2. Method Registration 18.2. Method Registration
Please update the "Hypertext Transfer Protocol (HTTP) Method IANA has updated 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 16.1.1 and the method names registration procedure of Section 16.1.1 and the method names
summarized in the following table. summarized in the following table.
+---------+------+------------+-------+ +---------+------+------------+-------+
| Method | Safe | Idempotent | Ref. | | Method | Safe | Idempotent | Ref. |
+---------+------+------------+-------+ +---------+------+------------+-------+
| CONNECT | no | no | 9.3.6 | | CONNECT | no | no | 9.3.6 |
| DELETE | no | yes | 9.3.5 | | DELETE | no | yes | 9.3.5 |
| GET | yes | yes | 9.3.1 | | GET | yes | yes | 9.3.1 |
| HEAD | yes | yes | 9.3.2 | | HEAD | yes | yes | 9.3.2 |
| OPTIONS | yes | yes | 9.3.7 | | OPTIONS | yes | yes | 9.3.7 |
| POST | no | no | 9.3.3 | | POST | no | no | 9.3.3 |
| PUT | no | yes | 9.3.4 | | PUT | no | yes | 9.3.4 |
| TRACE | yes | yes | 9.3.8 | | TRACE | yes | yes | 9.3.8 |
| * | no | no | 18.2 | | * | no | no | 18.2 |
+---------+------+------------+-------+ +---------+------+------------+-------+
Table 7 Table 7
The method name "*" is reserved, since using "*" as a method name The method name "*" is reserved because using "*" as a method name
would conflict with its usage as a wildcard in some fields (e.g., would conflict with its usage as a wildcard in some fields (e.g.,
"Access-Control-Request-Method"). "Access-Control-Request-Method").
18.3. Status Code Registration 18.3. Status Code Registration
Please update the "Hypertext Transfer Protocol (HTTP) Status Code IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code
Registry" at <https://www.iana.org/assignments/http-status-codes> Registry" at <https://www.iana.org/assignments/http-status-codes>
with the registration procedure of Section 16.2.1 and the status code with the registration procedure of Section 16.2.1 and the status code
values summarized in the following table. values summarized in the following table.
+-------+-------------------------------+---------+ +-------+-------------------------------+---------+
| Value | Description | Ref. | | Value | Description | Ref. |
+-------+-------------------------------+---------+ +-------+-------------------------------+---------+
| 100 | Continue | 15.2.1 | | 100 | Continue | 15.2.1 |
| 101 | Switching Protocols | 15.2.2 | | 101 | Switching Protocols | 15.2.2 |
| 200 | OK | 15.3.1 | | 200 | OK | 15.3.1 |
skipping to change at page 195, line 7 skipping to change at page 195, line 7
| 502 | Bad Gateway | 15.6.3 | | 502 | Bad Gateway | 15.6.3 |
| 503 | Service Unavailable | 15.6.4 | | 503 | Service Unavailable | 15.6.4 |
| 504 | Gateway Timeout | 15.6.5 | | 504 | Gateway Timeout | 15.6.5 |
| 505 | HTTP Version Not Supported | 15.6.6 | | 505 | HTTP Version Not Supported | 15.6.6 |
+-------+-------------------------------+---------+ +-------+-------------------------------+---------+
Table 8 Table 8
18.4. Field Name Registration 18.4. Field Name Registration
This specification updates the HTTP related aspects of the existing This specification updates the HTTP-related aspects of the existing
registration procedures for message header fields defined in registration procedures for message header fields defined in
[RFC3864]. It replaces the old procedures as they relate to HTTP, by [RFC3864]. It replaces the old procedures as they relate to HTTP by
defining a new registration procedure and moving HTTP field defining a new registration procedure and moving HTTP field
definitions into a separate registry. definitions into a separate registry.
Please create a new registry as outlined in Section 16.3.1. IANA has created a new registry titled "Hypertext Transfer Protocol
(HTTP) Field Name Registry" as outlined in Section 16.3.1.
After creating the registry, all entries in the Permanent and IANA has moved all entries in the "Permanent Message Header Field
Provisional Message Header Registries with the protocol 'http' are to Names" and "Provisional Message Header Field Names" registries (see
be moved to it, with the following changes applied: <https://www.iana.org/assignments/message-headers/>) with the
protocol 'http' to this registry and has applied the following
changes:
1. The 'Applicable Protocol' field is to be omitted. 1. The 'Applicable Protocol' field has been omitted.
2. Entries with a status of 'standard', 'experimental', 'reserved', 2. Entries that had a status of 'standard', 'experimental',
or 'informational' are to have a status of 'permanent'. 'reserved', or 'informational' have been made to have a status of
'permanent'.
3. Provisional entries without a status are to have a status of 3. Provisional entries without a status have been made to have a
'provisional'. status of 'provisional'.
4. Permanent entries without a status (after confirmation that the 4. Permanent entries without a status (after confirmation that the
registration document did not define one) will have a status of registration document did not define one) have been made to have
'provisional'. The Expert(s) can choose to update their status a status of 'provisional'. The expert(s) can choose to update
if there is evidence that another is more appropriate. the entries' status if there is evidence that another is more
appropriate.
Please annotate the Permanent and Provisional Message Header IANA has annotated the "Permanent Message Header Field Names" and
registries to indicate that HTTP field name registrations have moved, "Provisional Message Header Field Names" registries with the
with an appropriate link. following note to indicate that HTTP field name registrations have
moved:
After that is complete, please update the new registry with the field | *Note*
names listed in the following table. |
| HTTP field name registrations have been moved to
| [https://www.iana.org/assignments/http-fields] per [RFC9110].
IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name
Registry" with the field names listed in the following table.
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Field Name | Status | Ref. | Comments | | Field Name | Status | Ref. | Comments |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Accept | standard | 12.5.1 | | | Accept | permanent | 12.5.1 | |
| Accept-Charset | deprecated | 12.5.2 | | | Accept-Charset | deprecated | 12.5.2 | |
| Accept-Encoding | standard | 12.5.3 | | | Accept-Encoding | permanent | 12.5.3 | |
| Accept-Language | standard | 12.5.4 | | | Accept-Language | permanent | 12.5.4 | |
| Accept-Ranges | standard | 14.3 | | | Accept-Ranges | permanent | 14.3 | |
| Allow | standard | 10.2.1 | | | Allow | permanent | 10.2.1 | |
| Authentication-Info | standard | 11.6.3 | | | Authentication-Info | permanent | 11.6.3 | |
| Authorization | standard | 11.6.2 | | | Authorization | permanent | 11.6.2 | |
| Connection | standard | 7.6.1 | | | Connection | permanent | 7.6.1 | |
| Content-Encoding | standard | 8.4 | | | Content-Encoding | permanent | 8.4 | |
| Content-Language | standard | 8.5 | | | Content-Language | permanent | 8.5 | |
| Content-Length | standard | 8.6 | | | Content-Length | permanent | 8.6 | |
| Content-Location | standard | 8.7 | | | Content-Location | permanent | 8.7 | |
| Content-Range | standard | 14.4 | | | Content-Range | permanent | 14.4 | |
| Content-Type | standard | 8.3 | | | Content-Type | permanent | 8.3 | |
| Date | standard | 6.6.1 | | | Date | permanent | 6.6.1 | |
| ETag | standard | 8.8.3 | | | ETag | permanent | 8.8.3 | |
| Expect | standard | 10.1.1 | | | Expect | permanent | 10.1.1 | |
| From | standard | 10.1.2 | | | From | permanent | 10.1.2 | |
| Host | standard | 7.2 | | | Host | permanent | 7.2 | |
| If-Match | standard | 13.1.1 | | | If-Match | permanent | 13.1.1 | |
| If-Modified-Since | standard | 13.1.3 | | | If-Modified-Since | permanent | 13.1.3 | |
| If-None-Match | standard | 13.1.2 | | | If-None-Match | permanent | 13.1.2 | |
| If-Range | standard | 13.1.5 | | | If-Range | permanent | 13.1.5 | |
| If-Unmodified-Since | standard | 13.1.4 | | | If-Unmodified-Since | permanent | 13.1.4 | |
| Last-Modified | standard | 8.8.2 | | | Last-Modified | permanent | 8.8.2 | |
| Location | standard | 10.2.2 | | | Location | permanent | 10.2.2 | |
| Max-Forwards | standard | 7.6.2 | | | Max-Forwards | permanent | 7.6.2 | |
| Proxy-Authenticate | standard | 11.7.1 | | | Proxy-Authenticate | permanent | 11.7.1 | |
| Proxy-Authentication-Info | standard | 11.7.3 | | | Proxy-Authentication-Info | permanent | 11.7.3 | |
| Proxy-Authorization | standard | 11.7.2 | | | Proxy-Authorization | permanent | 11.7.2 | |
| Range | standard | 14.2 | | | Range | permanent | 14.2 | |
| Referer | standard | 10.1.3 | | | Referer | permanent | 10.1.3 | |
| Retry-After | standard | 10.2.3 | | | Retry-After | permanent | 10.2.3 | |
| Server | standard | 10.2.4 | | | Server | permanent | 10.2.4 | |
| TE | standard | 10.1.4 | | | TE | permanent | 10.1.4 | |
| Trailer | standard | 6.6.2 | | | Trailer | permanent | 6.6.2 | |
| Upgrade | standard | 7.8 | | | Upgrade | permanent | 7.8 | |
| User-Agent | standard | 10.1.5 | | | User-Agent | permanent | 10.1.5 | |
| Vary | standard | 12.5.5 | | | Vary | permanent | 12.5.5 | |
| Via | standard | 7.6.3 | | | Via | permanent | 7.6.3 | |
| WWW-Authenticate | standard | 11.6.1 | | | WWW-Authenticate | permanent | 11.6.1 | |
| * | standard | 12.5.5 | (reserved) | | * | permanent | 12.5.5 | (reserved) |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
Table 9 Table 9
The field name "*" is reserved, since using that name as an HTTP The field name "*" is reserved because using that name as an HTTP
header field might conflict with its special semantics in the Vary header field might conflict with its special semantics in the Vary
header field (Section 12.5.5). header field (Section 12.5.5).
Finally, please update the "Content-MD5" entry in the new registry to IANA has updated the "Content-MD5" entry in the new registry to have
have a status of 'obsoleted' with references to Section 14.15 of a status of 'obsoleted' with references to Section 14.15 of [RFC2616]
[RFC2616] (for the definition of the header field) and Appendix B of (for the definition of the header field) and Appendix B of [RFC7231]
[RFC7231] (which removed the field definition from the updated (which removed the field definition from the updated specification).
specification).
18.5. Authentication Scheme Registration 18.5. Authentication Scheme Registration
Please update the "Hypertext Transfer Protocol (HTTP) Authentication IANA has updated the "Hypertext Transfer Protocol (HTTP)
Scheme Registry" at <https://www.iana.org/assignments/http- Authentication Scheme Registry" at <https://www.iana.org/assignments/
authschemes> with the registration procedure of Section 16.4.1. No http-authschemes> with the registration procedure of Section 16.4.1.
authentication schemes are defined in this document. No authentication schemes are defined in this document.
18.6. Content Coding Registration 18.6. Content Coding Registration
Please update the "HTTP Content Coding Registry" at IANA has updated the "HTTP Content Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 16.6.1 and the content coding names registration procedure of Section 16.6.1 and the content coding names
summarized in the table below. summarized in the table below.
+------------+-------------------------------------------+---------+ +------------+-----------------------------------------+---------+
| Name | Description | Ref. | | Name | Description | Ref. |
+------------+-------------------------------------------+---------+ +------------+-----------------------------------------+---------+
| compress | UNIX "compress" data format [Welch] | 8.4.1.1 | | compress | UNIX "compress" data format [Welch] | 8.4.1.1 |
| deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2 | | deflate | "deflate" compressed data [RFC1951] | 8.4.1.2 |
| | inside the "zlib" data format ([RFC1950]) | | | | inside the "zlib" data format [RFC1950] | |
| gzip | GZIP file format [RFC1952] | 8.4.1.3 | | gzip | GZIP file format [RFC1952] | 8.4.1.3 |
| identity | Reserved | 12.5.3 | | identity | Reserved | 12.5.3 |
| x-compress | Deprecated (alias for compress) | 8.4.1.1 | | x-compress | Deprecated (alias for compress) | 8.4.1.1 |
| x-gzip | Deprecated (alias for gzip) | 8.4.1.3 | | x-gzip | Deprecated (alias for gzip) | 8.4.1.3 |
+------------+-------------------------------------------+---------+ +------------+-----------------------------------------+---------+
Table 10 Table 10
18.7. Range Unit Registration 18.7. Range Unit Registration
Please update the "HTTP Range Unit Registry" at IANA has updated the "HTTP Range Unit Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 16.5.1 and the range unit names registration procedure of Section 16.5.1 and the range unit names
summarized in the table below. summarized in the table below.
+-----------------+----------------------------------+--------+ +-----------------+----------------------------------+--------+
| Range Unit Name | Description | Ref. | | Range Unit Name | Description | Ref. |
+-----------------+----------------------------------+--------+ +-----------------+----------------------------------+--------+
| bytes | a range of octets | 14.1.2 | | bytes | a range of octets | 14.1.2 |
| none | reserved as keyword to indicate | 14.3 | | none | reserved as keyword to indicate | 14.3 |
| | range requests are not supported | | | | range requests are not supported | |
+-----------------+----------------------------------+--------+ +-----------------+----------------------------------+--------+
Table 11 Table 11
18.8. Media Type Registration 18.8. Media Type Registration
Please update the "Media Types" registry at IANA has updated 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 14.6 for the media type "multipart/ information in Section 14.6 for the media type "multipart/
byteranges". byteranges".
Furthermore please update the registry note about "q" parameters with IANA has updated the registry note about "q" parameters with a link
a link to Section 12.5.1 of this document. to Section 12.5.1 of this document.
18.9. Port Registration 18.9. Port Registration
Please update the "Service Name and Transport Protocol Port Number" IANA has updated the "Service Name and Transport Protocol Port Number
registry at <https://www.iana.org/assignments/service-names-port- Registry" at <https://www.iana.org/assignments/service-names-port-
numbers/> for the services on ports 80 and 443 that use UDP or TCP numbers/> for the services on ports 80 and 443 that use UDP or TCP
to: to:
1. use this document as "Reference", and 1. use this document as "Reference", and
2. when currently unspecified, set "Assignee" to "IESG" and 2. when currently unspecified, set "Assignee" to "IESG" and
"Contact" to "IETF_Chair". "Contact" to "IETF_Chair".
18.10. Upgrade Token Registration 18.10. Upgrade Token Registration
Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token IANA has updated the "Hypertext Transfer Protocol (HTTP) Upgrade
Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> Token Registry" at <https://www.iana.org/assignments/http-upgrade-
with the registration procedure of Section 16.7 and the upgrade token tokens> with the registration procedure described in Section 16.7 and
names summarized in the following table. the upgrade token names summarized in the following table.
+------+-------------------+-------------------------+------+ +------+-------------------+-------------------------+------+
| Name | Description | Expected Version Tokens | Ref. | | Name | Description | Expected Version Tokens | Ref. |
+------+-------------------+-------------------------+------+ +------+-------------------+-------------------------+------+
| HTTP | Hypertext | any DIGIT.DIGIT (e.g, | 2.5 | | HTTP | Hypertext | any DIGIT.DIGIT (e.g., | 2.5 |
| | Transfer Protocol | "2.0") | | | | Transfer Protocol | "2.0") | |
+------+-------------------+-------------------------+------+ +------+-------------------+-------------------------+------+
Table 12 Table 12
19. References 19. References
19.1. Normative References 19.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", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cache-latest, September 2021, draft-ietf-httpbis-cache-latest, January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-latest>. cache-latest>.
[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Format Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P., and [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
G. Randers-Pehrson, "GZIP file format specification RFC 1952, DOI 10.17487/RFC1952, May 1996,
version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 199, line 48 skipping to change at page 200, line 11
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "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>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
skipping to change at page 200, line 46 skipping to change at page 201, line 9
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T. A., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), Compression", IEEE Computer 17(6),
DOI 10.1109/MC.1984.1659158, June 1984, DOI 10.1109/MC.1984.1659158, June 1984,
<https://ieeexplore.ieee.org/document/1659158/>. <https://ieeexplore.ieee.org/document/1659158/>.
19.2. Informative References 19.2. Informative References
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, December 2005.
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 [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, June 2015, RFC 7595, June 2015.
<https://www.rfc-editor.org/info/bcp35>.
<https://www.rfc-editor.org/info/bcp35>
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", July 2013, CRIME Attack", July 2013,
<http://breachattack.com/resources/ <http://breachattack.com/resources/
BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>. BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[Bujlow] Bujlow, T., Carela-Espanol, V., Sole-Pareta, J., and P. [Bujlow] Bujlow, T., Carela-Español, V., Solé-Pareta, J., and P.
Barlet-Ros, "A Survey on Web Tracking: Mechanisms, Barlet-Ros, "A Survey on Web Tracking: Mechanisms,
Implications, and Defenses", Implications, and Defenses", In Proceedings of the IEEE
DOI 10.1109/JPROC.2016.2637878, Proceedings of the 105(8), DOI 10.1109/JPROC.2016.2637878, August 2017,
IEEE 105(8), August 2017,
<https://doi.org/10.1109/JPROC.2016.2637878>. <https://doi.org/10.1109/JPROC.2016.2637878>.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIE] 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>.
[Err1912] RFC Errata, Erratum ID 1912, RFC 2978, [Err1912] RFC Errata, Erratum ID 1912, RFC 2978,
<https://www.rfc-editor.org/errata/eid1912>. <https://www.rfc-editor.org/errata/eid1912>.
[Err5433] RFC Errata, Erratum ID 5433, RFC 2978, [Err5433] RFC Errata, Erratum ID 5433, RFC 2978,
<https://www.rfc-editor.org/errata/eid5433>. <https://www.rfc-editor.org/errata/eid5433>.
[Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, [Georgiev] 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,
DOI 10.1145/2382196.2382204, October 2012, DOI 10.1145/2382196.2382204, October 2012,
<https://doi.org/10.1145/2382196.2382204>. <https://doi.org/10.1145/2382196.2382204>.
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen, [HTTP/1.0] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>. <https://www.rfc-editor.org/info/rfc1945>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-latest, September 2021, ietf-httpbis-messaging-latest, January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-latest>. messaging-latest>.
[HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HTTP/3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, February 2, 2021, quic-http-34, February 2, 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>. http-34>.
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
skipping to change at page 203, line 14 skipping to change at page 203, line 34
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, DOI 10.17487/RFC1919, March 1996, RFC 1919, DOI 10.17487/RFC1919, March 1996,
<https://www.rfc-editor.org/info/rfc1919>. <https://www.rfc-editor.org/info/rfc1919>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996, RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/info/rfc2047>. <https://www.rfc-editor.org/info/rfc2047>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, DOI 10.17487/RFC2068, January 1997, RFC 2068, DOI 10.17487/RFC2068, January 1997,
<https://www.rfc-editor.org/info/rfc2068>. <https://www.rfc-editor.org/info/rfc2068>.
[RFC2145] Mogul, J.C., Fielding, R.T., Gettys, J., and H.F. Nielsen, [RFC2145] Mogul, J. C., Fielding, R., Gettys, J., and H. Frystyk,
"Use and Interpretation of HTTP Version Numbers", "Use and Interpretation of HTTP Version Numbers",
RFC 2145, DOI 10.17487/RFC2145, May 1997, RFC 2145, 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.H. Mutz, "Transparent Content [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
Negotiation in HTTP", RFC 2295, DOI 10.17487/RFC2295, in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
March 1998, <https://www.rfc-editor.org/info/rfc2295>. <https://www.rfc-editor.org/info/rfc2295>.
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1, (HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1,
1998, <https://www.rfc-editor.org/info/rfc2324>. 1998, <https://www.rfc-editor.org/info/rfc2324>.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
"MIME Encapsulation of Aggregate Documents, such as HTML 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>.
[RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999, RFC 2617, DOI 10.17487/RFC2617, June 1999,
<https://www.rfc-editor.org/info/rfc2617>. <https://www.rfc-editor.org/info/rfc2617>.
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP [RFC2774] Nielsen, H., Leach, P., and S. Lawrence, "An HTTP
Extension Framework", RFC 2774, DOI 10.17487/RFC2774, Extension Framework", RFC 2774, DOI 10.17487/RFC2774,
February 2000, <https://www.rfc-editor.org/info/rfc2774>. February 2000, <https://www.rfc-editor.org/info/rfc2774>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978,
October 2000, <https://www.rfc-editor.org/info/rfc2978>. October 2000, <https://www.rfc-editor.org/info/rfc2978>.
skipping to change at page 205, line 5 skipping to change at page 205, line 27
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[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. F. Reschke, Ed., "Hypertext [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Transfer Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Transfer Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
RFC 7231, DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Transfer Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
RFC 7232, DOI 10.17487/RFC7232, June 2014, DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>. <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): 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>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
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>.
[RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
Code 308 (Permanent Redirect)", RFC 7538, 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
DOI 10.17487/RFC7538, April 2015, April 2015, <https://www.rfc-editor.org/info/rfc7538>.
<https://www.rfc-editor.org/info/rfc7538>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/ [RFC7578] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
<https://www.rfc-editor.org/info/rfc7578>. <https://www.rfc-editor.org/info/rfc7578>.
[RFC7615] Reschke, J. F., "HTTP Authentication-Info and Proxy- [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
Authentication-Info Response Header Fields", RFC 7615, Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015, DOI 10.17487/RFC7615, September 2015,
<https://www.rfc-editor.org/info/rfc7615>. <https://www.rfc-editor.org/info/rfc7615>.
[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. F., "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>.
[RFC7694] Reschke, J. F., "Hypertext Transfer Protocol (HTTP) [RFC7694] Reschke, J., "Hypertext Transfer Protocol (HTTP) Client-
Client-Initiated Content-Encoding", RFC 7694, Initiated Content-Encoding", RFC 7694,
DOI 10.17487/RFC7694, November 2015, DOI 10.17487/RFC7694, November 2015,
<https://www.rfc-editor.org/info/rfc7694>. <https://www.rfc-editor.org/info/rfc7694>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8187] Reschke, J. F., "Indicating Character Encoding and [RFC8187] Reschke, J., "Indicating Character Encoding and Language
Language for HTTP Header Field Parameters", RFC 8187, for HTTP Header Field Parameters", RFC 8187,
DOI 10.17487/RFC8187, September 2017, DOI 10.17487/RFC8187, September 2017,
<https://www.rfc-editor.org/info/rfc8187>. <https://www.rfc-editor.org/info/rfc8187>.
[RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, [RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246,
DOI 10.17487/RFC8246, September 2017, DOI 10.17487/RFC8246, September 2017,
<https://www.rfc-editor.org/info/rfc8246>. <https://www.rfc-editor.org/info/rfc8246>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
skipping to change at page 206, line 47 skipping to change at page 207, line 24
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>. <https://www.rfc-editor.org/info/rfc8615>.
[RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>. <https://www.rfc-editor.org/info/rfc8941>.
[Sniffing] WHATWG, "MIME Sniffing", [Sniffing] WHATWG, "MIME Sniffing",
<https://mimesniff.spec.whatwg.org>. <https://mimesniff.spec.whatwg.org>.
[WEBDAV] Dusseault, L.M., Ed., "HTTP Extensions for Web Distributed [WEBDAV] 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>.
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 per
Section 5.6.1. Section 5.6.1.
Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [ Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [
weight ] ) ) ] weight ] ) ) ]
Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( ( Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( (
token / "*" ) [ weight ] ) ) ] token / "*" ) [ weight ] ) ) ]
Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [ Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [
weight ] ) ) ] weight ] ) ) ]
Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS ( Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS (
language-range [ weight ] ) ) ] language-range [ weight ] ) ) ]
skipping to change at page 211, line 41 skipping to change at page 212, line 18
type = token type = token
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
uri-host = <host, see [URI], Section 3.2.2> uri-host = <host, see [URI], Section 3.2.2>
weak = %x57.2F ; W/ weak = %x57.2F ; W/
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
Appendix B. Changes from previous RFCs Appendix B. Changes from Previous RFCs
B.1. Changes from RFC 2818 B.1. Changes from RFC 2818
None. None.
B.2. Changes from RFC 7230 B.2. Changes from RFC 7230
The sections introducing HTTP's design goals, history, architecture, The sections introducing HTTP's design goals, history, architecture,
conformance criteria, protocol versioning, URIs, message routing, and conformance criteria, protocol versioning, URIs, message routing, and
header fields have been moved here. header fields have been moved here.
The requirement on semantic conformance has been replaced with The requirement on semantic conformance has been replaced with
permission to ignore/workaround implementation-specific failures. permission to ignore or work around implementation-specific failures.
(Section 2.2) (Section 2.2)
The description of an origin and authoritative access to origin The description of an origin and authoritative access to origin
servers has been extended for both "http" and "https" URIs to account servers has been extended for both "http" and "https" URIs to account
for alternative services and secured connections that are not for alternative services and secured connections that are not
necessarily based on TCP. (Section 4.2.1, Section 4.2.2, necessarily based on TCP. (Sections 4.2.1, 4.2.2, 4.3.1, and 7.3.3)
Section 4.3.1, Section 7.3.3)
Explicit requirements have been added to check the target URI Explicit requirements have been added to check the target URI
scheme's semantics and reject requests that don't meet any associated scheme's semantics and reject requests that don't meet any associated
requirements. (Section 7.4) requirements. (Section 7.4)
Parameters in media type, media range, and expectation can be empty Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons. (Section 5.6.6) via one or more trailing semicolons. (Section 5.6.6)
"Field value" now refers to the value after multiple field lines are "Field value" now refers to the value after multiple field lines are
combined with commas -- by far the most common use. To refer to a combined with commas -- by far the most common use. To refer to a
skipping to change at page 212, line 25 skipping to change at page 213, line 4
Explicit requirements have been added to check the target URI Explicit requirements have been added to check the target URI
scheme's semantics and reject requests that don't meet any associated scheme's semantics and reject requests that don't meet any associated
requirements. (Section 7.4) requirements. (Section 7.4)
Parameters in media type, media range, and expectation can be empty Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons. (Section 5.6.6) via one or more trailing semicolons. (Section 5.6.6)
"Field value" now refers to the value after multiple field lines are "Field value" now refers to the value after multiple field lines are
combined with commas -- by far the most common use. To refer to a combined with commas -- by far the most common use. To refer to a
single header line's value, use "field line value". (Section 6.3) single header line's value, use "field line value". (Section 6.3)
Trailer field semantics now transcend the specifics of chunked Trailer field semantics now transcend the specifics of chunked
encoding. Use of trailer fields has been further limited to only encoding. The use of trailer fields has been further limited to
allow generation as a trailer field when the sender knows the field allow generation as a trailer field only when the sender knows the
defines that usage and to only allow merging into the header section field defines that usage and to allow merging into the header section
if the recipient knows the corresponding field definition permits and only if the recipient knows the corresponding field definition
defines how to merge. In all other cases, implementations are permits and defines how to merge. In all other cases,
encouraged to either store the trailer fields separately or discard implementations are encouraged either to store the trailer fields
them instead of merging. (Section 6.5.1) separately or to discard them instead of merging. (Section 6.5.1)
Made the priority of the absolute form of the request URI over the The priority of the absolute form of the request URI over the Host
Host header by origin servers explicit, to align with proxy handling. header field by origin servers has been made explicit to align with
(Section 7.2) proxy handling. (Section 7.2)
The grammar definition for the Via field's "received-by" was expanded The grammar definition for the Via field's "received-by" was expanded
in 7230 due to changes in the URI grammar for host [URI] that are not in RFC 7230 due to changes in the URI grammar for host [URI] that are
desirable for Via. For simplicity, we have removed uri-host from the not desirable for Via. For simplicity, we have removed uri-host from
received-by production because it can be encompassed by the existing the received-by production because it can be encompassed by the
grammar for pseudonym. In particular, this change removed comma from existing grammar for pseudonym. In particular, this change removed
the allowed set of charaters for a host name in received-by. comma from the allowed set of characters for a host name in received-
(Section 7.6.3) by. (Section 7.6.3)
B.3. Changes from RFC 7231 B.3. Changes from RFC 7231
Minimum URI lengths to be supported by implementations are now Minimum URI lengths to be supported by implementations are now
recommended. (Section 3.1) recommended. (Section 3.1)
Clarified that CR and NUL in field values are to be rejected or
mapped to SP and that leading and trailing whitespace need to be The following have been clarified: CR and NUL in field values are to
stripped from field values before they are consumed. (Section 5.5) be rejected or mapped to SP, and leading and trailing whitespace
needs to be stripped from field values before they are consumed.
(Section 5.5)
Parameters in media type, media range, and expectation can be empty Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons. (Section 5.6.6) via one or more trailing semicolons. (Section 5.6.6)
An abstract data type for HTTP messages has been introduced to define An abstract data type for HTTP messages has been introduced to define
the components of a message and their semantics as an abstraction the components of a message and their semantics as an abstraction
across multiple HTTP versions, rather than in terms of the specific across multiple HTTP versions, rather than in terms of the specific
syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after
the message is parsed. This makes it easier to distinguish between the message is parsed. This makes it easier to distinguish between
requirements on the content (what is conveyed) versus requirements on requirements on the content (what is conveyed) versus requirements on
skipping to change at page 213, line 25 skipping to change at page 214, line 4
the message is parsed. This makes it easier to distinguish between the message is parsed. This makes it easier to distinguish between
requirements on the content (what is conveyed) versus requirements on requirements on the content (what is conveyed) versus requirements on
the messaging syntax (how it is conveyed) and avoids baking the messaging syntax (how it is conveyed) and avoids baking
limitations of early protocol versions into the future of HTTP. limitations of early protocol versions into the future of HTTP.
(Section 6) (Section 6)
The terms "payload" and "payload body" have been replaced with The terms "payload" and "payload body" have been replaced with
"content", to better align with its usage elsewhere (e.g., in field "content", to better align with its usage elsewhere (e.g., in field
names) and to avoid confusion with frame payloads in HTTP/2 and names) and to avoid confusion with frame payloads in HTTP/2 and
HTTP/3. (Section 6.4) HTTP/3. (Section 6.4)
The term "effective request URI" has been replaced with "target URI". The term "effective request URI" has been replaced with "target URI".
(Section 7.1) (Section 7.1)
Restrictions on client retries have been loosened, to reflect Restrictions on client retries have been loosened to reflect
implementation behavior. (Section 9.2.2) implementation behavior. (Section 9.2.2)
Clarified that request bodies on GET, HEAD, and DELETE are not The fact that request bodies on GET, HEAD, and DELETE are not
interoperable. (Section 9.3.1, Section 9.3.2, Section 9.3.5) interoperable has been clarified. (Sections 9.3.1, 9.3.2, and 9.3.5)
Allowed use of the Content-Range header field (Section 14.4) as a The use of the Content-Range header field (Section 14.4) as a request
request modifier on PUT. (Section 9.3.4) modifier on PUT is allowed. (Section 9.3.4)
Removed a superfluous requirement about setting Content-Length from A superfluous requirement about setting Content-Length has been
the description of the OPTIONS method. (Section 9.3.7) removed from the description of the OPTIONS method. (Section 9.3.7)
Removed normative requirement to use the "message/http" media type in The normative requirement to use the "message/http" media type in
TRACE responses. (Section 9.3.8) TRACE responses has been removed. (Section 9.3.8)
Restore list-based grammar for Expect for compatibility with RFC List-based grammar for Expect has been restored for compatibility
2616. (Section 10.1.1) with RFC 2616. (Section 10.1.1)
Accept and Accept-Encoding are allowed in response messages; the
latter was introduced by [RFC7694]. (Section 12.3)
Allow Accept and Accept-Encoding in response messages; the latter was
introduced by [RFC7694]. (Section 12.3)
"Accept Parameters" (accept-params and accept-ext ABNF production) "Accept Parameters" (accept-params and accept-ext ABNF production)
have been removed from the definition of the Accept field. have been removed from the definition of the Accept field.
(Section 12.5.1) (Section 12.5.1)
The "Accept-Charset" field now is deprecated. (Section 12.5.2) The Accept-Charset field is now deprecated. (Section 12.5.2)
The semantics of "*" in the Vary header field when other values are The semantics of "*" in the Vary header field when other values are
present was clarified. (Section 12.5.5) present was clarified. (Section 12.5.5)
Range units are compared in a case insensitive fashion. Range units are compared in a case-insensitive fashion.
(Section 14.1) (Section 14.1)
Use of "Accept-Ranges" is not restricted to origin servers. The use of the Accept-Ranges field is not restricted to origin
(Section 14.3) servers. (Section 14.3)
The process of creating a redirected request has been clarified. The process of creating a redirected request has been clarified.
(Section 15.4) (Section 15.4)
Added status code 308 (previously defined in [RFC7538]) so that it's Status code 308 (previously defined in [RFC7538]) has been added so
defined closer to status codes 301, 302, and 307. (Section 15.4.9) that it's defined closer to status codes 301, 302, and 307.
(Section 15.4.9)
Added status code 421 (previously defined in Section 9.1.2 of Status code 421 (previously defined in Section 9.1.2 of [HTTP/2]) has
[HTTP/2]) because of its general applicability. 421 is no longer been added because of its general applicability. 421 is no longer
defined as heuristically cacheable, since the response is specific to defined as heuristically cacheable since the response is specific to
the connection (not the target resource). (Section 15.5.20) the connection (not the target resource). (Section 15.5.20)
Added status code 422 (previously defined in Section 11.2 of Status code 422 (previously defined in Section 11.2 of [WEBDAV]) has
[WEBDAV]) because of its general applicability. (Section 15.5.21) been added because of its general applicability. (Section 15.5.21)
B.4. Changes from RFC 7232 B.4. Changes from RFC 7232
Previous revisions of HTTP imposed an arbitrary 60-second limit on Previous revisions of HTTP imposed an arbitrary 60-second limit on
the determination of whether Last-Modified was a strong validator to the determination of whether Last-Modified was a strong validator to
guard against the possibility that the Date and Last-Modified values guard against the possibility that the Date and Last-Modified values
are generated from different clocks or at somewhat different times are generated from different clocks or at somewhat different times
during the preparation of the response. This specification has during the preparation of the response. This specification has
relaxed that to allow reasonable discretion. (Section 8.8.2.2) relaxed that to allow reasonable discretion. (Section 8.8.2.2)
Removed edge case requirement on If-Match and If-Unmodified-Since Removed edge-case requirement on If-Match and If-Unmodified-Since
that a validator not be sent in a 2xx response when validation fails that a validator not be sent in a 2xx response when validation fails
and the server decides that the same change request has already been and the server decides that the same change request has already been
applied. (Section 13.1.1 and Section 13.1.4) applied. (Sections 13.1.1 and 13.1.4)
The fact that If-Unmodified-Since does not apply to a resource
without a concept of modification time has been clarified.
(Section 13.1.4)
Clarified that If-Unmodified-Since doesn't apply to a resource
without a concept of modification time. (Section 13.1.4)
Preconditions can now be evaluated before the request content is Preconditions can now be evaluated before the request content is
processed rather than waiting until the response would otherwise be processed rather than waiting until the response would otherwise be
successful. (Section 13.2) successful. (Section 13.2)
B.5. Changes from RFC 7233 B.5. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other- (extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing range-unit by defining range units generically as a token and placing
skipping to change at page 215, line 41 skipping to change at page 216, line 19
B.7. Changes from RFC 7538 B.7. Changes from RFC 7538
None. None.
B.8. Changes from RFC 7615 B.8. Changes from RFC 7615
None. None.
B.9. Changes from RFC 7694 B.9. Changes from RFC 7694
This specification includes the extension defined in [RFC7694], but This specification includes the extension defined in [RFC7694] but
leaves out examples and deployment considerations. leaves out examples and deployment considerations.
Appendix C. Change Log Appendix C. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
C.1. Between RFC723x and draft 00 See <https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-
19.html#appendix-C> for changes up to version 19 of this document.
The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications.
o Remove version "1.1" from document title, indicating that this
specification applies to all HTTP versions.
o Adjust historical notes.
o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered.
C.2. Since draft-ietf-httpbis-semantics-00
The changes in this draft are editorial, with respect to HTTP as a
whole, to merge core HTTP semantics into this document:
o Merged introduction, architecture, conformance, and ABNF
extensions from RFC 7230 (Messaging).
o Rearranged architecture to extract conformance, http(s) schemes,
and protocol versioning into a separate major section.
o Moved discussion of MIME differences to [HTTP/1.1] since that is
primarily concerned with transforming 1.1 messages.
o Merged entire content of RFC 7232 (Conditional Requests).
o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC.
C.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 14.4, 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 15.4 (<https://github.com/httpwg/
http-core/issues/98>, <https://www.rfc-editor.org/errata/eid4452>)
o In Section 5.6.1, 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 15.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>)
C.4. Since draft-ietf-httpbis-semantics-02
o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>)
o In Section 9.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>)
o Add Section 15.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>)
o In Section 3.4 and Section 10.1.1, clarified when a response can
be sent (<https://github.com/httpwg/http-core/issues/82>)
o In Section 8.3.2, explain the difference between the "token"
production, the RFC 2978 ABNF for charset names, and the actual
registration practice (<https://github.com/httpwg/http-core/
issues/100>, <https://www.rfc-editor.org/errata/eid4689>)
o In Section 3.1, removed the fragment component in the URI scheme
definitions as per Section 4.3 of [URI], furthermore moved
fragment discussion into a separate section
(<https://github.com/httpwg/http-core/issues/103>,
<https://www.rfc-editor.org/errata/eid4251>, <https://www.rfc-
editor.org/errata/eid4252>)
o In Section 2.5, add language about minor HTTP version number
defaulting (<https://github.com/httpwg/http-core/issues/115>)
o Added Section 15.5.21 for status code 422, previously defined in
Section 11.2 of [WEBDAV] (<https://github.com/httpwg/http-core/
issues/123>)
o In Section 15.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>)
o In Section 3.4, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/
issues/145>)
C.5. Since draft-ietf-httpbis-semantics-03
o In Section 15.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>)
o In Section 8.3.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>)
o In Section 12.1, refactor and clarify description of wildcard
("*") handling (<https://github.com/httpwg/http-core/issues/46>)
o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/
issues/61>)
o In Section 13.2, mention Cache-Control: immutable
(<https://github.com/httpwg/http-core/issues/69>)
o In Section 5.3, clarify when header field combination is allowed
(<https://github.com/httpwg/http-core/issues/74>)
o In Section 18.4, instruct IANA to mark Content-MD5 as obsolete
(<https://github.com/httpwg/http-core/issues/93>)
o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 3.4 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>)
o In Section 9.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
C.6. Since draft-ietf-httpbis-semantics-04
o In Section 5.5, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>)
o Move Section 5.6.6 into its own section
(<https://github.com/httpwg/http-core/issues/45>)
o In Section 8.3, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>)
o In Section 5.6.1, simplify the #rule mapping for recipients
(<https://github.com/httpwg/http-core/issues/164>,
<https://www.rfc-editor.org/errata/eid5257>)
o In Section 9.3.7, remove misleading text about "extension" of HTTP
is needed to define method content (<https://github.com/httpwg/
http-core/issues/204>)
o Fix editorial issue in Section 3.2 (<https://github.com/httpwg/
http-core/issues/223>)
o In Section 15.5.21, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>)
o Move discussion of retries from [HTTP/1.1] into Section 9.2.2
(<https://github.com/httpwg/http-core/issues/230>)
C.7. Since draft-ietf-httpbis-semantics-05
o Moved transport-independent part of the description of trailers
into Section 6.5 (<https://github.com/httpwg/http-core/issues/16>)
o Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>)
o In Section 18.9, update IANA port registry for TCP/UDP on ports 80
and 443 (<https://github.com/httpwg/http-core/issues/36>)
o In Section 16.3.2.2, revise guidelines for new header field names
(<https://github.com/httpwg/http-core/issues/47>)
o In Section 9.2.3, remove concept of "cacheable methods" in favor
of prose (<https://github.com/httpwg/http-core/issues/54>,
<https://www.rfc-editor.org/errata/eid5300>)
o In Section 17.1, mention that the concept of authority can be
modified by protocol extensions (<https://github.com/httpwg/http-
core/issues/143>)
o Create new subsection on content in Section 6.4, taken from
portions of message body (<https://github.com/httpwg/http-core/
issues/159>)
o Moved definition of "Whitespace" into new container "Generic
Syntax" (<https://github.com/httpwg/http-core/issues/162>)
o In Section 3.1, recommend minimum URI size support for
implementations (<https://github.com/httpwg/http-core/issues/169>)
o In Section 14.1, refactored the range-unit and ranges-specifier
grammars (<https://github.com/httpwg/http-core/issues/196>,
<https://www.rfc-editor.org/errata/eid5620>)
o In Section 9.3.1, caution against a request content more strongly
(<https://github.com/httpwg/http-core/issues/202>)
o Reorganized text in Section 16.3.2.2 (<https://github.com/httpwg/
http-core/issues/214>)
o In Section 15.5.4, replace "authorize" with "fulfill"
(<https://github.com/httpwg/http-core/issues/218>)
o In Section 9.3.7, removed a misleading statement about Content-
Length (<https://github.com/httpwg/http-core/issues/235>,
<https://www.rfc-editor.org/errata/eid5806>)
o In Section 17.1, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>)
o Changed "cacheable by default" to "heuristically cacheable"
throughout (<https://github.com/httpwg/http-core/issues/242>)
C.8. Since draft-ietf-httpbis-semantics-06
o In Section 7.6.3, simplify received-by grammar (and disallow comma
character) (<https://github.com/httpwg/http-core/issues/24>)
o In Section 5.1, give guidance on interoperable field names
(<https://github.com/httpwg/http-core/issues/30>)
o In Section 5.6.3, define the semantics and possible replacement of
whitespace when it is known to occur (<https://github.com/httpwg/
http-core/issues/53>, <https://www.rfc-editor.org/errata/eid5163>)
o In Section 6.3, introduce field terminology and distinguish
between field line values and field values; use terminology
consistently throughout (<https://github.com/httpwg/http-core/
issues/111>)
o Moved #rule definition into Section 5.5 and whitespace into
Section 2.1 (<https://github.com/httpwg/http-core/issues/162>)
o In Section 14.1, explicitly call out range unit names as case-
insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>)
o In Section 8.4.1, explicitly call out content codings as case-
insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>)
o In Section 5.1, explicitly call out field names as case-
insensitive (<https://github.com/httpwg/http-core/issues/179>)
o In Section 17.13, cite [Bujlow] (<https://github.com/httpwg/http-
core/issues/185>)
o In Section 15, formally define "final" and "interim" status codes
(<https://github.com/httpwg/http-core/issues/245>)
o In Section 9.3.5, caution against a request content more strongly
(<https://github.com/httpwg/http-core/issues/258>)
o In Section 8.8.3, note that Etag can be used in trailers
(<https://github.com/httpwg/http-core/issues/262>)
o In Section 18.4, consider reserved fields as well
(<https://github.com/httpwg/http-core/issues/273>)
o In Section 4.2.4, be more correct about what was deprecated by RFC
3986 (<https://github.com/httpwg/http-core/issues/278>,
<https://www.rfc-editor.org/errata/eid5964>)
o In Section 5.3, recommend comma SP when combining field lines
(<https://github.com/httpwg/http-core/issues/148>)
o In Section 7.2, make explicit requirements on origin server to use
authority from absolute-form when available
(<https://github.com/httpwg/http-core/issues/191>)
o In Section 4.2.1, Section 4.2.2, Section 4.3.1, and Section 7.3.3,
refactored schemes to define origin and authoritative access to an
origin server for both "http" and "https" URIs to account for
alternative services and secured connections that are not
necessarily based on TCP (<https://github.com/httpwg/http-core/
issues/237>)
o In Section 2.2, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>)
C.9. Since draft-ietf-httpbis-semantics-07
o In Section 14.2, explicitly reference the definition of
representation data as including any content codings
(<https://github.com/httpwg/http-core/issues/11>)
o Move TE: trailers from [HTTP/1.1] into Section 6.5.1
(<https://github.com/httpwg/http-core/issues/18>)
o In Section 8.6, adjust requirements for handling multiple content-
length values (<https://github.com/httpwg/http-core/issues/59>)
o In Section 13.1.1 and Section 13.1.2, clarified condition
evaluation (<https://github.com/httpwg/http-core/issues/72>)
o In Section 5.5, remove concept of obs-fold, as that is
HTTP/1-specific (<https://github.com/httpwg/http-core/issues/116>)
o In Section 12, introduce the concept of request content
negotiation (Section 12.3) and define for Accept-Encoding
(<https://github.com/httpwg/http-core/issues/119>)
o In Section 15.3.6, Section 15.5.9, and Section 15.5.14, remove
HTTP/1-specific, connection-related requirements
(<https://github.com/httpwg/http-core/issues/144>)
o In Section 9.3.6, correct language about what is forwarded
(<https://github.com/httpwg/http-core/issues/170>)
o Throughout, replace "effective request URI", "request-target" and
similar with "target URI" (<https://github.com/httpwg/http-core/
issues/259>)
o In Section 16.3.2.2 and Section 16.2.2, describe how extensions
should consider scope of applicability
(<https://github.com/httpwg/http-core/issues/265>)
o In Section 3.4, don't rely on the HTTP/1.1 Messaging specification
to define "message" (<https://github.com/httpwg/http-core/
issues/311>)
o In Section 8.7 and Section 10.1.3, note that URL resolution is
necessary (<https://github.com/httpwg/http-core/issues/321>)
o In Section 3.2, explicitly reference 206 as one of the status
codes that provide representation data
(<https://github.com/httpwg/http-core/issues/325>)
o In Section 13.1.4, refine requirements so that they don't apply to
resources without a concept of modification time
(<https://github.com/httpwg/http-core/issues/326>)
o In Section 11.7.1, specify the scope as a request, not a target
resource (<https://github.com/httpwg/http-core/issues/331>)
o In Section 3.4, introduce concept of "complete" messages
(<https://github.com/httpwg/http-core/issues/334>)
o In Section 7.1, Section 9.3.6, and Section 9.3.7, refine use of
"request target" (<https://github.com/httpwg/http-core/
issues/340>)
o Throughout, remove "status-line" and "request-line", as these are
HTTP/1.1-specific (<https://github.com/httpwg/http-core/
issues/361>)
C.10. Since draft-ietf-httpbis-semantics-08
o In Section 15.5.17, remove duplicate definition of what makes a
range satisfiable and refer instead to each range unit's
definition (<https://github.com/httpwg/http-core/issues/12>)
o In Section 14.1.2 and Section 14.2, clarify that a selected
representation of zero length can only be satisfiable as a suffix
range and that a server can still ignore Range for that case
(<https://github.com/httpwg/http-core/issues/12>)
o In Section 12.5.1 and Section 15.5.16, allow "Accept" as response
field (<https://github.com/httpwg/http-core/issues/48>)
o Appendix A now uses the sender variant of the "#" list expansion
(<https://github.com/httpwg/http-core/issues/192>)
o In Section 12.5.5, make the field list-based even when "*" is
present (<https://github.com/httpwg/http-core/issues/272>)
o In Section 16.3.1, add optional "Comments" entry
(<https://github.com/httpwg/http-core/issues/273>)
o In Section 18.4, reserve "*" as field name
(<https://github.com/httpwg/http-core/issues/274>)
o In Section 18.2, reserve "*" as method name
(<https://github.com/httpwg/http-core/issues/274>)
o In Section 13.1.1 and Section 13.1.2, state that multiple "*" is
unlikely to be interoperable (<https://github.com/httpwg/http-
core/issues/305>)
o In Section 12.5.1, avoid use of obsolete media type parameter on
text/html (<https://github.com/httpwg/http-core/issues/375>,
<https://www.rfc-editor.org/errata/eid6149>)
o Rephrase prose in Section 3.4 to become version-agnostic
(<https://github.com/httpwg/http-core/issues/372>)
o In Section 5.5, instruct recipients how to deal with control
characters in field values (<https://github.com/httpwg/http-core/
issues/377>)
o In Section 5.5, update note about field ABNF
(<https://github.com/httpwg/http-core/issues/380>)
o Add Section 16 about Extending and Versioning HTTP
(<https://github.com/httpwg/http-core/issues/384>)
o In Section 15.1, include status 308 in list of heuristically
cacheable status codes (<https://github.com/httpwg/http-core/
issues/385>)
o In Section 8.4, make it clearer that "identity" is not to be
included (<https://github.com/httpwg/http-core/issues/388>)
C.11. Since draft-ietf-httpbis-semantics-09
o Switch to xml2rfc v3 mode for draft generation
(<https://github.com/httpwg/http-core/issues/394>)
C.12. Since draft-ietf-httpbis-semantics-10
o In Section 17.6, mention compression attacks
(<https://github.com/httpwg/http-core/issues/6>)
o In Section 16.6.1, advise to make new content codings self-
descriptive (<https://github.com/httpwg/http-core/issues/21>)
o In Section 5.6.6, introduced the "parameters" ABNF rule, allowing
empty parameters and trailing semicolons within media type, media
range, and expectation (<https://github.com/httpwg/http-core/
issues/33>)
o In Section 15.4, explain how to create a redirected request
(<https://github.com/httpwg/http-core/issues/38>)
o In Section 8.3, defined error handling for multiple members
(<https://github.com/httpwg/http-core/issues/39>)
o In Section 1, revise the introduction and introduce HTTP/2 and
HTTP/3 (<https://github.com/httpwg/http-core/issues/64>)
o In Section 8.6, added a definition for Content-Length that
encompasses its various roles in describing message content or
selected representation length; in Section 15.3.7, noted that
Content-Length counts only the message content (not the selected
representation) and that the representation length is in each
Content-Range (<https://github.com/httpwg/http-core/issues/118>)
o Noted that "WWW-Authenticate" with more than one value on a line
is sometimes not interoperable [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/136>)
o In Section 13.1.1 and Section 13.1.4, removed requirement that a
validator not be sent in a 2xx response when validation fails and
the server decides that the same change request has already been
applied (<https://github.com/httpwg/http-core/issues/166>)
o Moved requirements specific to HTTP/1.1 from Section 7.2 to
[HTTP/1.1] (<https://github.com/httpwg/http-core/issues/182>)
o In Section 5.5, introduce the terms "singleton field" and "list-
based field" (also - in various places - discuss what to do when a
singleton field is received as a list)
(<https://github.com/httpwg/http-core/issues/193>)
o In Section 10.1.1, change the ABNF back to be a list of
expectations, as defined in RFC 2616 (<https://github.com/httpwg/
http-core/issues/203>)
o In Section 6.6.2 (Trailer), Section 7.6.3 (Via), Section 7.8
(Upgrade), Section 7.6.1 (Connection), Section 8.4
(Content-Encoding), Section 8.5 (Content-Language), Section 10.1.1
(Expect), Section 13.1.1 (If-Match), Section 13.1.2
(If-None-Match), Section 12.5.2 (Accept-Charset), Section 12.5.4
(Accept-Language), Section 12.5.5 (Vary), Section 11.6.1
(WWW-Authenticate), and Section 11.7.1 (Proxy-Authenticate),
adjust ABNF to allow empty lists (<https://github.com/httpwg/http-
core/issues/210>)
o In Section 9.3.1 and Section 17.9, provide a more nuanced
explanation of sensitive data in GET-based forms and describe
workarounds (<https://github.com/httpwg/http-core/issues/277>)
o In Section 13.2, allow preconditions to be evaluated before the
request content (if any) is processed (<https://github.com/httpwg/
http-core/issues/261>)
o In Section 6.3 and Section 6.5.2, allow for trailer fields in
multiple trailer sections, depending on the HTTP version and
framing in use, with processing being iterative as each section is
received (<https://github.com/httpwg/http-core/issues/313>)
o Moved definitions of "TE" and "Upgrade" from [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/392>)
o Moved 1.1-specific discussion of TLS to Messaging and rewrote
Section 4.3.4 to refer to RFC6125 (<https://github.com/httpwg/
http-core/issues/404>)
o Moved definition of "Connection" from [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/407>)
C.13. Since draft-ietf-httpbis-semantics-11
o The entire document has been reorganized, with no changes to
content except editorial for the reorganization
(<https://github.com/httpwg/http-core/issues/368>)
o Move IANA Upgrade Token Registry instructions from [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/450>)
C.14. Since draft-ietf-httpbis-semantics-12
o In Appendix "Acknowledgements" (Appendix "Acknowledgements"),
added acks for the work since 2014 (<https://github.com/httpwg/
http-core/issues/442>)
o In Section 15.3.7, specifically require that a client check the
206 response header fields to determine what ranges are enclosed,
since it cannot assume they exactly match those requested
(<https://github.com/httpwg/http-core/issues/445>)
o In Section 16.3, explain why new fields need to be backwards-
compatible (<https://github.com/httpwg/http-core/issues/448>)
o In Section 5.3, constrain field combination to be within a section
(<https://github.com/httpwg/http-core/issues/454>)
o In Section 5.6.7, mention that caching relaxes date sensitivity
(<https://github.com/httpwg/http-core/issues/473>)
o In Section 18.4, moved "*" field registration into main table
(<https://github.com/httpwg/http-core/issues/476>)
o In Section 1.2, reference HTTP/0.9 (<https://github.com/httpwg/
http-core/issues/497>)
o In Section 9.3.4, clarify handling of unrecognized fields
(<https://github.com/httpwg/http-core/issues/502>)
o In Section 15.2, align language about bodies and trailers with 204
and 304 (<https://github.com/httpwg/http-core/issues/503>)
o Moved table of content codings into Section 18.6, moved table of
range units into Section 18.7 (<https://github.com/httpwg/http-
core/issues/506>)
o In Section 6, add an abstract data type for message to help define
semantics without being dependent on the specific structure of
HTTP/1.1 (<https://github.com/httpwg/http-core/issues/557>)
o In Section 8.8.2.2, relax arbitrary 60-second comparison limit
(<https://github.com/httpwg/http-core/issues/510>)
o In Section 7.2, add ":authority" pseudo-header to Host discussion
and make section applicable to both (<https://github.com/httpwg/
http-core/issues/511>)
o In Section 18.4, note that this document updates [RFC3864]
(<https://github.com/httpwg/http-core/issues/515>)
o Moved transfer-coding ABNF from [HTTP/1.1] to Section 10.1.4 and
replaced "t-ranking" ABNF by equivalent "weight"
(<https://github.com/httpwg/http-core/issues/531>)
o In Section 11.5, replace "canonical root URI" by "origin"
(<https://github.com/httpwg/http-core/issues/542>)
o In Section 10.1.1, remove obsolete note about a change in RFC 723x
(<https://github.com/httpwg/http-core/issues/547>)
o Changed to using "payload" when defining requirements about the
data being conveyed within a message, instead of the terms
"payload body" or "response body" or "representation body", since
they often get confused with the HTTP/1.1 message body (which
includes transfer coding) (<https://github.com/httpwg/http-core/
issues/553>)
o Rewrite definition of HEAD method (<https://github.com/httpwg/
http-core/issues/559>)
o In Section 13.1.5, fix an off-by-one bug about how many chars to
consider when checking for etags (<https://github.com/httpwg/http-
core/issues/570>)
o In Section 15.1, clarify that "no reason phrase" is fine as well
(<https://github.com/httpwg/http-core/issues/571>)
o In Section 15.3.4, remove an obsolete reference to the Warning
response header field (<https://github.com/httpwg/http-core/
issues/573>)
o In Section 15.5.9, rephrase prose about connection re-use
(<https://github.com/httpwg/http-core/issues/579>)
o In Section 14.2, potentially allow Range handling on methods other
than GET (<https://github.com/httpwg/http-core/issues/581>)
o In Section 18.3, remove redundant text about status code 418
(<https://github.com/httpwg/http-core/issues/583>)
o In Section 17.16.1, rewrite requirement to refer to "secured
connection" (<https://github.com/httpwg/http-core/issues/587>)
o Make reference to [TLS13] normative (<https://github.com/httpwg/
http-core/issues/589>)
C.15. Since draft-ietf-httpbis-semantics-13
o In Section 12.5.1, remove the unused "accept parameters"
(<https://github.com/httpwg/http-core/issues/568>)
o In Section 1.2, mention that RFC 1945 describes HTTP/0.9 as well
(<https://github.com/httpwg/http-core/issues/614>)
o In Section 14.5, describe non-standard use of the Content-Range
header field (Section 14.4) as a request modifier to perform a
partial PUT (<https://github.com/httpwg/http-core/issues/618>)
o In Section 15.5.20, import the 421 (Misdirected Request) status
code from [HTTP/2] (<https://github.com/httpwg/http-core/
issues/622>)
o In Section 2.3, rephrase the actual recipient parsing requirements
(<https://github.com/httpwg/http-core/issues/634>)
o In Section 16.1.2, mention request target forms in considerations
for new methods (<https://github.com/httpwg/http-core/issues/636>)
o Changed to using "content" instead of "payload" or "payload data"
to avoid confusion with the payload of version-specific messaging
frames (<https://github.com/httpwg/http-core/issues/654>)
o In Section 13.1.3, Section 13.1.4, and Section 13.1.5, specify
evaluation in a way similar to other conditional header fields
(<https://github.com/httpwg/http-core/issues/665>)
o In Section 6.6.1, specify that recipients can replace an invalid
Date header field value with the time received
(<https://github.com/httpwg/http-core/issues/669>)
C.16. Since draft-ietf-httpbis-semantics-14
o In Section 5.5, relax prohibition of characters in field values to
CR and NUL (<https://github.com/httpwg/http-core/issues/683>)
o In Section 15, clarify that status code values outside the range
100..599 are invalid, and recommend error handling
(<https://github.com/httpwg/http-core/issues/684>)
o In Section 2.2, replaced requirement on semantic conformance with
permission to ignore/workaround implementation-specific failures
(<https://github.com/httpwg/http-core/issues/687>)
o Avoid the term "whitelist" (<https://github.com/httpwg/http-core/
issues/688>)
o In Section 9.3.8, remove the normative requirement to use the
message/http media type (<https://github.com/httpwg/http-core/
issues/690>)
o In Section 7.6, discuss extensibility (<https://github.com/httpwg/
http-core/issues/692>)
o In Section 5.5, tighten the recommendation for characters in newly
defined fields, making it consistent with obs-text
(<https://github.com/httpwg/http-core/issues/696>)
o In Section 5.5, leading/trailing whitespace removal is at time of
use, not parsing (<https://github.com/httpwg/http-core/
issues/697>)
o In Section 6, clarify that HTTP self-descriptive messages have an
exception in that the request must be understood in order to parse
and interpret the response (<https://github.com/httpwg/http-core/
issues/700>)
o Remove "Canonicalization and Text Defaults"
(<https://github.com/httpwg/http-core/issues/703>)
o In Section 10.1.3, refine what can be sent in Referer, and when
(<https://github.com/httpwg/http-core/issues/709>)
o In Section 11.5, explain that the protection space is not defined
without additional information (<https://github.com/httpwg/http-
core/issues/710>)
o Simplify description of reactive content negotiation in
Section 12.2 (<https://github.com/httpwg/http-core/issues/712>)
o In Section 8.3.2, remove the "charset" ABNF production, and
clarify where charsets appear (<https://github.com/httpwg/http-
core/issues/713>)
o In Section 12.5.3, clarify that selection _between_ multiple
acceptable codings is only relevant when they have the same
purpose (<https://github.com/httpwg/http-core/issues/714>)
o In Section 13, rewrite introduction, mentioning extensibility
(<https://github.com/httpwg/http-core/issues/715>)
o Throughout, be consistent about 'content coding' vs 'content-
coding' (<https://github.com/httpwg/http-core/issues/719>)
o In Section 9.3.6, clarify that the port is mandatory in a CONNECT
request target (<https://github.com/httpwg/http-core/issues/736>)
and that the tunnel begins after the header section
(<https://github.com/httpwg/http-core/issues/737>)
o In Section 6.5, remove mid-stream trailers
(<https://github.com/httpwg/http-core/issues/740>)
o In Section 3.3, clarify duplexing semantics
(<https://github.com/httpwg/http-core/issues/741>)
o In Section 3.3, explain the implications of statelessness more
clearly (<https://github.com/httpwg/http-core/issues/743>)
o In Section 8.6, be more explicit about invalid and incorrect
values (<https://github.com/httpwg/http-core/issues/748> and
<https://github.com/httpwg/http-core/issues/749>)
o Move discussion of statelessness from Section 3.7 to Section 3.3
(<https://github.com/httpwg/http-core/issues/753>)
o In Section 15.2.2, clarify that the upgraded protocol is in effect
after the 101 response (<https://github.com/httpwg/http-core/
issues/776>)
o In Section 9.3.6, state that data received after the headers of a
CONNECT message is version-specific (<https://github.com/httpwg/
http-core/issues/780>)
o In Section 4.2.3, clarify how normalization works, and align with
RF3986 (<https://github.com/httpwg/http-core/issues/788>)
o In Section 6.6.2, note that the Trailer field can be used to
discover deleted trailers (<https://github.com/httpwg/http-core/
issues/793>)
o Throughout, remove unneeded normative references to [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/795>)
o In Section 10.1.4, explicitly require listing in Connection
(<https://github.com/httpwg/http-core/issues/809>)
C.17. Since draft-ietf-httpbis-semantics-15
o For [HTTP/3], add an RFC Editor note to rename to "RFCnnn" before
publication (<https://github.com/httpwg/http-core/issues/815>)
o In Section 9.3.2, align prose about content in HEAD requests with
description of GET (<https://github.com/httpwg/http-core/
issues/826>)
o In Section 5.3, remove the restriction to non-empty field line
values (<https://github.com/httpwg/http-core/issues/836>)
o Add forward references to definition of OWS
(<https://github.com/httpwg/http-core/issues/841>)
o In Section 17.10, add a security consideration regarding
application handling of field names (<https://github.com/httpwg/
http-core/issues/843>)
C.18. Since draft-ietf-httpbis-semantics-16
This draft addresses mostly editorial issues raised during or past C.1. Since draft-ietf-httpbis-semantics-19
IETF Last Call; see <https://github.com/httpwg/http-core/
issues?q=label%3Asemantics+created%3A%3E2021-05-26> for a summary.
This (unpublished) draft contains changes that were made after draft
19 was approved by the IESG. Most changes are editorial only.
Furthermore: Furthermore:
o In Section 15.3.7, reinstate 'to a request' o In Section 16.3.1, add states 'obsoleted' and 'deprecated'; in
(<https://github.com/httpwg/http-core/issues/857>) Section 18.4, change status 'standard' to 'permanent'
(<https://github.com/httpwg/http-core/issues/978>)
o Align Section 16.3.1 with Section 16.3.2.1
(<https://github.com/httpwg/http-core/issues/857>)
o In Section 14.3, clarify that Accept-Ranges can be sent by any
server, remove "none" from the ABNF because it is now a reserved
range unit, and allow the field to be sent in a trailer section
while noting why that is much less useful than as a header field
(<https://github.com/httpwg/http-core/issues/857>)
o In Section 7.6.3, don't specify TCP (<https://github.com/httpwg/
http-core/issues/865>)
o In Section 6.4, explain the "Content-" prefix
(<https://github.com/httpwg/http-core/issues/878>)
o In Section 7.4, check all target URIs for scheme semantic
mismatches (<https://github.com/httpwg/http-core/issues/896>)
o In Section 9.3.1, Section 9.3.2, and Section 9.3.5, clarify
(again) that sending content in a request for a method that does
not define such content will not interoperate without prior
agreement, even if it is parsed correctly, and cannot be relied
upon by an origin server unless they control the entire request
chain (<https://github.com/httpwg/http-core/issues/904>)
C.19. Since draft-ietf-httpbis-semantics-17
o Move ABNF for obs-text into Section 5.5
(<https://github.com/httpwg/http-core/issues/914>)
o In Section 6.4.1, note that response metadata can be relevant as
well (<https://github.com/httpwg/http-core/issues/914>)
o In Section 6.6.2, use the term "signature" througout and lower
expectations on what Trailer indicates without a trailer section
(<https://github.com/httpwg/http-core/issues/914>)
o In Section 8.3, cleanup mime sniffing discussion
(<https://github.com/httpwg/http-core/issues/914>)
o In Section 10.1.4, add a forward reference to "weight"
(<https://github.com/httpwg/http-core/issues/914>)
o In Section 12.5.3, clarify that the examples contains multiple
values; also remove obsolete HTTP/1.0 note about qvalues
(<https://github.com/httpwg/http-core/issues/914>)
o In Section 15.4, remove incorrect mention of Etag as request field
(<https://github.com/httpwg/http-core/issues/914>)
o Move text about obs-fold in message/http to [HTTP/1.1]; also note
that LF is forbidden in field values just as CR and NUL
(<https://github.com/httpwg/http-core/issues/923>)
o In Section 7.7, properly refer to text that has moved to
[HTTP/1.1] (<https://github.com/httpwg/http-core/issues/930>)
o Rewrite description of validators and move cache-related aspects
into [CACHING] (<https://github.com/httpwg/http-core/issues/933>)
o In Section 12.5.5, rephrase description to be more explanatory
(<https://github.com/httpwg/http-core/issues/938>)
o In Section 13.2.2, clarify that a false If-Range means ignore the
Range (<https://github.com/httpwg/http-core/issues/940>)
o In Section 13.1.3 and Section 13.1.4, restore text about missing
modification date (<https://github.com/httpwg/http-core/
issues/942>)
o In Section 5.6.1.1, avoid duplicate normative requirement
(<https://github.com/httpwg/http-core/issues/943>)
o In Section 8.8.2.1, reference 'Date' more visibly
(<https://github.com/httpwg/http-core/issues/945>)
o In Section 11.7.3, state that Proxy-Authentication-Info can be
used as trailer (<https://github.com/httpwg/http-core/issues/946>)
o In Section 15.4, slightly clarify history of redirect status codes
(<https://github.com/httpwg/http-core/issues/947>)
o In Section 16.3.1, fix requirements for provisional registrations
(<https://github.com/httpwg/http-core/issues/950>)
o In Section 4.3, explicitly refer to how this spec defines access
to http or https resources (<https://github.com/httpwg/http-core/
issues/951>)
o In Section 6.6.1, make clock a defined term and use that
definition throughout the spec (<https://github.com/httpwg/http-
core/issues/953>)
o In Section 13.1, make preconditions consistent on when they are
required to be evaluated (<https://github.com/httpwg/http-core/
issues/954>)
o Throughout, disambiguate "selected representation" and "selected
response" (now "chosen response") (<https://github.com/httpwg/
http-core/issues/958>)
C.20. Since draft-ietf-httpbis-semantics-18
o In Section 12.5.1, align text about "q" parameter with recent
changes to IANA media types registry, and instruct IANA to
reference this document with respect to the "q" special case
(<https://github.com/httpwg/http-core/issues/970>)
o In Section 18.4, rephrase text about the relation with [RFC3864]
(<https://github.com/httpwg/http-core/pull/973>)
o In Section 3.7, avoid bare "for the sake of security"
(<https://github.com/httpwg/http-core/pull/974>)
o In Section 12.2, wordsmith future guidance on reactive negotiation
(<https://github.com/httpwg/http-core/pull/975>)
o In Section 15.4.2 and Section 15.4.9, improve text about automatic o In Section 12.5.3, slightly relax requirements for handling
link-editing (<https://github.com/httpwg/http-core/pull/976>) Accept-Encoding field values (<https://github.com/httpwg/http-
core/issues/980>)
o In Section 17, reference [URI] security considerations o In Section 18.4, update IANA instructions based on received
(<https://github.com/httpwg/http-core/pull/977>) feedback (<https://github.com/httpwg/http-core/issues/982>)
Acknowledgements Acknowledgements
Aside from the current editors, the following individuals deserve Aside from the current editors, the following individuals deserve
special recognition for their contributions to early aspects of HTTP special recognition for their contributions to early aspects of HTTP
and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert
Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys, Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys,
Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery
L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott
D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry
Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris, Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris,
Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders, Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders,
Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles. Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles.
This edition builds on the many contributions that went into past This edition builds on the many contributions that went into past
specifications of HTTP, including RFC 1945, RFC 2068, RFC 2145, RFC specifications of HTTP, including RFC 1945, RFC 2068, RFC 2145, RFC
2616, RFC 2617, RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 2616, RFC 2617, RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC
skipping to change at page 239, line 4 skipping to change at page 220, line 4
browser Section 3.5 browser Section 3.5
C C
CONNECT method Section 9.3.6 CONNECT method Section 9.3.6
Connection header field Section 7.6.1 Connection header field Section 7.6.1
Content-Encoding header field Section 8.4 Content-Encoding header field Section 8.4
Content-Language header field Section 8.5 Content-Language header field Section 8.5
Content-Length header field Section 8.6 Content-Length header field Section 8.6
Content-Location header field Section 8.7 Content-Location header field Section 8.7
Content-MD5 header field Section 18.4, Paragraph 9 Content-MD5 header field Section 18.4, Paragraph 10
Content-Range header field Section 14.4; Section 14.5 Content-Range header field Section 14.4; Section 14.5
Content-Type header field Section 8.3 Content-Type header field Section 8.3
cache Section 3.8 cache Section 3.8
cacheable Section 3.8, Paragraph 4 cacheable Section 3.8, Paragraph 4
client Section 3.3 client Section 3.3
clock Section 5.6.7 clock Section 5.6.7
complete Section 6.1 complete Section 6.1
compress (Coding Format) Section 8.4.1.1 compress (Coding Format) Section 8.4.1.1
compress (content coding) Section 8.4.1 compress (content coding) Section 8.4.1
conditional request Section 13 conditional request Section 13
skipping to change at page 239, line 39 skipping to change at page 220, line 39
E E
ETag field Section 8.8.3 ETag field Section 8.8.3
Expect header field Section 10.1.1 Expect header field Section 10.1.1
effective request URI Section 7.1, Paragraph 8.1 effective request URI Section 7.1, Paragraph 8.1
F F
Fields Fields
* Section 18.4, Paragraph 8 * Section 18.4, Paragraph 9
Accept Section 12.5.1 Accept Section 12.5.1
Accept-Charset Section 12.5.2 Accept-Charset Section 12.5.2
Accept-Encoding Section 12.5.3 Accept-Encoding Section 12.5.3
Accept-Language Section 12.5.4 Accept-Language Section 12.5.4
Accept-Ranges Section 14.3 Accept-Ranges Section 14.3
Allow Section 10.2.1 Allow Section 10.2.1
Authentication-Info Section 11.6.3 Authentication-Info Section 11.6.3
Authorization Section 11.6.2 Authorization Section 11.6.2
Connection Section 7.6.1 Connection Section 7.6.1
Content-Encoding Section 8.4 Content-Encoding Section 8.4
Content-Language Section 8.5 Content-Language Section 8.5
Content-Length Section 8.6 Content-Length Section 8.6
Content-Location Section 8.7 Content-Location Section 8.7
Content-MD5 Section 18.4, Paragraph 9 Content-MD5 Section 18.4, Paragraph 10
Content-Range Section 14.4; Section 14.5 Content-Range Section 14.4; Section 14.5
Content-Type Section 8.3 Content-Type Section 8.3
Date Section 6.6.1 Date Section 6.6.1
ETag Section 8.8.3 ETag Section 8.8.3
Expect Section 10.1.1 Expect Section 10.1.1
From Section 10.1.2 From Section 10.1.2
Host Section 7.2 Host Section 7.2
If-Match Section 13.1.1 If-Match Section 13.1.1
If-Modified-Since Section 13.1.3 If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2 If-None-Match Section 13.1.2
skipping to change at page 244, line 23 skipping to change at page 225, line 23
Accept-Language Section 12.5.4 Accept-Language Section 12.5.4
Accept-Ranges Section 14.3 Accept-Ranges Section 14.3
Allow Section 10.2.1 Allow Section 10.2.1
Authentication-Info Section 11.6.3 Authentication-Info Section 11.6.3
Authorization Section 11.6.2 Authorization Section 11.6.2
Connection Section 7.6.1 Connection Section 7.6.1
Content-Encoding Section 8.4 Content-Encoding Section 8.4
Content-Language Section 8.5 Content-Language Section 8.5
Content-Length Section 8.6 Content-Length Section 8.6
Content-Location Section 8.7 Content-Location Section 8.7
Content-MD5 Section 18.4, Paragraph 9 Content-MD5 Section 18.4, Paragraph 10
Content-Range Section 14.4; Section 14.5 Content-Range Section 14.4; Section 14.5
Content-Type Section 8.3 Content-Type Section 8.3
Date Section 6.6.1 Date Section 6.6.1
ETag Section 8.8.3 ETag Section 8.8.3
Expect Section 10.1.1 Expect Section 10.1.1
From Section 10.1.2 From Section 10.1.2
Host Section 7.2 Host Section 7.2
If-Match Section 13.1.1 If-Match Section 13.1.1
If-Modified-Since Section 13.1.3 If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2 If-None-Match Section 13.1.2
skipping to change at page 248, line 28 skipping to change at page 229, line 28
Adobe Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
United States of America United States of America
Email: fielding@gbiv.com Email: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
Prahran VIC Prahran
Australia Australia
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian Reschke (editor) Julian Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
48155 Münster 48155 Münster
Germany Germany
 End of changes. 233 change blocks. 
1433 lines changed or deleted 500 lines changed or added

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