draft-ietf-httpbis-semantics-16.txt   draft-ietf-httpbis-semantics-17.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: 28 November 2021 27 May 2021 Expires: 27 January 2022 26 July 2021
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-16 draft-ietf-httpbis-semantics-17
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.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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.17. The changes in this draft are summarized in Appendix C.18.
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 28 November 2021. This Internet-Draft will expire on 27 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 49 skipping to change at page 2, line 49
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 . . . . . . . . . . . . . . . . . . . . . 11
1.4. Specifications Obsoleted by this Document . . . . . . . . 11 1.4. Specifications Obsoleted by this Document . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . 13
2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 14 2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 14
2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 15 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 15
2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15 2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15
3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16 3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16
3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17 3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17
3.3. Connections, Clients and Servers . . . . . . . . . . . . 17 3.3. Connections, Clients and Servers . . . . . . . . . . . . 17
skipping to change at page 3, line 24 skipping to change at page 3, line 24
3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 20 3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 20
3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22 3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22
4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 23 4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 23
4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23 4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23
4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 24 4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 24
4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 25 4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 25
4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25 4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25
4.2.3. http(s) Normalization and Comparison . . . . . . . . 26 4.2.3. http(s) Normalization and Comparison . . . . . . . . 26
4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27 4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27
4.2.5. http(s) References with Fragment Identifiers . . . . 27 4.2.5. http(s) References with Fragment Identifiers . . . . 28
4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28 4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28
4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28 4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28
4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 29 4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 29
4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 30 4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 30
4.3.4. https certificate verification . . . . . . . . . . . 31 4.3.4. https certificate verification . . . . . . . . . . . 31
4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 32 4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 32
5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 32 5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Field Lines and Combined Field Value . . . . . . . . . . 33 5.2. Field Lines and Combined Field Value . . . . . . . . . . 34
5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 34 5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 34
5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 35 5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 35
5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 35 5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 35
5.6. Common Rules for Defining Field Values . . . . . . . . . 37 5.6. Common Rules for Defining Field Values . . . . . . . . . 37
5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 37 5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 37
5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 37 5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 38
5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 38 5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 38
5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 38 5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 39
5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 39 5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 39
5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 39 5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 40
5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 40 5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 40
5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 40 5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 41
5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 41 5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 41
6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 43 6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 43
6.1. Framing and Completeness . . . . . . . . . . . . . . . . 44 6.1. Framing and Completeness . . . . . . . . . . . . . . . . 44
6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 45 6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 45
6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 46 6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 46
6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 46 6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 47
6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 47 6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 48
6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 48 6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 49
6.5.1. Limitations on use of Trailers . . . . . . . . . . . 49 6.5.1. Limitations on use of Trailers . . . . . . . . . . . 49
6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 50 6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 50
7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 50 7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 51
7.1. Determining the Target Resource . . . . . . . . . . . . . 50 7.1. Determining the Target Resource . . . . . . . . . . . . . 51
7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 51 7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 52
7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 52 7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 52
7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 52 7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 52
7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 52 7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 53
7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 52 7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 53
7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 53 7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 53
7.5. Response Correlation . . . . . . . . . . . . . . . . . . 53 7.5. Response Correlation . . . . . . . . . . . . . . . . . . 54
7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 54 7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 54
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 54 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 55
7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 56 7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 56
7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.7. Message Transformations . . . . . . . . . . . . . . . . . 58 7.7. Message Transformations . . . . . . . . . . . . . . . . . 59
7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 60
8. Representation Data and Metadata . . . . . . . . . . . . . . 62 8. Representation Data and Metadata . . . . . . . . . . . . . . 62
8.1. Representation Data . . . . . . . . . . . . . . . . . . . 62 8.1. Representation Data . . . . . . . . . . . . . . . . . . . 62
8.2. Representation Metadata . . . . . . . . . . . . . . . . . 62 8.2. Representation Metadata . . . . . . . . . . . . . . . . . 62
8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 62 8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 63
8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 63 8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 64
8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 64 8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 64
8.3.3. Multipart Types . . . . . . . . . . . . . . . . . . . 64 8.3.3. Multipart Types . . . . . . . . . . . . . . . . . . . 65
8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 65 8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 65
8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 66 8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 66
8.4.1.1. Compress Coding . . . . . . . . . . . . . . . . . 66 8.4.1.1. Compress Coding . . . . . . . . . . . . . . . . . 67
8.4.1.2. Deflate Coding . . . . . . . . . . . . . . . . . 66 8.4.1.2. Deflate Coding . . . . . . . . . . . . . . . . . 67
8.4.1.3. Gzip Coding . . . . . . . . . . . . . . . . . . . 67 8.4.1.3. Gzip Coding . . . . . . . . . . . . . . . . . . . 67
8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 67 8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 67
8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 68 8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 68
8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 68 8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 69
8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 70 8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 70
8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 72 8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 72
8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 72 8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 73
8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 74 8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 74
8.8.2.1. Generation . . . . . . . . . . . . . . . . . . . 74 8.8.2.1. Generation . . . . . . . . . . . . . . . . . . . 75
8.8.2.2. Comparison . . . . . . . . . . . . . . . . . . . 75 8.8.2.2. Comparison . . . . . . . . . . . . . . . . . . . 75
8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 76 8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 76
8.8.3.1. Generation . . . . . . . . . . . . . . . . . . . 77 8.8.3.1. Generation . . . . . . . . . . . . . . . . . . . 77
8.8.3.2. Comparison . . . . . . . . . . . . . . . . . . . 77 8.8.3.2. Comparison . . . . . . . . . . . . . . . . . . . 78
8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated 8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated
Resources . . . . . . . . . . . . . . . . . . . . . 78 Resources . . . . . . . . . . . . . . . . . . . . . 78
8.8.4. When to Use Entity-Tags and Last-Modified Dates . . . 79 8.8.4. When to Use Entity-Tags and Last-Modified Dates . . . 79
9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 80 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 80
9.2. Common Method Properties . . . . . . . . . . . . . . . . 82 9.2. Common Method Properties . . . . . . . . . . . . . . . . 83
9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 82 9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 83
9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 83 9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 84
9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 84 9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 85
9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 84 9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 85
9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 84 9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 85 9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 86
9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 86 9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 87
9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 87 9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 90 9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 91
9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 91 9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 93
9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 92 9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 94
9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 93 9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 95
10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 94 10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 96
10.1. Request Context Fields . . . . . . . . . . . . . . . . . 94 10.1. Request Context Fields . . . . . . . . . . . . . . . . . 96
10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 94 10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 96
10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 96 10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 98
10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 97 10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 99
10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 98 10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 99 10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 101
10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 99 10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 101
10.2. Response Context Fields . . . . . . . . . . . . . . . . 100 10.2. Response Context Fields . . . . . . . . . . . . . . . . 102
10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 101 10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 102
10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 101 10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 103
10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 102 10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 104
10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 104 10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 105
10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 104 10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 106
11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 105 11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 106
11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 105 11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 106
11.2. Authentication Parameters . . . . . . . . . . . . . . . 105 11.2. Authentication Parameters . . . . . . . . . . . . . . . 107
11.3. Challenge and Response . . . . . . . . . . . . . . . . . 106 11.3. Challenge and Response . . . . . . . . . . . . . . . . . 107
11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 107 11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 108
11.5. Establishing a Protection Space (Realm) . . . . . . . . 107 11.5. Establishing a Protection Space (Realm) . . . . . . . . 109
11.6. Authenticating Users to Origin Servers . . . . . . . . . 108 11.6. Authenticating Users to Origin Servers . . . . . . . . . 110
11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 108 11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 110
11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 109 11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 111
11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 110 11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 111
11.7. Authenticating Clients to Proxies . . . . . . . . . . . 110 11.7. Authenticating Clients to Proxies . . . . . . . . . . . 112
11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 110 11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 112
11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 111 11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 112
11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 111 11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 113
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 112 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 113
12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 113 12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 114
12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 114 12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 115
12.3. Request Content Negotiation . . . . . . . . . . . . . . 115 12.3. Request Content Negotiation . . . . . . . . . . . . . . 116
12.4. Content Negotiation Field Features . . . . . . . . . . . 115 12.4. Content Negotiation Field Features . . . . . . . . . . . 116
12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 115 12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 117
12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 115 12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 117
12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 116 12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 118
12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 116 12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 118
12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 116 12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 118
12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 119 12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 120
12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 119 12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 121
12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 121 12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 123
12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 122 12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 124
13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 124 13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 125
13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 124 13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 126
13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 125 13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 126
13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 126 13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 128
13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 128 13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 130
13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 130 13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 131
13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 131 13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 133
13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 132 13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 134
13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 133 13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 134
13.2.2. Precedence of Preconditions . . . . . . . . . . . . 133 13.2.2. Precedence of Preconditions . . . . . . . . . . . . 135
14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 135 14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 137
14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 135 14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 137
14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 136 14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 138
14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 137 14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 139
14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 138 14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 140
14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 140 14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 142
14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 140 14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 143
14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 142 14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 145
14.6. Media Type multipart/byteranges . . . . . . . . . . . . 143 14.6. Media Type multipart/byteranges . . . . . . . . . . . . 145
15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 145 15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 147
15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 146 15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 148
15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 146 15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 149
15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 147 15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 149
15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 147 15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 149
15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 147 15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 150
15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 148 15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 150
15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 148 15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 151
15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 149 15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 151
15.3.4. 203 Non-Authoritative Information . . . . . . . . . 149 15.3.4. 203 Non-Authoritative Information . . . . . . . . . 151
15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 149 15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 152
15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 150 15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 152
15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 150 15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 153
15.3.7.1. Single Part . . . . . . . . . . . . . . . . . . 151 15.3.7.1. Single Part . . . . . . . . . . . . . . . . . . 154
15.3.7.2. Multiple Parts . . . . . . . . . . . . . . . . . 152 15.3.7.2. Multiple Parts . . . . . . . . . . . . . . . . . 154
15.3.7.3. Combining Parts . . . . . . . . . . . . . . . . 153 15.3.7.3. Combining Parts . . . . . . . . . . . . . . . . 156
15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 154 15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 156
15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 156 15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 159
15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 157 15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 160
15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 157 15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 160
15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 158 15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 161
15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 159 15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 161
15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 159 15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 162
15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 159 15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 162
15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 160 15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 162
15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 160 15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 163
15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 160 15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 163
15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 161 15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 163
15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 161 15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 163
15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 161 15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 164
15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 161 15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 164
15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 162 15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 164
15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 162 15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 165
15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 162 15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 165
15.5.8. 407 Proxy Authentication Required . . . . . . . . . 163 15.5.8. 407 Proxy Authentication Required . . . . . . . . . 165
15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 163 15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 165
15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 163 15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 166
15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 163 15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 166
15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 164 15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 166
15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 164 15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 167
15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 164 15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 167
15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 165 15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 167
15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 165 15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 167
15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 165 15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 168
15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 166 15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 168
15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 166 15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 169
15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 167 15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 169
15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 167 15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 169
15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 167 15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 169
15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 168 15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 170
15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 168 15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 170
15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 168 15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 170
15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 168 15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 170
15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 168 15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 171
15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 169 15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 171
15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 169 15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 171
16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 169 16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 171
16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 170 16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 172
16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 170 16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 172
16.1.2. Considerations for New Methods . . . . . . . . . . . 170 16.1.2. Considerations for New Methods . . . . . . . . . . . 172
16.2. Status Code Extensibility . . . . . . . . . . . . . . . 171 16.2. Status Code Extensibility . . . . . . . . . . . . . . . 173
16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 171 16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 173
16.2.2. Considerations for New Status Codes . . . . . . . . 171 16.2.2. Considerations for New Status Codes . . . . . . . . 174
16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 172 16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 175
16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 173 16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 175
16.3.2. Considerations for New Fields . . . . . . . . . . . 174 16.3.2. Considerations for New Fields . . . . . . . . . . . 176
16.3.2.1. Considerations for New Field Names . . . . . . . 175 16.3.2.1. Considerations for New Field Names . . . . . . . 177
16.3.2.2. Considerations for New Field Values . . . . . . 176 16.3.2.2. Considerations for New Field Values . . . . . . 178
16.4. Authentication Scheme Extensibility . . . . . . . . . . 176 16.4. Authentication Scheme Extensibility . . . . . . . . . . 179
16.4.1. Authentication Scheme Registry . . . . . . . . . . . 177 16.4.1. Authentication Scheme Registry . . . . . . . . . . . 179
16.4.2. Considerations for New Authentication Schemes . . . 177 16.4.2. Considerations for New Authentication Schemes . . . 179
16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 178 16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 181
16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 179 16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 181
16.5.2. Considerations for New Range Units . . . . . . . . . 179 16.5.2. Considerations for New Range Units . . . . . . . . . 181
16.6. Content Coding Extensibility . . . . . . . . . . . . . . 179 16.6. Content Coding Extensibility . . . . . . . . . . . . . . 181
16.6.1. Content Coding Registry . . . . . . . . . . . . . . 179 16.6.1. Content Coding Registry . . . . . . . . . . . . . . 181
16.6.2. Considerations for New Content Codings . . . . . . . 180 16.6.2. Considerations for New Content Codings . . . . . . . 182
16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 180 16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 182
17. Security Considerations . . . . . . . . . . . . . . . . . . . 181 17. Security Considerations . . . . . . . . . . . . . . . . . . . 183
17.1. Establishing Authority . . . . . . . . . . . . . . . . . 181 17.1. Establishing Authority . . . . . . . . . . . . . . . . . 183
17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 182 17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 184
17.3. Attacks Based on File and Path Names . . . . . . . . . . 183 17.3. Attacks Based on File and Path Names . . . . . . . . . . 185
17.4. Attacks Based on Command, Code, or Query Injection . . . 183 17.4. Attacks Based on Command, Code, or Query Injection . . . 185
17.5. Attacks via Protocol Element Length . . . . . . . . . . 184 17.5. Attacks via Protocol Element Length . . . . . . . . . . 186
17.6. Attacks using Shared-dictionary Compression . . . . . . 184 17.6. Attacks using Shared-dictionary Compression . . . . . . 187
17.7. Disclosure of Personal Information . . . . . . . . . . . 185 17.7. Disclosure of Personal Information . . . . . . . . . . . 187
17.8. Privacy of Server Log Information . . . . . . . . . . . 185 17.8. Privacy of Server Log Information . . . . . . . . . . . 187
17.9. Disclosure of Sensitive Information in URIs . . . . . . 186 17.9. Disclosure of Sensitive Information in URIs . . . . . . 188
17.10. Application Handling of Field Names . . . . . . . . . . 186 17.10. Application Handling of Field Names . . . . . . . . . . 188
17.11. Disclosure of Fragment after Redirects . . . . . . . . . 187 17.11. Disclosure of Fragment after Redirects . . . . . . . . . 189
17.12. Disclosure of Product Information . . . . . . . . . . . 188 17.12. Disclosure of Product Information . . . . . . . . . . . 190
17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 188 17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 190
17.14. Validator Retention . . . . . . . . . . . . . . . . . . 189 17.14. Validator Retention . . . . . . . . . . . . . . . . . . 191
17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 189 17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 191
17.16. Authentication Considerations . . . . . . . . . . . . . 190 17.16. Authentication Considerations . . . . . . . . . . . . . 192
17.16.1. Confidentiality of Credentials . . . . . . . . . . 190 17.16.1. Confidentiality of Credentials . . . . . . . . . . 192
17.16.2. Credentials and Idle Clients . . . . . . . . . . . 190 17.16.2. Credentials and Idle Clients . . . . . . . . . . . 192
17.16.3. Protection Spaces . . . . . . . . . . . . . . . . . 191 17.16.3. Protection Spaces . . . . . . . . . . . . . . . . . 193
17.16.4. Additional Response Fields . . . . . . . . . . . . 191 17.16.4. Additional Response Fields . . . . . . . . . . . . 193
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 191 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 193
18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 192 18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 194
18.2. Method Registration . . . . . . . . . . . . . . . . . . 192 18.2. Method Registration . . . . . . . . . . . . . . . . . . 194
18.3. Status Code Registration . . . . . . . . . . . . . . . . 192 18.3. Status Code Registration . . . . . . . . . . . . . . . . 194
18.4. Field Name Registration . . . . . . . . . . . . . . . . 195 18.4. Field Name Registration . . . . . . . . . . . . . . . . 197
18.5. Authentication Scheme Registration . . . . . . . . . . . 197 18.5. Authentication Scheme Registration . . . . . . . . . . . 199
18.6. Content Coding Registration . . . . . . . . . . . . . . 198 18.6. Content Coding Registration . . . . . . . . . . . . . . 200
18.7. Range Unit Registration . . . . . . . . . . . . . . . . 198 18.7. Range Unit Registration . . . . . . . . . . . . . . . . 200
18.8. Media Type Registration . . . . . . . . . . . . . . . . 199 18.8. Media Type Registration . . . . . . . . . . . . . . . . 201
18.9. Port Registration . . . . . . . . . . . . . . . . . . . 199 18.9. Port Registration . . . . . . . . . . . . . . . . . . . 201
18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 199 18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 201
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 199 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 201
19.1. Normative References . . . . . . . . . . . . . . . . . . 199 19.1. Normative References . . . . . . . . . . . . . . . . . . 201
19.2. Informative References . . . . . . . . . . . . . . . . . 201 19.2. Informative References . . . . . . . . . . . . . . . . . 203
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 208 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 210
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 212 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 214
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 212 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 214
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 213 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 214
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 213 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 215
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 215 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 217
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 216 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 218
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 216 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 218
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 216 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 218
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 216 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 218
B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 216 B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 218
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 216 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 218
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 216 C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 218
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 217 C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 219
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 217 C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 219
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 219 C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 221
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 220 C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 222
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 220 C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 222
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 221 C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 223
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 222 C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 224
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 224 C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 226
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 225 C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 227
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 226 C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 228
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 226 C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 228
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 228 C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 230
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 228 C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 230
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 230 C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 232
C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 231 C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 233
C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 233 C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 235
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 234 C.18. Since draft-ietf-httpbis-semantics-16 . . . . . . . . . . 236
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 236
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 246 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 29 skipping to change at page 10, line 39
1.2. History and Evolution 1.2. History and Evolution
HTTP has been the primary information transfer protocol for the World HTTP has been the primary information transfer protocol for the World
Wide Web since its introduction in 1990. It began as a trivial Wide Web since its introduction in 1990. It began as a trivial
mechanism for low-latency requests, with a single method (GET) to mechanism for low-latency requests, with a single method (GET) to
request transfer of a presumed hypertext document identified by a request transfer of a presumed hypertext document identified by a
given pathname. As the Web grew, HTTP was extended to enclose given pathname. As the Web grew, HTTP was extended to enclose
requests and responses within messages, transfer arbitrary data requests and responses within messages, transfer arbitrary data
formats using MIME-like media types, and route requests through formats using MIME-like media types, and route requests through
intermediaries. These protocols were eventually defined as HTTP/0.9 intermediaries. These protocols were eventually defined as HTTP/0.9
and HTTP/1.0 (see [RFC1945]). 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] - [RFC7235]).
HTTP/2 ([RFC7540]) 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
([HTTP3]) 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
use. Implementations are expected to choose the most appropriate use. Implementations are expected to choose the most appropriate
transport and messaging syntax for their particular context. transport and messaging syntax for their particular context.
This revision of HTTP separates the definition of semantics (this This revision of HTTP separates the definition of semantics (this
document) and caching ([Caching]) from the current HTTP/1.1 messaging document) and caching ([CACHING]) from the current HTTP/1.1 messaging
syntax ([Messaging]) to allow each major protocol version to progress syntax ([HTTP/1.1]) to allow each major protocol version to progress
independently while referring to the same core semantics. independently while referring to the same core semantics.
1.3. Core Semantics 1.3. Core Semantics
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 3.1) - regardless of its type, nature, or implementation - (Section 3.1) - regardless of its type, nature, or implementation -
by sending messages that manipulate or transfer representations by sending messages that manipulate or transfer representations
(Section 3.2). (Section 3.2).
Each message is either a request or a response. A client constructs Each message is either a request or a response. A client constructs
skipping to change at page 12, line 33 skipping to change at page 12, line 37
| Authentication-Info Response Header Fields | | | | Authentication-Info Response Header Fields | | |
+--------------------------------------------+-----------+---------+ +--------------------------------------------+-----------+---------+
| HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 | | HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 |
+--------------------------------------------+-----------+---------+ +--------------------------------------------+-----------+---------+
Table 1 Table 1
[*] This document only obsoletes the portions of RFC 7230 that are [*] This document only obsoletes the portions of RFC 7230 that are
independent of the HTTP/1.1 messaging syntax and connection independent of the HTTP/1.1 messaging syntax and connection
management; the remaining bits of RFC 7230 are obsoleted by management; the remaining bits of RFC 7230 are obsoleted by
"HTTP/1.1" [Messaging]. "HTTP/1.1" [HTTP/1.1].
2. Conformance 2. Conformance
2.1. Syntax Notation 2.1. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 5.6.1, that allows It also uses a list extension, defined in Section 5.6.1, that allows
skipping to change at page 13, line 32 skipping to change at page 13, line 35
"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
of a participant in HTTP communication. Hence, requirements are of a participant in HTTP communication. Hence, requirements are
placed on senders, recipients, clients, servers, user agents, placed on senders, recipients, clients, servers, user agents,
intermediaries, origin servers, proxies, gateways, or caches, intermediaries, origin servers, proxies, gateways, or caches,
depending on what behavior is being constrained by the requirement. depending on what behavior is being constrained by the requirement.
Additional (social) requirements are placed on implementations, Additional requirements are placed on implementations, resource
resource owners, and protocol element registrations when they apply owners, and protocol element registrations when they apply beyond the
beyond the scope of a single communication. scope of a single communication.
The verb "generate" is used instead of "send" where a requirement The verb "generate" is used instead of "send" where a requirement
applies only to implementations that create the protocol element, applies only to implementations that create the protocol element,
rather than an implementation that forwards a received element rather than an implementation that forwards a received element
downstream. downstream.
An implementation is considered conformant if it complies with all of An implementation is considered conformant if it complies with all of
the requirements associated with the roles it partakes in HTTP. the requirements associated with the roles it partakes in HTTP.
A sender MUST NOT generate protocol elements that do not match the A sender MUST NOT generate protocol elements that do not match the
skipping to change at page 15, line 50 skipping to change at page 15, line 50
the expression of them "on the wire" can change, and so the HTTP the expression of them "on the wire" can change, and so the HTTP
version number changes when incompatible changes are made to the wire version number changes when incompatible changes are made to the wire
format. Additionally, HTTP allows incremental, backwards-compatible format. Additionally, HTTP allows incremental, backwards-compatible
changes to be made to the protocol without changing its version changes to be made to the protocol without changing its version
through the use of defined extension points (Section 16). through the 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 of HTTP. For example, the version "HTTP/1.1" is
defined by the combined specifications of this document, "HTTP defined by the combined specifications of this document, "HTTP
Caching" [Caching], and "HTTP/1.1" [Messaging]. Caching" [CACHING], 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
(by clients). (by clients).
When a major version of HTTP does not define any minor versions, the When a major version of HTTP does not define any minor versions, the
minor version "0" is implied and is used when referring to that minor version "0" is implied. The "0" is used when referring to that
protocol within a protocol element that requires sending a minor protocol within elements that require a minor version identifier.
version.
3. Terminology and Core Concepts 3. Terminology and Core Concepts
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP. terminology used to define HTTP.
3.1. Resources 3.1. Resources
The target of an HTTP request is called a _resource_. HTTP does not The target of an HTTP request is called a _resource_. HTTP does not
limit the nature of a resource; it merely defines an interface that limit the nature of a resource; it merely defines an interface that
might be used to interact with resources. Most resources are might be used to interact with resources. Most resources are
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 4. Section 4.
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 9) and a few request- semantics in the request method (Section 9) and a few request-
modifying header fields. A resource cannot treat a request in a modifying header fields. A resource cannot treat a request in a
manner inconsistent with the semantics of the method of the request. manner inconsistent with the semantics of the method of the request.
For example, though the URI of a resource might imply semantics that For example, though the URI of a resource might imply semantics that
are not safe, a client can expect the resource to avoid actions that are not safe, a client can expect the resource to avoid actions that
are unsafe when processing a request with a safe method (see are unsafe when processing a request with a safe method (see
Section 9.2.1). Section 9.2.1).
HTTP relies upon the Uniform Resource Identifier (URI) standard HTTP relies upon the Uniform Resource Identifier (URI) standard [URI]
[RFC3986] to indicate the target resource (Section 7.1) and to indicate the target resource (Section 7.1) and relationships
relationships between resources. between resources.
3.2. Representations 3.2. Representations
A _representation_ is information that is intended to reflect a past, A _representation_ is information that is intended to reflect a past,
current, or desired state of a given resource, in a format that can current, or desired state of a given resource, in a format that can
be readily communicated via the protocol. A representation consists be readily communicated via the protocol. A representation consists
of a set of representation metadata and a potentially unbounded of a set of representation metadata and a potentially unbounded
stream of representation data (Section 8). stream of representation data (Section 8).
HTTP allows "information hiding" behind its uniform interface by HTTP allows "information hiding" behind its uniform interface by
skipping to change at page 21, line 31 skipping to change at page 21, line 31
However, an HTTP-to-HTTP gateway that wishes to interoperate with However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers needs to conform to user agent requirements third-party HTTP servers needs to conform to user agent requirements
on the gateway's inbound connection. on the gateway's inbound connection.
A _tunnel_ acts as a blind relay between two connections without A _tunnel_ acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [RFC8446]) is used to establish Transport Layer Security (TLS, [TLS13]) is used to establish
confidential communication through a shared firewall proxy. confidential communication through a shared firewall proxy.
The above categories for intermediary only consider those acting as The above categories for intermediary only consider those acting as
participants in the HTTP communication. There are also participants in the HTTP communication. There are also
intermediaries that can act on lower layers of the network protocol intermediaries that can act on lower layers of the network protocol
stack, filtering or redirecting HTTP traffic without the knowledge or stack, filtering or redirecting HTTP traffic without the knowledge or
permission of message senders. Network intermediaries are permission of message senders. Network intermediaries are
indistinguishable (at a protocol level) from an on-path attacker, indistinguishable (at a protocol level) from an on-path attacker,
often introducing security flaws or interoperability problems due to often introducing security flaws or interoperability problems due to
mistakenly violating HTTP semantics. mistakenly violating HTTP semantics.
skipping to change at page 22, line 31 skipping to change at page 22, line 31
UA =========== A =========== B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
< < < <
Figure 3 Figure 3
A response is _cacheable_ if a cache is allowed to store a copy of A response is _cacheable_ if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. Even the response message for use in answering subsequent requests. Even
when a response is cacheable, there might be additional constraints when a response is cacheable, there might be additional constraints
placed by the client or by the origin server on when that cached placed by the client or by the origin server on when that cached
response can be used for a particular request. HTTP requirements for response can be used for a particular request. HTTP requirements for
cache behavior and cacheable responses are defined in [Caching]. cache behavior and cacheable responses are defined in [CACHING].
There is a wide variety of architectures and configurations of caches There is a wide variety of architectures and configurations of caches
deployed across the World Wide Web and inside large organizations. deployed across the World Wide Web and inside large organizations.
These include national hierarchies of proxy caches to save bandwidth These include national hierarchies of proxy caches to save bandwidth
and reduce latency, Content Delivery Networks that use gateway and reduce latency, Content Delivery Networks that use gateway
caching to optimise regional and global distribution of popular caching to optimise regional and global distribution of popular
sites, collaborative systems that broadcast or multicast cache sites, collaborative systems that broadcast or multicast cache
entries, archives of pre-fetched cache entries for use in off-line or entries, archives of pre-fetched cache entries for use in off-line or
high-latency environments, and so on. high-latency environments, and so on.
3.9. Example Message Exchange 3.9. Example Message Exchange
The following example illustrates a typical HTTP/1.1 message exchange The following example illustrates a typical HTTP/1.1 message exchange
for a GET request (Section 9.3.1) on the URI "http://www.example.com/ for a GET request (Section 9.3.1) on the URI "http://www.example.com/
hello.txt": hello.txt":
Client request: Client request:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 User-Agent: curl/7.64.1
Host: www.example.com Host: www.example.com
Accept-Language: en, mi Accept-Language: en, mi
Server response: Server response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00" ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes Accept-Ranges: bytes
Content-Length: 51 Content-Length: 51
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! My content includes a trailing CRLF. Hello World! My content includes a trailing CRLF.
4. Identifiers in HTTP 4. Identifiers in HTTP
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout Uniform Resource Identifiers (URIs) [URI] are used throughout HTTP as
HTTP as the means for identifying resources (Section 3.1). the means for identifying resources (Section 3.1).
4.1. URI References 4.1. URI References
URI references are used to target requests, indicate redirects, and URI references are used to target requests, indicate redirects, and
define relationships. define relationships.
The definitions of "URI-reference", "absolute-URI", "relative-part", The definitions of "URI-reference", "absolute-URI", "relative-part",
"authority", "port", "host", "path-abempty", "segment", and "query" "authority", "port", "host", "path-abempty", "segment", and "query"
are adopted from the URI generic syntax. An "absolute-path" rule is are adopted from the URI generic syntax. An "absolute-path" rule is
defined for protocol elements that can contain a non-empty path defined for protocol elements that can contain a non-empty path
component. (This rule differs slightly from the path-abempty rule of component. (This rule differs slightly from the path-abempty rule of
RFC 3986, which allows for an empty path to be used in references, RFC 3986, which allows for an empty path, and path-absolute rule,
and path-absolute rule, which does not allow paths that begin with which does not allow paths that begin with "//".) A "partial-URI"
"//".) A "partial-URI" rule is defined for protocol elements that rule is defined for protocol elements that can contain a relative URI
can contain a relative URI but not a fragment component. but not a fragment component.
URI-reference = <URI-reference, see [RFC3986], Section 4.1> URI-reference = <URI-reference, see [URI], Section 4.1>
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [RFC3986], Section 4.2> relative-part = <relative-part, see [URI], Section 4.2>
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [URI], Section 3.2>
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [URI], Section 3.2.2>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [URI], Section 3.2.3>
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [URI], Section 3.3>
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [URI], Section 3.3>
query = <query, see [RFC3986], Section 3.4> query = <query, see [URI], Section 3.4>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form (absolute- of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some URI), only the path and optional query components (partial-URI), or
combination of the above. Unless otherwise indicated, URI references some combination of the above. Unless otherwise indicated, URI
are parsed relative to the target URI (Section 7.1). references are parsed relative to the target URI (Section 7.1).
It is RECOMMENDED that all senders and recipients support, at a It is RECOMMENDED that all senders and recipients support, at a
minimum, URIs with lengths of 8000 octets in protocol elements. Note minimum, URIs with lengths of 8000 octets in protocol elements. Note
that this implies some structures and on-wire representations (for that this implies some structures and on-wire representations (for
example, the request line in HTTP/1.1) will necessarily be larger in example, the request line in HTTP/1.1) will necessarily be larger in
some cases. some cases.
4.2. HTTP-Related URI Schemes 4.2. HTTP-Related URI Schemes
IANA maintains the registry of URI Schemes [BCP35] at IANA maintains the registry of URI Schemes [BCP35] at
skipping to change at page 25, line 17 skipping to change at page 25, line 17
listening for connections. Anyone can mint a URI, whether or not a listening for connections. Anyone can mint a URI, whether or not a
server exists and whether or not that server currently maps that server exists and whether or not that server currently maps that
identifier to a resource. The delegated nature of registered names identifier to a resource. The delegated nature of registered names
and IP addresses creates a federated namespace whether or not an HTTP and IP addresses creates a federated namespace whether or not an HTTP
server is present. server is present.
4.2.1. http URI Scheme 4.2.1. http URI Scheme
The "http" URI scheme is hereby defined for minting identifiers The "http" URI scheme is hereby defined for minting identifiers
within the hierarchical namespace governed by a potential HTTP origin within the hierarchical namespace governed by a potential HTTP origin
server listening for TCP ([RFC0793]) connections on a given port. server listening for TCP ([TCP]) connections on a given port.
http-URI = "http" "://" authority path-abempty [ "?" query ] http-URI = "http" "://" authority path-abempty [ "?" query ]
The origin server for an "http" URI is identified by the authority The origin server for an "http" URI is identified by the authority
component, which includes a host identifier and optional port number component, which includes a host identifier ([URI], Section 3.2.2)
([RFC3986], Section 3.2.2). If the port subcomponent is empty or not and optional port number ([URI], Section 3.2.3). If the port
given, TCP port 80 (the reserved port for WWW services) is the subcomponent is empty or not given, TCP port 80 (the reserved port
default. The origin determines who has the right to respond for WWW services) is the default. The origin determines who has the
authoritatively to requests that target the identified resource, as right to respond authoritatively to requests that target the
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 name space.
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 ([RFC8446]) 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
confidentiality and integrity protection that is acceptable to both confidentiality and integrity protection that is acceptable to both
client and server. client and server.
https-URI = "https" "://" authority path-abempty [ "?" query ] https-URI = "https" "://" authority path-abempty [ "?" query ]
The origin server for an "https" URI is identified by the authority The origin server for an "https" URI is identified by the authority
component, which includes a host identifier and optional port number component, which includes a host identifier ([URI], Section 3.2.2)
([RFC3986], Section 3.2.2). If the port subcomponent is empty or not and optional port number ([URI], Section 3.2.3). If the port
given, TCP port 443 (the reserved port for HTTP over TLS) is the subcomponent is empty or not given, TCP port 443 (the reserved port
default. The origin determines who has the right to respond for HTTP over TLS) is the default. The origin determines who has the
authoritatively to requests that target the identified resource, as right to respond authoritatively to requests that target the
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 name space.
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, an extension to HTTP that is defined separate namespaces. However, extensions to HTTP that are defined as
to apply to all origins with the same host, such as the Cookie applying to all origins with the same host, such as the Cookie
protocol [RFC6265], can allow information set by one service to protocol [COOKIE], allow information set by one service to impact
impact communication with other services within a matching group of communication with other services within a matching group of host
host domains. domains. Such extensions ought to be designed with great care to
prevent information obtained from a secured connection being
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 [RFC3986], 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 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.
Two HTTP URIs that are equivalent after normalization (using any Scheme-based normalization (Section 6.2.3 of [URI]) of "http" and
method) can be assumed to identify the same resource, and any HTTP
component MAY perform normalization. As a result, distinct resources
SHOULD NOT be identified by HTTP URIs that are equivalent after
normalization (using any method defined in Section 6.2 of [RFC3986]).
Scheme-based normalization (Section 6.2.3 of [RFC3986]) of "http" and
"https" URIs involves the following additional rules: "https" URIs involves the following additional rules:
* If the port is equal to the default port for a scheme, the normal * 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.
* When not being used as the target of an OPTIONS request, an empty * When not being used as the target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. normal form is to provide a path of "/" instead.
* The scheme and host are case-insensitive and normally provided in * The scheme and host are case-insensitive and normally provided in
lowercase; all other components are compared in a case-sensitive lowercase; all other components are compared in a case-sensitive
manner. manner.
* Characters other than those in the "reserved" set are equivalent * Characters other than those in the "reserved" set are equivalent
to their percent-encoded octets: the normal form is to not encode to their percent-encoded octets: the normal form is to not encode
them (see Sections 2.1 and 2.2 of [RFC3986]). them (see Sections 2.1 and 2.2 of [URI]).
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
Two HTTP URIs that are equivalent after normalization (using any
method) can be assumed to identify the same resource, and any HTTP
component MAY perform normalization. As a result, distinct resources
SHOULD NOT be identified by HTTP URIs that are equivalent after
normalization (using any method defined in Section 6.2 of [URI]).
4.2.4. Deprecation of userinfo in http(s) URIs 4.2.4. Deprecation of userinfo in http(s) URIs
The URI generic syntax for authority also includes a userinfo The URI generic syntax for authority also includes a userinfo
subcomponent ([RFC3986], Section 3.2.1) for including user subcomponent ([URI], Section 3.2.1) for including user authentication
authentication information in the URI. In that subcomponent, the use information in the URI. In that subcomponent, the use of the format
of the format "user:password" is deprecated. "user:password" is deprecated.
Some implementations make use of the userinfo component for internal Some implementations make use of the userinfo component for internal
configuration of authentication information, such as within command configuration of authentication information, such as within command
invocation options, configuration files, or bookmark lists, even invocation options, configuration files, or bookmark lists, even
though such usage might expose a user identifier or password. though such usage might expose a user identifier or password.
A sender MUST NOT generate the userinfo subcomponent (and its "@" A sender MUST NOT generate the userinfo subcomponent (and its "@"
delimiter) when an "http" or "https" URI reference is generated delimiter) when an "http" or "https" URI reference is generated
within a message as a target URI or field value. within a message as a target URI or field value.
Before making use of an "http" or "https" URI reference received from Before making use of an "http" or "https" URI reference received from
an untrusted source, a recipient SHOULD parse for userinfo and treat an untrusted source, a recipient SHOULD parse for userinfo and treat
its presence as an error; it is likely being used to obscure the its presence as an error; it is likely being used to obscure the
authority for the sake of phishing attacks. authority for the sake of phishing attacks.
4.2.5. http(s) References with Fragment Identifiers 4.2.5. http(s) References with Fragment Identifiers
Fragment identifiers allow for indirect identification of a secondary Fragment identifiers allow for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986]. Some protocol elements that refer to a URI allow [URI]. Some protocol elements that refer to a URI allow inclusion of
inclusion of a fragment, while others do not. They are distinguished a fragment, while others do not. They are distinguished by use of
by use of the ABNF rule for elements where fragment is allowed; the ABNF rule for elements where fragment is allowed; otherwise, a
otherwise, a specific rule that excludes fragments is used. specific rule that excludes fragments is used.
| *Note:* The fragment identifier component is not part of the | *Note:* The fragment identifier component is not part of the
| scheme definition for a URI scheme (see Section 4.3 of | scheme definition for a URI scheme (see Section 4.3 of [URI]),
| [RFC3986]), thus does not appear in the ABNF definitions for | thus does not appear in the ABNF definitions for the "http" and
| the "http" and "https" URI schemes above. | "https" URI schemes above.
4.3. Authoritative Access 4.3. Authoritative Access
Authoritative access refers to dereferencing a given identifier, for Authoritative access refers to dereferencing a given identifier, for
the sake of access to the identified resource, in a way that the the sake of access to the identified resource, in a way that the
client believes is authoritative (controlled by the resource owner). client believes is authoritative (controlled by the resource owner).
The process for determining that access is defined by the URI scheme The process for determining whether access is granted is defined by
and often uses data within the URI components, such as the authority the URI scheme and often uses data within the URI components, such as
component when the generic syntax is used. However, authoritative the authority component when the generic syntax is used. However,
access is not limited to the identified mechanism. authoritative access is not limited to the identified mechanism.
Section 4.3.1 defines the concept of an origin as an aid to such Section 4.3.1 defines the concept of an origin as an aid to such
uses, and the subsequent subsections explain how to establish a uses, and the subsequent subsections explain how to establish that a
peer's association with an authority to represent an origin. peer has the authority to represent an origin.
See Section 17.1 for security considerations related to establishing See Section 17.1 for security considerations related to establishing
authority. authority.
4.3.1. URI Origin 4.3.1. URI Origin
The _origin_ for a given URI is the triple of scheme, host, and port The _origin_ for a given URI is the triple of scheme, host, and port
after normalizing the scheme and host to lowercase and normalizing after normalizing the scheme and host to lowercase and normalizing
the port to remove any leading zeros. If port is elided from the the port to remove any leading zeros. If port is elided from the
URI, the default port for that scheme is used. For example, the URI URI, the default port for that scheme is used. For example, the URI
skipping to change at page 29, line 44 skipping to change at page 29, line 52
host identifier to an IP address, establishing a TCP connection to host identifier to an IP address, establishing a TCP connection to
that address on the indicated port, and sending an HTTP request that address on the indicated port, and sending an HTTP request
message to the server containing the URI's identifying data. message to the server containing the URI's identifying data.
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]). For example, the Alt- response is always necessary (see [CACHING]). For example, the Alt-
Svc header field [RFC7838] 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
skipping to change at page 30, line 37 skipping to change at page 30, line 41
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. A server might be unwilling to serve as the origin for misdirected (Section 7.4).
some hosts even when they have the authority to do so.
For example, if a network attacker causes connections for port N to An origin server might be unwilling to process requests for certain
be received at port Q, checking the target URI is necessary to ensure target URIs even when they have the authority to do so. For example,
that the attacker can't cause "https://example.com:N/foo" to be when a host operates distinct services on different ports (e.g., 443
replaced by "https://example.com:Q/foo" without consent. and 8000), checking the target URI at the origin server is necessary
(even after the connection has been secured) because a network
attacker might cause connections for one port to be received at some
other port. Failing to check the target URI might allow such an
attacker to replace a response to one target URI (e.g.,
"https://example.com/foo") with a seemingly authoritative response
from the other port (e.g., "https://example.com:8000/foo").
Note that the "https" scheme does not rely on TCP and the connected Note that the "https" scheme does not rely on TCP and the connected
port number for associating authority, since both are outside the port number for associating authority, since both are outside the
secured communication and thus cannot be trusted as definitive. secured communication and thus cannot be trusted as definitive.
Hence, the HTTP communication might take place over any channel that Hence, the HTTP communication might take place over any channel that
has been secured, as defined in Section 4.2.2, including protocols has been secured, as defined in Section 4.2.2, including protocols
that don't use TCP. that don't use TCP.
When an "https" URI is used within a context that calls for access to When an "https" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the the indicated resource, a client MAY attempt access by resolving the
skipping to change at page 31, line 19 skipping to change at page 31, line 37
end by successfully initiating TLS over TCP with confidentiality and end by successfully initiating TLS over TCP with confidentiality and
integrity protection, and sending an HTTP request message over that integrity protection, and sending an HTTP request message over that
connection containing the URI's identifying data. connection containing the URI's identifying data.
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.
skipping to change at page 31, line 46 skipping to change at page 32, line 21
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 dynamic URI's origin server identity) rather than one matching the target URI's origin.
identifier.
In special cases, it might be appropriate for a client to simply In special cases, it might be appropriate for a client to simply
ignore the server's identity, but it must be understood that this ignore the server's identity, but it must be understood that this
leaves a connection open to active attack. leaves a connection open to active attack.
If the certificate is not valid for the URI's origin server, a user If the certificate is not valid for the target URI's origin, a user
agent MUST either notify the user (user agents MAY give the user an agent MUST either obtain confirmation from the user before proceeding
option to continue with the connection in any case) or terminate the (see Section 3.5) or terminate the connection with a bad certificate
connection with a bad certificate error. Automated clients MUST log error. Automated clients MUST log the error to an appropriate audit
the error to an appropriate audit log (if available) and SHOULD log (if available) and SHOULD terminate the connection (with a bad
terminate the connection (with a bad certificate error). Automated certificate error). Automated clients MAY provide a configuration
clients MAY provide a configuration setting that disables this check, setting that disables this check, but MUST provide a setting which
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 [RFC3986]. 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 16
octets. Use of IP-ID is not defined for any other IP version. The octets. Use of IP-ID is not defined for any other IP version. The
iPAddress choice in the certificate subjectAltName extension does not iPAddress choice in the certificate subjectAltName extension does not
explicitly include the IP version and so relies on the length of the explicitly include the IP version and so relies on the length of the
address to distinguish versions; see Section 4.2.1.6 of [RFC5280]. 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
skipping to change at page 33, line 46 skipping to change at page 34, line 26
value separated by a comma. value separated by a comma.
For example, this section: For example, this section:
Example-Field: Foo, Bar Example-Field: Foo, Bar
Example-Field: Baz Example-Field: Baz
contains two field lines, both with the field name "Example-Field". contains two field lines, both with the field name "Example-Field".
The first field line has a field line value of "Foo, Bar", while the The first field line has a field line value of "Foo, Bar", while the
second field line value is "Baz". The field value for "Example- second field line value is "Baz". The field value for "Example-
Field" is a list with three members: "Foo", "Bar", and "Baz". Field" is the list "Foo, Bar, Baz".
5.3. Field Order 5.3. Field Order
A recipient MAY combine multiple field lines within a field section A recipient MAY combine multiple field lines within a field section
that have the same field name into one field line, without changing that have the same field name into one field line, without changing
the semantics of the message, by appending each subsequent field line the semantics of the message, by appending each subsequent field line
value to the initial field line value in order, separated by a comma value to the initial field line value in order, separated by a comma
(",") 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.
skipping to change at page 34, line 28 skipping to change at page 35, line 5
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 ([RFC6265]) | *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.)
The order in which field lines with differing field names are The order in which field lines with differing field names are
received in a section is not significant. However, it is good received in a section is not significant. However, it is good
skipping to change at page 35, line 17 skipping to change at page 35, line 39
HTTP does not place a predefined limit on the length of each field HTTP does not place a predefined limit on the length of each field
line, field value, or on the length of a header or trailer section as line, field value, or on the length of a header or trailer section as
a whole, as described in Section 2. Various ad hoc limitations on a whole, as described in Section 2. Various ad hoc limitations on
individual lengths are found in practice, often depending on the individual lengths are found in practice, often depending on the
specific field's semantics. specific field's semantics.
A server that receives a request header field line, field value, or A server that receives a request header field line, field value, or
set of fields larger than it wishes to process MUST respond with an set of fields larger than it wishes to process MUST respond with an
appropriate 4xx (Client Error) status code. Ignoring such header appropriate 4xx (Client Error) status code. Ignoring such header
fields would increase the server's vulnerability to request smuggling fields would increase the server's vulnerability to request smuggling
attacks (Section 11.2 of [Messaging]). attacks (Section 11.2 of [HTTP/1.1]).
A client MAY discard or truncate received field lines that are larger A client MAY discard or truncate received field lines that are larger
than the client wishes to process if the field semantics are such than the client wishes to process if the field semantics are such
that the dropped value(s) can be safely ignored without changing the that the dropped value(s) can be safely ignored without changing the
message framing or response semantics. message framing or response semantics.
5.5. Field Values 5.5. Field Values
HTTP field values consist of a sequence of characters in a format HTTP field values consist of a sequence of characters in a format
defined by the field's grammar. Each field's grammar is usually defined by the field's grammar. Each field's grammar is usually
skipping to change at page 36, line 38 skipping to change at page 37, line 14
For example, a textual date and a URI (either of which might contain For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in list-based field values like a comma) could be safely carried in list-based field values like
these: these:
Example-URIs: "http://example.com/a.html,foo", Example-URIs: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters are almost always used with the Note that double-quote delimiters are almost always used with the
quoted-string production; using a different syntax inside double- quoted-string production (Section 5.6.4); using a different syntax
quotes will likely cause unnecessary confusion. inside double-quotes will likely cause unnecessary confusion.
Many fields (such as Content-Type, defined in Section 8.3) use a Many fields (such as Content-Type, defined in Section 8.3) use a
common syntax for parameters that allows both unquoted (token) and common syntax for parameters that allows both unquoted (token) and
quoted (quoted-string) syntax for a parameter value (Section 5.6.6). quoted (quoted-string) syntax for a parameter value (Section 5.6.6).
Use of common syntax allows recipients to reuse existing parser Use of common syntax allows recipients to reuse existing parser
components. When allowing both forms, the meaning of a parameter components. When allowing both forms, the meaning of a parameter
value ought to be the same whether it was received as a token or a value ought to be the same whether it was received as a token or a
quoted string. quoted string.
Historically, HTTP field values could be extended over multiple lines Historically, HTTP field values could be extended over multiple lines
by preceding each extra line with at least one space or horizontal by preceding each extra line with at least one space or horizontal
tab (obs-fold). This document assumes that any such obsolete line tab (obs-fold). This document assumes that any such obsolete line
folding has been removed prior to interpreting the field value (e.g., folding has been removed prior to interpreting the field value (e.g.,
as described in Section 5.2 of [Messaging]). as described in Section 5.2 of [HTTP/1.1]).
| *Note:* For defining field value syntax, this specification | *Note:* For defining field value syntax, this specification
| uses an ABNF rule named after the field name to define the | uses an ABNF rule named after the field name to define the
| allowed grammar for that field's value (after said value has | allowed grammar for that field's value (after said value has
| been extracted from the underlying messaging syntax and | been extracted from the underlying messaging syntax and
| multiple instances combined into a list). | multiple instances combined into a list).
5.6. Common Rules for Defining Field Values 5.6. Common Rules for Defining Field Values
5.6.1. Lists (#rule ABNF Extension) 5.6.1. Lists (#rule ABNF Extension)
skipping to change at page 42, line 46 skipping to change at page 43, line 9
; e.g., 02-Jun-82 ; e.g., 02-Jun-82
day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday" day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
/ %s"Thursday" / %s"Friday" / %s"Saturday" / %s"Thursday" / %s"Friday" / %s"Saturday"
/ %s"Sunday" / %s"Sunday"
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; e.g., Jun 2 ; e.g., Jun 2
HTTP-date is case sensitive. Note that Section 4.2 of [Caching] HTTP-date is case sensitive. Note that Section 4.2 of [CACHING]
relaxes this for cache recipients. relaxes this for cache recipients.
A sender MUST NOT generate additional whitespace in an HTTP-date A sender MUST NOT generate additional whitespace in an HTTP-date
beyond that specifically included as SP in the grammar. The beyond that specifically included as SP in the grammar. The
semantics of day-name, day, month, year, and time-of-day are the same semantics of day-name, day, month, year, and time-of-day are the same
as those defined for the Internet Message Format constructs with the as those defined for the Internet Message Format constructs with the
corresponding name ([RFC5322], Section 3.3). corresponding name ([RFC5322], Section 3.3).
Recipients of a timestamp value in rfc850-date format, which uses a Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, MUST interpret a timestamp that appears to be more two-digit year, MUST interpret a timestamp that appears to be more
skipping to change at page 45, line 13 skipping to change at page 45, line 20
level error indicates that it is not complete. level error indicates that it is not complete.
6.2. Control Data 6.2. Control Data
Messages start with control data that describe its primary purpose. Messages start with control data that describe its primary purpose.
Request message control data includes a request method (Section 9), Request message control data includes a request method (Section 9),
request target (Section 7.1), and protocol version (Section 2.5). request target (Section 7.1), and protocol version (Section 2.5).
Response message control data includes a status code (Section 15), Response message control data includes a status code (Section 15),
optional reason phrase, and protocol version. optional reason phrase, and protocol version.
In HTTP/1.1 ([Messaging]) and earlier, control data is sent as the In HTTP/1.1 ([HTTP/1.1]) and earlier, control data is sent as the
first line of a message. In HTTP/2 ([RFC7540]) and HTTP/3 ([HTTP3]), first line of a message. In HTTP/2 ([HTTP/2]) and HTTP/3 ([HTTP/3]),
control data is sent as pseudo-header fields with a reserved name control data is sent as pseudo-header fields with a reserved name
prefix (e.g., ":authority"). prefix (e.g., ":authority").
Every HTTP message has a protocol version. Depending on the version Every HTTP message has a protocol version. Depending on the version
in use, it might be identified within the message explicitly or in use, it might be identified within the message explicitly or
inferred by the connection over which the message is received. inferred by the connection over which the message is received.
Recipients use that version information to determine limitations or Recipients use that version information to determine limitations or
potential for later communication with that sender. potential for later communication with that sender.
When a message is forwarded by an intermediary, the protocol version When a message is forwarded by an intermediary, the protocol version
skipping to change at page 46, line 31 skipping to change at page 46, line 44
| section. | section.
6.4. Content 6.4. Content
HTTP messages often transfer a complete or partial representation as HTTP messages often transfer a complete or partial representation as
the message _content_: a stream of octets sent after the header the message _content_: a stream of octets sent after the header
section, as delineated by the message framing. section, as delineated by the message framing.
This abstract definition of content reflects the data after it has This abstract definition of content reflects the data after it has
been extracted from the message framing. For example, an HTTP/1.1 been extracted from the message framing. For example, an HTTP/1.1
message body (Section 6 of [Messaging]) might consist of a stream of message body (Section 6 of [HTTP/1.1]) might consist of a stream of
data encoded with the chunked transfer coding - a sequence of data data encoded with the chunked transfer coding - a sequence of data
chunks, one zero-length chunk, and a trailer section - whereas the chunks, one zero-length chunk, and a trailer section - whereas the
content of that same message includes only the data stream after the content of that same message includes only the data stream after the
transfer coding has been decoded; it does not include the chunk transfer coding has been decoded; it does not include the chunk
lengths, chunked framing syntax, nor the trailer fields lengths, chunked framing syntax, nor the trailer fields
(Section 6.5). (Section 6.5).
| *Note:* Some field names have a "Content-" prefix. This is an
| informal convention; while some of these fields refer to the
| content of the message, as defined above, others are scoped to
| the selected representation (Section 3.2). See the individual
| field's definition to disambiguate.
6.4.1. Content Semantics 6.4.1. Content Semantics
The purpose of content in a request is defined by the method The purpose of content in a request is defined by the method
semantics (Section 9). semantics (Section 9).
For example, a representation in the content of a PUT request For example, a representation in the content of a PUT request
(Section 9.3.4) represents the desired state of the target resource (Section 9.3.4) represents the desired state of the target resource
after the request is successfully applied, whereas a representation after the request is successfully applied, whereas a representation
in the content of a POST request (Section 9.3.3) represents in the content of a POST request (Section 9.3.3) represents
information to be processed by the target resource. information to be processed by the target resource.
skipping to change at page 47, line 43 skipping to change at page 48, line 13
responses do not include content. responses do not include content.
All other responses do include content, although that content might All other responses do include content, although that content might
be of zero length. be of zero length.
6.4.2. Identifying Content 6.4.2. Identifying Content
When a complete or partial representation is transferred as message When a complete or partial representation is transferred as message
content, it is often desirable for the sender to supply, or the content, it is often desirable for the sender to supply, or the
recipient to determine, an identifier for a resource corresponding to recipient to determine, an identifier for a resource corresponding to
that representation. that specific representation. For example, a client making a GET
request on a resource for "the current weather report" might want an
identifier specific to the content returned (e.g., "weather report
for Laguna Beach at 20210720T1711"). This can be useful for sharing
or bookmarking content from resources that are expected to have
changing representations over time.
For a request message: For a request message:
* If the request has a Content-Location header field, then the * If the request has a Content-Location header field, then the
sender asserts that the content is a representation of the sender asserts that the content is a representation of the
resource identified by the Content-Location field value. However, resource identified by the Content-Location field value. However,
such an assertion cannot be trusted unless it can be verified by such an assertion cannot be trusted unless it can be verified by
other means (not defined by this specification). The information other means (not defined by this specification). The information
might still be useful for revision history links. might still be useful for revision history links.
* Otherwise, the content is unidentified. * Otherwise, the content is unidentified by HTTP, but a more
specific identifier might be supplied within the content itself.
For a response message, the following rules are applied in order For a response message, the following rules are applied in order
until a match is found: until a match is found:
1. If the request method is HEAD or the response status code is 204 1. If the request method is HEAD or the response status code is 204
(No Content) or 304 (Not Modified), there is no content in the (No Content) or 304 (Not Modified), there is no content in the
response. response.
2. If the request method is GET and the response status code is 200 2. If the request method is GET and the response status code is 200
(OK), the content is a representation of the resource identified (OK), the content is a representation of the resource identified
skipping to change at page 48, line 39 skipping to change at page 49, line 16
value is a reference to the same URI as the target URI, the value is a reference to the same URI as the target URI, the
content is a representation of the target resource. content is a representation of the target resource.
6. If the response has a Content-Location header field and its field 6. If the response has a Content-Location header field and its field
value is a reference to a URI different from the target URI, then value is a reference to a URI different from the target URI, then
the sender asserts that the content is a representation of the the sender asserts that the content is a representation of the
resource identified by the Content-Location field value. resource identified by the Content-Location field value.
However, such an assertion cannot be trusted unless it can be However, such an assertion cannot be trusted unless it can be
verified by other means (not defined by this specification). verified by other means (not defined by this specification).
7. Otherwise, the content is unidentified. 7. Otherwise, the content is unidentified by HTTP, but a more
specific identifier might be supplied within the content itself.
6.5. Trailer Fields 6.5. Trailer Fields
Fields (Section 5) that are located within a _trailer section_ are Fields (Section 5) that are located within a _trailer section_ are
are referred to as "trailer fields" (or just "trailers", referred to as "trailer fields" (or just "trailers", colloquially).
colloquially). Trailer fields can be useful for supplying message Trailer fields can be useful for supplying message integrity checks,
integrity checks, digital signatures, delivery metrics, or post- digital signatures, delivery metrics, or post-processing status
processing status 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 [Messaging]). 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
generate a trailer field unless the sender knows the corresponding generate a trailer field unless the sender knows the corresponding
header field name's definition permits the field to be sent in header field name's definition permits the field to be sent in
trailers. trailers.
Trailer fields can be difficult to process by intermediaries that Trailer fields can be difficult to process by intermediaries that
skipping to change at page 50, line 47 skipping to change at page 51, line 24
Although HTTP is used in a wide variety of applications, most clients Although HTTP is used in a wide variety of applications, most clients
rely on the same resource identification mechanism and configuration rely on the same resource identification mechanism and configuration
techniques as general-purpose Web browsers. Even when communication techniques as general-purpose Web browsers. Even when communication
options are hard-coded in a client's configuration, we can think of options are hard-coded in a client's configuration, we can think of
their combined effect as a URI reference (Section 4.1). their combined effect as a URI reference (Section 4.1).
A URI reference is resolved to its absolute form in order to obtain A URI reference is resolved to its absolute form in order to obtain
the _target URI_. The target URI excludes the reference's fragment the _target URI_. The target URI excludes the reference's fragment
component, if any, since fragment identifiers are reserved for component, if any, since fragment identifiers are reserved for
client-side processing ([RFC3986], Section 3.5). client-side processing ([URI], Section 3.5).
To perform an action on a _target resource_, the client sends a To perform an action on a _target resource_, the client sends a
request message containing enough components of its parsed target URI request message containing enough components of its parsed target URI
to enable recipients to identify that same resource. For historical to enable recipients to identify that same resource. For historical
reasons, the parsed target URI components, collectively referred to reasons, the parsed target URI components, collectively referred to
as the _request target_, are sent within the message control data and as the _request target_, are sent within the message control data and
the Host header field (Section 7.2). the Host header field (Section 7.2).
There are two unusual cases for which the request target components There are two unusual cases for which the request target components
are in a method-specific form: are in a method-specific form:
skipping to change at page 51, line 27 skipping to change at page 51, line 48
* For OPTIONS (Section 9.3.7), the request target can be a single * For OPTIONS (Section 9.3.7), the request target can be a single
asterisk ("*"). asterisk ("*").
See the respective method definitions for details. These forms MUST See the respective method definitions for details. These forms MUST
NOT be used with other methods. NOT be used with other methods.
Upon receipt of a client's request, a server reconstructs the target Upon receipt of a client's request, a server reconstructs the target
URI from the received components in accordance with their local URI from the received components in accordance with their local
configuration and incoming connection context. This reconstruction configuration and incoming connection context. This reconstruction
is specific to each major protocol version. For example, Appendix of is specific to each major protocol version. For example, Section 3.3
[Messaging] defines how a server determines the target URI of an of [HTTP/1.1] defines how a server determines the target URI of an
HTTP/1.1 request. HTTP/1.1 request.
| *Note:* Previous specifications defined the recomposed target | *Note:* Previous specifications defined the recomposed target
| URI as a distinct concept, the _effective request URI_. | URI as a distinct concept, the _effective request URI_.
7.2. Host and :authority 7.2. Host and :authority
The "Host" header field in a request provides the host and port The "Host" header field in a request provides the host and port
information from the target URI, enabling the origin server to information from the target URI, enabling the origin server to
distinguish among resources while servicing requests for multiple distinguish among resources while servicing requests for multiple
host names. host names.
In HTTP/2 [RFC7540] and HTTP/3 [HTTP3], the Host header field is, in In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in
some cases, supplanted by the ":authority" pseudo-header field of a some cases, supplanted by the ":authority" pseudo-header field of a
request's control data. request's control data.
Host = uri-host [ ":" port ] ; Section 4 Host = uri-host [ ":" port ] ; Section 4
The target URI's authority information is critical for handling a The target URI's authority information is critical for handling a
request. A user agent MUST generate a Host header field in a request request. A user agent MUST generate a Host header field in a request
unless it sends that information as an ":authority" pseudo-header unless it sends that information as an ":authority" pseudo-header
field. A user agent that sends Host SHOULD send it as the first field. A user agent that sends Host SHOULD send it as the first
field in the header section of a request. field in the header section of a request.
skipping to change at page 52, line 28 skipping to change at page 52, line 50
address for that host. address for that host.
7.3. Routing Inbound Requests 7.3. Routing Inbound Requests
Once the target URI and its origin are determined, a client decides Once the target URI and its origin are determined, a client decides
whether a network request is necessary to accomplish the desired whether a network request is necessary to accomplish the desired
semantics and, if so, where that request is to be directed. semantics and, if so, where that request is to be directed.
7.3.1. To a Cache 7.3.1. To a Cache
If the client has a cache [Caching] and the request can be satisfied If the client has a cache [CACHING] and the request can be satisfied
by it, then the request is usually directed there first. by it, then the request is usually directed there first.
7.3.2. To a Proxy 7.3.2. To a Proxy
If the request is not satisfied by a cache, then a typical client If the request is not satisfied by a cache, then a typical client
will check its configuration to determine whether a proxy is to be will check its configuration to determine whether a proxy is to be
used to satisfy the request. Proxy configuration is implementation- used to satisfy the request. Proxy configuration is implementation-
dependent, but is often based on URI prefix matching, selective dependent, but is often based on URI prefix matching, selective
authority matching, or both, and the proxy itself is usually authority matching, or both, and the proxy itself is usually
identified by an "http" or "https" URI. If a proxy is applicable, identified by an "http" or "https" URI. If a proxy is applicable,
skipping to change at page 53, line 7 skipping to change at page 53, line 26
7.3.3. To the Origin 7.3.3. To the Origin
If no proxy is applicable, a typical client will invoke a handler If no proxy is applicable, a typical client will invoke a handler
routine, usually specific to the target URI's scheme, to connect routine, usually specific to the target URI's scheme, to connect
directly to an origin for the target resource. How that is directly to an origin for the target resource. How that is
accomplished is dependent on the target URI scheme and defined by its accomplished is dependent on the target URI scheme and defined by its
associated specification. associated specification.
7.4. Rejecting Misdirected Requests 7.4. Rejecting Misdirected Requests
Before performing a request, a server decides whether or not to Once a request is received by a server and parsed sufficiently to
provide service for the target URI via the connection in which the determine its target URI, the server decides whether to process the
request is received. For example, a request might have been request itself, forward the request to another server, redirect the
misdirected, deliberately or accidentally, such that the information client to a different resource, respond with an error, or drop the
within a received Host header field differs from the connection's connection. This decision can be influenced by anything about the
host or port. request or connection context, but is specifically directed at
whether the server has been configured to process requests for that
target URI and whether the connection context is appropriate for that
request.
If the connection is from a trusted gateway, such inconsistency might For example, a request might have been misdirected, deliberately or
be expected; otherwise, it might indicate an attempt to bypass accidentally, such that the information within a received Host header
security filters, trick the server into delivering non-public field differs from the connection's host or port. If the connection
content, or poison a cache. See Section 17 for security is from a trusted gateway, such inconsistency might be expected;
considerations regarding message routing. otherwise, it might indicate an attempt to bypass security filters,
trick the server into delivering non-public content, or poison a
cache. See Section 17 for security considerations regarding message
routing.
Unless the connection is from a trusted gateway, an origin server
MUST reject a request if any scheme-specific requirements for the
target URI are not met. In particular, a request for an "https"
resource MUST be rejected unless it has been received over a
connection that has been secured via a certificate valid for that
target URI's origin, as defined by Section 4.2.2.
The 421 (Misdirected Request) status code in a response indicates The 421 (Misdirected Request) status code in a response indicates
that the origin server has rejected the request because it appears to that the origin server has rejected the request because it appears to
have been misdirected (Section 15.5.20). have been misdirected (Section 15.5.20).
7.5. Response Correlation 7.5. Response Correlation
A connection might be used for multiple request/response exchanges. A connection might be used for multiple request/response exchanges.
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. Likewise, clients are not its corresponding request is complete (Section 6.1). Likewise,
expected to wait any specific amount of time for a response. Clients clients are not expected to wait any specific amount of time for a
(including intermediaries) might abandon a request if the response is response. Clients (including intermediaries) might abandon a request
not forthcoming within a reasonable period of time. if the response is not forthcoming within a reasonable period of
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 [Messaging] and Section 6.4 of [RFC7540]). 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
skipping to change at page 54, line 32 skipping to change at page 55, line 12
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
directly. directly.
An HTTP message can be parsed as a stream for incremental processing An HTTP message can be parsed as a stream for incremental processing
or forwarding downstream. However, recipients cannot rely on or forwarding downstream. However, senders and recipients cannot
incremental delivery of partial messages, since some implementations rely on incremental delivery of partial messages, since some
will buffer or delay message forwarding for the sake of network implementations will buffer or delay message forwarding for the sake
efficiency, security checks, or content transformations. of network efficiency, security checks, or content transformations.
7.6.1. Connection 7.6.1. Connection
The "Connection" header field allows the sender to list desired The "Connection" header field allows the sender to list desired
control options for the current connection. control options for the current connection.
When a field aside from Connection is used to supply control When a field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list information for or about the current connection, the sender MUST list
the corresponding field name within the Connection header field. the corresponding field name within the Connection header field.
Note that some versions of HTTP prohibit the use of fields for such Note that some versions of HTTP prohibit the use of fields for such
skipping to change at page 55, line 25 skipping to change at page 55, line 48
recipients on the chain ("end-to-end"), enabling the message to be recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by to be deployed without fear that they will be blindly forwarded by
older intermediaries. older intermediaries.
Furthermore, intermediaries SHOULD remove or replace field(s) whose Furthermore, intermediaries SHOULD remove or replace field(s) whose
semantics are known to require removal before forwarding, whether or semantics are known to require removal before forwarding, whether or
not they appear as a Connection option, after applying those fields' not they appear as a Connection option, after applying those fields'
semantics. This includes but is not limited to: semantics. This includes but is not limited to:
* Proxy-Connection (Appendix C.2.2 of [Messaging]) * Proxy-Connection (Appendix C.2.2 of [HTTP/1.1])
* Keep-Alive (Section 19.7.1 of [RFC2068]) * Keep-Alive (Section 19.7.1 of [RFC2068])
* TE (Section 10.1.4) * TE (Section 10.1.4)
* Transfer-Encoding (Section 6.1 of [HTTP/1.1])
* Transfer-Encoding (Section 6.1 of [Messaging])
* Upgrade (Section 7.8) * Upgrade (Section 7.8)
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
Connection = #connection-option Connection = #connection-option
connection-option = token connection-option = token
Connection options are case-insensitive. Connection options are case-insensitive.
A sender MUST NOT send a connection option corresponding to a field A sender MUST NOT send a connection option corresponding to a field
that is intended for all recipients of the content. For example, that is intended for all recipients of the content. For example,
Cache-Control is never appropriate as a connection option Cache-Control is never appropriate as a connection option
(Section 5.2 of [Caching]). (Section 5.2 of [CACHING]).
Connection options do not always correspond to a field present in the Connection options do not always correspond to a field present in the
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
skipping to change at page 57, line 48 skipping to change at page 58, line 10
what backwards-incompatible features might be safe to use in what backwards-incompatible features might be safe to use in
response, or within a later request, as described in Section 2.5. response, or within a later request, as described in Section 2.5.
For brevity, the protocol-name is omitted when the received protocol For brevity, the protocol-name is omitted when the received protocol
is HTTP. is HTTP.
The received-by portion is normally the host and optional port number The received-by portion is normally the host and optional port number
of a recipient server or client that subsequently forwarded the of a recipient server or client that subsequently forwarded the
message. However, if the real host is considered to be sensitive message. However, if the real host is considered to be sensitive
information, a sender MAY replace it with a pseudonym. If a port is information, a sender MAY replace it with a pseudonym. If a port is
not provided, a recipient MAY interpret that as meaning it was not provided, a recipient MAY interpret that as meaning it was
received on the default TCP port, if any, for the received-protocol. received on the default port, if any, for the received-protocol.
A sender MAY generate comments to identify the software of each A sender MAY generate comments to identify the software of each
recipient, analogous to the User-Agent and Server header fields. recipient, analogous to the User-Agent and Server header fields.
However, comments in Via are optional, and a recipient MAY remove However, comments in Via are optional, and a recipient MAY remove
them prior to forwarding the message. them prior to forwarding the message.
For example, a request message could be sent from an HTTP/1.0 user For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
forward the request to a public proxy at p.example.net, which forward the request to a public proxy at p.example.net, which
completes the request by forwarding it to the origin server at completes the request by forwarding it to the origin server at
skipping to change at page 59, line 28 skipping to change at page 59, line 40
qualified domain name, it MAY add its own domain to the host name it qualified domain name, it MAY add its own domain to the host name it
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 noted above to replace an empty path with "/" or "*". except as noted above to replace an empty path with "/" or "*".
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 message
that contains a no-transform cache-control response directive that contains a no-transform cache-control response directive
(Section 5.2 of [Caching]). Note that this does not include changes (Section 5.2 of [CACHING]). Note that this does not include changes
to the message body that do not affect the content, such as transfer to the message body that do not affect the content, such as transfer
codings (Section 7 of [Messaging]). 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-control 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
skipping to change at page 65, line 39 skipping to change at page 66, line 8
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 [Messaging]), 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.
Typically, the representation is only decoded just prior to rendering Typically, the representation is only decoded just prior to rendering
or analogous usage. or analogous usage.
If the media type includes an inherent encoding, such as a data If the media type includes an inherent encoding, such as a data
format that is always compressed, then that encoding would not be format that is always compressed, then that encoding would not be
restated in Content-Encoding even if it happens to be the same restated in Content-Encoding even if it happens to be the same
skipping to change at page 68, line 38 skipping to change at page 69, line 11
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information. See [RFC5646] for further information.
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 [Messaging]). can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In
In other cases, Content-Length indicates the selected other cases, Content-Length indicates the selected representation's
representation's current length, which can be used by recipients to current length, which can be used by recipients to estimate transfer
estimate transfer time or compare to previously stored time or compare to previously stored representations.
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 70, line 27 skipping to change at page 70, line 44
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.
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
The field value is either an absolute-URI or a partial-URI. In the The field value is either an absolute-URI or a partial-URI. In the
latter case (Section 4), the referenced URI is relative to the target latter case (Section 4), the referenced URI is relative to the target
URI ([RFC3986], Section 5). URI ([URI], Section 5).
The Content-Location value is not a replacement for the target URI The Content-Location value is not a replacement for the target URI
(Section 7.1). It is representation metadata. It has the same (Section 7.1). It is representation metadata. It has the same
syntax and semantics as the header field of the same name defined for syntax and semantics as the header field of the same name defined for
MIME body parts in Section 4 of [RFC2557]. However, its appearance MIME body parts in Section 4 of [RFC2557]. However, its appearance
in an HTTP message has some special implications for HTTP recipients. in an HTTP message has some special implications for HTTP recipients.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a message and its value refers (after conversion to absolute form) to a
URI that is the same as the target URI, then the recipient MAY URI that is the same as the target URI, then the recipient MAY
skipping to change at page 72, line 29 skipping to change at page 72, line 46
For example, an ETag field in a 201 (Created) response communicates For example, an ETag field in a 201 (Created) response communicates
the entity-tag of the newly created resource's representation, so the entity-tag of the newly created resource's representation, so
that it can be used in later conditional requests to prevent the that it can be used in later conditional requests to prevent the
"lost update" problem (Section 13.1). "lost update" problem (Section 13.1).
This specification defines two forms of metadata that are commonly This specification defines two forms of metadata that are commonly
used to observe resource state and test for preconditions: used to observe resource state and test for preconditions:
modification dates (Section 8.8.2) and opaque entity tags modification dates (Section 8.8.2) and opaque entity tags
(Section 8.8.3). Additional metadata that reflects resource state (Section 8.8.3). Additional metadata that reflects resource state
has been defined by various extensions of HTTP, such as Web has been defined by various extensions of HTTP, such as Web
Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are Distributed Authoring and Versioning [WEBDAV], that are beyond the
beyond the scope of this specification. A resource metadata value is scope of this specification. A resource metadata value is referred
referred to as a _validator_ when it is used within a precondition. to as a _validator_ when it is used within a precondition.
8.8.1. Weak versus Strong 8.8.1. Weak versus Strong
Validators come in two flavors: strong or weak. Weak validators are Validators come in two flavors: strong or weak. Weak validators are
easy to generate but are far less useful for comparisons. Strong easy to generate but are far less useful for comparisons. Strong
validators are ideal for comparisons but can be very difficult (and validators are ideal for comparisons but can be very difficult (and
occasionally impossible) to generate efficiently. Rather than impose occasionally impossible) to generate efficiently. Rather than impose
that all forms of resource adhere to the same strength of validator, that all forms of resource adhere to the same strength of validator,
HTTP exposes the type of validator in use and imposes restrictions on HTTP exposes the type of validator in use and imposes restrictions on
when weak validators can be used as preconditions. when weak validators can be used as preconditions.
skipping to change at page 74, line 32 skipping to change at page 75, line 4
8.8.2. Last-Modified 8.8.2. Last-Modified
The "Last-Modified" header field in a response provides a timestamp The "Last-Modified" header field in a response provides a timestamp
indicating the date and time at which the origin server believes the indicating the date and time at which the origin server believes the
selected representation was last modified, as determined at the selected representation was last modified, as determined at the
conclusion of handling the request. conclusion of handling the request.
Last-Modified = HTTP-date Last-Modified = HTTP-date
An example of its use is An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
8.8.2.1. Generation 8.8.2.1. Generation
An origin server SHOULD send Last-Modified for any selected An origin server SHOULD send Last-Modified for any selected
representation for which a last modification date can be reasonably representation for which a last modification date can be reasonably
and consistently determined, since its use in conditional requests and consistently determined, since its use in conditional requests
and evaluating cache freshness ([Caching]) can substantially reduce and evaluating cache freshness ([CACHING]) can substantially reduce
unnecessary transfers and significantly improve service availability unnecessary transfers and significantly improve service availability
and scalability. and scalability.
A representation is typically the sum of many parts behind the A representation is typically the sum of many parts behind the
resource interface. The last-modified time would usually be the most resource interface. The last-modified time would usually be the most
recent time that any of those parts were changed. How that value is recent time that any of those parts were changed. How that value is
determined for any given resource is an implementation detail beyond determined for any given resource is an implementation detail beyond
the scope of this specification. the scope of this specification.
An origin server SHOULD obtain the Last-Modified value of the An origin server SHOULD obtain the Last-Modified value of the
skipping to change at page 77, line 36 skipping to change at page 78, line 8
applied to all changes might use an internal revision number, perhaps applied to all changes might use an internal revision number, perhaps
combined with a variance identifier for content negotiation, to combined with a variance identifier for content negotiation, to
accurately differentiate between representations. Other accurately differentiate between representations. Other
implementations might use a collision-resistant hash of implementations might use a collision-resistant hash of
representation content, a combination of various file attributes, or representation content, a combination of various file attributes, or
a modification timestamp that has sub-second resolution. a modification timestamp that has sub-second resolution.
An origin server SHOULD send an ETag for any selected representation An origin server SHOULD send an ETag for any selected representation
for which detection of changes can be reasonably and consistently for which detection of changes can be reasonably and consistently
determined, since the entity-tag's use in conditional requests and determined, since the entity-tag's use in conditional requests and
evaluating cache freshness ([Caching]) can substantially reduce evaluating cache freshness ([CACHING]) can substantially reduce
unnecessary transfers and significantly improve service availability, unnecessary transfers and significantly improve service availability,
scalability, and reliability. scalability, and reliability.
8.8.3.2. Comparison 8.8.3.2. Comparison
There are two entity-tag comparison functions, depending on whether There are two entity-tag comparison functions, depending on whether
or not the comparison context allows the use of weak validators: or not the comparison context allows the use of weak validators:
_Strong comparison_: two entity-tags are equivalent if both are not _Strong comparison_: two entity-tags are equivalent if both are not
weak and their opaque-tags match character-by-character. weak and their opaque-tags match character-by-character.
skipping to change at page 79, line 4 skipping to change at page 79, line 21
ETag: "123-a" ETag: "123-a"
Content-Length: 70 Content-Length: 70
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! Hello World!
Hello World! Hello World!
Hello World! Hello World!
Hello World! Hello World!
Hello World! Hello World!
An alternative representation that does use gzip content coding would An alternative representation that does use gzip content coding would
be: be:
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b" ETag: "123-b"
Content-Length: 43 Content-Length: 43
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Content-Encoding: gzip Content-Encoding: gzip
...binary data... ...binary data...
| *Note:* Content codings are a property of the representation | *Note:* Content codings are a property of the representation
| data, so a strong entity-tag for a content-encoded | data, so a strong entity-tag for a content-encoded
| representation has to be distinct from the entity tag of an | representation has to be distinct from the entity tag of an
| unencoded representation to prevent potential conflicts during | unencoded representation to prevent potential conflicts during
| cache updates and range requests. In contrast, transfer | cache updates and range requests. In contrast, transfer
| codings (Section 7 of [Messaging]) apply only during message | codings (Section 7 of [HTTP/1.1]) apply only during message
| transfer and do not result in distinct entity-tags. | transfer and do not result in distinct entity-tags.
8.8.4. When to Use Entity-Tags and Last-Modified Dates 8.8.4. When to Use Entity-Tags and Last-Modified Dates
In 200 (OK) responses to GET or HEAD, an origin server: In 200 (OK) responses to GET or HEAD, an origin server:
* SHOULD send an entity-tag validator unless it is not feasible to * SHOULD send an entity-tag validator unless it is not feasible to
generate one. generate one.
* MAY send a weak entity-tag instead of a strong entity-tag, if * MAY send a weak entity-tag instead of a strong entity-tag, if
skipping to change at page 82, line 29 skipping to change at page 83, line 24
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
This definition of safe methods does not prevent an implementation This definition of safe methods does not prevent an implementation
from including behavior that is potentially harmful, that is not from including behavior that is potentially harmful, that is not
entirely read-only, or that causes side effects while invoking a safe entirely read-only, or that causes side effects while invoking a safe
method. What is important, however, is that the client did not method. What is important, however, is that the client did not
request that additional behavior and cannot be held accountable for request that additional behavior and cannot be held accountable for
it. For example, most servers append request information to access it. For example, most servers append request information to access
log files at the completion of every response, regardless of the log files at the completion of every response, regardless of the
method, and that is considered safe even though the log storage might method, and that is considered safe even though the log storage might
become full and crash the server. Likewise, a safe request initiated become full and cause the server to fail. Likewise, a safe request
by selecting an advertisement on the Web will often have the side initiated by selecting an advertisement on the Web will often have
effect of charging an advertising account. the side effect of charging an advertising account.
Of the request methods defined by this specification, the GET, HEAD, Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe. OPTIONS, and TRACE methods are defined to be safe.
The purpose of distinguishing between safe and unsafe methods is to The purpose of distinguishing between safe and unsafe methods is to
allow automated retrieval processes (spiders) and cache performance allow automated retrieval processes (spiders) and cache performance
optimization (pre-fetching) to work without fear of causing harm. In optimization (pre-fetching) to work without fear of causing harm. In
addition, it allows a user agent to apply appropriate constraints on addition, it allows a user agent to apply appropriate constraints on
the automated use of unsafe methods when processing potentially the automated use of unsafe methods when processing potentially
untrusted content. untrusted content.
skipping to change at page 84, line 14 skipping to change at page 85, line 20
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 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 which 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
The GET method requests transfer of a current selected representation The GET method requests transfer of a current selected representation
for the target resource. for the target resource. A successful response reflects the quality
of "sameness" identified by the target URI (Section 1.2.2 of [URI]).
Hence, retrieving identifiable information via HTTP is usually
performed by making a GET request on an identifier associated with
the potential for providing that information in a 200 (OK) response.
GET is the primary mechanism of information retrieval and the focus GET is the primary mechanism of information retrieval and the focus
of almost all performance optimizations. Hence, when people speak of of almost all performance optimizations. Applications that produce a
retrieving some identifiable information via HTTP, they are generally URI for each important resource can benefit from those optimizations
referring to making a GET request. A successful response reflects while enabling their reuse by other applications, creating a network
the quality of "sameness" identified by the target URI. In turn, effect that promotes further expansion of the Web.
constructing applications such that they produce a URI for each
important resource results in more resources being available for
other applications, producing a network effect that promotes further
expansion of the Web.
It is tempting to think of resource identifiers as remote file system It is tempting to think of resource identifiers as remote file system
pathnames and of representations as being a copy of the contents of pathnames and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see such files. In fact, that is how many resources are implemented (see
Section 17.3 for related security considerations). However, there Section 17.3 for related security considerations). However, there
are no such limitations in practice. are no such limitations in practice.
The HTTP interface for a resource is just as likely to be implemented The HTTP interface for a resource is just as likely to be implemented
as a tree of content objects, a programmatic view on various database as a tree of content objects, a programmatic view on various database
records, or a gateway to other information systems. Even when the records, or a gateway to other information systems. Even when the
URI mapping mechanism is tied to a file system, an origin server URI mapping mechanism is tied to a file system, an origin server
might be configured to execute the files with the request as input might be configured to execute the files with the request as input
and send the output as the representation rather than transfer the and send the output as the representation rather than transfer the
files directly. Regardless, only the origin server needs to know how files directly. Regardless, only the origin server needs to know how
each of its resource identifiers corresponds to an implementation and each resource identifier corresponds to an implementation and how
how each implementation manages to select and send a current that implementation manages to select and send a current
representation of the target resource in a response to GET. representation of the target resource.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
(Section 14.2). (Section 14.2).
A client SHOULD NOT generate content in a GET request. Content Although request message framing is independent of the method used,
received in a GET request has no defined semantics, cannot alter the content received in a GET request has no generally defined semantics,
meaning or target of the request, and might lead some implementations cannot alter the meaning or target of the request, and might lead
to reject the request and close the connection because of its some implementations to reject the request and close the connection
potential as a request smuggling attack (Section 11.2 of because of its potential as a request smuggling attack (Section 11.2
[Messaging]). of [HTTP/1.1]). A client SHOULD NOT generate content in a GET
request unless it is made directly to an origin server that has
previously indicated, in or out of band, that such a request has a
purpose and will be adequately supported. An origin server SHOULD
NOT rely on private agreements to receive content, since participants
in HTTP communication are often unaware of intermediaries along the
request chain.
The response to a GET request is cacheable; a cache MAY use it to The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [Caching]). by the Cache-Control header field (Section 5.2 of [CACHING]).
When information retrieval is performed with a mechanism that When information retrieval is performed with a mechanism that
constructs a target URI from user-provided information, such as the constructs a target URI from user-provided information, such as the
query fields of a form using GET, potentially sensitive data might be query fields of a form using GET, potentially sensitive data might be
provided that would not be appropriate for disclosure within a URI provided that would not be appropriate for disclosure within a URI
(see Section 17.9). In some cases, the data can be filtered or (see Section 17.9). In some cases, the data can be filtered or
transformed such that it would not reveal such information. In transformed such that it would not reveal such information. In
others, particularly when there is no benefit from caching a others, particularly when there is no benefit from caching a
response, using the POST method (Section 9.3.3) instead of GET can response, using the POST method (Section 9.3.3) instead of GET can
transmit such information in the request content rather than within transmit such information in the request content rather than within
skipping to change at page 86, line 5 skipping to change at page 87, line 18
determined only while generating the content. For example, some determined only while generating the content. For example, some
servers buffer a dynamic response to GET until a minimum amount of servers buffer a dynamic response to GET until a minimum amount of
data is generated so that they can more efficiently delimit small data is generated so that they can more efficiently delimit small
responses or make late decisions with regard to content selection. responses or make late decisions with regard to content selection.
Such a response to GET might contain Content-Length and Vary fields, Such a response to GET might contain Content-Length and Vary fields,
for example, that are not generated within a HEAD response. These for example, that are not generated within a HEAD response. These
minor inconsistencies are considered preferable to generating and minor inconsistencies are considered preferable to generating and
discarding the content for a HEAD request, since HEAD is usually discarding the content for a HEAD request, since HEAD is usually
requested for the sake of efficiency. requested for the sake of efficiency.
A client SHOULD NOT generate content in a HEAD request. Content Although request message framing is independent of the method used,
received in a HEAD request has no defined semantics, cannot alter the content received in a HEAD request has no generally defined
meaning or target of the request, and might lead some implementations semantics, cannot alter the meaning or target of the request, and
to reject the request and close the connection because of its might lead some implementations to reject the request and close the
potential as a request smuggling attack (Section 11.2 of connection because of its potential as a request smuggling attack
[Messaging]). (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content
in a HEAD request unless it is made directly to an origin server that
has previously indicated, in or out of band, that such a request has
a purpose and will be adequately supported. An origin server SHOULD
NOT rely on private agreements to receive content, since participants
in HTTP communication are often unaware of intermediaries along the
request chain.
The response to a HEAD request is cacheable; a cache MAY use it to The response to a HEAD request is cacheable; a cache MAY use it to
satisfy subsequent HEAD requests unless otherwise indicated by the satisfy subsequent HEAD requests unless otherwise indicated by the
Cache-Control header field (Section 5.2 of [Caching]). A HEAD Cache-Control header field (Section 5.2 of [CACHING]). A HEAD
response might also affect previously cached responses to GET; see response might also affect previously cached responses to GET; see
Section 4.3.5 of [Caching]. Section 4.3.5 of [CACHING].
9.3.3. POST 9.3.3. POST
The POST method requests that the target resource process the The POST method requests that the target resource process the
representation enclosed in the request according to the resource's representation enclosed in the request according to the resource's
own specific semantics. For example, POST is used for the following own specific semantics. For example, POST is used for the following
functions (among others): functions (among others):
* Providing a block of data, such as the fields entered into an HTML * Providing a block of data, such as the fields entered into an HTML
form, to a data-handling process; form, to a data-handling process;
skipping to change at page 86, line 51 skipping to change at page 88, line 22
Satisfiable)). Satisfiable)).
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 10.2.3) and a representation that describes the status of (Section 10.2.3) and a representation that describes the status of
the request while referring to the new resource(s). the request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [Caching]) and a explicit freshness information (see Section 4.2.1 of [CACHING]) and a
Content-Location header field that has the same value as the POST's Content-Location header field that has the same value as the POST's
target URI (Section 8.7). A cached POST response can be reused to target URI (Section 8.7). A cached POST response can be reused to
satisfy a later GET or HEAD request, but not a POST request, since satisfy a later GET or HEAD request, but not a POST request, since
POST is required to be written through to the origin server, because POST is required to be written through to the origin server, because
it is unsafe; see Section 4 of [Caching]. it is unsafe; see Section 4 of [CACHING].
If the result of processing a POST would be equivalent to a If the result of processing a POST would be equivalent to a
representation of an existing resource, an origin server MAY redirect representation of an existing resource, an origin server MAY redirect
the user agent to that resource by sending a 303 (See Other) response the user agent to that resource by sending a 303 (See Other) response
with the existing resource's identifier in the Location field. This with the existing resource's identifier in the Location field. This
has the benefits of providing the user agent a resource identifier has the benefits of providing the user agent a resource identifier
and transferring the representation via a method more amenable to and transferring the representation via a method more amenable to
shared caching, though at the cost of an extra request if the user shared caching, though at the cost of an extra request if the user
agent does not already have the representation cached. agent does not already have the representation cached.
skipping to change at page 87, line 43 skipping to change at page 89, line 15
If the target resource does not have a current representation and the If the target resource does not have a current representation and the
PUT successfully creates one, then the origin server MUST inform the PUT successfully creates one, then the origin server MUST inform the
user agent by sending a 201 (Created) response. If the target user agent by sending a 201 (Created) response. If the target
resource does have a current representation and that representation resource does have a current representation and that representation
is successfully modified in accordance with the state of the enclosed is successfully modified in accordance with the state of the enclosed
representation, then the origin server MUST send either a 200 (OK) or representation, then the origin server MUST send either a 200 (OK) or
a 204 (No Content) response to indicate successful completion of the a 204 (No Content) response to indicate successful completion of the
request. request.
An origin server SHOULD verify that the PUT representation is An origin server SHOULD verify that the PUT representation is
consistent with any constraints the server has for the target consistent with its configured constraints for the target resource.
resource that cannot or will not be changed by the PUT. This is For example, if an origin server determines a resource's
particularly important when the origin server uses internal representation metadata based on the URI, then the origin server
configuration information related to the URI in order to set the needs to ensure that the content received in a successful PUT request
values for representation metadata on GET responses. When a PUT is consistent with that metadata. When a PUT representation is
representation is inconsistent with the target resource, the origin inconsistent with the target resource, the origin server SHOULD
server SHOULD either make them consistent, by transforming the either make them consistent, by transforming the representation or
representation or changing the resource configuration, or respond changing the resource configuration, or respond with an appropriate
with an appropriate error message containing sufficient information error message containing sufficient information to explain why the
to explain why the representation is unsuitable. The 409 (Conflict) representation is unsuitable. The 409 (Conflict) or 415 (Unsupported
or 415 (Unsupported Media Type) status codes are suggested, with the Media Type) status codes are suggested, with the latter being
latter being specific to constraints on Content-Type values. specific to constraints on Content-Type values.
For example, if the target resource is configured to always have a For example, if the target resource is configured to always have a
Content-Type of "text/html" and the representation being PUT has a Content-Type of "text/html" and the representation being PUT has a
Content-Type of "image/jpeg", the origin server ought to do one of: Content-Type of "image/jpeg", the origin server ought to do one of:
a. reconfigure the target resource to reflect the new media type; a. reconfigure the target resource to reflect the new media type;
b. transform the PUT representation to a format consistent with that b. transform the PUT representation to a format consistent with that
of the resource before saving it as the new resource state; or, of the resource before saving it as the new resource state; or,
skipping to change at page 88, line 38 skipping to change at page 90, line 10
result of a change in resource state, nor how the origin server result of a change in resource state, nor how the origin server
translates resource state into representations. Generally speaking, translates resource state into representations. Generally speaking,
all implementation details behind the resource interface are all implementation details behind the resource interface are
intentionally hidden by the server. intentionally hidden by the server.
This extends to how header and trailer fields are stored; while This extends to how header and trailer fields are stored; while
common header fields like Content-Type will typically be stored and common header fields like Content-Type will typically be stored and
returned upon subsequent GET requests, header and trailer field returned upon subsequent GET requests, header and trailer field
handling is specific to the resource that received the request. As a handling is specific to the resource that received the request. As a
result, an origin server SHOULD ignore unrecognized header and result, an origin server SHOULD ignore unrecognized header and
trailer fields received in a PUT request (i.e., do not save them as trailer fields received in a PUT request (i.e., not save them as part
part 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 doesn't need to be retrieved again from the origin
skipping to change at page 90, line 8 skipping to change at page 91, line 22
the state of the target resource, and might also cause links to be the state of the target resource, and might also cause links to be
added between the related resources. added between the related resources.
Some origin servers support use of the Content-Range header field Some origin servers support use of the Content-Range header field
(Section 14.4) as a request modifier to perform a partial PUT, as (Section 14.4) as a request modifier to perform a partial PUT, as
described in Section 14.5. described in Section 14.5.
Responses to the PUT method are not cacheable. If a successful PUT Responses to the PUT method are not cacheable. If a successful PUT
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the target URI, those stored responses will be invalidated (see for the target URI, those stored responses will be invalidated (see
Section 4.4 of [Caching]). Section 4.4 of [CACHING]).
9.3.5. DELETE 9.3.5. DELETE
The DELETE method requests that the origin server remove the The DELETE method requests that the origin server remove the
association between the target resource and its current association between the target resource and its current
functionality. In effect, this method is similar to the "rm" command functionality. In effect, this method is similar to the "rm" command
in UNIX: it expresses a deletion operation on the URI mapping of the in UNIX: it expresses a deletion operation on the URI mapping of the
origin server rather than an expectation that the previously origin server rather than an expectation that the previously
associated information be deleted. associated information be deleted.
skipping to change at page 91, line 5 skipping to change at page 92, line 28
* a 202 (Accepted) status code if the action will likely succeed but * a 202 (Accepted) status code if the action will likely succeed but
has not yet been enacted, has not yet been enacted,
* a 204 (No Content) status code if the action has been enacted and * a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or no further information is to be supplied, or
* a 200 (OK) status code if the action has been enacted and the * a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status. response message includes a representation describing the status.
A client SHOULD NOT generate content in a DELETE request. Content Although request message framing is independent of the method used,
received in a DELETE request has no defined semantics, cannot alter content received in a DELETE request has no generally defined
the meaning or target of the request, and might lead some semantics, cannot alter the meaning or target of the request, and
implementations to reject the request. might lead some implementations to reject the request and close the
connection because of its potential as a request smuggling attack
(Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content
in a DELETE request unless it is made directly to an origin server
that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported. An origin server
SHOULD NOT rely on private agreements to receive content, since
participants in HTTP communication are often unaware of
intermediaries along the request chain.
Responses to the DELETE method are not cacheable. If a successful Responses to the DELETE method are not cacheable. If a successful
DELETE request passes through a cache that has one or more stored DELETE request passes through a cache that has one or more stored
responses for the target URI, those stored responses will be responses for the target URI, those stored responses will be
invalidated (see Section 4.4 of [Caching]). invalidated (see Section 4.4 of [CACHING]).
9.3.6. CONNECT 9.3.6. CONNECT
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request target and, the destination origin server identified by the request target and,
if successful, thereafter restrict its behavior to blind forwarding if successful, thereafter restrict its behavior to blind forwarding
of data, in both directions, until the tunnel is closed. Tunnels are of data, in both directions, until the tunnel is closed. Tunnels are
commonly used to create an end-to-end virtual connection, through one commonly used to create an end-to-end virtual connection, through one
or more proxies, which can then be secured using TLS (Transport Layer or more proxies, which can then be secured using TLS (Transport Layer
Security, [RFC8446]). Security, [TLS13]).
CONNECT uses a special form of request target, unique to this method, CONNECT uses a special form of request target, unique to this method,
consisting of only the host and port number of the tunnel consisting of only the host and port number of the tunnel
destination, separated by a colon. There is no default port; a destination, separated by a colon. There is no default port; a
client MUST send the port number even if the CONNECT request is based client MUST send the port number even if the CONNECT request is based
on a URI reference that contains an authority component with an on a URI reference that contains an authority component with an
elided port (Section 4.1). For example, elided port (Section 4.1). For example,
CONNECT server.example.com:80 HTTP/1.1 CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com Host: server.example.com
skipping to change at page 92, line 36 skipping to change at page 94, line 27
proxy into relaying spam email. Proxies that support CONNECT SHOULD proxy into relaying spam email. Proxies that support CONNECT SHOULD
restrict its use to a limited set of known ports or a configurable restrict its use to a limited set of known ports or a configurable
list of safe request targets. list of safe request targets.
A server MUST NOT send any Transfer-Encoding or Content-Length header A server MUST NOT send any Transfer-Encoding or Content-Length header
fields in a 2xx (Successful) response to CONNECT. A client MUST fields in a 2xx (Successful) response to CONNECT. A client MUST
ignore any Content-Length or Transfer-Encoding header fields received ignore any Content-Length or Transfer-Encoding header fields received
in a successful response to CONNECT. in a successful response to CONNECT.
A CONNECT request message does not have content. The interpretation A CONNECT request message does not have content. The interpretation
of and allowability of data sent after the header section of the of data sent after the header section of the CONNECT request message
CONNECT request message is specific to the version of HTTP in use. is specific to the version of HTTP in use.
Responses to the CONNECT method are not cacheable. Responses to the CONNECT method are not cacheable.
9.3.7. OPTIONS 9.3.7. OPTIONS
The OPTIONS method requests information about the communication The OPTIONS method requests information about the communication
options available for the target resource, at either the origin options available for the target resource, at either the origin
server or an intervening intermediary. This method allows a client server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a to determine the options and/or requirements associated with a
resource, or the capabilities of a server, without implying a resource, or the capabilities of a server, without implying a
skipping to change at page 93, line 45 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 [Messaging]) format is one way to do "message/http" (Section 10.1 of [HTTP/1.1]) format 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 [RFC6265] 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
response content. response content.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 7.6.3) is of information. The value of the Via header field (Section 7.6.3) is of
particular interest, since it acts as a trace of the request chain. particular interest, since it acts as a trace of the request chain.
Use of the Max-Forwards header field allows the client to limit the Use of the Max-Forwards header field allows the client to limit the
length of the request chain, which is useful for testing a chain of length of the request chain, which is useful for testing a chain of
skipping to change at page 96, line 15 skipping to change at page 98, line 7
* A server MAY omit sending a 100 (Continue) response if it has * A server MAY omit sending a 100 (Continue) response if it has
already received some or all of the content for the corresponding already received some or all of the content for the corresponding
request, or if the framing indicates that there is no content. request, or if the framing indicates that there is no content.
* A server that sends a 100 (Continue) response MUST ultimately send * A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once it receives and processes the request a final status code, once it receives and processes the request
content, unless the connection is closed prematurely. content, unless the connection is closed prematurely.
* A server that responds with a final status code before reading the * A server that responds with a final status code before reading the
entire request content SHOULD indicate whether it intends to close entire request content SHOULD indicate whether it intends to close
the connection (e.g., see Section 9.6 of [Messaging]) or continue the connection (e.g., see Section 9.6 of [HTTP/1.1]) or continue
reading the request content. reading the request content.
An origin server MUST, upon receiving an HTTP/1.1 (or later) request An origin server MUST, upon receiving an HTTP/1.1 (or later) request
that has a method, target URI, and complete header section that that has a method, target URI, and complete header section that
contains a 100-continue expectation and an indication that request contains a 100-continue expectation and an indication that request
content will follow, either send an immediate response with a final content will follow, either send an immediate response with a final
status code, if that status can be determined by examining just the status code, if that status can be determined by examining just the
method, target URI, and header fields, or send an immediate 100 method, target URI, and header fields, or send an immediate 100
(Continue) response to encourage the client to send the request (Continue) response to encourage the client to send the request
content. The origin server MUST NOT wait for the content before content. The origin server MUST NOT wait for the content before
skipping to change at page 97, line 18 skipping to change at page 99, line 11
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.
A server SHOULD NOT use the From header field for access control or A server SHOULD NOT use the From header field for access control or
authentication. authentication, since its value is expected to be visible to anyone
receiving or observing the request and is often recorded within
logfiles and error reports without any expectation of privacy.
10.1.3. Referer 10.1.3. Referer
The "Referer" [sic] header field allows the user agent to specify a The "Referer" [sic] header field allows the user agent to specify a
URI reference for the resource from which the target URI was obtained URI reference for the resource from which the target URI was obtained
(i.e., the "referrer", though the field name is misspelled). A user (i.e., the "referrer", though the field name is misspelled). A user
agent MUST NOT include the fragment and userinfo components of the agent MUST NOT include the fragment and userinfo components of the
URI reference [RFC3986], if any, when generating the Referer field URI reference [URI], if any, when generating the Referer field value.
value.
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
The field value is either an absolute-URI or a partial-URI. In the The field value is either an absolute-URI or a partial-URI. In the
latter case (Section 4), the referenced URI is relative to the target latter case (Section 4), the referenced URI is relative to the target
URI ([RFC3986], Section 5). URI ([URI], Section 5).
The Referer header field allows servers to generate back-links to The Referer header field allows servers to generate back-links to
other resources for simple analytics, logging, optimized caching, other resources for simple analytics, logging, optimized caching,
etc. It also allows obsolete or mistyped links to be found for etc. It also allows obsolete or mistyped links to be found for
maintenance. Some servers use the Referer header field as a means of maintenance. Some servers use the Referer header field as a means of
denying links from other sites (so-called "deep linking") or denying links from other sites (so-called "deep linking") or
restricting cross-site request forgery (CSRF), but not all requests restricting cross-site request forgery (CSRF), but not all requests
contain it. contain it.
Example: Example:
skipping to change at page 98, line 39 skipping to change at page 100, line 31
Intermediaries and user agent extensions that wish to limit Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with specific edits, such as replacing internal domain names with
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 in a request can be used to indicate that the The "TE" header field describes capabilities of the client with
sender will not discard trailer fields when it contains a "trailers" regard to transfer encodings and trailer sections.
member, as described in Section 6.5.
Additionally, specific HTTP versions can use it to indicate the A TE field with a "trailers" member sent in a request indicates that
transfer codings the client is willing to accept in the response. As the client will not discard trailer fields, as described in
of publication, only HTTP/1.1 uses transfer codings (see Section 7 of Section 6.5.
[Messaging]).
TE is also used within HTTP/1.1 to advise servers about what 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
[HTTP/1.1]).
The TE field value consists of a list of tokens, each allowing for The TE field value consists of a list of tokens, each allowing for
optional parameters (except for the special case "trailers"). optional parameters (except for the special case "trailers").
TE = #t-codings TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ weight ] ) t-codings = "trailers" / ( transfer-coding [ weight ] )
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
A sender of TE MUST also send a "TE" connection option within the A sender of TE MUST also send a "TE" connection option within the
skipping to change at page 100, line 39 skipping to change at page 102, line 36
Likewise, implementations are encouraged not to use the product Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. If a user with them, as this circumvents the purpose of the field. If a user
agent masquerades as a different user agent, recipients can assume agent masquerades as a different user agent, recipients can assume
that the user intentionally desires to see responses tailored for that the user intentionally desires to see responses tailored for
that identified user agent, even if they might not work as well for that identified user agent, even if they might not work as well for
the actual user agent being used. the actual user agent being used.
10.2. Response Context Fields 10.2. Response Context Fields
Response header fields can supply control data that supplements the The response header fields below provide additional information about
status code, directs caching, or instructs the client where to go the response, beyond what is implied by the status code, including
next. information about the server, about the target resource, or about
related resources.
The response header fields allow the server to pass additional
information about the response beyond the status code. These header
fields give information about the server, about further access to the
target resource, or about related resources.
Although each response header field has a defined meaning, in
general, the precise semantics might be further refined by the
semantics of the request method and/or response status code.
The remaining response header fields provide more information about
the target resource for potential use in later requests.
10.2.1. Allow 10.2.1. Allow
The "Allow" header field lists the set of methods advertised as The "Allow" header field lists the set of methods advertised as
supported by the target resource. The purpose of this field is supported by the target resource. The purpose of this field is
strictly to inform the recipient of valid request methods associated strictly to inform the recipient of valid request methods associated
with the resource. with the resource.
Allow = #method Allow = #method
skipping to change at page 102, line 7 skipping to change at page 103, line 37
A sender that generates a Date header field SHOULD generate its field A sender that generates a Date header field SHOULD generate its field
value as the best available approximation of the date and time of value as the best available approximation of the date and time of
message generation. In theory, the date ought to represent the message generation. In theory, the date ought to represent the
moment just before generating the message content. In practice, a moment just before generating the message content. In practice, a
sender can generate the date value at any time during message sender can generate the date value at any time during message
origination. origination.
An origin server MUST NOT send a Date header field if it does not An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the have a clock capable of providing a reasonable approximation of the
current instance in Coordinated Universal Time. An origin server MAY current instant in Coordinated Universal Time. An origin server MAY
send a Date header field if the response is in the 1xx send a Date header field if the response is in the 1xx
(Informational) or 5xx (Server Error) class of status codes. An (Informational) or 5xx (Server Error) class of status codes. An
origin server MUST send a Date header field in all other cases. origin server MUST send a Date header field in all other cases.
A recipient with a clock that receives a response message without a A recipient with a clock that receives a response message without a
Date header field MUST record the time it was received and append a Date header field MUST record the time it was received and append a
corresponding Date header field to the message's header section if it corresponding Date header field to the message's header section if it
is cached or forwarded downstream. is cached or forwarded downstream.
A recipient with a clock that receives a response with an invalid A recipient with a clock that receives a response with an invalid
skipping to change at page 102, line 38 skipping to change at page 104, line 22
10.2.3. Location 10.2.3. Location
The "Location" header field is used in some responses to refer to a The "Location" header field is used in some responses to refer to a
specific resource in relation to the response. The type of specific resource in relation to the response. The type of
relationship is defined by the combination of request method and relationship is defined by the combination of request method and
status code semantics. status code semantics.
Location = URI-reference Location = URI-reference
The field value consists of a single URI-reference. When it has the The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final form of a relative reference ([URI], Section 4.2), the final value is
value is computed by resolving it against the target URI ([RFC3986], computed by resolving it against the target URI ([URI], Section 5).
Section 5).
For 201 (Created) responses, the Location value refers to the primary For 201 (Created) responses, the Location value refers to the primary
resource created by the request. For 3xx (Redirection) responses, resource created by the request. For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for the Location value refers to the preferred target resource for
automatically redirecting the request. automatically redirecting the request.
If the Location value provided in a 3xx (Redirection) response does If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the redirection as if the value inherits the fragment component of the
URI reference used to generate the target URI (i.e., the redirection URI reference used to generate the target URI (i.e., the redirection
skipping to change at page 105, line 44 skipping to change at page 107, line 22
11.2. Authentication Parameters 11.2. Authentication Parameters
The authentication scheme is followed by additional information The authentication scheme is followed by additional information
necessary for achieving authentication via that scheme as either a necessary for achieving authentication via that scheme as either a
comma-separated list of parameters or a single sequence of characters comma-separated list of parameters or a single sequence of characters
capable of holding base64-encoded information. capable of holding base64-encoded information.
token68 = 1*( ALPHA / DIGIT / token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"=" "-" / "." / "_" / "~" / "+" / "/" ) *"="
The token68 syntax allows the 66 unreserved URI characters The token68 syntax allows the 66 unreserved URI characters ([URI]),
([RFC3986]), plus a few others, so that it can hold a base64, plus a few others, so that it can hold a base64, base64url (URL and
base64url (URL and filename safe alphabet), base32, or base16 (hex) filename safe alphabet), base32, or base16 (hex) encoding, with or
encoding, with or without padding, but excluding whitespace without padding, but excluding whitespace ([RFC4648]).
([RFC4648]).
Authentication parameters are name=value pairs, where the name token Authentication parameters are name=value pairs, where the name token
is matched case-insensitively and each parameter name MUST only occur is matched case-insensitively and each parameter name MUST only occur
once per challenge. once per challenge.
auth-param = token BWS "=" BWS ( token / quoted-string ) auth-param = token BWS "=" BWS ( token / quoted-string )
Parameter values can be expressed either as "token" or as "quoted- Parameter values can be expressed either as "token" or as "quoted-
string" (Section 5.6). Authentication scheme definitions need to string" (Section 5.6). Authentication scheme definitions need to
accept both notations, both for senders and recipients, to allow accept both notations, both for senders and recipients, to allow
skipping to change at page 107, line 46 skipping to change at page 109, line 23
(Section 15.5.4). (Section 15.5.4).
HTTP does not restrict applications to this simple challenge-response HTTP does not restrict applications to this simple challenge-response
framework for access authentication. Additional mechanisms can be framework for access authentication. Additional mechanisms can be
used, such as authentication at the transport level or via message used, such as authentication at the transport level or via message
encapsulation, and with additional header fields specifying encapsulation, and with additional header fields specifying
authentication information. However, such additional mechanisms are authentication information. However, such additional mechanisms are
not defined by this specification. not defined by this specification.
Note that various custom mechanisms for user authentication use the Note that various custom mechanisms for user authentication use the
Set-Cookie and Cookie header fields, defined in [RFC6265], for Set-Cookie and Cookie header fields, defined in [COOKIE], for passing
passing tokens related to authentication. tokens related to authentication.
11.5. Establishing a Protection Space (Realm) 11.5. Establishing a Protection Space (Realm)
The _realm_ authentication parameter is reserved for use by The _realm_ authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection. authentication schemes that wish to indicate a scope of protection.
A _protection space_ is defined by the origin (see Section 4.3.1) of A _protection space_ is defined by the origin (see Section 4.3.1) of
the server being accessed, in combination with the realm value if the server being accessed, in combination with the realm value if
present. These realms allow the protected resources on a server to present. These realms allow the protected resources on a server to
be partitioned into a set of protection spaces, each with its own be partitioned into a set of protection spaces, each with its own
skipping to change at page 108, line 39 skipping to change at page 110, line 22
For historical reasons, a sender MUST only generate the quoted-string For historical reasons, a sender MUST only generate the quoted-string
syntax. Recipients might have to support both token and quoted- syntax. Recipients might have to support both token and quoted-
string syntax for maximum interoperability with existing clients that string syntax for maximum interoperability with existing clients that
have been accepting both notations for a long time. have been accepting both notations for a long time.
11.6. Authenticating Users to Origin Servers 11.6. Authenticating Users to Origin Servers
11.6.1. WWW-Authenticate 11.6.1. WWW-Authenticate
The "WWW-Authenticate" header field indicates the authentication The "WWW-Authenticate" response header field indicates the
scheme(s) and parameters applicable to the target resource. authentication scheme(s) and parameters applicable to the target
resource.
WWW-Authenticate = #challenge WWW-Authenticate = #challenge
A server generating a 401 (Unauthorized) response MUST send a WWW- A server generating a 401 (Unauthorized) response MUST send a WWW-
Authenticate header field containing at least one challenge. A Authenticate header field containing at least one challenge. A
server MAY generate a WWW-Authenticate header field in other response server MAY generate a WWW-Authenticate header field in other response
messages to indicate that supplying credentials (or different messages to indicate that supplying credentials (or different
credentials) might affect the response. credentials) might affect the response.
A proxy forwarding a response MUST NOT modify any WWW-Authenticate A proxy forwarding a response MUST NOT modify any WWW-Authenticate
skipping to change at page 109, line 49 skipping to change at page 111, line 33
Authorization = credentials Authorization = credentials
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials are presumed to be valid for all other requests within credentials are presumed to be valid for all other requests within
this realm (assuming that the authentication scheme itself does not this realm (assuming that the authentication scheme itself does not
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 response
field to communicate information after the client's authentication field to communicate information after the client's authentication
credentials have been accepted. This information can include a credentials have been accepted. This information can include a
finalization message from the server (e.g., it can contain the server finalization message from the server (e.g., it can contain the server
authentication). authentication).
skipping to change at page 113, line 21 skipping to change at page 114, line 47
available representations for a response (the dimensions over which available representations for a response (the dimensions over which
it might vary, such as language, content coding, etc.) compared to it might vary, such as language, content coding, etc.) compared to
various information supplied in the request, including both the various information supplied in the request, including both the
explicit negotiation header fields below and implicit explicit negotiation header fields below and implicit
characteristics, such as the client's network address or parts of the characteristics, such as the client's network address or parts of the
User-Agent field. User-Agent field.
Proactive negotiation is advantageous when the algorithm for Proactive negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to selecting from among the available representations is difficult to
describe to a user agent, or when the server desires to send its describe to a user agent, or when the server desires to send its
"best guess" to the user agent along with the first response (hoping "best guess" to the user agent along with the first response (when
to avoid the round trip delay of a subsequent request if the "best that "best guess" is good enough for the user, this avoids the round
guess" is good enough for the user). In order to improve the trip delay of a subsequent request). In order to improve the
server's guess, a user agent MAY send request header fields that server's guess, a user agent MAY send request header fields that
describe its preferences. describe its preferences.
Proactive negotiation has serious disadvantages: Proactive negotiation has serious disadvantages:
* It is impossible for the server to accurately determine what might * It is impossible for the server to accurately determine what might
be "best" for any given user, since that would require complete be "best" for any given user, since that would require complete
knowledge of both the capabilities of the user agent and the knowledge of both the capabilities of the user agent and the
intended use for the response (e.g., does the user want to view it intended use for the response (e.g., does the user want to view it
on screen or print it on paper?); on screen or print it on paper?);
skipping to change at page 115, line 20 skipping to change at page 117, line 4
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
axis of negotiation. dimension of negotiation.
If a content negotiation header field is present in a request and If a content negotiation header field is present in a request and
none of the available representations for the response can be none of the available representations for the response can be
considered acceptable according to it, the origin server can either considered acceptable according to it, the origin server can either
honor the header field by sending a 406 (Not Acceptable) response or honor the header field by sending a 406 (Not Acceptable) response or
disregard the header field by treating the response as if it is not disregard the header field by treating the response as if it is not
subject to content negotiation for that request header field. This subject to content negotiation for that request header field. This
does not imply, however, that the client will be able to use the does not imply, however, that the client will be able to use the
representation. representation.
| *Note:* Sending these header fields makes it easier for a | *Note:* A user agent sending these header fields makes it
| server to identify an individual by virtue of the user agent's | easier for a server to identify an individual by virtue of the
| request characteristics (Section 17.13). | user agent's request characteristics (Section 17.13).
12.4.2. Quality Values 12.4.2. Quality Values
The content negotiation fields defined by this specification use a The content negotiation fields defined by this specification use a
common parameter, named "q" (case-insensitive), to assign a relative common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This "weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to same parameter name is often used within server configurations to
assign a weight to the relative quality of the various assign a weight to the relative quality of the various
representations that can be selected for a resource. representations that can be selected for a resource.
skipping to change at page 116, line 23 skipping to change at page 118, line 10
A sender of qvalue MUST NOT generate more than three digits after the A sender of qvalue MUST NOT generate more than three digits after the
decimal point. User configuration of these values ought to be decimal point. User configuration of these values ought to be
limited in the same fashion. limited in the same fashion.
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, except for within Vary where it means the variance is unacceptable. Within Vary, the wildcard value means that the
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 example, "I prefer image/* more or less than (some other | for example, "I prefer image/* more or less than (some other
| specific value)". Clients can explicitly request a 406 (Not | specific value)". Clients can explicitly request a 406 (Not
| Acceptable) response if a more preferred format is not | Acceptable) response if a more preferred format is not
| available by sending Accept: */*;q=0, but they still need to be | available by sending Accept: */*;q=0, 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 to ignore their preference. | allowed to ignore their preference.
skipping to change at page 117, line 23 skipping to change at page 119, line 7
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range might be followed by optional applicable media type Each media-range might be followed by optional applicable media type
parameters (e.g., charset), followed by an optional "q" parameter for parameters (e.g., charset), followed by an optional "q" parameter for
indicating a relative weight (Section 12.4.2). indicating a relative weight (Section 12.4.2).
Previous specifications allowed additional extension parameters to Previous specifications allowed additional extension parameters to
appear after the weight parameter. The accept extension grammar appear after the weight parameter. The accept extension grammar
(accept-ext) has been removed because it had a complicated (accept-params, accept-ext) has been removed because it had a
definition, was not being used in practice, and is more easily complicated definition, was not being used in practice, and is more
deployed through new header fields. Senders using weights SHOULD easily deployed through new header fields. Senders using weights
send "q" last (after all media-range parameters). Recipients SHOULD SHOULD send "q" last (after all media-range parameters). Recipients
process any parameter named "q" as weight, regardless of parameter SHOULD process any parameter named "q" as weight, regardless of
ordering. parameter ordering.
| *Note:* Use of the "q" parameter name to control content | *Note:* Use of the "q" parameter name to control content
| negotiation is due to historical practice. Although this | negotiation is due to historical practice. Although this
| prevents any media type parameter named "q" from being used | prevents any media type parameter named "q" from being used
| with a media range, such an event is believed to be unlikely | with a media range, such an event is believed to be unlikely
| given the lack of any "q" parameters in the IANA media type | given the lack of any "q" parameters in the IANA media type
| registry and the rare usage of any media type parameters in | registry and the rare usage of any media type parameters in
| Accept. Future media types are discouraged from registering | Accept. Future media types are discouraged from registering
| any parameter named "q". | any parameter named "q".
skipping to change at page 123, line 32 skipping to change at page 125, line 11
indicates that the origin server might have used the request's indicates that the origin server might have used the request's
Accept-Encoding and Accept-Language header fields (or lack thereof) Accept-Encoding and Accept-Language header fields (or lack thereof)
as determining factors while choosing the content for this response. as determining factors while choosing the content for this response.
An origin server might send Vary with a list of header fields for two An origin server might send Vary with a list of header fields for two
purposes: purposes:
1. To inform cache recipients that they MUST NOT use this response 1. To inform cache recipients that they MUST NOT use this response
to satisfy a later request unless the later request has the same to satisfy a later request unless the later request has the same
values for the listed header fields as the original request values for the listed header fields as the original request
(Section 4.1 of [Caching]). In other words, Vary expands the (Section 4.1 of [CACHING]). In other words, Vary expands the
cache key required to match a new request to the stored cache cache key required to match a new request to the stored cache
entry. entry.
2. To inform user agent recipients that this response is subject to 2. To inform user agent recipients that this response is subject to
content negotiation (Section 12) and that a different content negotiation (Section 12) and that a different
representation might be sent in a subsequent request if representation might be sent in a subsequent request if
additional parameters are provided in the listed header fields additional parameters are provided in the listed header fields
(proactive negotiation). (proactive negotiation).
An origin server SHOULD send a Vary header field when its algorithm An origin server SHOULD send a Vary header field when its algorithm
for selecting a representation varies based on aspects of the request for selecting a representation varies based on aspects of the request
message other than the method and target URI, unless the variance message other than the method and target URI, unless the variance
cannot be crossed or the origin server has been deliberately cannot be crossed or the origin server has been deliberately
configured to prevent cache transparency. For example, there is no configured to prevent cache transparency. For example, there is no
need to send the Authorization field name in Vary because reuse need to send the Authorization field name in Vary because reuse
across users is constrained by the field definition (Section 11.6.2). across users is constrained by the field definition (Section 11.6.2).
Likewise, an origin server might use Cache-Control response Likewise, an origin server might use Cache-Control response
directives (Section 5.2 of [Caching]) to supplant Vary if it directives (Section 5.2 of [CACHING]) to supplant Vary if it
considers the variance less significant than the performance cost of considers the variance less significant than the performance cost of
Vary's impact on caching. Vary's impact on caching.
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
when more than one precondition is present. when more than one precondition is present.
Conditional GET requests are the most efficient mechanism for HTTP Conditional GET requests are the most efficient mechanism for HTTP
cache updates [Caching]. Conditionals can also be applied to state- cache updates [CACHING]. Conditionals can also be applied to state-
changing methods, such as PUT and DELETE, to prevent the "lost changing methods, such as PUT and DELETE, to prevent the "lost
update" problem: one client accidentally overwriting the work of update" problem: one client accidentally overwriting the work of
another client that has been acting in parallel. another client that has been acting in parallel.
13.1. Preconditions 13.1. Preconditions
Preconditions are usually defined with respect to a state of the Preconditions are usually defined with respect to a state of the
target resource as a whole (its current value set) or the state as target resource as a whole (its current value set) or the state as
observed in a previously obtained representation (one value in that observed in a previously obtained representation (one value in that
set). If a resource has multiple current representations, each with set). If a resource has multiple current representations, each with
skipping to change at page 124, line 45 skipping to change at page 126, line 31
whether the state of the target resource has changed since a given whether the state of the target resource has changed since a given
state known by the client. The effect of such an evaluation depends state known by the client. The effect of such an evaluation depends
on the method semantics and choice of conditional, as defined in on the method semantics and choice of conditional, as defined in
Section 13.2. Section 13.2.
Other preconditions, defined by other specifications as extension Other preconditions, defined by other specifications as extension
fields, might place conditions on all recipients, on the state of the fields, might place conditions on all recipients, on the state of the
target resource in general, or on a group of resources. For target resource in general, or on a group of resources. For
instance, the "If" header field in WebDAV can make a request instance, the "If" header field in WebDAV can make a request
conditional on various aspects of multiple resources, such as locks, conditional on various aspects of multiple resources, such as locks,
if the recipient understands and implements that field ([RFC4918], if the recipient understands and implements that field ([WEBDAV],
Section 10.4). Section 10.4).
Extensibility of preconditions is only possible when the precondition Extensibility of preconditions is only possible when the precondition
can be safely ignored if unknown (like If-Modified-Since), when can be safely ignored if unknown (like If-Modified-Since), when
deployment can be assumed for a given use case, or when deployment can be assumed for a given use case, or when
implementation is signaled by some other property of the target implementation is signaled by some other property of the target
resource. This encourages a focus on mutually agreed deployment of resource. This encourages a focus on mutually agreed deployment of
common standards. common standards.
13.1.1. If-Match 13.1.1. If-Match
skipping to change at page 126, line 35 skipping to change at page 128, line 22
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.
The If-Match header field can be ignored by caches and intermediaries The If-Match header field can be ignored by caches and intermediaries
because it is not applicable to a stored response. because it is not applicable to a stored response.
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 unlikely to be and other values (including other instances of "*") is syntactically
interoperable. invalid (therefore not allowed to be generated) and furthermore is
unlikely to be interoperable.
13.1.2. If-None-Match 13.1.2. If-None-Match
The "If-None-Match" header field makes the request method conditional The "If-None-Match" header field makes the request method conditional
on a recipient cache or origin server either not having any current on a recipient cache or origin server either not having any current
representation of the target resource, when the field value is "*", representation of the target resource, when the field value is "*",
or having a selected representation with an entity-tag that does not or having a selected representation with an entity-tag that does not
match any of those listed in the field value. match any of those listed in the field value.
A recipient MUST use the weak comparison function when comparing A recipient MUST use the weak comparison function when comparing
skipping to change at page 127, line 52 skipping to change at page 129, line 39
3. Otherwise, the condition is true. 3. Otherwise, the condition is true.
An origin server MUST NOT perform the requested method if a received An origin server MUST NOT perform the requested method if a received
If-None-Match condition evaluates to false; instead, the origin If-None-Match condition evaluates to false; instead, the origin
server MUST respond with either a) the 304 (Not Modified) status code server MUST respond with either a) the 304 (Not Modified) status code
if the request method is GET or HEAD or b) the 412 (Precondition if the request method is GET or HEAD or b) the 412 (Precondition
Failed) status code for all other request methods. Failed) status code for all other request methods.
Requirements on cache handling of a received If-None-Match header Requirements on cache handling of a received If-None-Match header
field are defined in Section 4.3.2 of [Caching]. field are defined in Section 4.3.2 of [CACHING].
Note that an If-None-Match header field with a list value containing Note that an If-None-Match header field with a list value containing
"*" and other values (including other instances of "*") is unlikely "*" and other values (including other instances of "*") is
to be interoperable. syntactically invalid (therefore not allowed to be generated) and
furthermore is unlikely to be interoperable.
13.1.3. If-Modified-Since 13.1.3. If-Modified-Since
The "If-Modified-Since" header field makes a GET or HEAD request The "If-Modified-Since" header field makes a GET or HEAD request
method conditional on the selected representation's modification date method conditional on the selected representation's modification date
being more recent than the date provided in the field value. being more recent than the date provided in the field value.
Transfer of the selected representation's data is avoided if that Transfer of the selected representation's data is avoided if that
data has not changed. data has not changed.
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
skipping to change at page 129, line 46 skipping to change at page 131, line 33
2. Otherwise, the condition is true. 2. Otherwise, the condition is true.
An origin server SHOULD NOT perform the requested method if a An origin server SHOULD NOT perform the requested method if a
received If-Modified-Since condition evaluates to false; instead, the received If-Modified-Since condition evaluates to false; instead, the
origin server SHOULD generate a 304 (Not Modified) response, origin server SHOULD generate a 304 (Not Modified) response,
including only those metadata that are useful for identifying or including only those metadata that are useful for identifying or
updating a previously cached response. updating a previously cached response.
Requirements on cache handling of a received If-Modified-Since header Requirements on cache handling of a received If-Modified-Since header
field are defined in Section 4.3.2 of [Caching]. field are defined in Section 4.3.2 of [CACHING].
13.1.4. If-Unmodified-Since 13.1.4. If-Unmodified-Since
The "If-Unmodified-Since" header field makes the request method The "If-Unmodified-Since" header field makes the request method
conditional on the selected representation's last modification date conditional on the selected representation's last modification date
being earlier than or equal to the date provided in the field value. being earlier than or equal to the date provided in the field value.
This field accomplishes the same purpose as If-Match for cases where This field accomplishes the same purpose as If-Match for cases where
the user agent does not have an entity-tag for the representation. the user agent does not have an entity-tag for the representation.
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
skipping to change at page 132, line 46 skipping to change at page 134, line 33
1. If the entity-tag validator provided exactly matches the ETag 1. If the entity-tag validator provided exactly matches the ETag
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 by exact match, including when the Note that the If-Range comparison is by exact match, including when
validator is an HTTP-date, differs from the "earlier than or equal the validator is an HTTP-date, and so differs from the "earlier than
to" comparison used when evaluating an If-Unmodified-Since or equal to" comparison used when evaluating an If-Unmodified-Since
conditional. 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
to processing the request content, would have been a status code to processing the request content, would have been a status code
other than a 2xx (Successful) or 412 (Precondition Failed). In other other than a 2xx (Successful) or 412 (Precondition Failed). In other
skipping to change at page 133, line 30 skipping to change at page 135, line 17
evaluate the conditional request header fields defined by this evaluate the conditional request header fields defined by this
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
revalidation is triggered. For example, the "immutable" cache preconditions are evaluated or the consequences of their evaluation.
directive (defined by [RFC8246]) instructs caches to forgo For example, the "immutable" cache directive (defined by [RFC8246])
revalidation of fresh responses even when requested by the client. instructs caches to forgo forwarding conditional requests 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 135, line 4 skipping to change at page 136, line 40
* if false, respond 304 (Not Modified) * if false, respond 304 (Not Modified)
5. When the method is GET and both Range and If-Range are present, 5. When the method is GET and both Range and If-Range are present,
evaluate the If-Range precondition: evaluate the If-Range precondition:
* if the validator matches and the Range specification is * if the validator matches and the Range specification is
applicable to the selected representation, respond 206 applicable to the selected representation, respond 206
(Partial Content) (Partial Content)
6. Otherwise, 6. Otherwise,
* all conditions are met, so perform the requested action and * all conditions are met, so perform the requested action and
respond according to its success or failure. respond according to its success or failure.
Any extension to HTTP that defines additional conditional request Any extension to HTTP that defines additional conditional request
header fields ought to define its own expectations regarding the header fields ought to define the order for evaluating such fields in
order for evaluating such fields in relation to those defined in this relation to those defined in this document and other conditionals
document and other conditionals that might be found in practice. that might be found in practice.
14. Range Requests 14. Range Requests
Clients often encounter interrupted data transfers as a result of Clients often encounter interrupted data transfers as a result of
canceled requests or dropped connections. When a client has stored a canceled requests or dropped connections. When a client has stored a
partial representation, it is desirable to request the remainder of partial representation, it is desirable to request the remainder of
that representation in a subsequent request rather than transfer the that representation in a subsequent request rather than transfer the
entire representation. Likewise, devices with limited local storage entire representation. Likewise, devices with limited local storage
might benefit from being able to request only a subset of a larger might benefit from being able to request only a subset of a larger
representation, such as a single page of a very large document, or representation, such as a single page of a very large document, or
skipping to change at page 135, line 49 skipping to change at page 137, line 42
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.
range-unit = token range-unit = token
All range unit names are case-insensitive and ought to be registered All range unit names are case-insensitive and ought to be registered
within the "HTTP Range Unit Registry", as defined in Section 16.5.1 within the "HTTP Range Unit Registry", as defined in Section 16.5.1.
Range units are intended to be extensible, as described in Range units are intended to be extensible, as described in
Section 16.5. Section 16.5.
14.1.1. Range Specifiers 14.1.1. Range Specifiers
Ranges are expressed in terms of a range unit paired with a set of Ranges are expressed in terms of a range unit paired with a set of
range specifiers. The range unit name determines what kinds of range specifiers. The range unit name determines what kinds of
range-spec are applicable to its own specifiers. Hence, the range-spec are applicable to its own specifiers. Hence, the
following gramar is generic: each range unit is expected to specify following grammar is generic: each range unit is expected to specify
requirements on when int-range, suffix-range, and other-range are requirements on when int-range, suffix-range, and other-range are
allowed. allowed.
A range request can specify a single range or a set of ranges within A range request can specify a single range or a set of ranges within
a single representation. a single representation.
ranges-specifier = range-unit "=" range-set ranges-specifier = range-unit "=" range-set
range-set = 1#range-spec range-set = 1#range-spec
range-spec = int-range range-spec = int-range
/ suffix-range / suffix-range
skipping to change at page 140, line 18 skipping to change at page 142, line 18
client to re-request the remaining portions later if they are still client to re-request the remaining portions later if they are still
desired (see Section 15.3.7). desired (see Section 15.3.7).
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are header field for the target resource, and the specified range(s) are
invalid or unsatisfiable, the server SHOULD send a 416 (Range Not invalid or unsatisfiable, the server SHOULD send a 416 (Range Not
Satisfiable) response. Satisfiable) response.
14.3. Accept-Ranges 14.3. Accept-Ranges
The "Accept-Ranges" header field allows a server to indicate that it The "Accept-Ranges" field in a response indicates whether an upstream
supports range requests for the target resource. server supports range requests for the target resource.
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
acceptable-ranges = 1#range-unit / "none" acceptable-ranges = 1#range-unit
An origin server that supports byte-range requests for a given target For example, a server that supports byte-range requests
resource MAY send (Section 14.1.2) can send the field
Accept-Ranges: bytes Accept-Ranges: bytes
to indicate what range units are supported. A client MAY generate to indicate that it supports byte range requests for that target
range requests without having received this header field for the resource, thereby encouraging its use by the client for future
resource involved. Range units are defined in Section 14.1. partial requests on the same request path. Range units are defined
in Section 14.1.
A client MAY generate range requests regardless of having received an
Accept-Ranges field. The information only provides advice for the
sake of improving performance and reducing unnecessary network
transfers.
Conversely, a client MUST NOT assume that receiving an Accept-Ranges
field means that future range requests will return partial responses.
The content might change, the server might only support range
requests at certain times or under certain conditions, or a different
intermediary might process the next request.
A server that does not support any kind of range request for the A server that does not support any kind of range request for the
target resource MAY send target resource MAY send
Accept-Ranges: none Accept-Ranges: none
to advise the client not to attempt a range request. to advise the client not to attempt a range request on the same
request path. The range unit "none" is reserved for this purpose.
The Accept-Ranges field MAY be sent in a trailer section, but is
preferred to be sent as a header field because the information is
particularly useful for restarting large information transfers that
have failed in mid-content (before the trailer section is received).
14.4. Content-Range 14.4. Content-Range
The "Content-Range" header field is sent in a single part 206 The "Content-Range" header field is sent in a single part 206
(Partial Content) response to indicate the partial range of the (Partial Content) response to indicate the partial range of the
selected representation enclosed as the message content, sent in each selected representation enclosed as the message content, sent in each
part of a multipart 206 response to indicate the range enclosed part of a multipart 206 response to indicate the range enclosed
within each body part, and sent in 416 (Range Not Satisfiable) within each body part, and sent in 416 (Range Not Satisfiable)
responses to provide information about the selected representation. responses to provide information about the selected representation.
skipping to change at page 146, line 33 skipping to change at page 148, line 40
The status codes listed below are defined in this specification. The The status codes listed below are defined in this specification. The
reason phrases listed here are only recommendations - they can be reason phrases listed here are only recommendations - they can be
replaced by local equivalents or left out altogether without replaced by local equivalents or left out altogether without
affecting the protocol. affecting the protocol.
Responses with status codes that are defined as heuristically Responses with status codes that are defined as heuristically
cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,
414, and 501 in this specification) can be reused by a cache with 414, and 501 in this specification) can be reused by a cache with
heuristic expiration unless otherwise indicated by the method heuristic expiration unless otherwise indicated by the method
definition or explicit cache controls [Caching]; all other status definition or explicit cache controls [CACHING]; all other status
codes are not heuristically cacheable. codes are not heuristically cacheable.
Additional status codes, outside the scope of this specification, Additional status codes, outside the scope of this specification,
have been specified for use in HTTP. All such status codes ought to have been specified for use in HTTP. All such status codes ought to
be registered within the "Hypertext Transfer Protocol (HTTP) Status be registered within the "Hypertext Transfer Protocol (HTTP) Status
Code Registry", as described in Section 16.2. Code Registry", as described in Section 16.2.
15.2. Informational 1xx 15.2. Informational 1xx
The _1xx (Informational)_ class of status code indicates an interim The _1xx (Informational)_ class of status code indicates an interim
skipping to change at page 148, line 34 skipping to change at page 150, line 45
+----------------+--------------------------------------------+ +----------------+--------------------------------------------+
| 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 |
| | server returning the trace | | | server returning the trace |
+----------------+--------------------------------------------+ +----------------+--------------------------------------------+
Table 6 Table 6
Aside from responses to CONNECT, a 200 response always has content, Aside from responses to CONNECT, a 200 response is expected to
though an origin server MAY generate content of zero length. If no contain message content unless the message framing explicitly
content is desired, an origin server ought to send _204 (No Content)_ indicates that the content has zero length. If some aspect of the
instead. For CONNECT, no content is allowed because the successful request indicates a preference for no content upon success, the
result is a tunnel, which begins immediately after the 200 response origin server ought to send a _204 (No Content)_ response instead.
header section. For CONNECT, there is no content because the successful result is a
tunnel, which begins immediately after the 200 response header
section.
A 200 response is heuristically cacheable; i.e., unless otherwise A 200 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.3.2. 201 Created 15.3.2. 201 Created
The _201 (Created)_ status code indicates that the request has been The _201 (Created)_ status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
header field is received, by the target URI. header field is received, by the target URI.
The 201 response content typically describes and links to the The 201 response content typically describes and links to the
skipping to change at page 149, line 41 skipping to change at page 152, line 7
the request was successful but the enclosed content has been modified the request was successful but the enclosed content has been modified
from that of the origin server's 200 (OK) response by a transforming from that of the origin server's 200 (OK) response by a transforming
proxy (Section 7.7). This status code allows the proxy to notify proxy (Section 7.7). This status code allows the proxy to notify
recipients when a transformation has been applied, since that recipients when a transformation has been applied, since that
knowledge might impact later decisions regarding the content. For knowledge might impact later decisions regarding the content. For
example, future cache validation requests for the content might only example, future cache validation requests for the content might only
be applicable along the same request path (through the same proxies). be applicable along the same request path (through the same proxies).
A 203 response is heuristically cacheable; i.e., unless otherwise A 203 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.3.5. 204 No Content 15.3.5. 204 No Content
The _204 (No Content)_ status code indicates that the server has The _204 (No Content)_ status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response content. Metadata in the response content to send in the response content. Metadata in the response
header fields refer to the target resource and its selected header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
skipping to change at page 150, line 29 skipping to change at page 152, line 41
interfaces corresponding to a "save" action, such that the document interfaces corresponding to a "save" action, such that the document
being saved remains available to the user for editing. It is also being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems. to be prevalent, such as within distributed version control systems.
A 204 response is terminated by the end of the header section; it A 204 response is terminated by the end of the header section; it
cannot contain content or trailers. cannot contain content or trailers.
A 204 response is heuristically cacheable; i.e., unless otherwise A 204 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.3.6. 205 Reset Content 15.3.6. 205 Reset Content
The _205 (Reset Content)_ status code indicates that the server has The _205 (Reset Content)_ status code indicates that the server has
fulfilled the request and desires that the user agent reset the fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original "document view", which caused the request to be sent, to its original
state as received from the origin server. state as received from the origin server.
This response is intended to support a common data entry use case This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form, where the user receives content that supports data entry (a form,
skipping to change at page 151, line 30 skipping to change at page 153, line 42
below, if the field would have been sent in a 200 (OK) response to below, if the field would have been sent in a 200 (OK) response to
the same request: Date, Cache-Control, ETag, Expires, the same request: Date, Cache-Control, ETag, Expires,
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 with an If-Range header field A sender that generates a 206 response to a request with an If-Range
SHOULD NOT generate other representation header fields beyond those header field SHOULD NOT generate other representation header fields
required, because the client already has a prior response containing beyond those required, because the client already has a prior
those header fields. Otherwise, a sender MUST generate all of the response containing those header fields. Otherwise, a sender MUST
representation header fields that would have been sent in a 200 (OK) generate all of the representation header fields that would have been
response to the same request. sent in 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
consisting of the range. For example: consisting of the range. For example:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT Date: Wed, 15 Nov 1995 06:25:24 GMT
skipping to change at page 155, line 48 skipping to change at page 158, line 24
4. Change the request method according to the redirecting status 4. Change the request method according to the redirecting status
code's semantics, if applicable. code's semantics, if applicable.
5. If the request method has been changed to GET or HEAD, remove 5. If the request method has been changed to GET or HEAD, remove
content-specific header fields, including (but not limited to) content-specific header fields, including (but not limited to)
Content-Encoding, Content-Language, Content-Location, Content-Encoding, Content-Language, Content-Location,
Content-Type, Content-Length, Digest, ETag, Last-Modified. Content-Type, Content-Length, Digest, ETag, Last-Modified.
| *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently) | *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
| and 302 (Found) were defined for the first type of redirect | and 302 (Found) were defined for the first type of redirect
| ([RFC1945], Section 9.3). Early user agents split on whether | ([HTTP/1.0], Section 9.3). Early user agents split on whether
| the method applied to the redirect target would be the same as | the method applied to the redirect target would be the same as
| the original request or would be rewritten as GET. Although | the original request or would be rewritten as GET. Although
| HTTP originally defined the former semantics for 301 and 302 | HTTP originally defined the former semantics for 301 and 302
| (to match its original implementation at CERN), and defined 303 | (to match its original implementation at CERN), and defined 303
| (See Other) to match the latter semantics, prevailing practice | (See Other) to match the latter semantics, prevailing practice
| gradually converged on the latter semantics for 301 and 302 as | gradually converged on the latter semantics for 301 and 302 as
| well. The first revision of HTTP/1.1 added 307 (Temporary | well. The first revision of HTTP/1.1 added 307 (Temporary
| Redirect) to indicate the former semantics of 302 without being | Redirect) to indicate the former semantics of 302 without being
| impacted by divergent practice. For the same reason, 308 | impacted by divergent practice. For the same reason, 308
| (Permanent Redirect) was later on added in [RFC7538] to match | (Permanent Redirect) was later on added in [RFC7538] to match
skipping to change at page 157, line 7 skipping to change at page 159, line 35
from that list automatically if it understands the provided media from that list automatically if it understands the provided media
type. A specific format for automatic selection is not defined by type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the this specification because HTTP tries to remain orthogonal to the
definition of its content. In practice, the representation is definition of its content. In practice, the representation is
provided in some easily parsed format believed to be acceptable to provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format. negotiation, or in some commonly accepted hypertext format.
A 300 response is heuristically cacheable; i.e., unless otherwise A 300 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:* The original proposal for the 300 status code defined | *Note:* The original proposal for the 300 status code defined
| the URI header field as providing a list of alternative | the URI header field as providing a list of alternative
| representations, such that it would be usable for 200, 300, and | representations, such that it would be usable for 200, 300, and
| 406 responses and be transferred in responses to the HEAD | 406 responses and be transferred in responses to the HEAD
| method. However, lack of deployment and disagreement over | method. However, lack of deployment and disagreement over
| syntax led to both URI and Alternates (a subsequent proposal) | syntax led to both URI and Alternates (a subsequent proposal)
| being dropped from this specification. It is possible to | being dropped from this specification. It is possible to
| communicate the list as a Link header field value [RFC8288] | communicate the list as a Link header field value [RFC8288]
| whose members have a relationship of "alternate", though | whose members have a relationship of "alternate", though
skipping to change at page 157, line 42 skipping to change at page 160, line 27
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).
| *Note:* For historical reasons, a user agent MAY change the | *Note:* For historical reasons, a user agent MAY change the
| request method from POST to GET for the subsequent request. If | request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 308 (Permanent Redirect) status | this behavior is undesired, the 308 (Permanent Redirect) status
| code can be used instead. | code can be used instead.
A 301 response is heuristically cacheable; i.e., unless otherwise A 301 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.4.3. 302 Found 15.4.3. 302 Found
The _302 (Found)_ status code indicates that the target resource The _302 (Found)_ status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
target URI for future requests. target URI for future requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
skipping to change at page 159, line 30 skipping to change at page 162, line 18
ETag, Expires, and Vary. ETag, Expires, and Vary.
Since the goal of a 304 response is to minimize information transfer Since the goal of a 304 response is to minimize information transfer
when the recipient already has one or more cached representations, a when the recipient already has one or more cached representations, a
sender SHOULD NOT generate representation metadata other than the sender SHOULD NOT generate representation metadata other than the
above listed fields unless said metadata exists for the purpose of above listed fields unless said metadata exists for the purpose of
guiding cache updates (e.g., Last-Modified might be useful if the guiding cache updates (e.g., Last-Modified might be useful if the
response does not have an ETag field). response does not have an ETag field).
Requirements on a cache that receives a 304 response are defined in Requirements on a cache that receives a 304 response are defined in
Section 4.3.4 of [Caching]. If the conditional request originated Section 4.3.4 of [CACHING]. If the conditional request originated
with an outbound client, such as a user agent with its own cache with an outbound client, such as a user agent with its own cache
sending a conditional GET to a shared proxy, then the proxy SHOULD sending a conditional GET to a shared proxy, then the proxy SHOULD
forward the 304 response to that client. forward the 304 response to that client.
A 304 response is terminated by the end of the header section; it A 304 response is terminated by the end of the header section; it
cannot contain content or trailers. cannot contain content or trailers.
15.4.6. 305 Use Proxy 15.4.6. 305 Use Proxy
The _305 (Use Proxy)_ status code was defined in a previous version The _305 (Use Proxy)_ status code was defined in a previous version
skipping to change at page 160, line 37 skipping to change at page 163, line 22
sent by the server, where possible. sent by the server, where possible.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
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 Section 4 of [RFC7538] for deployment considerations. | See 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
skipping to change at page 162, line 17 skipping to change at page 164, line 48
The _404 (Not Found)_ status code indicates that the origin server The _404 (Not Found)_ status code indicates that the origin server
did not find a current representation for the target resource or is did not find a current representation for the target resource or is
not willing to disclose that one exists. A 404 status code does not not willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that origin server knows, presumably through some configurable means, that
the condition is likely to be permanent. the condition is likely to be permanent.
A 404 response is heuristically cacheable; i.e., unless otherwise A 404 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.6. 405 Method Not Allowed 15.5.6. 405 Method Not Allowed
The _405 (Method Not Allowed)_ status code indicates that the method The _405 (Method Not Allowed)_ status code indicates that the method
received in the request-line is known by the origin server but not received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target Allow header field in a 405 response containing a list of the target
resource's currently supported methods. resource's currently supported methods.
A 405 response is heuristically cacheable; i.e., unless otherwise A 405 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.7. 406 Not Acceptable 15.5.7. 406 Not Acceptable
The _406 (Not Acceptable)_ status code indicates that the target The _406 (Not Acceptable)_ status code indicates that the target
resource does not have a current representation that would be resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 12.1), and the server header fields received in the request (Section 12.1), and the server
is unwilling to supply a default representation. is unwilling to supply a default representation.
The server SHOULD generate content containing a list of available The server SHOULD generate content containing a list of available
skipping to change at page 164, line 17 skipping to change at page 166, line 43
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server's site. It individuals no longer associated with the origin server's site. It
is not necessary to mark all permanently unavailable resources as is not necessary to mark all permanently unavailable resources as
"gone" or to keep the mark for any length of time - that is left to "gone" or to keep the mark for any length of time - that is left to
the discretion of the server owner. the discretion of the server owner.
A 410 response is heuristically cacheable; i.e., unless otherwise A 410 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.12. 411 Length Required 15.5.12. 411 Length Required
The _411 (Length Required)_ status code indicates that the server The _411 (Length Required)_ status code indicates that the server
refuses to accept the request without a defined Content-Length refuses to accept the request without a defined Content-Length
(Section 8.6). The client MAY repeat the request if it adds a valid (Section 8.6). The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the request Content-Length header field containing the length of the request
content. content.
15.5.13. 412 Precondition Failed 15.5.13. 412 Precondition Failed
skipping to change at page 165, line 18 skipping to change at page 167, line 40
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 a "black hole" of redirection (e.g., a redirected URI
prefix that points to a suffix of itself) or when the server is under prefix that points to a suffix of itself) or when the server is under
attack by a client attempting to exploit potential security holes. 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.
skipping to change at page 167, line 18 skipping to change at page 169, line 32
was directed at a server that is unable or unwilling to produce an was directed at a server that is unable or unwilling to produce an
authoritative response for the target URI. An origin server (or authoritative response for the target URI. An origin server (or
gateway acting on behalf of the origin server) sends 421 to reject a gateway acting on behalf of the origin server) sends 421 to reject a
target URI that does not match an origin for which the server has target URI that does not match an origin for which the server has
been configured (Section 4.3.1) or does not match the connection been configured (Section 4.3.1) or does not match the connection
context over which the request was received (Section 7.4). 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 [RFC7838]. 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 server
understands the content type of the request content (hence a 415 understands the content type of the request content (hence a 415
(Unsupported Media Type) status code is inappropriate), and the (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 was unable to process
the contained instructions. For example, this status code can be the contained instructions. For example, this status code can be
skipping to change at page 168, line 32 skipping to change at page 170, line 42
15.6.2. 501 Not Implemented 15.6.2. 501 Not Implemented
The _501 (Not Implemented)_ status code indicates that the server The _501 (Not Implemented)_ status code indicates that the server
does not support the functionality required to fulfill the request. does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize This is the appropriate response when the server does not recognize
the request method and is not capable of supporting it for any the request method and is not capable of supporting it for any
resource. resource.
A 501 response is heuristically cacheable; i.e., unless otherwise A 501 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.6.3. 502 Bad Gateway 15.6.3. 502 Bad Gateway
The _502 (Bad Gateway)_ status code indicates that the server, while The _502 (Bad Gateway)_ status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request. inbound server it accessed while attempting to fulfill the request.
15.6.4. 503 Service Unavailable 15.6.4. 503 Service Unavailable
The _503 (Service Unavailable)_ status code indicates that the server The _503 (Service Unavailable)_ status code indicates that the server
skipping to change at page 169, line 30 skipping to change at page 171, line 43
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-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 [Messaging]) and HTTP/2 ([RFC7540]) SETTINGS or frame (Section 6.1 of [HTTP/1.1]) and HTTP/2 ([HTTP/2]) SETTINGS or frame
types. These extension points are specific to the version of the types. These extension points are specific to the version of the
protocol they occur within. 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
skipping to change at page 172, line 32 skipping to change at page 174, line 44
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 status code ought to specify whether or not The definition of a new final status code ought to specify whether or
it is cacheable. Note that all status codes can be cached if the not it is heuristically cacheable. Note that all final status codes
response they occur in has explicit freshness information; however, can be cached if the response they occur in has explicit freshness
status codes that are defined as being cacheable are allowed to be information; however, those status codes that are defined as being
cached without explicit freshness information. Likewise, the heuristically cacheable are allowed to be cached without explicit
definition of a status code can place constraints upon cache freshness information. Likewise, the definition of a status code can
behavior. See [Caching] for more information. place constraints upon cache behavior, if the 'must-understand' cache
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 173, line 28 skipping to change at page 175, line 42
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines
the namespace for HTTP field names. the namespace for HTTP field names.
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@ietf.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 at least the following information: Registration requests consist of at least 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 SHOULD be restricted to just
letters, digits, hyphen ('-') and underscore ('_') characters, letters, digits, and hyphen ('-') characters, with the first
with the first character being a letter. character being a letter.
Status: Status:
"permanent" or "provisional". "permanent" or "provisional".
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. An indication of the relevant section(s) can also be document. An indication of the relevant section(s) can also be
included, but is not required. included, but is not required.
skipping to change at page 175, line 11 skipping to change at page 177, line 27
field will need to carefully consider issues such as content field will need to carefully consider issues such as content
negotiation, the time period of applicability, and (in some cases) negotiation, the time period of applicability, and (in some cases)
multi-tenant server deployments. multi-tenant server deployments.
* Under what conditions intermediaries are allowed to insert, * Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value. delete, or modify the field's value.
* If the field is allowable in trailers; by default, it will not be * If the field is allowable in trailers; by default, it will not be
(see Section 6.5.1). (see Section 6.5.1).
* Whether it is appropriate to list the field name in the Connection * Whether it is appropriate or even required to list the field name
header field (i.e., if the field is to be hop-by-hop; see in the Connection header field (i.e., if the field is to be hop-
Section 7.6.1). by-hop; see Section 7.6.1).
* Whether the field introduces any additional security * 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 behaviour is not appropriate:
* If it is appropriate to list the field name in a Vary response * 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).
skipping to change at page 175, line 49 skipping to change at page 178, line 16
single application or use case) are encouraged to use a name that single application or use case) are encouraged to use a name that
includes that use (or an abbreviation) as a prefix; for example, if includes that use (or an abbreviation) as a prefix; for example, if
the Foo Application needs a Description field, it might use "Foo- the Foo Application needs a Description field, it might use "Foo-
Desc"; "Description" is too generic, and "Foo-Description" is Desc"; "Description" is too generic, and "Foo-Description" is
needlessly long. needlessly long.
While the field-name syntax is defined to allow any token character, While the field-name syntax is defined to allow any token character,
in practice some implementations place limits on the characters they in practice some implementations place limits on the characters they
accept in field-names. To be interoperable, new field names SHOULD accept in field-names. To be interoperable, new field names SHOULD
constrain themselves to alphanumeric characters, "-", and ".", and constrain themselves to alphanumeric characters, "-", and ".", and
SHOULD begin with an alphanumeric character. For example, the SHOULD begin with a letter. For example, the underscore ("_")
underscore ("_") character can be problematic when passed through character can be problematic when passed through non-HTTP gateway
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. These "Accept-" is used in many content negotiation headers, and "Content-"
prefixes are only an aid to recognizing the purpose of a field, and is used as explained in Section 6.4. These prefixes are only an aid
do not trigger automatic processing. to recognizing the purpose of a field, and do not trigger automatic
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
rules in this specification or those in [RFC8941] to define the rules in this specification or those in [RFC8941] to define the
syntax of new field values. syntax of new field values.
Authors are advised to carefully consider how the combination of Authors are advised to carefully consider how the combination of
multiple field lines will impact them (see Section 5.3). Because multiple field lines will impact them (see Section 5.3). Because
senders might send erroneously send multiple values, and both senders might erroneously send multiple values, and both
intermediaries and HTTP libraries can perform combination intermediaries and HTTP libraries can perform combination
automatically, this applies to all field values - even when only a automatically, this applies to all field values - even when only a
single value is anticipated. single value is anticipated.
Therefore, authors are advised to delimit or encode values that Therefore, authors are advised to delimit or encode values that
contain commas (e.g., with the quoted-string rule of Section 5.6.4, contain commas (e.g., with the quoted-string rule of Section 5.6.4,
the String data type of [RFC8941]), or a field-specific encoding). the String data type of [RFC8941], or a field-specific encoding).
This ensures that commas within field data are not confused with the This ensures that commas within field data are not confused with the
commas that delimit a list value. commas that delimit a list value.
For example, the Content-Type field value only allows commas inside For example, the Content-Type field value only allows commas inside
quoted strings, which can be reliably parsed even when multiple quoted strings, which can be reliably parsed even when multiple
values are present. The Location field value provides a counter- values are present. The Location field value provides a counter-
example that should not be emulated: because URIs can include commas, example that should not be emulated: because URIs can include commas,
it is not possible to reliably distinguish between a single value it is not possible to reliably distinguish between a single value
that includes a comma from two values. that includes a comma from two values.
skipping to change at page 177, line 34 skipping to change at page 179, line 49
There are certain aspects of the HTTP Authentication framework that There are certain aspects of the HTTP Authentication framework that
put constraints on how new authentication schemes can work: put constraints on how new authentication schemes can work:
* HTTP authentication is presumed to be stateless: all of the * HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided information necessary to authenticate a request MUST be provided
in the request, rather than be dependent on the server remembering in the request, rather than be dependent on the server remembering
prior requests. Authentication based on, or bound to, the prior requests. Authentication based on, or bound to, the
underlying connection is outside the scope of this specification underlying connection is outside the scope of this specification
and inherently flawed unless steps are taken to ensure that the and inherently flawed unless steps are taken to ensure that the
connection cannot be used by any party other than the connection cannot be used by any party other than the
authenticated user (see Section 3.7). authenticated user (see Section 3.3).
* The authentication parameter "realm" is reserved for defining * The authentication parameter "realm" is reserved for defining
protection spaces as described in Section 11.5. New schemes MUST protection spaces as described in Section 11.5. New schemes MUST
NOT use it in a way incompatible with that definition. NOT use it in a way incompatible with that definition.
* The "token68" notation was introduced for compatibility with * The "token68" notation was introduced for compatibility with
existing authentication schemes and can only be used once per existing authentication schemes and can only be used once per
challenge or credential. Thus, new schemes ought to use the auth- challenge or credential. Thus, new schemes ought to use the auth-
param syntax instead, because otherwise future extensions will be param syntax instead, because otherwise future extensions will be
impossible. impossible.
skipping to change at page 178, line 33 skipping to change at page 180, line 43
defining new parameters (such as "update the specification" or defining new parameters (such as "update the specification" or
"use this registry"). "use this registry").
* Authentication schemes need to document whether they are usable in * Authentication schemes need to document whether they are usable in
origin-server authentication (i.e., using WWW-Authenticate), and/ origin-server authentication (i.e., using WWW-Authenticate), and/
or proxy authentication (i.e., using Proxy-Authenticate). or proxy authentication (i.e., using Proxy-Authenticate).
* The credentials carried in an Authorization header field are * The credentials carried in an Authorization header field are
specific to the user agent and, therefore, have the same effect on specific to the user agent and, therefore, have the same effect on
HTTP caches as the "private" Cache-Control response directive HTTP caches as the "private" Cache-Control response directive
(Section 5.2.2.7 of [Caching]), within the scope of the request in (Section 5.2.2.7 of [CACHING]), within the scope of the request in
which they appear. which they appear.
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by defined header field) will need to explicitly disallow caching, by
mandating the use of Cache-Control response directives (e.g., mandating the use of Cache-Control response directives (e.g.,
"private"). "private").
* Schemes using Authentication-Info, Proxy-Authentication-Info, or * Schemes using Authentication-Info, Proxy-Authentication-Info, or
any other authentication related response header field need to any other authentication related response header field need to
skipping to change at page 181, line 11 skipping to change at page 183, 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 [Messaging]. 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. Various Internet in general, rather than security of the protocol. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
17.1. Establishing Authority 17.1. Establishing Authority
skipping to change at page 181, line 39 skipping to change at page 183, line 47
When a registered name is used in the authority component, the "http" When a registered name is used in the authority component, the "http"
URI scheme (Section 4.2.1) relies on the user's local name resolution URI scheme (Section 4.2.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names, means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on or name resolution libraries becomes an avenue for attack on
establishing authority for "http" URIs. Likewise, the user's choice establishing authority for "http" URIs. Likewise, the user's choice
of server for Domain Name Service (DNS), and the hierarchy of servers of server for Domain Name Service (DNS), and the hierarchy of servers
from which it obtains resolution results, could impact the from which it obtains resolution results, could impact the
authenticity of address mappings; DNS Security Extensions (DNSSEC, authenticity of address mappings; DNS Security Extensions (DNSSEC,
[RFC4033]) are one way to improve authenticity. [RFC4033]) are one way to improve authenticity, as are the various
mechanisms for making DNS requests over more secure transfer
protocols.
Furthermore, after an IP address is obtained, establishing authority Furthermore, after an IP address is obtained, establishing authority
for an "http" URI is vulnerable to attacks on Internet Protocol for an "http" URI is vulnerable to attacks on Internet Protocol
routing. routing.
The "https" scheme (Section 4.2.2) is intended to prevent (or at The "https" scheme (Section 4.2.2) is intended to prevent (or at
least reveal) many of these potential attacks on establishing least reveal) many of these potential attacks on establishing
authority, provided that the negotiated connection is secured and the authority, provided that the negotiated connection is secured and the
client properly verifies that the communicating server's identity client properly verifies that the communicating server's identity
matches the target URI's authority component (Section 4.3.4). matches the target URI's authority component (Section 4.3.4).
Correctly implementing such verification can be difficult (see Correctly implementing such verification can be difficult (see
[Georgiev]). [Georgiev]).
Authority for a given origin server can be delegated through protocol Authority for a given origin server can be delegated through protocol
extensions; for example, [RFC7838]. Likewise, the set of servers for extensions; for example, [ALTSVC]. Likewise, the set of servers for
which a connection is considered authoritative can be changed with a which a connection is considered authoritative can be changed with a
protocol extension like [RFC8336]. protocol extension like [RFC8336].
Providing a response from a non-authoritative source, such as a Providing a response from a non-authoritative source, such as a
shared proxy cache, is often useful to improve performance and shared proxy cache, is often useful to improve performance and
availability, but only to the extent that the source can be trusted availability, but only to the extent that the source can be trusted
or the distrusted response can be safely used. or the distrusted response can be safely used.
Unfortunately, communicating authority to users can be difficult. Unfortunately, communicating authority to users can be difficult.
For example, _phishing_ is an attack on the user's perception of For example, _phishing_ is an attack on the user's perception of
skipping to change at page 182, line 39 skipping to change at page 184, line 51
Compromise of the systems on which the intermediaries run can result Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about access to security-related information, personal information about
individual users and organizations, and proprietary information individual users and organizations, and proprietary information
belonging to users and content providers. A compromised belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks. commission of a wide range of potential attacks.
Intermediaries that contain a shared cache are especially vulnerable Intermediaries that contain a shared cache are especially vulnerable
to cache poisoning attacks, as described in Section 7 of [Caching]. to cache poisoning attacks, as described in Section 7 of [CACHING].
Implementers need to consider the privacy and security implications Implementers need to consider the privacy and security implications
of their design and coding decisions, and of the configuration of their design and coding decisions, and of the configuration
options they provide to operators (especially the default options they provide to operators (especially the default
configuration). configuration).
Users need to be aware that intermediaries are no more trustworthy Intermediaries are no more trustworthy than the people and policies
than the people who run them; HTTP itself cannot solve this problem. under which they operate; HTTP cannot solve this problem.
17.3. Attacks Based on File and Path Names 17.3. Attacks Based on File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
manage the mapping from target URI to resource representations. Most manage the mapping from target URI to resource representations. Most
file systems are not designed to protect against malicious file or file systems are not designed to protect against malicious file or
path names. Therefore, an origin server needs to avoid accessing path names. Therefore, an origin server needs to avoid accessing
names that have a special significance to the system when mapping the names that have a special significance to the system when mapping the
target resource to files, folders, or directories. target resource to files, folders, or directories.
skipping to change at page 184, line 38 skipping to change at page 186, line 46
choose substantially higher limits. choose substantially higher limits.
A server can reject a message that has a target URI that is too long A server can reject a message that has a target URI that is too long
(Section 15.5.15) or request content that is too large (Section 15.5.15) or request content that is too large
(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 buffer chunk lengths. Failure to limit such processing can result in
overflows, arithmetic overflows, or increased vulnerability to arbitrary code execution due to buffer or arithmetic overflows, and
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
TLS compression, content codings, transfer codings, and other TLS compression, content codings, transfer codings, and other
extension or version-specific mechanisms. extension or version-specific mechanisms.
The most effective mitigation for this risk is to disable compression The most effective mitigation for this risk is to disable compression
on sensitive data, or to strictly separate sensitive data from on sensitive data, or to strictly separate sensitive data from
attacker-controlled data so that they cannot share the same attacker-controlled data so that they cannot share the same
compression dictionary. With careful design, a compression scheme compression dictionary. With careful design, a compression scheme
can be designed in a way that is not considered exploitable in can be designed in a way that is not considered exploitable in
limited use cases, such as HPACK ([RFC7541]). limited use cases, such as HPACK ([HPACK]).
17.7. Disclosure of Personal Information 17.7. Disclosure of Personal Information
Clients are often privy to large amounts of personal information, Clients are often privy to large amounts of personal information,
including both information provided by the user to interact with including both information provided by the user to interact with
resources (e.g., the user's name, location, mail address, passwords, resources (e.g., the user's name, location, mail address, passwords,
encryption keys, etc.) and information about the user's browsing encryption keys, etc.) and information about the user's browsing
activity over time (e.g., history, bookmarks, etc.). Implementations activity over time (e.g., history, bookmarks, etc.). Implementations
need to prevent unintentional disclosure of personal information. need to prevent unintentional disclosure of personal information.
skipping to change at page 187, line 30 skipping to change at page 189, line 30
instead of the default one. (This historical practice is why instead of the default one. (This historical practice is why
Section 16.3.2.1 discourages the creation of new field names that Section 16.3.2.1 discourages the creation of new field names that
contain an underscore.) contain an underscore.)
Unfortunately, mapping field names to different interface names can Unfortunately, mapping field names to different interface names can
lead to security vulnerabilities if the mapping is incomplete or lead to security vulnerabilities if the mapping is incomplete or
ambiguous. For example, if an attacker were to send a field named ambiguous. For example, if an attacker were to send a field named
"Transfer_Encoding", a naive interface might map that to the same "Transfer_Encoding", a naive interface might map that to the same
variable name as the "Transfer-Encoding" field, resulting in a variable name as the "Transfer-Encoding" field, resulting in a
potential request smuggling vulnerability (Section 11.2 of potential request smuggling vulnerability (Section 11.2 of
[Messaging]). [HTTP/1.1]).
To mitigate the associated risks, implementations that perform such To mitigate the associated risks, implementations that perform such
mappings are advised to make the mapping unambiguous and complete for mappings are advised to make the mapping unambiguous and complete for
the full range of potential octets received as a name (including the full range of potential octets received as a name (including
those that are discouraged or forbidden by the HTTP grammar). For those that are discouraged or forbidden by the HTTP grammar). For
example, a field with an unusual name character might result in the example, a field with an unusual name character might result in the
request being blocked, the specific field being removed, or the name request being blocked, the specific field being removed, or the name
being passed with a different prefix to distinguish it from other being passed with a different prefix to distinguish it from other
fields. fields.
skipping to change at page 188, line 25 skipping to change at page 190, line 25
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that might identify hosts behind the firewall. The Via header field that might identify hosts behind the firewall. The Via header field
allows intermediaries to replace sensitive machine names with allows intermediaries to replace sensitive machine names with
pseudonyms. pseudonyms.
17.13. Browser Fingerprinting 17.13. Browser Fingerprinting
Browser fingerprinting is a set of techniques for identifying a Browser fingerprinting is a set of techniques for identifying a
specific user agent over time through its unique set of specific user agent over time through its unique set of
characteristics. These characteristics might include information characteristics. These characteristics might include information
related to its TCP behavior, feature capabilities, and scripting related to how it uses the underlying transport protocol, feature
environment, though of particular interest here is the set of unique capabilities, and scripting environment, though of particular
characteristics that might be communicated via HTTP. Fingerprinting interest here is the set of unique characteristics that might be
is considered a privacy concern because it enables tracking of a user communicated via HTTP. Fingerprinting is considered a privacy
agent's behavior over time ([Bujlow]) without the corresponding concern because it enables tracking of a user agent's behavior over
controls that the user might have over other forms of data collection time ([Bujlow]) without the corresponding controls that the user
(e.g., cookies). Many general-purpose user agents (i.e., Web might have over other forms of data collection (e.g., cookies). Many
browsers) have taken steps to reduce their fingerprints. general-purpose user agents (i.e., Web browsers) have taken steps to
reduce their fingerprints.
There are a number of request header fields that might reveal There are a number of request header fields that might reveal
information to servers that is sufficiently unique to enable information to servers that is sufficiently unique to enable
fingerprinting. The From header field is the most obvious, though it fingerprinting. The From header field is the most obvious, though it
is expected that From will only be sent when self-identification is is expected that From will only be sent when self-identification is
desired by the user. Likewise, Cookie header fields are deliberately desired by the user. Likewise, Cookie header fields are deliberately
designed to enable re-identification, so fingerprinting concerns only designed to enable re-identification, so fingerprinting concerns only
apply to situations where cookies are disabled or restricted by the apply to situations where cookies are disabled or restricted by the
user agent's configuration. user agent's configuration.
skipping to change at page 199, line 44 skipping to change at page 201, line 44
| 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-16, 27 May 2021, draft-ietf-httpbis-cache-17, 26 July 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-16>. <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-17>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, Format Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 200, line 29 skipping to change at page 202, line 29
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
2006, <https://www.rfc-editor.org/info/rfc4647>. 2006, <https://www.rfc-editor.org/info/rfc4647>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
skipping to change at page 201, line 29 skipping to change at page 203, line 25
<https://www.rfc-editor.org/info/rfc6365>. <https://www.rfc-editor.org/info/rfc6365>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<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., "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
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013, RFC 6838, January 2013,
<https://www.rfc-editor.org/info/bcp13>. <https://www.rfc-editor.org/info/bcp13>.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012, Application Protocols", BCP 178, RFC 6648, June 2012,
<https://www.rfc-editor.org/info/bcp178>. <https://www.rfc-editor.org/info/bcp178>.
skipping to change at page 202, line 22 skipping to change at page 204, line 32
<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-Espanol, V., Sole-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",
DOI 10.1109/JPROC.2016.2637878, Proceedings of the DOI 10.1109/JPROC.2016.2637878, Proceedings of the
IEEE 105(8), 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,
DOI 10.17487/RFC6265, April 2011,
<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", DOI 10.1145/2382196.2382204, In Proceedings of Software", In Proceedings of the 2012 ACM Conference on
the 2012 ACM Conference on Computer and Communications Computer and Communications Security (CCS '12), pp. 38-49,
Security (CCS '12), pp. 38-49, October 2012, DOI 10.1145/2382196.2382204, October 2012,
<https://doi.org/10.1145/2382196.2382204>. <https://doi.org/10.1145/2382196.2382204>.
[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-17, 26 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-17>.
[HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[HTTP/3] Bishop, M., "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, 2 February 2021, quic-http-34, 2 February 2021,
<https://tools.ietf.org/html/draft-ietf-quic-http-34>. <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
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.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology 1(2), Politics", ACM Transactions on Internet Technology 1(2),
November 2001, <http://arxiv.org/abs/cs.SE/0105018>. November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-16, 27 May 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
16>.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Application Applications and Web Services", The Open Web Application
Security Project (OWASP) 2.0.1, 27 July 2005, Security Project (OWASP) 2.0.1, 27 July 2005,
<https://www.owasp.org/>. <https://www.owasp.org/>.
[REST] Fielding, R.T., "Architectural Styles and the Design of [REST] Fielding, R.T., "Architectural Styles and the Design of
Network-based Software Architectures", Network-based Software Architectures", Doctoral
Doctoral Dissertation, University of California, Irvine, Dissertation, University of California, Irvine, September
September 2000, 2000, <https://roy.gbiv.com/pubs/dissertation/top.htm>.
<https://roy.gbiv.com/pubs/dissertation/top.htm>.
[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>.
[RFC1945] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>.
[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., Nielsen, 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>.
skipping to change at page 205, line 15 skipping to change at page 207, line 33
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>. <https://www.rfc-editor.org/info/rfc4559>.
[RFC4918] Dusseault, L.M., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010, RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>. <https://www.rfc-editor.org/info/rfc5789>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[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. F. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Routing", Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
skipping to change at page 206, line 35 skipping to change at page 208, line 40
[RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, Transfer 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. F., "The Hypertext Transfer Protocol Status
Code 308 (Permanent Redirect)", RFC 7538, Code 308 (Permanent Redirect)", RFC 7538,
DOI 10.17487/RFC7538, April 2015, DOI 10.17487/RFC7538, April 2015,
<https://www.rfc-editor.org/info/rfc7538>. <https://www.rfc-editor.org/info/rfc7538>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>.
[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. F., "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
skipping to change at page 207, line 19 skipping to change at page 209, line 14
[RFC7617] Reschke, J. F., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J. F., "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. F., "Hypertext Transfer Protocol (HTTP)
Client-Initiated Content-Encoding", RFC 7694, Client-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>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[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. F., "Indicating Character Encoding and
Language for HTTP Header Field Parameters", RFC 8187, Language 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>.
skipping to change at page 208, line 8 skipping to change at page 209, line 47
(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
Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007,
<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 as per
Section 5.6.1.1. Section 5.6.1.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 [
skipping to change at page 209, line 30 skipping to change at page 211, line 26
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
Range = ranges-specifier Range = ranges-specifier
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
TE = [ t-codings *( OWS "," OWS t-codings ) ] TE = [ t-codings *( OWS "," OWS t-codings ) ]
Trailer = [ field-name *( OWS "," OWS field-name ) ] Trailer = [ field-name *( OWS "," OWS field-name ) ]
URI-reference = <URI-reference, see [RFC3986], Section 4.1> URI-reference = <URI-reference, see [URI], Section 4.1>
Upgrade = [ protocol *( OWS "," OWS protocol ) ] Upgrade = [ protocol *( OWS "," OWS protocol ) ]
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
Vary = [ ( "*" / field-name ) *( OWS "," OWS ( "*" / field-name ) ) Vary = [ ( "*" / field-name ) *( OWS "," OWS ( "*" / field-name ) )
] ]
Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS
"," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) ] "," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) ]
WWW-Authenticate = [ challenge *( OWS "," OWS challenge ) ] WWW-Authenticate = [ challenge *( OWS "," OWS challenge ) ]
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [URI], Section 4.3>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
acceptable-ranges = ( range-unit *( OWS "," OWS range-unit ) ) / acceptable-ranges = range-unit *( OWS "," OWS range-unit )
"none"
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
auth-param = token BWS "=" BWS ( token / quoted-string ) auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token auth-scheme = token
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [URI], Section 3.2>
challenge = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS "," challenge = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS ","
OWS auth-param ) ] ) ] OWS auth-param ) ] ) ]
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
comment = "(" *( ctext / quoted-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
complete-length = 1*DIGIT complete-length = 1*DIGIT
connection-option = token connection-option = token
content-coding = token content-coding = token
credentials = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS "," credentials = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS ","
OWS auth-param ) ] ) ] OWS auth-param ) ] ) ]
ctext = HTAB / SP / %x21-27 ; '!'-''' ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'[' / %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
skipping to change at page 211, line 42 skipping to change at page 213, line 37
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
other-range = 1*( %x21-2B ; '!'-'+' other-range = 1*( %x21-2B ; '!'-'+'
/ %x2D-7E ; '-'-'~' / %x2D-7E ; '-'-'~'
) )
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
parameters = *( OWS ";" OWS [ parameter ] ) parameters = *( OWS ";" OWS [ parameter ] )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [URI], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [URI], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol = protocol-name [ "/" protocol-version ] protocol = protocol-name [ "/" protocol-version ]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
pseudonym = token pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
query = <query, see [RFC3986], Section 3.4> query = <query, see [URI], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
range-resp = incl-range "/" ( complete-length / "*" ) range-resp = incl-range "/" ( complete-length / "*" )
range-set = range-spec *( OWS "," OWS range-spec ) range-set = range-spec *( OWS "," OWS range-spec )
range-spec = int-range / suffix-range / other-range range-spec = int-range / suffix-range / other-range
range-unit = token range-unit = token
ranges-specifier = range-unit "=" range-set ranges-specifier = range-unit "=" range-set
received-by = pseudonym [ ":" port ] received-by = pseudonym [ ":" port ]
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [RFC3986], Section 4.2> relative-part = <relative-part, see [URI], Section 4.2>
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [URI], Section 3.3>
subtype = token subtype = token
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
suffix-range = "-" suffix-length suffix-range = "-" suffix-length
t-codings = "trailers" / ( transfer-coding [ weight ] ) t-codings = "trailers" / ( transfer-coding [ weight ] )
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = 1*tchar token = 1*tchar
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"=" *"="
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
type = token type = token
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
uri-host = <host, see [RFC3986], 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
skipping to change at page 213, line 21 skipping to change at page 215, line 15
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/workaround 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. (Section 4.2.1, Section 4.2.2,
Section 4.3.1, Section 7.3.3) Section 4.3.1, Section 7.3.3)
Explicit requirements have been added to check the target URI
scheme's semantics and reject requests that don't meet any associated
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. Use of trailer fields has been further limited to only
allow generation as a trailer field when the sender knows the field allow generation as a trailer field when the sender knows the field
skipping to change at page 213, line 42 skipping to change at page 215, line 40
if the recipient knows the corresponding field definition permits and if the recipient knows the corresponding field definition permits and
defines how to merge. In all other cases, implementations are defines how to merge. In all other cases, implementations are
encouraged to either store the trailer fields separately or discard encouraged to either store the trailer fields separately or discard
them instead of merging. (Section 6.5.1) them instead of merging. (Section 6.5.1)
Made the priority of the absolute form of the request URI over the Made the priority of the absolute form of the request URI over the
Host header by origin servers explicit, to align with proxy handling. Host header by origin servers explicit, to align with proxy handling.
(Section 7.2) (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 [RFC3986] that are in 7230 due to changes in the URI grammar for host [URI] that are not
not desirable for Via. For simplicity, we have removed uri-host from desirable for Via. For simplicity, we have removed uri-host from the
the received-by production because it can be encompassed by the received-by production because it can be encompassed by the existing
existing grammar for pseudonym. In particular, this change removed grammar for pseudonym. In particular, this change removed comma from
comma from the allowed set of charaters for a host name in received- the allowed set of charaters for a host name in received-by.
by. (Section 7.6.3) (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 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 mapped to SP and that leading and trailing whitespace need to be
stripped from field values before they are consumed. (Section 5.5) 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 [Messaging], and reflect the contents syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after
after the message is parsed. This makes it easier to distinguish the message is parsed. This makes it easier to distinguish between
between requirements on the content (what is conveyed) versus requirements on the content (what is conveyed) versus requirements on
requirements on the messaging syntax (how it is conveyed) and avoids the messaging syntax (how it is conveyed) and avoids baking
baking limitations of early protocol versions into the future of limitations of early protocol versions into the future of HTTP.
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
skipping to change at page 214, line 49 skipping to change at page 217, line 4
the description of the OPTIONS method. (Section 9.3.7) the description of the OPTIONS method. (Section 9.3.7)
Removed normative requirement to use the "message/http" media type in Removed normative requirement to use the "message/http" media type in
TRACE responses. (Section 9.3.8) TRACE responses. (Section 9.3.8)
Restore list-based grammar for Expect for compatibility with RFC Restore list-based grammar for Expect for compatibility with RFC
2616. (Section 10.1.1) 2616. (Section 10.1.1)
Allow Accept and Accept-Encoding in response messages; the latter was Allow Accept and Accept-Encoding in response messages; the latter was
introduced by [RFC7694]. (Section 12.3) introduced by [RFC7694]. (Section 12.3)
"Accept Parameters" (accept-params and accept-ext ABNF production)
have been removed from the definition of the Accept field.
(Section 12.5.1)
The "Accept-Charset" field now is deprecated. (Section 12.5.2)
"Accept Parameters" (accept-params) have been removed from the
definition of the Accept field. (Section 12.5.1)
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.
(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 Added status code 308 (previously defined in [RFC7538]) so that it's
defined closer to status codes 301, 302, and 307. (Section 15.4.9) 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 Added status code 421 (previously defined in Section 9.1.2 of
[RFC7540]) because of its general applicability. 421 is no longer [HTTP/2]) 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 Added status code 422 (previously defined in Section 11.2 of
[RFC4918]) because of its general applicability. (Section 15.5.21) [WEBDAV]) 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)
skipping to change at page 217, line 30 skipping to change at page 219, line 33
The changes in this draft are editorial, with respect to HTTP as a The changes in this draft are editorial, with respect to HTTP as a
whole, to merge core HTTP semantics into this document: whole, to merge core HTTP semantics into this document:
* Merged introduction, architecture, conformance, and ABNF * Merged introduction, architecture, conformance, and ABNF
extensions from RFC 7230 (Messaging). extensions from RFC 7230 (Messaging).
* Rearranged architecture to extract conformance, http(s) schemes, * Rearranged architecture to extract conformance, http(s) schemes,
and protocol versioning into a separate major section. and protocol versioning into a separate major section.
* Moved discussion of MIME differences to [Messaging] since that is * Moved discussion of MIME differences to [HTTP/1.1] since that is
primarily concerned with transforming 1.1 messages. primarily concerned with transforming 1.1 messages.
* Merged entire content of RFC 7232 (Conditional Requests). * Merged entire content of RFC 7232 (Conditional Requests).
* Merged entire content of RFC 7233 (Range Requests). * Merged entire content of RFC 7233 (Range Requests).
* Merged entire content of RFC 7235 (Auth Framework). * Merged entire content of RFC 7235 (Auth Framework).
* Moved all extensibility tips, registration procedures, and * Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
skipping to change at page 219, line 34 skipping to change at page 221, line 37
* In Section 3.4 and Section 10.1.1, clarified when a response can * In Section 3.4 and Section 10.1.1, clarified when a response can
be sent (<https://github.com/httpwg/http-core/issues/82>) be sent (<https://github.com/httpwg/http-core/issues/82>)
* In Section 8.3.2, explain the difference between the "token" * In Section 8.3.2, explain the difference between the "token"
production, the RFC 2978 ABNF for charset names, and the actual production, the RFC 2978 ABNF for charset names, and the actual
registration practice (<https://github.com/httpwg/http-core/ registration practice (<https://github.com/httpwg/http-core/
issues/100>, <https://www.rfc-editor.org/errata/eid4689>) issues/100>, <https://www.rfc-editor.org/errata/eid4689>)
* In Section 3.1, removed the fragment component in the URI scheme * In Section 3.1, removed the fragment component in the URI scheme
definitions as per Section 4.3 of [RFC3986], furthermore moved definitions as per Section 4.3 of [URI], furthermore moved
fragment discussion into a separate section fragment discussion into a separate section
(<https://github.com/httpwg/http-core/issues/103>, (<https://github.com/httpwg/http-core/issues/103>,
<https://www.rfc-editor.org/errata/eid4251>, <https://www.rfc- <https://www.rfc-editor.org/errata/eid4251>, <https://www.rfc-
editor.org/errata/eid4252>) editor.org/errata/eid4252>)
* In Section 2.5, add language about minor HTTP version number * In Section 2.5, add language about minor HTTP version number
defaulting (<https://github.com/httpwg/http-core/issues/115>) defaulting (<https://github.com/httpwg/http-core/issues/115>)
* Added Section 15.5.21 for status code 422, previously defined in * Added Section 15.5.21 for status code 422, previously defined in
Section 11.2 of [RFC4918] (<https://github.com/httpwg/http-core/ Section 11.2 of [WEBDAV] (<https://github.com/httpwg/http-core/
issues/123>) issues/123>)
* In Section 15.5.17, fixed prose about byte range comparison * In Section 15.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>, (<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>) <https://www.rfc-editor.org/errata/eid5474>)
* In Section 3.4, explain that request/response correlation is * In Section 3.4, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/ version specific (<https://github.com/httpwg/http-core/
issues/145>) issues/145>)
skipping to change at page 221, line 26 skipping to change at page 223, line 26
is needed to define method content (<https://github.com/httpwg/ is needed to define method content (<https://github.com/httpwg/
http-core/issues/204>) http-core/issues/204>)
* Fix editorial issue in Section 3.2 (<https://github.com/httpwg/ * Fix editorial issue in Section 3.2 (<https://github.com/httpwg/
http-core/issues/223>) http-core/issues/223>)
* In Section 15.5.21, rephrase language not to use "entity" anymore, * In Section 15.5.21, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http- and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>) core/issues/224>)
* Move discussion of retries from [Messaging] into Section 9.2.2 * Move discussion of retries from [HTTP/1.1] into Section 9.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
C.7. Since draft-ietf-httpbis-semantics-05 C.7. Since draft-ietf-httpbis-semantics-05
* Moved transport-independent part of the description of trailers * Moved transport-independent part of the description of trailers
into Section 6.5 (<https://github.com/httpwg/http-core/issues/16>) into Section 6.5 (<https://github.com/httpwg/http-core/issues/16>)
* Loosen requirements on retries based upon implementation behavior * Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>) (<https://github.com/httpwg/http-core/issues/27>)
skipping to change at page 224, line 17 skipping to change at page 226, line 17
* In Section 2.2, reference RFC 8174 as well * In Section 2.2, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>) (<https://github.com/httpwg/http-core/issues/303>)
C.9. Since draft-ietf-httpbis-semantics-07 C.9. Since draft-ietf-httpbis-semantics-07
* In Section 14.2, explicitly reference the definition of * In Section 14.2, explicitly reference the definition of
representation data as including any content codings representation data as including any content codings
(<https://github.com/httpwg/http-core/issues/11>) (<https://github.com/httpwg/http-core/issues/11>)
* Move TE: trailers from [Messaging] into Section 6.5.1 * Move TE: trailers from [HTTP/1.1] into Section 6.5.1
(<https://github.com/httpwg/http-core/issues/18>) (<https://github.com/httpwg/http-core/issues/18>)
* In Section 8.6, adjust requirements for handling multiple content- * In Section 8.6, adjust requirements for handling multiple content-
length values (<https://github.com/httpwg/http-core/issues/59>) length values (<https://github.com/httpwg/http-core/issues/59>)
* In Section 13.1.1 and Section 13.1.2, clarified condition * In Section 13.1.1 and Section 13.1.2, clarified condition
evaluation (<https://github.com/httpwg/http-core/issues/72>) evaluation (<https://github.com/httpwg/http-core/issues/72>)
* In Section 5.5, remove concept of obs-fold, as that is * In Section 5.5, remove concept of obs-fold, as that is
HTTP/1-specific (<https://github.com/httpwg/http-core/issues/116>) HTTP/1-specific (<https://github.com/httpwg/http-core/issues/116>)
skipping to change at page 227, line 27 skipping to change at page 229, line 27
HTTP/3 (<https://github.com/httpwg/http-core/issues/64>) HTTP/3 (<https://github.com/httpwg/http-core/issues/64>)
* In Section 8.6, added a definition for Content-Length that * In Section 8.6, added a definition for Content-Length that
encompasses its various roles in describing message content or encompasses its various roles in describing message content or
selected representation length; in Section 15.3.7, noted that selected representation length; in Section 15.3.7, noted that
Content-Length counts only the message content (not the selected Content-Length counts only the message content (not the selected
representation) and that the representation length is in each representation) and that the representation length is in each
Content-Range (<https://github.com/httpwg/http-core/issues/118>) Content-Range (<https://github.com/httpwg/http-core/issues/118>)
* Noted that "WWW-Authenticate" with more than one value on a line * Noted that "WWW-Authenticate" with more than one value on a line
is sometimes not interoperable [Messaging] is sometimes not interoperable [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/136>) (<https://github.com/httpwg/http-core/issues/136>)
* In Section 13.1.1 and Section 13.1.4, removed requirement that a * 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 validator not be sent in a 2xx response when validation fails and
the server decides that the same change request has already been the server decides that the same change request has already been
applied (<https://github.com/httpwg/http-core/issues/166>) applied (<https://github.com/httpwg/http-core/issues/166>)
* Moved requirements specific to HTTP/1.1 from Section 7.2 to * Moved requirements specific to HTTP/1.1 from Section 7.2 to
[Messaging] (<https://github.com/httpwg/http-core/issues/182>) [HTTP/1.1] (<https://github.com/httpwg/http-core/issues/182>)
* In Section 5.5, introduce the terms "singleton field" and "list- * In Section 5.5, introduce the terms "singleton field" and "list-
based field" (also - in various places - discuss what to do when a based field" (also - in various places - discuss what to do when a
singleton field is received as a list) singleton field is received as a list)
(<https://github.com/httpwg/http-core/issues/193>) (<https://github.com/httpwg/http-core/issues/193>)
* In Section 10.1.1, change the ABNF back to be a list of * In Section 10.1.1, change the ABNF back to be a list of
expectations, as defined in RFC 2616 (<https://github.com/httpwg/ expectations, as defined in RFC 2616 (<https://github.com/httpwg/
http-core/issues/203>) http-core/issues/203>)
skipping to change at page 228, line 21 skipping to change at page 230, line 21
* In Section 13.2, allow preconditions to be evaluated before the * In Section 13.2, allow preconditions to be evaluated before the
request content (if any) is processed (<https://github.com/httpwg/ request content (if any) is processed (<https://github.com/httpwg/
http-core/issues/261>) http-core/issues/261>)
* In Section 6.3 and Section 6.5.2, allow for trailer fields in * In Section 6.3 and Section 6.5.2, allow for trailer fields in
multiple trailer sections, depending on the HTTP version and multiple trailer sections, depending on the HTTP version and
framing in use, with processing being iterative as each section is framing in use, with processing being iterative as each section is
received (<https://github.com/httpwg/http-core/issues/313>) received (<https://github.com/httpwg/http-core/issues/313>)
* Moved definitions of "TE" and "Upgrade" from [Messaging] * Moved definitions of "TE" and "Upgrade" from [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/392>) (<https://github.com/httpwg/http-core/issues/392>)
* Moved 1.1-specific discussion of TLS to Messaging and rewrote * Moved 1.1-specific discussion of TLS to Messaging and rewrote
Section 4.3.4 to refer to RFC6125 (<https://github.com/httpwg/ Section 4.3.4 to refer to RFC6125 (<https://github.com/httpwg/
http-core/issues/404>) http-core/issues/404>)
* Moved definition of "Connection" from [Messaging] * Moved definition of "Connection" from [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/407>) (<https://github.com/httpwg/http-core/issues/407>)
C.13. Since draft-ietf-httpbis-semantics-11 C.13. Since draft-ietf-httpbis-semantics-11
* The entire document has been reorganized, with no changes to * The entire document has been reorganized, with no changes to
content except editorial for the reorganization content except editorial for the reorganization
(<https://github.com/httpwg/http-core/issues/368>) (<https://github.com/httpwg/http-core/issues/368>)
* Move IANA Upgrade Token Registry instructions from [Messaging] * Move IANA Upgrade Token Registry instructions from [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/450>) (<https://github.com/httpwg/http-core/issues/450>)
C.14. Since draft-ietf-httpbis-semantics-12 C.14. Since draft-ietf-httpbis-semantics-12
* In Appendix "Acknowledgments" (Appendix "Acknowledgments"), added * In Appendix "Acknowledgements" (Appendix "Acknowledgements"),
acks for the work since 2014 (<https://github.com/httpwg/http- added acks for the work since 2014 (<https://github.com/httpwg/
core/issues/442>) http-core/issues/442>)
* In Section 15.3.7, specifically require that a client check the * In Section 15.3.7, specifically require that a client check the
206 response header fields to determine what ranges are enclosed, 206 response header fields to determine what ranges are enclosed,
since it cannot assume they exactly match those requested since it cannot assume they exactly match those requested
(<https://github.com/httpwg/http-core/issues/445>) (<https://github.com/httpwg/http-core/issues/445>)
* In Section 16.3, explain why new fields need to be backwards- * In Section 16.3, explain why new fields need to be backwards-
compatible (<https://github.com/httpwg/http-core/issues/448>) compatible (<https://github.com/httpwg/http-core/issues/448>)
* In Section 5.3, constrain field combination to be within a section * In Section 5.3, constrain field combination to be within a section
skipping to change at page 229, line 44 skipping to change at page 231, line 44
* In Section 8.8.2.2, relax arbitrary 60-second comparison limit * In Section 8.8.2.2, relax arbitrary 60-second comparison limit
(<https://github.com/httpwg/http-core/issues/510>) (<https://github.com/httpwg/http-core/issues/510>)
* In Section 7.2, add ":authority" pseudo-header to Host discussion * In Section 7.2, add ":authority" pseudo-header to Host discussion
and make section applicable to both (<https://github.com/httpwg/ and make section applicable to both (<https://github.com/httpwg/
http-core/issues/511>) http-core/issues/511>)
* In Section 18.4, note that this document updates [RFC3864] * In Section 18.4, note that this document updates [RFC3864]
(<https://github.com/httpwg/http-core/issues/515>) (<https://github.com/httpwg/http-core/issues/515>)
* Moved transfer-coding ABNF from [Messaging] to Section 10.1.4 and * Moved transfer-coding ABNF from [HTTP/1.1] to Section 10.1.4 and
replaced "t-ranking" ABNF by equivalent "weight" replaced "t-ranking" ABNF by equivalent "weight"
(<https://github.com/httpwg/http-core/issues/531>) (<https://github.com/httpwg/http-core/issues/531>)
* In Section 11.5, replace "canonical root URI" by "origin" * In Section 11.5, replace "canonical root URI" by "origin"
(<https://github.com/httpwg/http-core/issues/542>) (<https://github.com/httpwg/http-core/issues/542>)
* In Section 10.1.1, remove obsolete note about a change in RFC 723x * In Section 10.1.1, remove obsolete note about a change in RFC 723x
(<https://github.com/httpwg/http-core/issues/547>) (<https://github.com/httpwg/http-core/issues/547>)
* Changed to using "payload" when defining requirements about the * Changed to using "payload" when defining requirements about the
skipping to change at page 230, line 38 skipping to change at page 232, line 38
* In Section 14.2, potentially allow Range handling on methods other * In Section 14.2, potentially allow Range handling on methods other
than GET (<https://github.com/httpwg/http-core/issues/581>) than GET (<https://github.com/httpwg/http-core/issues/581>)
* In Section 18.3, remove redundant text about status code 418 * In Section 18.3, remove redundant text about status code 418
(<https://github.com/httpwg/http-core/issues/583>) (<https://github.com/httpwg/http-core/issues/583>)
* In Section 17.16.1, rewrite requirement to refer to "secured * In Section 17.16.1, rewrite requirement to refer to "secured
connection" (<https://github.com/httpwg/http-core/issues/587>) connection" (<https://github.com/httpwg/http-core/issues/587>)
* Make reference to [RFC8446] normative (<https://github.com/httpwg/ * Make reference to [TLS13] normative (<https://github.com/httpwg/
http-core/issues/589>) http-core/issues/589>)
C.15. Since draft-ietf-httpbis-semantics-13 C.15. Since draft-ietf-httpbis-semantics-13
* In Section 12.5.1, remove the unused "accept parameters" * In Section 12.5.1, remove the unused "accept parameters"
(<https://github.com/httpwg/http-core/issues/568>) (<https://github.com/httpwg/http-core/issues/568>)
* In Section 1.2, mention that RFC 1945 describes HTTP/0.9 as well * In Section 1.2, mention that RFC 1945 describes HTTP/0.9 as well
(<https://github.com/httpwg/http-core/issues/614>) (<https://github.com/httpwg/http-core/issues/614>)
* In Section 14.5, describe non-standard use of the Content-Range * In Section 14.5, describe non-standard use of the Content-Range
header field (Section 14.4) as a request modifier to perform a header field (Section 14.4) as a request modifier to perform a
partial PUT (<https://github.com/httpwg/http-core/issues/618>) partial PUT (<https://github.com/httpwg/http-core/issues/618>)
* In Section 15.5.20, import the 421 (Misdirected Request) status * In Section 15.5.20, import the 421 (Misdirected Request) status
code from [RFC7540] (<https://github.com/httpwg/http-core/ code from [HTTP/2] (<https://github.com/httpwg/http-core/
issues/622>) issues/622>)
* In Section 2.3, rephrase the actual recipient parsing requirements * In Section 2.3, rephrase the actual recipient parsing requirements
(<https://github.com/httpwg/http-core/issues/634>) (<https://github.com/httpwg/http-core/issues/634>)
* In Section 16.1.2, mention request target forms in considerations * In Section 16.1.2, mention request target forms in considerations
for new methods (<https://github.com/httpwg/http-core/issues/636>) for new methods (<https://github.com/httpwg/http-core/issues/636>)
* Changed to using "content" instead of "payload" or "payload data" * Changed to using "content" instead of "payload" or "payload data"
to avoid confusion with the payload of version-specific messaging to avoid confusion with the payload of version-specific messaging
skipping to change at page 233, line 30 skipping to change at page 235, line 30
CONNECT message is version-specific (<https://github.com/httpwg/ CONNECT message is version-specific (<https://github.com/httpwg/
http-core/issues/780>) http-core/issues/780>)
* In Section 4.2.3, clarify how normalization works, and align with * In Section 4.2.3, clarify how normalization works, and align with
RF3986 (<https://github.com/httpwg/http-core/issues/788>) RF3986 (<https://github.com/httpwg/http-core/issues/788>)
* In Section 10.1.5, note that the Trailer field can be used to * In Section 10.1.5, note that the Trailer field can be used to
discover deleted trailers (<https://github.com/httpwg/http-core/ discover deleted trailers (<https://github.com/httpwg/http-core/
issues/793>) issues/793>)
* Throughout, remove unneeded normative references to [Messaging] * Throughout, remove unneeded normative references to [HTTP/1.1]
(<https://github.com/httpwg/http-core/issues/795>) (<https://github.com/httpwg/http-core/issues/795>)
* In Section 10.1.4, explicitly require listing in Connection * In Section 10.1.4, explicitly require listing in Connection
(<https://github.com/httpwg/http-core/issues/809>) (<https://github.com/httpwg/http-core/issues/809>)
C.17. Since draft-ietf-httpbis-semantics-15 C.17. Since draft-ietf-httpbis-semantics-15
* For [HTTP3], add an RFC Editor note to rename to "RFCnnn" before * For [HTTP/3], add an RFC Editor note to rename to "RFCnnn" before
publication (<https://github.com/httpwg/http-core/issues/815>) publication (<https://github.com/httpwg/http-core/issues/815>)
* In Section 9.3.2, align prose about content in HEAD requests with * In Section 9.3.2, align prose about content in HEAD requests with
description of GET (<https://github.com/httpwg/http-core/ description of GET (<https://github.com/httpwg/http-core/
issues/826>) issues/826>)
* In Section 5.3, remove the restriction to non-empty field line * In Section 5.3, remove the restriction to non-empty field line
values (<https://github.com/httpwg/http-core/issues/836>) values (<https://github.com/httpwg/http-core/issues/836>)
* Add forward references to definition of OWS * Add forward references to definition of OWS
(<https://github.com/httpwg/http-core/issues/841>) (<https://github.com/httpwg/http-core/issues/841>)
* In Section 17.10, add a security consideration regarding * In Section 17.10, add a security consideration regarding
application handling of field names (<https://github.com/httpwg/ application handling of field names (<https://github.com/httpwg/
http-core/issues/843>) http-core/issues/843>)
Acknowledgments C.18. Since draft-ietf-httpbis-semantics-16
This draft addresses mostly editorial issues raised during or past
IETF Last Call; see <https://github.com/httpwg/http-core/
issues?q=label%3Asemantics+created%3A%3E2021-05-26> for a summary.
Furthermore:
* In Section 15.3.7, reinstate 'to a request'
(<https://github.com/httpwg/http-core/issues/857>)
* Align Section 16.3.1 with Section 16.3.2.1
(<https://github.com/httpwg/http-core/issues/857>)
* 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>)
* In Section 7.6.3, don't specify TCP (<https://github.com/httpwg/
http-core/issues/865>)
* In Section 6.4, explain the "Content-" prefix
(<https://github.com/httpwg/http-core/issues/878>)
* In Section 7.4, check all target URIs for scheme semantic
mismatches (<https://github.com/httpwg/http-core/issues/896>)
* 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>)
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,
skipping to change at page 234, line 34 skipping to change at page 237, line 21
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
7234, and RFC 7235. The acknowledgements within those documents 7234, and RFC 7235. The acknowledgements within those documents
still apply. still apply.
Since 2014, the following contributors have helped improve this Since 2014, the following contributors have helped improve this
specification by reporting bugs, asking smart questions, drafting or specification by reporting bugs, asking smart questions, drafting or
reviewing text, and evaluating open issues: reviewing text, and evaluating open issues:
Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders
Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron
Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright, Duby, Asanka Herath, Asbjørn Ulsberg, Asta Olofsson, Attila Gulyas,
Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris Austin Wright, Barry Pollard, Ben Burkert, Benjamin Kaduk, Björn
Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa, Höhrmann, Brad Fitzpatrick, Chris Pacejo, Colin Bendell, Cory
Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David Benfield, Cory Nelson, Daisuke Miyakawa, Dale Worley, Daniel
Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Stenberg, Danil Suits, David Benjamin, David Matson, David Schinazi,
Rescorla, Erwin Pe, Etan Kissling, Evert Pot, Evgeny Vrublevsky, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Rescorla, Éric
Florian Best, Igor Lubashev, James Callahan, James Peach, Jeffrey Vyncke, Erik Kline, Erwin Pe, Etan Kissling, Evert Pot, Evgeny
Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken Vrublevsky, Florian Best, Francesca Palombini, Igor Lubashev, James
Murchison, Krzysztof Maczyński, Lucas Pardue, Martin Dürst, Martin Callahan, James Peach, Jeffrey Yasskin, Kalin Gyokov, Kannan Goundan,
Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael 奥 一穂 (Kazuho Oku), Ken Murchison, Krzysztof Maczyński, Lars Eggert,
Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Nathaniel Lucas Pardue, Martin Duke, Martin Dürst, Martin Thomson, Martynas
J. Smith, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr Jusevičius, Matt Menke, Matthias Pigulla, Mattias Grenfeldt, Michael
Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Samuel Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Mohit
Williams, Semyon Kholodnov, Simon Pieters, Simon Schüppel, Todd Sethi, Murray Kucherawy, Nathaniel J. Smith, Nicholas Hurley, Nikita
Greer, Tommy Pauly, Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, Prokhorov, Patrick McManus, Piotr Sikora, Poul-Henning Kamp, Rick van
William A. Rowe Jr., Willy Tarreau, Xingwei Liu, and Yishuai Li. Rein, Robert Wilton, Roberto Polli, Roman Danyliw, Samuel Williams,
Semyon Kholodnov, Simon Pieters, Simon Schüppel, Stefan Eissing,
Taylor Hunt, Todd Greer, Tommy Pauly, Vasiliy Faronov, Vladimir
Lashchev, Wenbo Zhu, William A. Rowe Jr., Willy Tarreau, Xingwei Liu,
Yishuai Li, and Zaheduzzaman Sarker.
Index Index
1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X 1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X
1 1
100 Continue (status code) Section 15.2.1 100 Continue (status code) Section 15.2.1
100-continue (expect value) Section 10.1.1 100-continue (expect value) Section 10.1.1
101 Switching Protocols (status code) Section 15.2.2 101 Switching Protocols (status code) Section 15.2.2
 End of changes. 254 change blocks. 
756 lines changed or deleted 877 lines changed or added

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