draft-ietf-httpbis-semantics-10.txt   draft-ietf-httpbis-semantics-11.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
Intended status: Standards Track J. F. Reschke, Ed. Intended status: Standards Track J. F. Reschke, Ed.
Expires: January 13, 2021 greenbytes Expires: February 28, 2021 greenbytes
July 12, 2020 August 27, 2020
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-10 draft-ietf-httpbis-semantics-11
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix D.11. The changes in this draft are summarized in Appendix C.12.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2021. This Internet-Draft will expire on February 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 41 skipping to change at page 2, line 41
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 10 1.2. Evolution . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . 10 1.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4. Obsoletes . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 11 1.5. Requirements Notation . . . . . . . . . . . . . . . . . . 11
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 14 1.6. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 11
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.6.1. Whitespace . . . . . . . . . . . . . . . . . . . . . 12
2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 16 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 13
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 18 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 15
2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 19 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.3. http and https URI Normalization and Comparison . . . 20 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 18
2.5.4. Deprecated userinfo . . . . . . . . . . . . . . . . . 20 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.5. Fragment Identifiers on http(s) URI References . . . 21 2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 19
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 20
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 21 2.5.3. http and https URI Normalization and Comparison . . . 21
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 22 2.5.4. Deprecated userinfo . . . . . . . . . . . . . . . . . 21
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 23 2.5.5. Fragment Identifiers on http(s) URI References . . . 22
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Extending and Versioning HTTP . . . . . . . . . . . . . . . . 24 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 22
4.1. Extending HTTP . . . . . . . . . . . . . . . . . . . . . 24 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 23
4.2. Protocol Versioning . . . . . . . . . . . . . . . . . . . 25 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 24
5. Header and Trailer Fields . . . . . . . . . . . . . . . . . . 26 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 24
5.1. Field Ordering and Combination . . . . . . . . . . . . . 27 4. Extending and Versioning HTTP . . . . . . . . . . . . . . . . 25
5.2. Field Limits . . . . . . . . . . . . . . . . . . . . . . 28 4.1. Extending HTTP . . . . . . . . . . . . . . . . . . . . . 25
5.3. Field Names . . . . . . . . . . . . . . . . . . . . . . . 28 4.2. Protocol Versioning . . . . . . . . . . . . . . . . . . . 26
5.3.1. Field Extensibility . . . . . . . . . . . . . . . . . 29 5. Header and Trailer Fields . . . . . . . . . . . . . . . . . . 27
5.3.2. Field Name Registry . . . . . . . . . . . . . . . . . 30 5.1. Field Ordering and Combination . . . . . . . . . . . . . 28
5.4. Field Values . . . . . . . . . . . . . . . . . . . . . . 31 5.2. Field Limits . . . . . . . . . . . . . . . . . . . . . . 29
5.4.1. Common Field Value Components . . . . . . . . . . . . 32 5.3. Field Names . . . . . . . . . . . . . . . . . . . . . . . 30
5.5. ABNF List Extension: #rule . . . . . . . . . . . . . . . 36 5.3.1. Field Extensibility . . . . . . . . . . . . . . . . . 30
5.5.1. Sender Requirements . . . . . . . . . . . . . . . . . 36 5.3.2. Field Name Registry . . . . . . . . . . . . . . . . . 31
5.5.2. Recipient Requirements . . . . . . . . . . . . . . . 37 5.4. Field Values . . . . . . . . . . . . . . . . . . . . . . 32
5.6. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 37 5.4.1. Common Field Value Components . . . . . . . . . . . . 34
5.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 38 5.5. ABNF List Extension: #rule . . . . . . . . . . . . . . . 37
5.6.2. Limitations . . . . . . . . . . . . . . . . . . . . . 38 5.5.1. Sender Requirements . . . . . . . . . . . . . . . . . 38
5.6.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.2. Recipient Requirements . . . . . . . . . . . . . . . 38
5.7. Considerations for New HTTP Fields . . . . . . . . . . . 39 5.6. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 39
5.8. Fields Defined In This Document . . . . . . . . . . . . . 40 5.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 39
6. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 42 5.6.2. Limitations . . . . . . . . . . . . . . . . . . . . . 39
6.1. Identifying a Target Resource . . . . . . . . . . . . . . 42 5.6.3. Processing . . . . . . . . . . . . . . . . . . . . . 40
6.2. Determining Origin . . . . . . . . . . . . . . . . . . . 43 5.6.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . 41
6.3. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 43 5.6.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4. Direct Authoritative Access . . . . . . . . . . . . . . . 44 5.7. Considerations for New HTTP Fields . . . . . . . . . . . 41
6.4.1. http origins . . . . . . . . . . . . . . . . . . . . 44 5.8. Fields Defined In This Document . . . . . . . . . . . . . 43
6.4.2. https origins . . . . . . . . . . . . . . . . . . . . 45 6. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 44
6.4.3. Initiating HTTP Over TLS . . . . . . . . . . . . . . 46 6.1. Identifying a Target Resource . . . . . . . . . . . . . . 44
6.5. Reconstructing the Target URI . . . . . . . . . . . . . . 48 6.2. Determining Origin . . . . . . . . . . . . . . . . . . . 45
6.6. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.3. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 45
6.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 50 6.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 46
6.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 46
6.7.2. Transformations . . . . . . . . . . . . . . . . . . . 52 6.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 46
7. Representations . . . . . . . . . . . . . . . . . . . . . . . 53 6.4. Reconstructing the Target URI . . . . . . . . . . . . . . 49
7.1. Representation Data . . . . . . . . . . . . . . . . . . . 54 6.5. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 54 6.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 50
7.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 56 6.6.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 58 6.6.2. Transformations . . . . . . . . . . . . . . . . . . . 53
7.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 59 6.7. Upgrading HTTP . . . . . . . . . . . . . . . . . . . . . 54
7.2. Representation Metadata . . . . . . . . . . . . . . . . . 63 6.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 56
7.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 63 6.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 56
7.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 64
7.2.3. Content-Language . . . . . . . . . . . . . . . . . . 65
7.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 66
7.2.5. Content-Location . . . . . . . . . . . . . . . . . . 67
7.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 69
7.3.2. Identification . . . . . . . . . . . . . . . . . . . 70
7.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 71
7.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 72
7.3.5. Media Type multipart/byteranges . . . . . . . . . . . 73
7.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 75
7.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 76
7.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 77
7.4.3. Request Payload Negotiation . . . . . . . . . . . . . 78
7.4.4. Quality Values . . . . . . . . . . . . . . . . . . . 78
8. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 79
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2. Common Method Properties . . . . . . . . . . . . . . . . 80
8.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 81
8.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 82
8.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 83
8.3. Method Definitions . . . . . . . . . . . . . . . . . . . 83
8.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 84
8.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 84
8.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 88
8.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 89
8.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 91
8.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 92
8.4. Method Extensibility . . . . . . . . . . . . . . . . . . 92
8.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 92
8.4.2. Considerations for New Methods . . . . . . . . . . . 93
9. Request Header Fields . . . . . . . . . . . . . . . . . . . . 94
9.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 97
9.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 97
9.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 98
9.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 99
9.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 101
9.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 102
9.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 103
9.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 105
9.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 106
9.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 109
9.4.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 110
9.4.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 112
9.4.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . 113
9.4.4. Accept-Language . . . . . . . . . . . . . . . . . . . 115
9.5. Authentication Credentials . . . . . . . . . . . . . . . 116
9.5.1. Challenge and Response . . . . . . . . . . . . . . . 116
9.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 118
9.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 119
9.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 119
9.5.5. Authentication Scheme Extensibility . . . . . . . . . 120
9.6. Request Context . . . . . . . . . . . . . . . . . . . . . 122
9.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 122
9.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 123
9.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 124
10. Response Status Codes . . . . . . . . . . . . . . . . . . . . 125
10.1. Overview of Status Codes . . . . . . . . . . . . . . . . 126
10.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 127
10.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 127
10.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 128
10.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 128
10.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 128
10.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 129
10.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 129
10.3.4. 203 Non-Authoritative Information . . . . . . . . . 130
10.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 130
10.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 131
10.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 131
10.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 135
10.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 136
10.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 137
10.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 137
10.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 138
10.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 138
10.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 139
10.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 139
10.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 139
10.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 140
10.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 140
10.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 140
10.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 140
10.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 141
10.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 141
10.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 141
10.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 142
10.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 142
10.5.8. 407 Proxy Authentication Required . . . . . . . . . 142
10.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 142
10.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 143
10.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 143
10.5.12. 411 Length Required . . . . . . . . . . . . . . . . 143
10.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 144
10.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . 144
10.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 144
10.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 144
10.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 145
10.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 145
10.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 146
10.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . 146
10.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 146
10.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 147
10.6.1. 500 Internal Server Error . . . . . . . . . . . . . 147
10.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 147
10.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 147
10.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 147
10.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 148
10.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 148
10.7. Status Code Extensibility . . . . . . . . . . . . . . . 148
10.7.1. Status Code Registry . . . . . . . . . . . . . . . . 148
10.7.2. Considerations for New Status Codes . . . . . . . . 149
11. Response Header Fields . . . . . . . . . . . . . . . . . . . 150
11.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 150
11.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . 150
11.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 151
11.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 153
11.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 153
11.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 154
11.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 155
11.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 157
11.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 159
11.2.4. When to Use Entity-Tags and Last-Modified Dates . . 162
11.3. Authentication Challenges . . . . . . . . . . . . . . . 163
11.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 163
11.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 164
11.3.3. Authentication-Info . . . . . . . . . . . . . . . . 165
11.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 166
11.4. Response Context . . . . . . . . . . . . . . . . . . . . 166
11.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 166
11.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 167
11.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 167
12. Security Considerations . . . . . . . . . . . . . . . . . . . 168
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 168
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 169
12.3. Attacks Based on File and Path Names . . . . . . . . . . 170
12.4. Attacks Based on Command, Code, or Query Injection . . . 171
12.5. Attacks via Protocol Element Length . . . . . . . . . . 171
12.6. Disclosure of Personal Information . . . . . . . . . . . 172
12.7. Privacy of Server Log Information . . . . . . . . . . . 172
12.8. Disclosure of Sensitive Information in URIs . . . . . . 173
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 173
12.10. Disclosure of Product Information . . . . . . . . . . . 173
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 174
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 175
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 175
12.14. Authentication Considerations . . . . . . . . . . . . . 176
12.14.1. Confidentiality of Credentials . . . . . . . . . . 176
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 176
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 177
12.14.4. Additional Response Fields . . . . . . . . . . . . 177
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 177
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 178
13.2. Method Registration . . . . . . . . . . . . . . . . . . 178
13.3. Status Code Registration . . . . . . . . . . . . . . . . 178
13.4. HTTP Field Name Registration . . . . . . . . . . . . . . 178
13.5. Authentication Scheme Registration . . . . . . . . . . . 179
13.6. Content Coding Registration . . . . . . . . . . . . . . 179
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 180
13.8. Media Type Registration . . . . . . . . . . . . . . . . 180
13.9. Port Registration . . . . . . . . . . . . . . . . . . . 180
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 180
14.1. Normative References . . . . . . . . . . . . . . . . . . 180
14.2. Informative References . . . . . . . . . . . . . . . . . 182
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 188
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 192
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 192
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 192
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 193
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 194
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 194
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 194
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 194
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 194
Appendix C. Changes from RFC 7694 . . . . . . . . . . . . . . . 195
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 195
D.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 195
D.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 195
D.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 196
D.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 197
D.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 198
D.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 199
D.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 199
D.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 201
D.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 202
D.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 203
D.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 204
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 205
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 205
1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- 6.8. Connection-Specific Fields . . . . . . . . . . . . . . . 57
level request/response protocol that uses extensible semantics and 7. Representations . . . . . . . . . . . . . . . . . . . . . . . 59
self-descriptive messages for flexible interaction with network-based 7.1. Representation Data . . . . . . . . . . . . . . . . . . . 59
hypertext information systems. HTTP is defined by a series of 7.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 60
documents that collectively form the HTTP/1.1 specification: 7.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 62
7.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 64
7.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 64
7.2. Representation Metadata . . . . . . . . . . . . . . . . . 68
7.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 69
7.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 70
7.2.3. Content-Language . . . . . . . . . . . . . . . . . . 71
7.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 72
7.2.5. Content-Location . . . . . . . . . . . . . . . . . . 73
7.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 75
7.3.2. Identification . . . . . . . . . . . . . . . . . . . 76
7.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 77
7.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 78
7.3.5. Media Type multipart/byteranges . . . . . . . . . . . 79
7.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 81
7.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 82
7.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 83
7.4.3. Request Payload Negotiation . . . . . . . . . . . . . 84
7.4.4. Quality Values . . . . . . . . . . . . . . . . . . . 84
8. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 85
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2. Common Method Properties . . . . . . . . . . . . . . . . 86
8.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 87
8.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 88
8.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 89
8.3. Method Definitions . . . . . . . . . . . . . . . . . . . 89
8.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 90
8.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 95
8.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 96
8.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 97
8.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 98
8.4. Method Extensibility . . . . . . . . . . . . . . . . . . 99
8.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 99
8.4.2. Considerations for New Methods . . . . . . . . . . . 100
9. Request Header Fields . . . . . . . . . . . . . . . . . . . . 100
9.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 100
9.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 101
9.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 103
9.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 104
9.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 105
9.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 106
9.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 107
9.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 109
9.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 110
9.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 112
9.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 113
9.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 114
9.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 116
9.4.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 117
9.4.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 119
9.4.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . 120
9.4.4. Accept-Language . . . . . . . . . . . . . . . . . . . 122
9.5. Authentication Credentials . . . . . . . . . . . . . . . 123
9.5.1. Challenge and Response . . . . . . . . . . . . . . . 123
9.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 125
9.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 126
9.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 126
9.5.5. Authentication Scheme Extensibility . . . . . . . . . 127
9.6. Request Context . . . . . . . . . . . . . . . . . . . . . 129
9.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 129
9.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 130
9.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 131
10. Response Status Codes . . . . . . . . . . . . . . . . . . . . 132
10.1. Overview of Status Codes . . . . . . . . . . . . . . . . 133
10.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 134
10.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 134
10.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 135
10.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 135
10.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 135
10.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 136
10.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 136
10.3.4. 203 Non-Authoritative Information . . . . . . . . . 137
10.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 137
10.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 138
10.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 138
10.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 141
10.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 144
10.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 145
10.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 145
10.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 146
10.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 146
10.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 147
10.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 147
10.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 147
10.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 148
10.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 148
10.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 148
10.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 148
10.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 149
10.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 149
10.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 149
10.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 150
10.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 150
10.5.8. 407 Proxy Authentication Required . . . . . . . . . 150
10.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 150
10.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 151
10.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 151
10.5.12. 411 Length Required . . . . . . . . . . . . . . . . 151
10.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 152
10.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . 152
10.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 152
10.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 152
10.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 153
10.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 153
10.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 154
10.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . 154
10.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 154
10.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 155
10.6.1. 500 Internal Server Error . . . . . . . . . . . . . 155
10.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 155
10.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 155
10.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 155
10.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 156
10.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 156
10.7. Status Code Extensibility . . . . . . . . . . . . . . . 156
10.7.1. Status Code Registry . . . . . . . . . . . . . . . . 156
10.7.2. Considerations for New Status Codes . . . . . . . . 157
11. Response Header Fields . . . . . . . . . . . . . . . . . . . 158
11.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 158
11.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . 158
11.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 159
11.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 161
11.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 161
11.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 162
11.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 163
11.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 165
11.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 167
11.2.4. When to Use Entity-Tags and Last-Modified Dates . . 170
11.3. Authentication Challenges . . . . . . . . . . . . . . . 171
11.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 172
11.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 173
11.3.3. Authentication-Info . . . . . . . . . . . . . . . . 173
11.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 174
11.4. Response Context . . . . . . . . . . . . . . . . . . . . 175
11.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 175
11.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 175
11.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 176
12. Security Considerations . . . . . . . . . . . . . . . . . . . 177
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 177
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 178
12.3. Attacks Based on File and Path Names . . . . . . . . . . 179
12.4. Attacks Based on Command, Code, or Query Injection . . . 179
12.5. Attacks via Protocol Element Length . . . . . . . . . . 180
12.6. Attacks using Shared-dictionary Compression . . . . . . 180
12.7. Disclosure of Personal Information . . . . . . . . . . . 181
12.8. Privacy of Server Log Information . . . . . . . . . . . 181
12.9. Disclosure of Sensitive Information in URIs . . . . . . 182
12.10. Disclosure of Fragment after Redirects . . . . . . . . . 182
12.11. Disclosure of Product Information . . . . . . . . . . . 183
12.12. Browser Fingerprinting . . . . . . . . . . . . . . . . . 183
12.13. Validator Retention . . . . . . . . . . . . . . . . . . 184
12.14. Denial-of-Service Attacks Using Range . . . . . . . . . 184
12.15. Authentication Considerations . . . . . . . . . . . . . 185
12.15.1. Confidentiality of Credentials . . . . . . . . . . 185
12.15.2. Credentials and Idle Clients . . . . . . . . . . . 186
12.15.3. Protection Spaces . . . . . . . . . . . . . . . . . 186
12.15.4. Additional Response Fields . . . . . . . . . . . . 187
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 187
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 187
13.2. Method Registration . . . . . . . . . . . . . . . . . . 187
13.3. Status Code Registration . . . . . . . . . . . . . . . . 187
13.4. HTTP Field Name Registration . . . . . . . . . . . . . . 188
13.5. Authentication Scheme Registration . . . . . . . . . . . 189
13.6. Content Coding Registration . . . . . . . . . . . . . . 189
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 189
13.8. Media Type Registration . . . . . . . . . . . . . . . . 189
13.9. Port Registration . . . . . . . . . . . . . . . . . . . 189
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 189
14.1. Normative References . . . . . . . . . . . . . . . . . . 189
14.2. Informative References . . . . . . . . . . . . . . . . . 191
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 197
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 202
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 202
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 202
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 203
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 204
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 205
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 205
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 205
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 205
B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 205
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 205
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 205
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 206
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 206
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 208
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 208
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 209
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 210
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 211
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 212
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 214
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 215
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 215
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 217
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 217
o "HTTP Semantics" (this document) 1. Introduction
o "HTTP Caching" [Caching] 1.1. Purpose
o "HTTP/1.1 Messaging" [Messaging] The Hypertext Transfer Protocol (HTTP) is a family of stateless,
application-level, request/response protocols that share a generic
interface, extensible semantics, and self-descriptive messages to
enable flexible interaction with network-based hypertext information
systems.
HTTP is a generic interface protocol for information systems. It is HTTP hides the details of how a service is implemented by presenting
designed to hide the details of how a service is implemented by a uniform interface to clients that is independent of the types of
presenting a uniform interface to clients that is independent of the resources provided. Likewise, servers do not need to be aware of
types of resources provided. Likewise, servers do not need to be each client's purpose: a request can be considered in isolation
aware of each client's purpose: an HTTP request can be considered in rather than being associated with a specific type of client or a
isolation rather than being associated with a specific type of client predetermined sequence of application steps. This allows general-
or a predetermined sequence of application steps. The result is a purpose implementations to be used effectively in many different
protocol that can be used effectively in many different contexts and contexts, reduces interaction complexity, and enables independent
for which implementations can evolve independently over time. evolution over time.
HTTP is also designed for use as an intermediation protocol for HTTP is also designed for use as an intermediation protocol, wherein
translating communication to and from non-HTTP information systems. proxies and gateways can translate non-HTTP information systems into
HTTP proxies and gateways can provide access to alternative a more generic interface.
information services by translating their diverse protocols into a
hypertext format that can be viewed and manipulated by clients in the
same way as HTTP services.
One consequence of this flexibility is that the protocol cannot be One consequence of this flexibility is that the protocol cannot be
defined in terms of what occurs behind the interface. Instead, we defined in terms of what occurs behind the interface. Instead, we
are limited to defining the syntax of communication, the intent of are limited to defining the syntax of communication, the intent of
received communication, and the expected behavior of recipients. If received communication, and the expected behavior of recipients. If
the communication is considered in isolation, then successful actions the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response. such changes be observable beyond the scope of a single response.
Each HTTP message is either a request or a response. A server 1.2. Evolution
listens on a connection for a request, parses each message received,
interprets the message semantics in relation to the identified target HTTP has been the primary information transfer protocol for the World
resource, and responds to that request with one or more response Wide Web since its introduction in 1990. It began as a trivial
messages. A client constructs request messages to communicate mechanism for low-latency requests, with a single method (GET) to
specific intentions, examines received responses to see if the request transfer of a presumed hypertext document identified by a
intentions were carried out, and determines how to interpret the given pathname (HTTP/0.9). As the Web grew, HTTP was extended to
results. enclose requests and responses within messages, transfer arbitrary
data formats using MIME-like media types, and route requests through
intermediaries, eventually being defined as HTTP/1.0 [RFC1945].
HTTP/1.1 was designed to refine the protocol's features while
retaining compatibility with the existing text-based messaging
syntax, improving its interoperability, scalability, and robustness
across the Internet. This included length-based payload delimiters
for both fixed and dynamic (chunked) content, a consistent framework
for content negotiation, opaque validators for conditional requests,
cache controls for better cache consistency, range requests for
partial updates, and default persistent connections. HTTP/1.1 was
introduced in 1995 and published on the standards track in 1997
[RFC2068], 1999 [RFC2616], and 2014 ([RFC7230] - [RFC7235]).
HTTP/2 ([RFC7540]) introduced a multiplexed session layer on top of
the existing TLS and TCP protocols for exchanging concurrent HTTP
messages with efficient header field compression and server push.
HTTP/3 ([HTTP3]) provides greater independence for concurrent
messages by using QUIC as a secure multiplexed transport over UDP
instead of TCP.
All three major versions of HTTP rely on the semantics defined by
this document. They have not obsoleted each other because each one
has specific benefits and limitations depending on the context of
use. Implementations are expected to choose the most appropriate
transport and messaging syntax for their particular context.
This revision of HTTP separates the definition of semantics (this
document) and caching ([Caching]) from the current HTTP/1.1 messaging
syntax ([Messaging]) to allow each major protocol version to progress
independently while referring to the same core semantics.
1.3. Semantics
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 2.5), regardless of its type, nature, or implementation, via (Section 2.5), regardless of its type, nature, or implementation, by
the manipulation and transfer of representations (Section 7). sending messages that manipulate or transfer representations
(Section 7).
This document defines semantics that are common to all versions of Each message is either a request or a response. A client constructs
HTTP. HTTP semantics include the intentions defined by each request request messages that communicate its intentions and routes those
method (Section 8), extensions to those semantics that might be messages toward an identified origin server. A server listens for
described in request header fields (Section 9), the meaning of status requests, parses each message received, interprets the message
codes to indicate a machine-readable response (Section 10), and the semantics in relation to the identified target resource, and responds
meaning of other control data and resource metadata that might be to that request with one or more response messages. The client
given in response header fields (Section 11). examines received responses to see if its intentions were carried
out, determining what to do next based on the received status and
payloads.
This document also defines representation metadata that describe how HTTP semantics include the intentions defined by each request method
a payload is intended to be interpreted by a recipient, the request (Section 8), extensions to those semantics that might be described in
header fields that might influence content selection, and the various request header fields (Section 9), status codes that describe the
response (Section 10), and other control data and resource metadata
that might be given in response fields (Section 11).
Semantics also include representation metadata that describe how a
payload is intended to be interpreted by a recipient, request header
fields that might influence content selection, and the various
selection algorithms that are collectively referred to as "content selection algorithms that are collectively referred to as "content
negotiation" (Section 7.4). negotiation" (Section 7.4).
This document defines HTTP range requests, partial responses, and the 1.4. Obsoletes
multipart/byteranges media type.
This document obsoletes the portions of RFC 7230 that are independent This document obsoletes the following specifications:
of the HTTP/1.1 messaging syntax and connection management, with the
changes being summarized in Appendix B.2. The other parts of RFC
7230 are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This
document also obsoletes RFC 2818 (see Appendix B.1), RFC 7231 (see
Appendix B.3), RFC 7232 (see Appendix B.4), RFC 7233 (see
Appendix B.5), RFC 7235 (see Appendix B.6), RFC 7538 (see
Appendix B.7), RFC 7615 (see Appendix B.8), and RFC 7694 (see
Appendix C).
1.1. Requirements Notation -------------------------------------------- ----------- ---------
Title Reference Changes
-------------------------------------------- ----------- ---------
HTTP Over TLS [RFC2818] B.1
HTTP/1.1 Message Syntax and Routing [*] [RFC7230] B.2
HTTP/1.1 Semantics and Content [RFC7231] B.3
HTTP/1.1 Conditional Requests [RFC7232] B.4
HTTP/1.1 Range Requests [RFC7233] B.5
HTTP/1.1 Authentication [RFC7235] B.6
HTTP Status Code 308 (Permanent Redirect) [RFC7538] B.7
HTTP Authentication-Info and Proxy- [RFC7615] B.8
Authentication-Info Response Header Fields
HTTP Client-Initiated Content-Encoding [RFC7694] B.9
-------------------------------------------- ----------- ---------
Table 1
[*] This document only obsoletes the portions of RFC 7230 that are
independent of the HTTP/1.1 messaging syntax and connection
management; the remaining bits of RFC 7230 are obsoleted by "HTTP/1.1
Messaging" [Messaging].
1.5. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 3. defined in Section 3.
1.2. Syntax Notation 1.6. 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.5, that allows It also uses a list extension, defined in Section 5.5, that allows
for compact definition of comma-separated lists using a '#' operator for compact definition of comma-separated lists using a '#' operator
(similar to how the '*' operator indicates repetition). Appendix A (similar to how the '*' operator indicates repetition). Appendix A
shows the collected grammar with all list operators expanded to shows the collected grammar with all list operators expanded to
standard ABNF notation. standard ABNF notation.
skipping to change at page 10, line 30 skipping to change at page 11, line 41
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
Section 5.4.1 defines some generic syntactic components for field Section 5.4.1 defines some generic syntactic components for field
values. values.
The rules below are defined in [Messaging]: The rule below is defined in [Messaging];
protocol-name = <protocol-name, see [Messaging], Section 9.9> transfer-coding = <transfer-coding, see [Messaging], Section 7>
protocol-version = <protocol-version, see [Messaging], Section 9.9>
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
1.2.1. Whitespace 1.6.1. Whitespace
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white out invalid or generate optional whitespace except as needed to white out invalid or
skipping to change at page 12, line 32 skipping to change at page 13, line 41
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
Figure 1 Figure 1
Each major version of HTTP defines its own syntax for the inclusion Each major version of HTTP defines its own syntax for the
of information in messages. Nevertheless, a common abstraction is communication of messages. Nevertheless, a common abstraction is
that a message includes some form of envelope/framing, a potential that each message contains some form of envelope/framing with self-
set of named fields up front (a header section), a potential body, descriptive control data that indicates its semantics and routing, a
and a potential following set of named fields (a trailer section). potential set of named fields up front (a header section), a
potential body, and potential fields sent after the body begins
(trailer sections).
A client sends an HTTP request to a server in the form of a request A client sends requests to a server in the form of a request message
message with a method (Section 8) and request target. The request with a method (Section 8) and request target. The request might also
might also contain header fields for request modifiers, client contain header fields for request modifiers, client information, and
information, and representation metadata (Section 5), a payload body representation metadata (Section 5), a payload body (Section 7.3.3)
(Section 7.3.3) to be processed in accordance with the method, and to be processed in accordance with the method, and trailer fields for
trailer fields for metadata collected while sending the payload. metadata collected while sending the payload.
A server responds to a client's request by sending one or more HTTP A server responds to a client's request by sending one or more
response messages, each including a success or error code response messages, each including a status code (Section 10). The
(Section 10). The response might also contain header fields for response might also contain header fields for server information,
server information, resource metadata, and representation metadata resource metadata, and representation metadata (Section 5), a payload
(Section 5), a payload body (Section 7.3.3) to be interpreted in body (Section 7.3.3) to be interpreted in accordance with the status
accordance with the status code, and trailer fields for metadata code, and trailer fields for metadata collected while sending the
collected while sending the payload. payload.
One of the functions of the message framing mechanism is to assure One of the functions of message framing is to assure that messages
that messages are complete. A message is considered complete when are complete. A message is considered complete when all of the
all of the octets indicated by its framing are available. Note that, octets indicated by its framing are available. Note that, when no
when no explicit framing is used, a response message that is ended by explicit framing is used, a response message that is ended by the
the transport connection's close is considered complete even though transport connection's close is considered complete even though it
it might be indistinguishable from an incomplete response, unless a might be indistinguishable from an incomplete response, unless a
transport-level error indicates that it is not complete. transport-level error indicates that it is not complete.
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.
Responses (both final and interim) can be sent at any time after a Responses (both final and interim) can be sent at any time after a
request is received, even if it is not yet complete. However, request is received, even if it is not yet complete. However,
clients (including intermediaries) might abandon a request if the clients (including intermediaries) might abandon a request if the
skipping to change at page 14, line 51 skipping to change at page 16, line 16
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs, translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching. for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in messages or payloads while they are being forwarded, as described in
Section 6.7.2. Section 6.6.2.
A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection but translates received an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers. requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing "accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
skipping to change at page 15, line 35 skipping to change at page 16, line 48
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, [RFC8446]) 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 a man-in-the-middle indistinguishable (at a protocol level) from an on-path attacker,
attack, often introducing security flaws or interoperability problems often introducing security flaws or interoperability problems due to
due to mistakenly violating HTTP semantics. mistakenly violating HTTP semantics.
For example, an "interception proxy" [RFC3040] (also commonly known For example, an "interception proxy" [RFC3040] (also commonly known
as a "transparent proxy" [RFC1919] or "captive portal") differs from as a "transparent proxy" [RFC1919] or "captive portal") differs from
an HTTP proxy because it is not selected by the client. Instead, an an HTTP proxy because it is not selected by the client. Instead, an
interception proxy filters or redirects outgoing TCP port 80 packets interception proxy filters or redirects outgoing TCP port 80 packets
(and occasionally other common port traffic). Interception proxies (and occasionally other common port traffic). Interception proxies
are commonly found on public network access points, as a means of are commonly found on public network access points, as a means of
enforcing account subscription prior to allowing use of non-local enforcing account subscription prior to allowing use of non-local
Internet services, and within corporate firewalls to enforce network Internet services, and within corporate firewalls to enforce network
usage policies. usage policies.
skipping to change at page 18, line 17 skipping to change at page 19, line 31
semantics in the request method (Section 8) and a few request- semantics in the request method (Section 8) and a few request-
modifying header fields (Section 9). If there is a conflict between modifying header fields (Section 9). If there is a conflict between
the method semantics and any semantic implied by the URI itself, as the method semantics and any semantic implied by the URI itself, as
described in Section 8.2.1, the method semantics take precedence. described in Section 8.2.1, the method semantics take precedence.
IANA maintains the registry of URI Schemes [BCP35] at IANA maintains the registry of URI Schemes [BCP35] at
<https://www.iana.org/assignments/uri-schemes/>. Although requests <https://www.iana.org/assignments/uri-schemes/>. Although requests
might target any URI scheme, the following schemes are inherent to might target any URI scheme, the following schemes are inherent to
HTTP servers: HTTP servers:
+------------+------------------------------------+---------------+ ------------ ------------------------------------ -------
| URI Scheme | Description | Reference | URI Scheme Description Ref.
| http | Hypertext Transfer Protocol | Section 2.5.1 | ------------ ------------------------------------ -------
| https | Hypertext Transfer Protocol Secure | Section 2.5.2 | http Hypertext Transfer Protocol 2.5.1
+------------+------------------------------------+---------------+ https Hypertext Transfer Protocol Secure 2.5.2
------------ ------------------------------------ -------
Table 1 Table 2
Note that the presence of an "http" or "https" URI does not imply Note that the presence of an "http" or "https" URI does not imply
that there is always an HTTP server at the identified origin that there is always an HTTP server at the identified origin
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.
2.5.1. http URI Scheme 2.5.1. http URI Scheme
skipping to change at page 18, line 47 skipping to change at page 20, line 13
server listening for TCP ([RFC0793]) connections on a given port. server listening for TCP ([RFC0793]) 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 and optional port number
([RFC3986], Section 3.2.2). If the port subcomponent is empty or not ([RFC3986], Section 3.2.2). If the port subcomponent is empty or not
given, TCP port 80 (the reserved port for WWW services) is the given, TCP port 80 (the reserved port for WWW services) is the
default. The origin determines who has the right to respond default. The origin determines who has the right to respond
authoritatively to requests that target the identified resource, as authoritatively to requests that target the identified resource, as
defined in Section 6.4.1. defined in Section 6.3.3.1.
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.
2.5.2. https URI Scheme 2.5.2. https URI Scheme
skipping to change at page 19, line 28 skipping to change at page 20, line 42
strong encryption. strong encryption.
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 and optional port number
([RFC3986], Section 3.2.2). If the port subcomponent is empty or not ([RFC3986], Section 3.2.2). If the port subcomponent is empty or not
given, TCP port 443 (the reserved port for HTTP over TLS) is the given, TCP port 443 (the reserved port for HTTP over TLS) is the
default. The origin determines who has the right to respond default. The origin determines who has the right to respond
authoritatively to requests that target the identified resource, as authoritatively to requests that target the identified resource, as
defined in Section 6.4.2. defined in Section 6.3.3.2.
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
skipping to change at page 26, line 35 skipping to change at page 27, line 35
implementation of the same major version. implementation of the same major version.
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 and is used when referring to that
protocol within a protocol element that requires sending a minor protocol within a protocol element that requires sending a minor
version. version.
5. Header and Trailer Fields 5. Header and Trailer Fields
HTTP messages use key/value pairs to convey data about the message, HTTP messages use key/value pairs to convey data about the message,
its payload, the target resource, or the connection (i.e., control its payload, the target resource, or the connection. They are called
data). They are called "HTTP fields" or just "fields". "HTTP fields" or just "fields".
Every message can have two separate areas that such fields can occur Fields that are sent/received before the message body are referred to
within; the "header field section" (or just "header section") as "header fields" (or just "headers", colloquially) and are located
preceding the message body and containing "header fields" (or just within the "header section" of a message. We refer to some named
"headers", colloquially) and the "trailer field section" (or just fields specifically as a "header field" when they are only allowed to
"trailer section") after the message body containing "trailer fields" be sent in the header section.
(or just "trailers" colloquially). Header fields are more common;
see Section 5.6 for discussion of the applicability and limitations Fields that are sent/received after the header section has ended
of trailer fields. (usually after the message body begins to stream) are referred to as
"trailer fields" (or just "trailers", colloquially) and located
within a "trailer section". One or more trailer sections are only
possible when supported by the version of HTTP in use and enabled by
an extensible mechanism for framing message sections.
Both sections are composed of any number of "field lines", each with Both sections are composed of any number of "field lines", each with
a "field name" (see Section 5.3) identifying the field, and a "field a "field name" (see Section 5.3) identifying the field, and a "field
line value" that conveys data for the field. line value" that conveys data for the field.
Each field name present in a section has a corresponding "field Each field name present in a section has a corresponding "field
value" for that section, composed from all field line values with value" for that section, composed from all field line values with
that given field name in that section, concatenated together and that given field name in that section, concatenated together and
separated with commas. See Section 5.1 for further discussion of the separated with commas. See Section 5.1 for further discussion of the
semantics of field ordering and combination in messages, and semantics of field ordering and combination in messages, and
skipping to change at page 28, line 31 skipping to change at page 29, line 37
| 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.)
5.2. Field Limits 5.2. Field Limits
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 the header or trailer section line, field value, or on the length of a header or trailer section as
as a whole, as described in Section 3. Various ad hoc limitations on a whole, as described in Section 3. 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 [Messaging]).
A client MAY discard or truncate received field lines that are larger A client MAY discard or truncate received field lines that are larger
skipping to change at page 30, line 6 skipping to change at page 31, line 6
There is no limit on the introduction of new field names, each There is no limit on the introduction of new field names, each
presumably defining new semantics. presumably defining new semantics.
New fields can be defined such that, when they are understood by a New fields can be defined such that, when they are understood by a
recipient, they might override or enhance the interpretation of recipient, they might override or enhance the interpretation of
previously defined fields, define preconditions on request previously defined fields, define preconditions on request
evaluation, or refine the meaning of responses. evaluation, or refine the meaning of responses.
A proxy MUST forward unrecognized header fields unless the field name A proxy MUST forward unrecognized header fields unless the field name
is listed in the Connection header field (Section 9.1 of [Messaging]) is listed in the Connection header field (Section 6.8) or the proxy
or the proxy is specifically configured to block, or otherwise is specifically configured to block, or otherwise transform, such
transform, such fields. Other recipients SHOULD ignore unrecognized fields. Other recipients SHOULD ignore unrecognized header and
header and trailer fields. These requirements allow HTTP's trailer fields. These requirements allow HTTP's functionality to be
functionality to be enhanced without requiring prior update of enhanced without requiring prior update of deployed intermediaries.
deployed intermediaries.
5.3.2. Field Name Registry 5.3.2. Field Name Registry
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 a HTTP field. See Section 5.7 Any party can request registration of a HTTP field. See Section 5.7
for considerations to take into account when creating a new HTTP for considerations to take into account when creating a new HTTP
field. field.
skipping to change at page 31, line 49 skipping to change at page 32, line 49
subset of the US-ASCII charset [USASCII]. Newly defined fields subset of the US-ASCII charset [USASCII]. Newly defined fields
SHOULD limit their values to US-ASCII octets. A recipient SHOULD SHOULD limit their values to US-ASCII octets. A recipient SHOULD
treat other octets in field content (obs-text) as opaque data. treat other octets in field content (obs-text) as opaque data.
Field values containing control (CTL) characters such as CR or LF are Field values containing control (CTL) characters such as CR or LF are
invalid; recipients MUST either reject a field value containing invalid; recipients MUST either reject a field value containing
control characters, or convert them to SP before processing or control characters, or convert them to SP before processing or
forwarding the message. forwarding the message.
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 5.1 of [Messaging]). Field definitions where field parsing (e.g., Section 5.1 of [Messaging]). Field definitions
leading or trailing whitespace in values is significant will have to where leading or trailing whitespace in values is significant will
use a container syntax such as quoted-string (Section 5.4.1.2). have to use a container syntax such as quoted-string
(Section 5.4.1.2).
Because commas (",") are used as a generic delimiter between members Commas (",") often are used to separate members in field values.
of a list-based field value, they need to be treated with care if Fields that allow multiple members are referred to as list-based
they are allowed as data within those members. Typically, list fields. Fields that only anticipate a single member are referred to
members that might contain a comma are enclosed in a quoted-string. as singleton fields.
Because commas are used as a generic delimiter between members, they
need to be treated with care if they are allowed as data within a
member. This is true for both list-based and singleton fields, since
a singleton field might be sent with multiple members erroneously;
being able to detect this condition improves interoperability.
Fields that expect to contain a comma within a member, such as an
HTTP-date or URI-reference element, ought to be defined with
delimiters around that element to distinguish any comma within that
data from potential list separators.
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-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the Note that double-quote delimiters almost always are used with the
skipping to change at page 34, line 7 skipping to change at page 35, line 16
Comments can be included in some HTTP fields by surrounding the Comments can be included in some HTTP fields by surrounding the
comment text with parentheses. Comments are only allowed in fields comment text with parentheses. Comments are only allowed in fields
containing "comment" as part of their field value definition. containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
5.4.1.4. Parameters 5.4.1.4. Parameters
A parameter is a name=value pair that is often defined within field Parameters are zero or more instances of a name=value pair; they are
values as a common syntax for appending auxiliary information to an often used in field values as a common syntax for appending auxiliary
item. Each parameter is usually delimited by an immediately information to an item. Each parameter is usually delimited by an
preceding semicolon. immediately preceding semicolon.
parameters = *( OWS ";" OWS [ parameter ] )
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 )
Parameter names are case-insensitive. Parameter values might or Parameter names are case-insensitive. Parameter values might or
might not be case-sensitive, depending on the semantics of the might not be case-sensitive, depending on the semantics of the
parameter name. Examples of parameters and some equivalent forms can parameter name. Examples of parameters and some equivalent forms can
be seen in media types (Section 7.1.1) and the Accept header field be seen in media types (Section 7.1.1) and the Accept header field
(Section 9.4.1). (Section 9.4.1).
skipping to change at page 35, line 43 skipping to change at page 37, line 4
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second) ; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT hour = 2DIGIT
minute = 2DIGIT minute = 2DIGIT
second = 2DIGIT second = 2DIGIT
Obsolete formats: Obsolete formats:
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
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
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
; 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"Sunday" / %s"Thursday" / %s"Friday" / %s"Saturday"
/ %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. A sender MUST NOT generate additional HTTP-date is case sensitive. A sender MUST NOT generate additional
whitespace in an HTTP-date beyond that specifically included as SP in whitespace in an HTTP-date beyond that specifically included as SP in
the grammar. The semantics of day-name, day, month, year, and the grammar. The semantics of day-name, day, month, year, and
time-of-day are the same as those defined for the Internet Message time-of-day are the same as those defined for the Internet Message
Format constructs with the corresponding name ([RFC5322], Format constructs with the corresponding name ([RFC5322],
skipping to change at page 38, line 44 skipping to change at page 40, line 6
forward messages from one protocol version to another. If the entire forward messages from one protocol version to another. If the entire
message can be buffered in transit, some intermediaries could merge message can be buffered in transit, some intermediaries could merge
trailer fields into the header section (as appropriate) before it is trailer fields into the header section (as appropriate) before it is
forwarded. However, in most cases, the trailers are simply forwarded. However, in most cases, the trailers are simply
discarded. A recipient MUST NOT merge a trailer field into a header discarded. A recipient MUST NOT merge a trailer field into a header
section unless the recipient understands the corresponding header section unless the recipient understands the corresponding header
field definition and that definition explicitly permits and defines field definition and that definition explicitly permits and defines
how trailer field values can be safely merged. how trailer field values can be safely merged.
The presence of the keyword "trailers" in the TE header field The presence of the keyword "trailers" in the TE header field
(Section 7.4 of [Messaging]) indicates that the client is willing to (Section 5.6.5) indicates that the client is willing to accept
accept trailer fields, on behalf of itself and any downstream trailer fields, on behalf of itself and any downstream clients. For
clients. For requests from an intermediary, this implies that all requests from an intermediary, this implies that all downstream
downstream clients are willing to accept trailer fields in the clients are willing to accept trailer fields in the forwarded
forwarded response. Note that the presence of "trailers" does not response. Note that the presence of "trailers" does not mean that
mean that the client(s) will process any particular trailer field in the client(s) will process any particular trailer field in the
the response; only that the trailer section as a whole will not be response; only that the trailer section(s) will not be dropped by any
dropped by any of the clients. of the clients.
Because of the potential for trailer fields to be discarded in Because of the potential for trailer fields to be discarded in
transit, a server SHOULD NOT generate trailer fields that it believes transit, a server SHOULD NOT generate trailer fields that it believes
are necessary for the user agent to receive. are necessary for the user agent to receive.
5.6.3. Trailer 5.6.3. Processing
Like header fields, trailer fields with the same name are processed
in the order received; multiple trailer field lines with the same
name have the equivalent semantics as appending the multiple values
as a list of members, even when the field lines are received in
separate trailer sections. Trailer fields that might be generated
more than once during a message MUST be defined as a list value even
if each member value is only processed once per field line received.
Trailer fields are expected (but not required) to be processed one
trailer section at a time. That is, for each trailer section
received, a recipient that is looking for trailer fields will parse
the received section into fields, invoke any associated processing
for those fields at that point in the message processing, and then
append those fields to the set of trailer fields received for the
overall message.
This behavior allows for iterative processing of trailer fields that
contain incremental signatures or mid-stream status information, and
fields that might refer to each other's values within the same
section. However, there is no guarantee that trailer sections won't
shift in relation to the message body stream, or won't be recombined
(or dropped) in transit, so trailer fields that refer to data outside
the present trailer section need to use self-descriptive references
(i.e., refer to the data by name, ordinal position, or an octet
range) rather than assume it is the data most recently received.
Likewise, at the end of a message, a recipient MAY treat the entire
set of received trailer fields as one data structure to be considered
as the message concludes. Additional processing expectations, if
any, can be defined within the field specification for a field
intended for use in trailers.
5.6.4. Trailer
The "Trailer" header field provides a list of field names that the The "Trailer" header field provides a list of field names that the
sender anticipates sending as trailer fields within that message. sender anticipates sending as trailer fields within that message.
This allows a recipient to prepare for receipt of the indicated This allows a recipient to prepare for receipt of the indicated
metadata before it starts processing the body. metadata before it starts processing the body.
Trailer = 1#field-name Trailer = #field-name
For example, a sender might indicate that a message integrity check For example, a sender might indicate that a message integrity check
will be computed as the payload is being streamed and provide the will be computed as the payload is being streamed and provide the
final signature as a trailer field. This allows a recipient to final signature as a trailer field. This allows a recipient to
perform the same check on the fly as the payload data is received. perform the same check on the fly as the payload data is received.
A sender that intends to generate one or more trailer fields in a A sender that intends to generate one or more trailer fields in a
message SHOULD generate a Trailer header field in the header section message SHOULD generate a Trailer header field in the header section
of that message to indicate which fields might be present in the of that message to indicate which fields might be present in the
trailers. trailers.
5.6.5. TE
The "TE" header field in a request can be used to indicate that the
sender will not discard trailer fields when it contains a "trailers"
member, as described in Section 5.6.
Additionally, specific HTTP versions can use it to indicate the
transfer codings the client is willing to accept in the response.
The TE field-value consists of a list of tokens, each allowing for
optional parameters (as described in Section 5.4.1.4).
TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
5.7. Considerations for New HTTP Fields 5.7. Considerations for New HTTP Fields
See Section 5.3 for a general requirements for field names, and See Section 5.3 for a general requirements for field names, and
Section 5.4 for a discussion of field values. Section 5.4 for a discussion of field values.
Authors of specifications defining new fields are advised to consider Authors of specifications defining new fields are advised to consider
documenting: documenting:
o Whether the field is a single value or whether it can be a list o Whether the field has a singleton or list-based value (see
(delimited by commas; see Section 5.4). Section 5.4).
If it is not a list, document how to treat messages where the If it is a singleton field, document how to treat messages where
field occurs multiple times (a sensible default would be to ignore the multiple members are present (a sensible default would be to
the field, but this might not always be the right choice). ignore the field, but this might not always be the right choice).
Note that intermediaries and software libraries might combine Note that intermediaries and software libraries might combine
multiple field instances into a single one, despite the field's multiple field instances into a single one, despite the field
definition not allowing the list syntax. A robust format enables being defined as a singleton. A robust format enables recipients
recipients to discover these situations (good example: "Content- to discover these situations (good example: "Content-Type", as the
Type", as the comma can only appear inside quoted strings; bad comma can only appear inside quoted strings; bad example:
example: "Location", as a comma can occur inside a URI). "Location", as a comma can occur inside a URI).
o Under what conditions the field can be used; e.g., only in o Under what conditions the field can be used; e.g., only in
responses or requests, in all messages, only on responses to a responses or requests, in all messages, only on responses to a
particular request method, etc. particular request method, etc.
o What the scope of applicability for the information conveyed in o What the scope of applicability for the information conveyed in
the field is. By default, fields apply only to the message they the field is. By default, fields apply only to the message they
are associated with, but some response fields are designed to are associated with, but some response fields are designed to
apply to all representations of a resource, the resource itself, apply to all representations of a resource, the resource itself,
or an even broader scope. Specifications that expand the scope of or an even broader scope. Specifications that expand the scope of
skipping to change at page 40, line 22 skipping to change at page 42, line 37
some cases) multi-tenant server deployments. some cases) multi-tenant server deployments.
o Whether the field should be stored by origin servers that o Whether the field should be stored by origin servers that
understand it upon a PUT request. understand it upon a PUT request.
o Whether the field semantics are further refined by the context, o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes. such as by existing request methods or status codes.
o Whether it is appropriate to list the field name in the Connection o Whether it is appropriate to list the field name in the Connection
header field (i.e., if the field is to be hop-by-hop; see header field (i.e., if the field is to be hop-by-hop; see
Section 9.1 of [Messaging]). Section 6.8).
o Under what conditions intermediaries are allowed to insert, o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value. delete, or modify the field's value.
o Whether it is appropriate to list the field name in a Vary o Whether it is appropriate to list the field name in a Vary
response header field (e.g., when the request header field is used response header field (e.g., when the request header field is used
by an origin server's content selection algorithm; see by an origin server's content selection algorithm; see
Section 11.1.4). Section 11.1.4).
o Whether the field is allowable in trailers (see Section 5.6). o Whether the field is allowable in trailers (see Section 5.6).
o Whether the field ought to be preserved across redirects. o Whether the field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
5.8. Fields Defined In This Document 5.8. Fields Defined In This Document
The following fields are defined by this document: The following fields are defined by this document:
+---------------------------+------------+----------------+ --------------------------- ------------ --------
| Field Name | Status | Reference | Field Name Status Ref.
| Accept | standard | Section 9.4.1 | --------------------------- ------------ --------
| Accept-Charset | deprecated | Section 9.4.2 | Accept standard 9.4.1
| Accept-Encoding | standard | Section 9.4.3 | Accept-Charset deprecated 9.4.2
| Accept-Language | standard | Section 9.4.4 | Accept-Encoding standard 9.4.3
| Accept-Ranges | standard | Section 11.4.1 | Accept-Language standard 9.4.4
| Allow | standard | Section 11.4.2 | Accept-Ranges standard 11.4.1
| Authentication-Info | standard | Section 11.3.3 | Allow standard 11.4.2
| Authorization | standard | Section 9.5.3 | Authentication-Info standard 11.3.3
| Content-Encoding | standard | Section 7.2.2 | Authorization standard 9.5.3
| Content-Language | standard | Section 7.2.3 | Connection standard 6.8
| Content-Length | standard | Section 7.2.4 | Content-Encoding standard 7.2.2
| Content-Location | standard | Section 7.2.5 | Content-Language standard 7.2.3
| Content-Range | standard | Section 7.3.4 | Content-Length standard 7.2.4
| Content-Type | standard | Section 7.2.1 | Content-Location standard 7.2.5
| Date | standard | Section 11.1.1 | Content-Range standard 7.3.4
| ETag | standard | Section 11.2.3 | Content-Type standard 7.2.1
| Expect | standard | Section 9.1.1 | Date standard 11.1.1
| From | standard | Section 9.6.1 | ETag standard 11.2.3
| Host | standard | Section 6.6 | Expect standard 9.1.1
| If-Match | standard | Section 9.2.3 | From standard 9.6.1
| If-Modified-Since | standard | Section 9.2.5 | Host standard 6.5
| If-None-Match | standard | Section 9.2.4 | If-Match standard 9.2.3
| If-Range | standard | Section 9.2.7 | If-Modified-Since standard 9.2.5
| If-Unmodified-Since | standard | Section 9.2.6 | If-None-Match standard 9.2.4
| Last-Modified | standard | Section 11.2.2 | If-Range standard 9.2.7
| Location | standard | Section 11.1.2 | If-Unmodified-Since standard 9.2.6
| Max-Forwards | standard | Section 9.1.2 | Last-Modified standard 11.2.2
| Proxy-Authenticate | standard | Section 11.3.2 | Location standard 11.1.2
| Proxy-Authentication-Info | standard | Section 11.3.4 | Max-Forwards standard 9.1.2
| Proxy-Authorization | standard | Section 9.5.4 | Proxy-Authenticate standard 11.3.2
| Range | standard | Section 9.3 | Proxy-Authentication-Info standard 11.3.4
| Referer | standard | Section 9.6.2 | Proxy-Authorization standard 9.5.4
| Retry-After | standard | Section 11.1.3 | Range standard 9.3
| Server | standard | Section 11.4.3 | Referer standard 9.6.2
| Trailer | standard | Section 5.6.3 | Retry-After standard 11.1.3
| User-Agent | standard | Section 9.6.3 | Server standard 11.4.3
| Vary | standard | Section 11.1.4 | TE standard 5.6.5
| Via | standard | Section 6.7.1 | Trailer standard 5.6.4
| WWW-Authenticate | standard | Section 11.3.1 | Upgrade standard 6.7
+---------------------------+------------+----------------+ User-Agent standard 9.6.3
Vary standard 11.1.4
Via standard 6.6.1
WWW-Authenticate standard 11.3.1
--------------------------- ------------ --------
Table 2 Table 3
Furthermore, the field name "*" is reserved, since using that name as Furthermore, the field name "*" is reserved, since using that name as
an HTTP header field might conflict with its special semantics in the an HTTP header field might conflict with its special semantics in the
Vary header field (Section 11.1.4). Vary header field (Section 11.1.4).
+------------+----------+-------------+------------+ ------------ ---------- ------ ------------
| Field Name | Status | Reference | Comments | Field Name Status Ref. Comments
| * | standard | Section 5.8 | (reserved) | ------------ ---------- ------ ------------
+------------+----------+-------------+------------+ * standard 5.8 (reserved)
------------ ---------- ------ ------------
Table 3 Table 4
6. Message Routing 6. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the response routing follows the same connection chain back to the
client. client.
6.1. Identifying a Target Resource 6.1. Identifying a Target Resource
skipping to change at page 43, line 45 skipping to change at page 46, line 5
Origin is also used within HTML and related Web protocols, beyond the Origin is also used within HTML and related Web protocols, beyond the
scope of this document, as described in [RFC6454]. scope of this document, as described in [RFC6454].
6.3. Routing Inbound 6.3. Routing Inbound
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.
6.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.
6.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,
the client connects inbound by establishing (or reusing) a connection the client connects inbound by establishing (or reusing) a connection
to that proxy. to that proxy.
6.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, similar to how this specification defines associated specification.
origin server access for resolution of the "http" (Section 2.5.1) and
"https" (Section 2.5.2) schemes.
6.4. Direct Authoritative Access
6.4.1. http origins 6.3.3.1. http origins
Although HTTP is independent of the transport protocol, the "http" Although HTTP is independent of the transport protocol, the "http"
scheme is specific to associating authority with whomever controls scheme (Section 2.5.1) is specific to associating authority with
the origin server listening for TCP connections on the indicated port whomever controls the origin server listening for TCP connections on
of whatever host is identified within the authority component. This the indicated port of whatever host is identified within the
is a very weak sense of authority because it depends on both client- authority component. This is a very weak sense of authority because
specific name resolution mechanisms and communication that might not it depends on both client-specific name resolution mechanisms and
be secured from man-in-the-middle attacks. Nevertheless, it is a communication that might not be secured from an on-path attacker.
sufficient minimum for binding "http" identifiers to an origin server Nevertheless, it is a sufficient minimum for binding "http"
for consistent resolution within a trusted environment. identifiers to an origin server for consistent resolution within a
trusted environment.
If the host identifier is provided as an IP address, the origin If the host identifier is provided as an IP address, the origin
server is the listener (if any) on the indicated TCP port at that IP server is the listener (if any) on the indicated TCP port at that IP
address. If host is a registered name, the registered name is an address. If host is a registered name, the registered name is an
indirect identifier for use with a name resolution service, such as indirect identifier for use with a name resolution service, such as
DNS, to find an address for an appropriate origin server. DNS, to find an address for an appropriate origin server.
When an "http" URI is used within a context that calls for access to When an "http" 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
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
(Section 2 of [Messaging]). (Section 2.1).
If the server responds to such a request with a non-interim HTTP If the server responds to such a request with a non-interim HTTP
response message, as described in Section 10, then that response is response message, as described in Section 10, 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 [RFC7838] 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.
See Section 12.1 for security considerations related to establishing See Section 12.1 for security considerations related to establishing
authority. authority.
6.4.2. https origins 6.3.3.2. https origins
The "https" scheme associates authority based on the ability of a The "https" scheme (Section 2.5.2) associates authority based on the
server to use a private key associated with a certificate that the ability of a server to use the private key corresponding to a
client considers to be trustworthy for the identified host. If a certificate that the client considers to be trustworthy for the
server presents a certificate that verifiably applies to the host, identified origin server. The client usually relies upon a chain of
along with proof that it controls the corresponding private key, then trust, conveyed from some prearranged or configured trust anchor, to
a client will accept a secured connection to that server as being deem a certificate trustworthy (Section 6.3.3.3).
authoritative for all origins with the same scheme and host.
A client is therefore relying upon a chain of trust, conveyed from In HTTP/1.1 and earlier, a client will only attribute authority to a
some trust anchor (which is usually prearranged or configured), server when they are communicating over a successfully established
through a chain of certificates (e.g., [RFC5280]) to a final and secured connection specifically to that URI origin's host. The
certificate that binds a private key to the host name of the origin. connection establishment and certificate verification are used as
The handshake and certificate validation in Section 6.4.3 describe proof of authority.
how that final certificate can be used to initiate a secured
connection. In HTTP/2 and HTTP/3, a client will attribute authority to a server
when they are communicating over a successfully established and
secured connection if the URI origin's host matches any of the hosts
present in the server's certificate and the client believes that it
could open a connection to that host for that URI. In practice, a
client will make a DNS query to check that the origin's host contains
the same server IP address as the established connection. This
restriction can be removed by the origin server sending an equivalent
ORIGIN frame [RFC8336].
The request target's host and port value are passed within each HTTP
request, identifying the origin and distinguishing it from other
namespaces that might be controlled by the same server. It is the
origin's responsibility to ensure that any services provided with
control over its certificate's private key are equally responsible
for managing the corresponding "https" namespaces, or at least
prepared to reject requests that appear to have been misdirected. A
server might be unwilling to serve as the origin for some hosts even
when they have the authority to do so.
For example, if a network attacker causes connections for port N to
be received at port Q, checking the target URI is necessary to ensure
that the attacker can't cause "https://example.com:N/foo" to be
replaced by "https://example.com:Q/foo" without consent.
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 2.5.2, including protocols has been secured, as defined in Section 2.5.2, including protocols
that don't use TCP. It is the origin's responsibility to ensure that that don't use TCP.
any services provided with control over its certificate's private key
are equally responsible for managing the corresponding "https"
namespaces, or at least prepared to reject requests that appear to
have been misdirected. Regardless, the origin's host and port value
are passed within each HTTP request, identifying the target resource
and distinguishing it from other namespaces that might be controlled
by the same server.
In HTTP/1.1 and earlier, the only URIs for which a client will
attribute authority to a server are those for which a TLS connection
was specifically established toward the origin's host. Only the
characteristics of the connection establishment and certificate are
used. For a host that is a domain name, the client MUST include that
name in the TLS server_name extension (if used) and MUST verify that
the name also appears as either the CN field of the certificate
subject or as a dNSName in the subjectAltName field of the
certificate (see [RFC6125]). For a host that is an IP address, the
client MUST verify that the address appears in the subjectAltName of
the certificate.
In HTTP/2, a client will associate authority to all names that are
present in the certificate. However, a client will only do that if
it concludes that it could open a connection to the origin for that
URI. In practice, a client will make a DNS query and see that it
contains the same server IP address. A server sending the ORIGIN
frame removes this restriction [RFC8336].
In addition to the client's verification, an origin server is
responsible for verifying that requests it receives over a connection
correspond to resources for which it actually wants to be the origin.
If a network attacker causes connections for port N to be received at
port Q, checking the target URI is necessary to ensure that the
attacker can't cause "https://example.com:N/foo" to be replaced by
"https://example.com:Q/foo" without consent. Likewise, a server
might be unwilling to serve as the origin for some hosts even when
they have the authority to do so.
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
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, securing the connection end-to- that address on the indicated port, securing the connection end-to-
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 to the integrity protection, and sending an HTTP request message over that
server over that secured connection containing the URI's identifying connection containing the URI's identifying data (Section 2.1).
data (Section 2 of [Messaging]).
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 10, then that response is response message, as described in Section 10, 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]).
6.4.3. Initiating HTTP Over TLS 6.3.3.3. https certificate verification
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
precisely as you would use HTTP over TCP.
The agent acting as the HTTP client should also act as the TLS
client. It should initiate a connection to the server on the
appropriate port and then send the TLS ClientHello to begin the TLS
handshake. When the TLS handshake has finished. The client may then
initiate the first HTTP request. All HTTP data MUST be sent as TLS
"application data". Normal HTTP behavior, including retained
connections should be followed.
6.4.3.1. Identifying HTTPS Servers
In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client.
If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.
If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Matching is performed using the matching rules specified by
[RFC5280]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
If the hostname does not match the identity in the certificate, user To establish a secured connection to dereference a URI, a client MUST
oriented clients MUST either notify the user (clients MAY give the verify that the service's identity is an acceptable match for the
user the opportunity to continue with the connection in any case) or URI's origin server. Certificate verification is used to prevent
terminate the connection with a bad certificate error. Automated server impersonation by an on-path attacker or by an attacker that
clients MUST log the error to an appropriate audit log (if available) controls name resolution. This process requires that a client be
and SHOULD terminate the connection (with a bad certificate error). configured with a set of trust anchors.
Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it.
Note that in many cases the URI itself comes from an untrusted In general, a client MUST verify the service identity using the
source. The above-described check provides no protection against verification process defined in Section 6 of [RFC6125] (for a
attacks where this source is compromised. For example, if the URI reference identifier of type URI-ID) unless the client has been
was obtained by clicking on an HTML page which was itself obtained specifically configured to accept some other form of verification.
without using HTTP/TLS, a man in the middle could have replaced the For example, a client might be connecting to a server whose address
URI. In order to prevent this form of attack, users should carefully and hostname are dynamic, with an expectation that the service will
examine the certificate presented by the server to determine if it present a specific certificate (or a certificate matching some
meets their expectations. externally defined reference identity) rather than one matching the
dynamic URI's origin server identifier.
6.4.3.2. Identifying HTTPS Clients In special cases, it might be appropriate for a client to simply
ignore the server's identity, but it must be understood that this
leaves a connection open to active attack.
Typically, the server has no external knowledge of what the client's If the certificate is not valid for the URI's origin server, a user
identity ought to be and so checks (other than that the client has a agent MUST either notify the user (user agents MAY give the user an
certificate chain rooted in an appropriate CA) are not possible. If option to continue with the connection in any case) or terminate the
a server has such knowledge (typically from some source external to connection with a bad certificate error. Automated clients MUST log
HTTP or TLS) it SHOULD check the identity as described above. the error to an appropriate audit log (if available) and SHOULD
terminate the connection (with a bad certificate error). Automated
clients MAY provide a configuration setting that disables this check,
but MUST provide a setting which enables it.
6.5. Reconstructing the Target URI 6.4. Reconstructing the Target URI
Once an inbound connection is obtained, the client sends an HTTP Once an inbound connection is obtained, the client sends an HTTP
request message (Section 2 of [Messaging]). request message (Section 2.1).
Depending on the nature of the request, the client's target URI might Depending on the nature of the request, the client's target URI might
be split into components and transmitted (or implied) within various be split into components and transmitted (or implied) within various
parts of a request message. These parts are recombined by each parts of a request message. These parts are recombined by each
recipient, in accordance with their local configuration and incoming recipient, in accordance with their local configuration and incoming
connection context, to determine the target URI. Appendix of connection context, to determine the target URI. Appendix of
[Messaging] defines how a server determines the target URI for an [Messaging] defines how a server determines the target URI for an
HTTP/1.1 request. HTTP/1.1 request.
Once the target URI has been reconstructed, an origin server needs to Once the target URI has been reconstructed, an origin server needs to
skipping to change at page 49, line 8 skipping to change at page 50, line 8
from the host or port upon which the connection has been made. If from the host or port upon which the connection has been made. If
the connection is from a trusted gateway, that inconsistency might be the connection is from a trusted gateway, that inconsistency might be
expected; otherwise, it might indicate an attempt to bypass security expected; otherwise, it might indicate an attempt to bypass security
filters, trick the server into delivering non-public content, or filters, trick the server into delivering non-public content, or
poison a cache. See Section 12 for security considerations regarding poison a cache. See Section 12 for security considerations regarding
message routing. message routing.
| *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.
6.6. Host 6.5. Host
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 on a single IP address. host names on a single IP address.
Host = uri-host [ ":" port ] ; Section 2.4 Host = uri-host [ ":" port ] ; Section 2.4
A client MUST send a Host header field in all HTTP/1.1 request
messages. If the target URI includes an authority component, then a
client MUST send a field value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its "@"
delimiter (Section 2.5.1). If the authority component is missing or
undefined for the target URI, then a client MUST send a Host header
field with an empty field value.
Since the Host field value is critical information for handling a Since the Host field value is critical information for handling a
request, a user agent SHOULD generate Host as the first header field request, a user agent SHOULD generate Host as the first field in the
following the request-line. header section.
For example, a GET request to the origin server for For example, a GET request to the origin server for
<http://www.example.org/pub/WWW/> would begin with: <http://www.example.org/pub/WWW/> would begin with:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.example.org Host: www.example.org
Since the Host header field acts as an application-level routing Since the Host header field acts as an application-level routing
mechanism, it is a frequent target for malware seeking to poison a mechanism, it is a frequent target for malware seeking to poison a
shared cache or redirect a request to an unintended server. An shared cache or redirect a request to an unintended server. An
interception proxy is particularly vulnerable if it relies on the interception proxy is particularly vulnerable if it relies on the
Host field value for redirecting requests to internal servers, or for Host field value for redirecting requests to internal servers, or for
use as a cache key in a shared cache, without first verifying that use as a cache key in a shared cache, without first verifying that
the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for that
host. host.
A server MUST respond with a 400 (Bad Request) status code to any 6.6. Message Forwarding
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field value.
6.7. Message Forwarding
As described in Section 2.2, intermediaries can serve a variety of As described in Section 2.2, intermediaries can serve a variety of
roles in the processing of HTTP requests and responses. Some roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability. intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the intermediary can enhance (or interfere) with either direction of the
stream. stream.
An intermediary not acting as a tunnel MUST implement the Connection An intermediary not acting as a tunnel MUST implement the Connection
header field, as specified in Section 9.1 of [Messaging], and exclude header field, as specified in Section 6.8, and exclude fields from
fields from being forwarded that are only intended for the incoming being forwarded that are only intended for the incoming connection.
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, recipients cannot rely on
incremental delivery of partial messages, since some implementations incremental delivery of partial messages, since some implementations
will buffer or delay message forwarding for the sake of network will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations. efficiency, security checks, or payload transformations.
6.7.1. Via 6.6.1. Via
The "Via" header field indicates the presence of intermediate The "Via" header field indicates the presence of intermediate
protocols and recipients between the user agent and the server (on protocols and recipients between the user agent and the server (on
requests) or between the origin server and the client (on responses), requests) or between the origin server and the client (on responses),
similar to the "Received" header field in email (Section 3.6.7 of similar to the "Received" header field in email (Section 3.6.7 of
[RFC5322]). Via can be used for tracking message forwards, avoiding [RFC5322]). Via can be used for tracking message forwards, avoiding
request loops, and identifying the protocol capabilities of senders request loops, and identifying the protocol capabilities of senders
along the request/response chain. along the request/response chain.
Via = 1#( received-protocol RWS received-by [ RWS comment ] ) Via = #( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
; see [Messaging], Section 9.9 ; see Section 6.7
received-by = pseudonym [ ":" port ] received-by = pseudonym [ ":" port ]
pseudonym = token pseudonym = token
Each member of the Via field value represents a proxy or gateway that Each member of the Via field value represents a proxy or gateway that
has forwarded the message. Each intermediary appends its own has forwarded the message. Each intermediary appends its own
information about how the message was received, such that the end information about how the message was received, such that the end
result is ordered according to the sequence of forwarding recipients. result is ordered according to the sequence of forwarding recipients.
A proxy MUST send an appropriate Via header field, as described A proxy MUST send an appropriate Via header field, as described
below, in each message that it forwards. An HTTP-to-HTTP gateway below, in each message that it forwards. An HTTP-to-HTTP gateway
skipping to change at page 52, line 20 skipping to change at page 53, line 10
could be collapsed to could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
A sender SHOULD NOT combine multiple list members unless they are all A sender SHOULD NOT combine multiple list members unless they are all
under the same organizational control and the hosts have already been under the same organizational control and the hosts have already been
replaced by pseudonyms. A sender MUST NOT combine members that have replaced by pseudonyms. A sender MUST NOT combine members that have
different received-protocol values. different received-protocol values.
6.7.2. Transformations 6.6.2. Transformations
Some intermediaries include features for transforming messages and Some intermediaries include features for transforming messages and
their payloads. A proxy might, for example, convert between image their payloads. A proxy might, for example, convert between image
formats in order to save cache space or to reduce the amount of formats in order to save cache space or to reduce the amount of
traffic on a slow link. However, operational problems might occur traffic on a slow link. However, operational problems might occur
when these transformations are applied to payloads intended for when these transformations are applied to payloads intended for
critical applications, such as medical imaging or scientific data critical applications, such as medical imaging or scientific data
analysis, particularly when integrity checks or digital signatures analysis, particularly when integrity checks or digital signatures
are used to ensure that the payload received is identical to the are used to ensure that the payload received is identical to the
original. original.
skipping to change at page 53, line 5 skipping to change at page 53, line 43
If a proxy receives a target URI with a host name that is not a fully If a proxy receives a target URI with a host name that is not a fully
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 MAY modify the message body through application or removal of
a transfer coding (Section 7 of [Messaging]).
A proxy MUST NOT transform the payload (Section 7.3) of a message A proxy MUST NOT transform the payload (Section 7.3) 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]). (Section 5.2 of [Caching]). Note that this does not include changes
to the message body that do not affect the payload, such as transfer
codings (Section 7 of [Messaging]).
A proxy MAY transform the payload of a message that does not contain A proxy MAY transform the payload 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
payload of a 200 (OK) response can inform downstream recipients that payload 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 10.3.4). code to 203 (Non-Authoritative Information) (Section 10.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 payload) unless the or the selected representation (other than the payload) unless the
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
6.7. Upgrading HTTP
The "Upgrade" header field is intended to provide a simple mechanism
for transitioning from HTTP/1.1 to some other protocol on the same
connection.
A client MAY send a list of protocol names in the Upgrade header
field of a request to invite the server to switch to one or more of
the named protocols, in order of descending preference, before
sending the final response. A server MAY ignore a received Upgrade
header field if it wishes to continue using the current protocol on
that connection. Upgrade cannot be used to insist on a protocol
change.
Upgrade = #protocol
protocol = protocol-name ["/" protocol-version]
protocol-name = token
protocol-version = token
Although protocol names are registered with a preferred case,
recipients SHOULD use case-insensitive comparison when matching each
protocol-name to supported protocols.
A server that sends a 101 (Switching Protocols) response MUST send an
Upgrade header field to indicate the new protocol(s) to which the
connection is being switched; if multiple protocol layers are being
switched, the sender MUST list the protocols in layer-ascending
order. A server MUST NOT switch to a protocol that was not indicated
by the client in the corresponding request's Upgrade header field. A
server MAY choose to ignore the order of preference indicated by the
client and select the new protocol(s) based on other factors, such as
the nature of the request or the current load on the server.
A server that sends a 426 (Upgrade Required) response MUST send an
Upgrade header field to indicate the acceptable protocols, in order
of descending preference.
A server MAY send an Upgrade header field in any other response to
advertise that it implements support for upgrading to the listed
protocols, in order of descending preference, when appropriate for a
future request.
The following is a hypothetical example sent by a client:
GET /hello HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: websocket, IRC/6.9, RTA/x11
The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101
(Switching Protocols) response, the server is expected to continue
responding to the original request as if it had received its
equivalent within the new protocol (i.e., the server still has an
outstanding request to satisfy after the protocol has been changed,
and is expected to do so without requiring the request to be
repeated).
For example, if the Upgrade header field is received in a GET request
and the server decides to switch protocols, it first responds with a
101 (Switching Protocols) message in HTTP/1.1 and then immediately
follows that with the new protocol's equivalent of a response to a
GET on the target resource. This allows a connection to be upgraded
to protocols with the same semantics as HTTP without the latency cost
of an additional round trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol.
The following is an example response to the above hypothetical
request:
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: websocket
[... data stream switches to websocket with an appropriate response
(as defined by new protocol) to the "GET /hello" request ...]
When Upgrade is sent, the sender MUST also send a Connection header
field (Section 6.8) that contains an "upgrade" connection option, in
order to prevent Upgrade from being accidentally forwarded by
intermediaries that might not implement the listed protocols. A
server MUST ignore an Upgrade header field that is received in an
HTTP/1.0 request.
A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client
can't change the protocol it is sending in the middle of a message).
If a server receives both an Upgrade and an Expect header field with
the "100-continue" expectation (Section 9.1.1), the server MUST send
a 100 (Continue) response before sending a 101 (Switching Protocols)
response.
The Upgrade header field only applies to switching protocols on top
of the existing connection; it cannot be used to switch the
underlying connection (transport) protocol, nor to switch the
existing communication to a different connection. For those
purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 10.4).
6.7.1. Upgrade Protocol Names
This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 4.2 and future updates to this
specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 6.7.2.
------ ------------------- ------------------------- ------
Name Description Expected Version Tokens Ref.
------ ------------------- ------------------------- ------
HTTP Hypertext any DIGIT.DIGIT (e.g, 4.2
Transfer Protocol "2.0")
------ ------------------- ------------------------- ------
Table 5
6.7.2. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at
<https://www.iana.org/assignments/http-upgrade-tokens>.
Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection
will be processed after it has been upgraded.
Registrations happen on a "First Come First Served" basis (see
Section 4.4 of [RFC8126]) and are subject to the following rules:
1. A protocol-name token, once registered, stays registered forever.
2. A protocol-name token is case-insensitive and registered with the
preferred case to be generated by senders.
3. The registration MUST name a responsible party for the
registration.
4. The registration MUST name a point of contact.
5. The registration MAY name a set of specifications associated with
that token. Such specifications need not be publicly available.
6. The registration SHOULD name a set of expected "protocol-version"
tokens associated with that token at the time of registration.
7. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them
available upon request.
8. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party
cannot be contacted.
6.8. Connection-Specific Fields
The "Connection" header field allows the sender to list desired
control options for the current connection.
When a field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list
the corresponding field name within the Connection header field.
Note that some versions of HTTP prohibit the use of fields for such
information, and therefore do not allow the Connection field.
Intermediaries MUST parse a received Connection header field before a
message is forwarded and, for each connection-option in this field,
remove any header or trailer field(s) from the message with the same
name as the connection-option, and then remove the Connection header
field itself (or replace it with the intermediary's own connection
options for the forwarded message).
Hence, the Connection header field provides a declarative way of
distinguishing fields that are only intended for the immediate
recipient ("hop-by-hop") from those fields that are intended for all
recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by
older intermediaries.
Furthermore, intermediaries SHOULD remove or replace field(s) whose
semantics are known to require removal before forwarding, whether or
not they appear as a Connection option, after applying those fields'
semantics. This includes but is not limited to:
o Proxy-Connection (Appendix C.1.2 of [Messaging])
o Keep-Alive (Section 19.7.1 of [RFC2068])
o TE (Section 5.6.5)
o Trailer (Section 5.6.4)
o Transfer-Encoding (Section 6.1 of [Messaging])
o Upgrade (Section 6.7)
The Connection header field's value has the following grammar:
Connection = #connection-option
connection-option = token
Connection options are case-insensitive.
A sender MUST NOT send a connection option corresponding to a field
that is intended for all recipients of the payload. For example,
Cache-Control is never appropriate as a connection option
(Section 5.2 of [Caching]).
The connection options do not always correspond to a field present in
the message, since a connection-specific field might not be needed if
there are no parameters associated with a connection option. In
contrast, a connection-specific field that is received without a
corresponding connection option usually indicates that the field has
been improperly forwarded by an intermediary and ought to be ignored
by the recipient.
When defining new connection options, specification authors ought to
document it as reserved field name and register that definition in
the Hypertext Transfer Protocol (HTTP) Field Name Registry
(Section 5.3.2), to avoid collisions.
7. Representations 7. Representations
Considering that a resource could be anything, and that the uniform Considering that a resource could be anything, and that the uniform
interface provided by HTTP is similar to a window through which one interface provided by HTTP is similar to a window through which one
can observe and act upon such a thing only through the communication can observe and act upon such a thing only through the communication
of messages to some independent actor on the other side, an of messages to some independent actor on the other side, an
abstraction is needed to represent ("take the place of") the current abstraction is needed to represent ("take the place of") the current
or desired state of that thing in our communications. That or desired state of that thing in our communications. That
abstraction is called a representation [REST]. abstraction is called a representation [REST].
skipping to change at page 54, line 27 skipping to change at page 60, line 13
representation-data := Content-Encoding( Content-Type( bits ) ) representation-data := Content-Encoding( Content-Type( bits ) )
7.1.1. Media Type 7.1.1. Media Type
HTTP uses media types [RFC2046] in the Content-Type (Section 7.2.1) HTTP uses media types [RFC2046] in the Content-Type (Section 7.2.1)
and Accept (Section 9.4.1) header fields in order to provide open and and Accept (Section 9.4.1) header fields in order to provide open and
extensible data typing and type negotiation. Media types define both extensible data typing and type negotiation. Media types define both
a data format and various processing models: how to process that data a data format and various processing models: how to process that data
in accordance with each context in which it is received. in accordance with each context in which it is received.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype parameters
type = token type = token
subtype = token subtype = token
The type and subtype tokens are case-insensitive. The type and subtype tokens are case-insensitive.
The type/subtype MAY be followed by semicolon-delimited parameters The type/subtype MAY be followed by semicolon-delimited parameters
(Section 5.4.1.4) in the form of name=value pairs. The presence or (Section 5.4.1.4) in the form of name=value pairs. The presence or
absence of a parameter might be significant to the processing of a absence of a parameter might be significant to the processing of a
media type, depending on its definition within the media type media type, depending on its definition within the media type
registry. Parameter values might or might not be case-sensitive, registry. Parameter values might or might not be case-sensitive,
skipping to change at page 57, line 5 skipping to change at page 62, line 35
All content codings are case-insensitive and ought to be registered All content codings are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as defined in within the "HTTP Content Coding Registry", as defined in
Section 7.1.2.4 Section 7.1.2.4
Content-coding values are used in the Accept-Encoding (Section 9.4.3) Content-coding values are used in the Accept-Encoding (Section 9.4.3)
and Content-Encoding (Section 7.2.2) header fields. and Content-Encoding (Section 7.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
+------------+-------------------------------+-----------+ ------------ ------------------------------------------- ---------
| Name | Description | Reference | Name Description Ref.
| compress | UNIX "compress" data format | Section | ------------ ------------------------------------------- ---------
| | [Welch] | 7.1.2.1 | compress UNIX "compress" data format [Welch] 7.1.2.1
| deflate | "deflate" compressed data | Section | deflate "deflate" compressed data ([RFC1951]) 7.1.2.2
| | ([RFC1951]) inside the "zlib" | 7.1.2.2 | inside the "zlib" data format ([RFC1950])
| | data format ([RFC1950]) | | gzip GZIP file format [RFC1952] 7.1.2.3
| gzip | GZIP file format [RFC1952] | Section | identity Reserved 9.4.3
| | | 7.1.2.3 | x-compress Deprecated (alias for compress) 7.1.2.1
| identity | Reserved | Section | x-gzip Deprecated (alias for gzip) 7.1.2.3
| | | 9.4.3 | ------------ ------------------------------------------- ---------
| x-compress | Deprecated (alias for | Section |
| | compress) | 7.1.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section |
| | | 7.1.2.3 |
+------------+-------------------------------+-----------+
Table 4 Table 6
7.1.2.1. Compress Coding 7.1.2.1. Compress Coding
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
[Welch] that is commonly produced by the UNIX file compression [Welch] that is commonly produced by the UNIX file compression
program "compress". A recipient SHOULD consider "x-compress" to be program "compress". A recipient SHOULD consider "x-compress" to be
equivalent to "compress". equivalent to "compress".
7.1.2.2. Deflate Coding 7.1.2.2. Deflate Coding
skipping to change at page 58, line 22 skipping to change at page 64, line 5
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (Section 7 of [Messaging]), unless the encoding codings (Section 7 of [Messaging]), unless the encoding
transformation is identical (as is the case for the compression transformation is identical (as is the case for the compression
codings defined in Section 7.1.2). codings defined in Section 7.1.2).
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
Section 4.8 of [RFC8126]) and MUST conform to the purpose of content Section 4.8 of [RFC8126]) and MUST conform to the purpose of content
coding defined in Section 7.1.2. coding defined in Section 7.1.2.
New content codings ought to be self-descriptive whenever possible,
with optional parameters discoverable within the coding format
itself, rather than rely on external metadata that might be lost
during transit.
7.1.3. Language Tags 7.1.3. Language Tags
A language tag, as defined in [RFC5646], identifies a natural A language tag, as defined in [RFC5646], identifies a natural
language spoken, written, or otherwise conveyed by human beings for language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer communication of information to other human beings. Computer
languages are explicitly excluded. languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and HTTP uses language tags within the Accept-Language and
Content-Language header fields. Accept-Language uses the broader Content-Language header fields. Accept-Language uses the broader
language-range production defined in Section 9.4.4, whereas language-range production defined in Section 9.4.4, whereas
skipping to change at page 59, line 28 skipping to change at page 65, line 12
Content-Range (Section 7.3.4) payload header field to describe which Content-Range (Section 7.3.4) payload header field to describe which
part of a representation is being transferred. part of a 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 7.1.4.4 within the "HTTP Range Unit Registry", as defined in Section 7.1.4.4
The following range unit names are defined by this document: The following range unit names are defined by this document:
+-----------------+----------------------------------+-----------+ ----------------- ---------------------------------- ---------
| Range Unit Name | Description | Reference | Range Unit Name Description Ref.
| bytes | a range of octets | Section | ----------------- ---------------------------------- ---------
| | | 7.1.4.2 | bytes a range of octets 7.1.4.2
| none | reserved as keyword to indicate | Section | none reserved as keyword to indicate 11.4.1
| | range requests are not supported | 11.4.1 | range requests are not supported
+-----------------+----------------------------------+-----------+ ----------------- ---------------------------------- ---------
Table 5 Table 7
7.1.4.1. Range Specifiers 7.1.4.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 gramar 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.
skipping to change at page 63, line 17 skipping to change at page 69, line 5
Representation header fields provide metadata about the Representation header fields provide metadata about the
representation. When a message includes a payload body, the representation. When a message includes a payload body, the
representation header fields describe how to interpret the representation header fields describe how to interpret the
representation data enclosed in the payload body. In a response to a representation data enclosed in the payload body. In a response to a
HEAD request, the representation header fields describe the HEAD request, the representation header fields describe the
representation data that would have been enclosed in the payload body representation data that would have been enclosed in the payload body
if the same request had been a GET. if the same request had been a GET.
The following header fields convey representation metadata: The following header fields convey representation metadata:
+------------------+---------------+ ------------------ -------
| Field Name | Defined in... | Field Name Ref.
| Content-Type | Section 7.2.1 | ------------------ -------
| Content-Encoding | Section 7.2.2 | Content-Type 7.2.1
| Content-Language | Section 7.2.3 | Content-Encoding 7.2.2
| Content-Length | Section 7.2.4 | Content-Language 7.2.3
| Content-Location | Section 7.2.5 | Content-Length 7.2.4
+------------------+---------------+ Content-Location 7.2.5
------------------ -------
Table 6 Table 8
7.2.1. Content-Type 7.2.1. Content-Type
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in the associated representation: either the representation enclosed in the
message payload or the selected representation, as determined by the message payload or the selected representation, as determined by the
message semantics. The indicated media type defines both the data message semantics. The indicated media type defines both the data
format and how that data is intended to be processed by a recipient, format and how that data is intended to be processed by a recipient,
within the scope of the received message semantics, after any content within the scope of the received message semantics, after any content
codings indicated by Content-Encoding are decoded. codings indicated by Content-Encoding are decoded.
skipping to change at page 64, line 17 skipping to change at page 70, line 5
representation. Some user agents examine a payload's content and, in representation. Some user agents examine a payload's content and, in
certain cases, override the received type (for example, see certain cases, override the received type (for example, see
[Sniffing]). This "MIME sniffing" risks drawing incorrect [Sniffing]). This "MIME sniffing" risks drawing incorrect
conclusions about the data, which might expose the user to additional conclusions about the data, which might expose the user to additional
security risks (e.g., "privilege escalation"). Furthermore, it is security risks (e.g., "privilege escalation"). Furthermore, it is
impossible to determine the sender's intended processing model by impossible to determine the sender's intended processing model by
examining the data format: many data formats match multiple media examining the data format: many data formats match multiple media
types that differ only in processing semantics. Implementers are types that differ only in processing semantics. Implementers are
encouraged to provide a means to disable such sniffing. encouraged to provide a means to disable such sniffing.
Furthermore, although Content-Type is defined as a singleton field,
it is sometimes incorrectly generated multiple times, resulting in a
combined field value that appears to be a list. Recipients often
attempt to handle this error by using the last syntactically valid
member of the list, but note that some implementations might have
different error handling behaviors, leading to interoperability and/
or security issues.
7.2.2. Content-Encoding 7.2.2. Content-Encoding
The "Content-Encoding" header field indicates what content codings The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in the have been applied to the representation, beyond those inherent in the
media type, and thus what decoding mechanisms have to be applied in media type, and thus what decoding mechanisms have to be applied in
order to obtain data in the media type referenced by the Content-Type order to obtain data in the media type referenced by the Content-Type
header field. Content-Encoding is primarily used to allow a header field. Content-Encoding is primarily used to allow a
representation's data to be compressed without losing the identity of representation's data to be compressed without losing the identity of
its underlying media type. its underlying media type.
Content-Encoding = 1#content-coding Content-Encoding = #content-coding
An example of its use is An example of its use is
Content-Encoding: gzip Content-Encoding: gzip
If one or more encodings have been applied to a representation, the If one or more encodings have been applied to a representation, the
sender that applied the encodings MUST generate a Content-Encoding sender that applied the encodings MUST generate a Content-Encoding
header field that lists the content codings in the order in which header field that lists the content codings in the order in which
they were applied. Note that the coding named "identity" is reserved they were applied. Note that the coding named "identity" is reserved
for its special role in Accept-Encoding, and thus SHOULD NOT be for its special role in Accept-Encoding, and thus SHOULD NOT be
skipping to change at page 65, line 28 skipping to change at page 71, line 21
Media Type) if a representation in the request message has a content Media Type) if a representation in the request message has a content
coding that is not acceptable. coding that is not acceptable.
7.2.3. Content-Language 7.2.3. Content-Language
The "Content-Language" header field describes the natural language(s) The "Content-Language" header field describes the natural language(s)
of the intended audience for the representation. Note that this of the intended audience for the representation. Note that this
might not be equivalent to all the languages used within the might not be equivalent to all the languages used within the
representation. representation.
Content-Language = 1#language-tag Content-Language = #language-tag
Language tags are defined in Section 7.1.3. The primary purpose of Language tags are defined in Section 7.1.3. The primary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
representations according to the users' own preferred language. representations according to the users' own preferred language.
Thus, if the content is intended only for a Danish-literate audience, Thus, if the content is intended only for a Danish-literate audience,
the appropriate field is the appropriate field is
Content-Language: da Content-Language: da
If no Content-Language is specified, the default is that the content If no Content-Language is specified, the default is that the content
skipping to change at page 66, line 13 skipping to change at page 72, line 7
linguistic audiences. An example would be a beginner's language linguistic audiences. An example would be a beginner's language
primer, such as "A First Lesson in Latin", which is clearly intended primer, such as "A First Lesson in Latin", which is clearly intended
to be used by an English-literate audience. In this case, the to be used by an English-literate audience. In this case, the
Content-Language would properly only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type - it is not limited Content-Language MAY be applied to any media type - it is not limited
to textual documents. to textual documents.
7.2.4. Content-Length 7.2.4. Content-Length
// The "Content-Length" header field indicates the number of data The "Content-Length" header field indicates the associated
// octets (body length) for the representation. In some cases, representation's data length as a decimal non-negative integer number
// Content-Length is used to define or estimate message framing. of octets. When transferring a representation in a message, Content-
Length refers specifically to the amount of data enclosed so that it
can be used to delimit framing of the message body (e.g., Section 6.2
of [Messaging]). In other cases, Content-Length indicates the
selected representation's current length, which can be used by
recipients to estimate transfer time or compare to previously stored
representations.
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field. that contains a Transfer-Encoding header field.
skipping to change at page 69, line 30 skipping to change at page 75, line 30
the message "payload". In some cases, a payload might contain only the message "payload". In some cases, a payload might contain only
the associated representation's header fields (e.g., responses to the associated representation's header fields (e.g., responses to
HEAD) or only some part(s) of the representation data (e.g., the 206 HEAD) or only some part(s) of the representation data (e.g., the 206
(Partial Content) status code). (Partial Content) status code).
Header fields that specifically describe the payload, rather than the Header fields that specifically describe the payload, rather than the
associated representation, are referred to as "payload header associated representation, are referred to as "payload header
fields". Payload header fields are defined in other parts of this fields". Payload header fields are defined in other parts of this
specification, due to their impact on message parsing. specification, due to their impact on message parsing.
+-------------------+----------------------------+ ------------------- ----------------------------
| Field Name | Defined in... | Field Name Ref.
| Content-Range | Section 7.3.4 | ------------------- ----------------------------
| Trailer | Section 5.6.3 | Content-Range 7.3.4
| Transfer-Encoding | Section 6.1 of [Messaging] | Trailer 5.6.4
+-------------------+----------------------------+ Transfer-Encoding Section 6.1 of [Messaging]
------------------- ----------------------------
Table 7 Table 9
7.3.1. Purpose 7.3.1. Purpose
The purpose of a payload in a request is defined by the method The purpose of a payload in a request is defined by the method
semantics. For example, a representation in the payload of a PUT semantics. For example, a representation in the payload of a PUT
request (Section 8.3.4) represents the desired state of the target request (Section 8.3.4) represents the desired state of the target
resource if the request is successfully applied, whereas a resource if the request is successfully applied, whereas a
representation in the payload of a POST request (Section 8.3.3) representation in the payload of a POST request (Section 8.3.3)
represents information to be processed by the target resource. represents information to be processed by the target resource.
skipping to change at page 80, line 8 skipping to change at page 86, line 8
Unlike distributed objects, the standardized request methods in HTTP Unlike distributed objects, the standardized request methods in HTTP
are not resource-specific, since uniform interfaces provide for are not resource-specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed. whether those semantics are implemented or allowed.
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. commonly used in HTTP, as outlined by the following table.
+---------+--------------------------------------------+-------+ --------- -------------------------------------------- -------
| Method | Description | Sec. | Method Description Ref.
| GET | Transfer a current representation of the | 8.3.1 | --------- -------------------------------------------- -------
| | target resource. | | GET Transfer a current representation of the 8.3.1
| HEAD | Same as GET, but do not transfer the | 8.3.2 | target resource.
| | response body. | | HEAD Same as GET, but do not transfer the 8.3.2
| POST | Perform resource-specific processing on | 8.3.3 | response body.
| | the request payload. | | POST Perform resource-specific processing on 8.3.3
| PUT | Replace all current representations of the | 8.3.4 | the request payload.
| | target resource with the request payload. | | PUT Replace all current representations of the 8.3.4
| DELETE | Remove all current representations of the | 8.3.5 | target resource with the request payload.
| | target resource. | | DELETE Remove all current representations of the 8.3.5
| CONNECT | Establish a tunnel to the server | 8.3.6 | target resource.
| | identified by the target resource. | | CONNECT Establish a tunnel to the server 8.3.6
| OPTIONS | Describe the communication options for the | 8.3.7 | identified by the target resource.
| | target resource. | | OPTIONS Describe the communication options for the 8.3.7
| TRACE | Perform a message loop-back test along the | 8.3.8 | target resource.
| | path to the target resource. | | TRACE Perform a message loop-back test along the 8.3.8
+---------+--------------------------------------------+-------+ path to the target resource.
--------- -------------------------------------------- -------
Table 8 Table 10
All general-purpose servers MUST support the methods GET and HEAD. All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL. All other methods are OPTIONAL.
The set of methods allowed by a target resource can be listed in an The set of methods allowed by a target resource can be listed in an
Allow header field (Section 11.4.2). However, the set of allowed Allow header field (Section 11.4.2). However, the set of allowed
methods can change dynamically. When a request method is received methods can change dynamically. When a request method is received
that is unrecognized or not implemented by an origin server, the that is unrecognized or not implemented by an origin server, the
origin server SHOULD respond with the 501 (Not Implemented) status origin server SHOULD respond with the 501 (Not Implemented) status
code. When a request method is received that is known by an origin code. When a request method is received that is known by an origin
server but not allowed for the target resource, the origin server server but not allowed for the target resource, the origin server
SHOULD respond with the 405 (Method Not Allowed) status code. SHOULD respond with the 405 (Method Not Allowed) status code.
8.2. Common Method Properties 8.2. Common Method Properties
+---------+------+------------+---------------+ --------- ------ ------------ -------
| Method | Safe | Idempotent | Reference | Method Safe Idempotent Ref.
| CONNECT | no | no | Section 8.3.6 | --------- ------ ------------ -------
| DELETE | no | yes | Section 8.3.5 | CONNECT no no 8.3.6
| GET | yes | yes | Section 8.3.1 | DELETE no yes 8.3.5
| HEAD | yes | yes | Section 8.3.2 | GET yes yes 8.3.1
| OPTIONS | yes | yes | Section 8.3.7 | HEAD yes yes 8.3.2
| POST | no | no | Section 8.3.3 | OPTIONS yes yes 8.3.7
| PUT | no | yes | Section 8.3.4 | POST no no 8.3.3
| TRACE | yes | yes | Section 8.3.8 | PUT no yes 8.3.4
+---------+------+------------+---------------+ TRACE yes yes 8.3.8
--------- ------ ------------ -------
Table 9 Table 11
8.2.1. Safe Methods 8.2.1. Safe Methods
Request methods are considered "safe" if their defined semantics are Request methods are considered "safe" if their defined semantics are
essentially read-only; i.e., the client does not request, and does essentially read-only; i.e., the client does not request, and does
not expect, any state change on the origin server as a result of not expect, any state change on the origin server as a result of
applying a safe method to a target resource. Likewise, reasonable applying a safe method to a target resource. Likewise, reasonable
use of a safe method is not expected to cause any harm, loss of use of a safe method is not expected to cause any harm, loss of
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
skipping to change at page 83, line 22 skipping to change at page 89, line 25
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.
8.3. Method Definitions 8.3. Method Definitions
8.3.1. GET 8.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. GET is the primary mechanism of information for the target resource.
retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request.
The GET method is specifically intended to reflect the quality of GET is the primary mechanism of information retrieval and the focus
"sameness" identified by the request URI as if it were referenced as of almost all performance optimizations. Hence, when people speak of
an ordinary hypertext link. retrieving some identifiable information via HTTP, they are generally
referring to making a GET request. A successful response reflects
the quality of "sameness" identified by the target URI. In turn,
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 12.3 for related security considerations). However, there Section 12.3 for related security considerations). However, there
are no such limitations in practice. The HTTP interface for a are no such limitations in practice.
resource is just as likely to be implemented as a tree of content
objects, a programmatic view on various database records, or a The HTTP interface for a resource is just as likely to be implemented
gateway to other information systems. Even when the URI mapping as a tree of content objects, a programmatic view on various database
mechanism is tied to a file system, an origin server might be records, or a gateway to other information systems. Even when the
configured to execute the files with the request as input and send URI mapping mechanism is tied to a file system, an origin server
the output as the representation rather than transfer the files might be configured to execute the files with the request as input
directly. Regardless, only the origin server needs to know how each and send the output as the representation rather than transfer the
of its resource identifiers corresponds to an implementation and how files directly. Regardless, only the origin server needs to know how
each implementation manages to select and send a current each of its resource identifiers corresponds to an implementation and
how each implementation manages to select and send a current
representation of the target resource in a response to GET. representation of the target resource in a response to GET.
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 9.3). (Section 9.3).
A client SHOULD NOT generate a body in a GET request. A payload A client SHOULD NOT generate a body in a GET request. A payload
received in a GET request has no defined semantics, cannot alter the received in a GET request has no defined semantics, cannot alter the
meaning or target of the request, and might lead some implementations meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its to reject the request and close the connection because of its
potential as a request smuggling attack (Section 11.2 of potential as a request smuggling attack (Section 11.2 of
[Messaging]). [Messaging]).
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]). A by the Cache-Control header field (Section 5.2 of [Caching]). A
cache that receives a payload in a GET request is likely to ignore cache that receives a payload in a GET request is likely to ignore
that payload and cache regardless of the payload contents. that payload and cache regardless of the payload contents.
When information retrieval is performed with a mechanism that
constructs a target URI from user-provided information, such as the
query fields of a form using GET, potentially sensitive data might be
provided that would not be appropriate for disclosure within a URI
(see Section 12.9). In some cases, the data can be filtered or
transformed such that it would not reveal such information. In
others, particularly when there is no benefit from caching a
response, using the POST method (Section 8.3.3) instead of GET will
usually transmit such information in the request body rather than
construct a new URI.
8.3.2. HEAD 8.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at send a message body in the response (i.e., the response terminates at
the end of the header section). The server SHOULD send the same the end of the header section). The server SHOULD send the same
header fields in response to a HEAD request as it would have sent if header fields in response to a HEAD request as it would have sent if
the request had been a GET, except that the payload header fields the request had been a GET, except that the payload header fields
(Section 7.3) MAY be omitted. This method can be used for obtaining (Section 7.3) MAY be omitted. This method can be used for obtaining
metadata about the selected representation without transferring the metadata about the selected representation without transferring the
representation data and is often used for testing hypertext links for representation data and is often used for testing hypertext links for
skipping to change at page 85, line 13 skipping to change at page 91, line 32
blog, or similar group of articles; blog, or similar group of articles;
o Creating a new resource that has yet to be identified by the o Creating a new resource that has yet to be identified by the
origin server; and origin server; and
o Appending data to a resource's existing representation(s). o Appending data to a resource's existing representation(s).
An origin server indicates response semantics by choosing an An origin server indicates response semantics by choosing an
appropriate status code depending on the result of processing the appropriate status code depending on the result of processing the
POST request; almost all of the status codes defined by this POST request; almost all of the status codes defined by this
specification might be received in a response to POST (the exceptions specification could be received in a response to POST (the exceptions
being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
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 11.1.2) and a representation that describes the status of (Section 11.1.2) 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).
skipping to change at page 92, line 26 skipping to change at page 99, line 11
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 9.5 or cookies [RFC6265] in a TRACE request. The final Section 9.5 or cookies [RFC6265] 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 body. response body.
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 6.7.1) is of information. The value of the Via header field (Section 6.6.1) 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
proxies forwarding messages in an infinite loop. proxies forwarding messages in an infinite loop.
A client MUST NOT send a message body in a TRACE request. A client MUST NOT send a message body in a TRACE request.
Responses to the TRACE method are not cacheable. Responses to the TRACE method are not cacheable.
8.4. Method Extensibility 8.4. Method Extensibility
skipping to change at page 94, line 19 skipping to change at page 101, line 5
target resource state, suggest preferred formats for the response, target resource state, suggest preferred formats for the response,
supply authentication credentials, or modify the expected request supply authentication credentials, or modify the expected request
processing. These fields act as request modifiers, similar to the processing. These fields act as request modifiers, similar to the
parameters on a programming language method invocation. parameters on a programming language method invocation.
9.1. Controls 9.1. Controls
Controls are request header fields that direct specific handling of Controls are request header fields that direct specific handling of
the request. the request.
+---------------+----------------------------+ --------------- --------------------------
| Field Name | Defined in... | Field Name Ref.
| Cache-Control | Section 5.2 of [Caching] | --------------- --------------------------
| Expect | Section 9.1.1 | Cache-Control Section 5.2 of [Caching]
| Host | Section 6.6 | Expect 9.1.1
| Max-Forwards | Section 9.1.2 | Host 6.5
| Pragma | Section 5.4 of [Caching] | Max-Forwards 9.1.2
| TE | Section 7.4 of [Messaging] | Pragma Section 5.4 of [Caching]
+---------------+----------------------------+ TE 5.6.5
--------------- --------------------------
Table 10 Table 12
9.1.1. Expect 9.1.1. Expect
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. The only such expectation order to properly handle this request.
defined by this specification is 100-continue.
Expect = "100-continue" Expect = #expectation
expectation = token [ "=" ( token / quoted-string ) parameters ]
The Expect field value is case-insensitive. The Expect field value is case-insensitive.
A server that receives an Expect field value other than 100-continue The only expectation defined by this specification is "100-continue"
MAY respond with a 417 (Expectation Failed) status code to indicate (with no defined parameters).
that the unexpected expectation cannot be met.
A server that receives an Expect field value containing a member
other than 100-continue MAY respond with a 417 (Expectation Failed)
status code to indicate that the unexpected expectation cannot be
met.
A 100-continue expectation informs recipients that the client is A 100-continue expectation informs recipients that the client is
about to send a (presumably large) message body in this request and about to send a (presumably large) message body in this request and
wishes to receive a 100 (Continue) interim response if the method, wishes to receive a 100 (Continue) interim response if the method,
target URI, and header fields are not sufficient to cause an target URI, and header fields are not sufficient to cause an
immediate success, redirect, or error response. This allows the immediate success, redirect, or error response. This allows the
client to wait for an indication that it is worthwhile to send the client to wait for an indication that it is worthwhile to send the
message body before actually doing so, which can improve efficiency message body before actually doing so, which can improve efficiency
when the message body is huge or when the client anticipates that an when the message body is huge or when the client anticipates that an
error is likely (e.g., when sending a state-changing method, for the error is likely (e.g., when sending a state-changing method, for the
skipping to change at page 96, line 16 skipping to change at page 103, line 7
already received some or all of the message body for the already received some or all of the message body for the
corresponding request, or if the framing indicates that there is corresponding request, or if the framing indicates that there is
no message body. no message body.
o A server that sends a 100 (Continue) response MUST ultimately send o A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once the message body is received and a final status code, once the message body is received and
processed, unless the connection is closed prematurely. processed, unless the connection is closed prematurely.
o A server that responds with a final status code before reading the o A server that responds with a final status code before reading the
entire request payload body SHOULD indicate whether it intends to entire request payload body SHOULD indicate whether it intends to
close the connection (see Section 9.7 of [Messaging]) or continue close the connection (e.g., see Section 9.6 of [Messaging]) or
reading the payload body. continue reading the payload body.
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 indicates a request message contains a 100-continue expectation and indicates a request message
body will follow, either send an immediate response with a final body 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's (Continue) response to encourage the client to send the request's
message body. The origin server MUST NOT wait for the message body message body. The origin server MUST NOT wait for the message body
before sending the 100 (Continue) response. before sending the 100 (Continue) response.
skipping to change at page 98, line 20 skipping to change at page 105, line 10
corresponding to the method semantics will not be applied if the corresponding to the method semantics will not be applied if the
precondition evaluates to false. Each precondition defined by this precondition evaluates to false. Each precondition defined by this
specification consists of a comparison between a set of validators specification consists of a comparison between a set of validators
obtained from prior representations of the target resource to the obtained from prior representations of the target resource to the
current state of validators for the selected representation current state of validators for the selected representation
(Section 11.2). Hence, these preconditions evaluate whether the (Section 11.2). Hence, these preconditions evaluate whether the
state of the target resource has changed since a given state known by state of the target resource has changed since a given state known by
the client. The effect of such an evaluation depends on the method the client. The effect of such an evaluation depends on the method
semantics and choice of conditional, as defined in Section 9.2.1. semantics and choice of conditional, as defined in Section 9.2.1.
+---------------------+---------------+ --------------------- -------
| Field Name | Defined in... | Field Name Ref.
| If-Match | Section 9.2.3 | --------------------- -------
| If-None-Match | Section 9.2.4 | If-Match 9.2.3
| If-Modified-Since | Section 9.2.5 | If-None-Match 9.2.4
| If-Unmodified-Since | Section 9.2.6 | If-Modified-Since 9.2.5
| If-Range | Section 9.2.7 | If-Unmodified-Since 9.2.6
+---------------------+---------------+ If-Range 9.2.7
--------------------- -------
Table 11 Table 13
9.2.1. Evaluation 9.2.1. Evaluation
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 perform performed its normal request checks and just before it would process
the action associated with the request method. A server MUST ignore the request body (if any) or perform the action associated with the
all received preconditions if its response to the same request request method. A server MUST ignore all received preconditions if
without those conditions would have been a status code other than a its response to the same request without those conditions, prior to
2xx (Successful) or 412 (Precondition Failed). In other words, processing the request body, would have been a status code other than
redirects and failures take precedence over the evaluation of a 2xx (Successful) or 412 (Precondition Failed). In other words,
preconditions in conditional requests. redirects and failures that can be detected before significant
processing occurs take precedence over the evaluation of
preconditions.
A server that is not the origin server for the target resource and A server that is not the origin server for the target resource and
cannot act as a cache for requests on the target resource MUST NOT cannot act as a cache for requests on the target resource MUST NOT
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,
skipping to change at page 101, line 24 skipping to change at page 108, line 5
representation of the target resource, when the field value is "*", representation of the target resource, when the field value is "*",
or having a current representation of the target resource that has an or having a current representation of the target resource that has an
entity-tag matching a member of the list of entity-tags provided in entity-tag matching a member of the list of entity-tags provided in
the field value. the field value.
An origin server MUST use the strong comparison function when An origin server MUST use the strong comparison function when
comparing entity-tags for If-Match (Section 11.2.3.2), since the comparing entity-tags for If-Match (Section 11.2.3.2), since the
client intends this precondition to prevent the method from being client intends this precondition to prevent the method from being
applied if there have been any changes to the representation data. applied if there have been any changes to the representation data.
If-Match = "*" / 1#entity-tag If-Match = "*" / #entity-tag
Examples: Examples:
If-Match: "xyzzy" If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: * If-Match: *
If-Match is most often used with state-changing methods (e.g., POST, If-Match is most often used with state-changing methods (e.g., POST,
PUT, DELETE) to prevent accidental overwrites when multiple user PUT, DELETE) to prevent accidental overwrites when multiple user
agents might be acting in parallel on the same resource (i.e., to agents might be acting in parallel on the same resource (i.e., to
prevent the "lost update" problem). It can also be used with safe prevent the "lost update" problem). It can also be used with any
methods to abort a request if the selected representation does not method to abort a request if the selected representation does not
match one already stored (or partially stored) from a prior request. match one that the client has already stored (or partially stored)
from a prior request.
An origin server that receives an If-Match header field MUST evaluate An origin server that receives an If-Match header field MUST evaluate
the condition as per Section 9.2.1 prior to performing the method. the condition as per Section 9.2.1 prior to performing the method.
To evaluate a received If-Match header field: To evaluate a received If-Match header field:
1. If the field value is "*", the condition is true if the origin 1. If the field value is "*", the condition is true if the origin
server has a current representation for the target resource. server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is 2. If the field value is a list of entity-tags, the condition is
true if any of the listed tags match the entity-tag of the true if any of the listed tags match the entity-tag of the
selected representation. selected representation.
3. Otherwise, the condition is false. 3. Otherwise, the condition is false.
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-Match condition evaluates to false; instead, the origin server If-Match condition evaluates to false. Instead, the origin server
MUST respond with either a) the 412 (Precondition Failed) status code MAY indicate that the conditional request failed by responding with a
or b) one of the 2xx (Successful) status codes if the origin server 412 (Precondition Failed) status code. Alternatively, if the request
has verified that a state change is being requested and the final is a state-changing operation that appears to have already been
state is already reflected in the current state of the target applied to the selected representation, the origin server MAY respond
resource (i.e., the change requested by the user agent has already with a 2xx (Successful) status code (i.e., the change requested by
succeeded, but the user agent might not be aware of it, perhaps the user agent has already succeeded, but the user agent might not be
because the prior response was lost or a compatible change was made aware of it, perhaps because the prior response was lost or an
by some other user agent). In the latter case, the origin server equivalent change was made by some other user agent).
MUST NOT send a validator header field in the response unless it can
verify that the request is a duplicate of an immediately prior change Allowing an origin server to send a success response when a change
made by the same user agent. request appears to have already been applied is more efficient for
many authoring use cases, but comes with some risk if multiple user
agents are making change requests that are very similar but not
cooperative. For example, multiple user agents writing to a common
resource as a semaphore (e.g., a non-atomic increment) are likely to
collide and potentially lose important state transitions. For those
kinds of resources, an origin server is better off being stringent in
sending 412 for every failed precondition on an unsafe method. In
other cases, excluding the ETag field from a success response might
encourage the user agent to perform a GET as its next request to
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 unlikely to be
interoperable. interoperable.
9.2.4. If-None-Match 9.2.4. If-None-Match
skipping to change at page 102, line 39 skipping to change at page 109, line 30
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
entity-tags for If-None-Match (Section 11.2.3.2), since weak entity- entity-tags for If-None-Match (Section 11.2.3.2), since weak entity-
tags can be used for cache validation even if there have been changes tags can be used for cache validation even if there have been changes
to the representation data. to the representation data.
If-None-Match = "*" / 1#entity-tag If-None-Match = "*" / #entity-tag
Examples: Examples:
If-None-Match: "xyzzy" If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy" If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: * If-None-Match: *
If-None-Match is primarily used in conditional GET requests to enable If-None-Match is primarily used in conditional GET requests to enable
skipping to change at page 104, line 19 skipping to change at page 111, line 13
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is If-None-Match header field; the condition in If-None-Match is
considered to be a more accurate replacement for the condition in If- considered to be a more accurate replacement for the condition in If-
Modified-Since, and the two are only combined for the sake of Modified-Since, and the two are only combined for the sake of
interoperating with older intermediaries that might not implement interoperating with older intermediaries that might not implement
If-None-Match. If-None-Match.
A recipient MUST ignore the If-Modified-Since header field if the A recipient MUST ignore the If-Modified-Since header field if the
received field value is not a valid HTTP-date, or if the request received field value is not a valid HTTP-date, the field value has
method is neither GET nor HEAD. more than one member, or if the request method is neither GET nor
HEAD.
A recipient MUST interpret an If-Modified-Since field value's A recipient MUST interpret an If-Modified-Since field value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Modified-Since is typically used for two distinct purposes: 1) to If-Modified-Since is typically used for two distinct purposes: 1) to
allow efficient updates of a cached representation that does not have allow efficient updates of a cached representation that does not have
an entity-tag and 2) to limit the scope of a web traversal to an entity-tag and 2) to limit the scope of a web traversal to
resources that have recently changed. resources that have recently changed.
When used for cache updates, a cache will typically use the value of When used for cache updates, a cache will typically use the value of
skipping to change at page 105, line 38 skipping to change at page 112, line 38
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Unmodified-Since if the request contains A recipient MUST ignore If-Unmodified-Since if the request contains
an If-Match header field; the condition in If-Match is considered to an If-Match header field; the condition in If-Match is considered to
be a more accurate replacement for the condition in If-Unmodified- be a more accurate replacement for the condition in If-Unmodified-
Since, and the two are only combined for the sake of interoperating Since, and the two are only combined for the sake of interoperating
with older intermediaries that might not implement If-Match. with older intermediaries that might not implement If-Match.
A recipient MUST ignore the If-Unmodified-Since header field if the A recipient MUST ignore the If-Unmodified-Since header field if the
received field value is not a valid HTTP-date. received field value is not a valid HTTP-date (including when the
field value appears to be a list of dates).
A recipient MUST interpret an If-Unmodified-Since field value's A recipient MUST interpret an If-Unmodified-Since field value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Unmodified-Since is most often used with state-changing methods If-Unmodified-Since is most often used with state-changing methods
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when (e.g., POST, PUT, DELETE) to prevent accidental overwrites when
multiple user agents might be acting in parallel on a resource that multiple user agents might be acting in parallel on a resource that
does not supply entity-tags with its representations (i.e., to does not supply entity-tags with its representations (i.e., to
prevent the "lost update" problem). It can also be used with safe prevent the "lost update" problem). It can also be used with any
methods to abort a request if the selected representation does not method to abort a request if the selected representation does not
match one already stored (or partially stored) from a prior request. match one that the client already stored (or partially stored) from a
prior request.
An origin server that receives an If-Unmodified-Since header field An origin server that receives an If-Unmodified-Since header field
MUST evaluate the condition as per Section 9.2.1 prior to performing MUST evaluate the condition as per Section 9.2.1 prior to performing
the method. the method.
If the selected representation has a last modification date, the If the selected representation has a last modification date, the
origin server MUST NOT perform the requested method if that date is origin server MUST NOT perform the requested method if that date is
more recent than the date provided in the field value. Instead, the more recent than the date provided in the field value. Instead, the
origin server MUST respond with either a) the 412 (Precondition origin server MAY indicate that the conditional request failed by
Failed) status code or b) one of the 2xx (Successful) status codes if responding with a 412 (Precondition Failed) status code.
the origin server has verified that a state change is being requested Alternatively, if the request is a state-changing operation that
and the final state is already reflected in the current state of the appears to have already been applied to the selected representation,
target resource (i.e., the change requested by the user agent has the origin server MAY respond with a 2xx (Successful) status code
already succeeded, but the user agent might not be aware of that (i.e., the change requested by the user agent has already succeeded,
because the prior response message was lost or a compatible change but the user agent might not be aware of it, perhaps because the
was made by some other user agent). In the latter case, the origin prior response was lost or an equivalent change was made by some
server MUST NOT send a validator header field in the response unless other user agent).
it can verify that the request is a duplicate of an immediately prior
change made by the same user agent. Allowing an origin server to send a success response when a change
request appears to have already been applied is more efficient for
many authoring use cases, but comes with some risk if multiple user
agents are making change requests that are very similar but not
cooperative. In those cases, an origin server is better off being
stringent in sending 412 for every failed precondition on an unsafe
method.
The If-Unmodified-Since header field can be ignored by caches and The If-Unmodified-Since header field can be ignored by caches and
intermediaries because it is not applicable to a stored response. intermediaries because it is not applicable to a stored response.
9.2.7. If-Range 9.2.7. If-Range
The "If-Range" header field provides a special conditional request The "If-Range" header field provides a special conditional request
mechanism that is similar to the If-Match and If-Unmodified-Since mechanism that is similar to the If-Match and If-Unmodified-Since
header fields but that instructs the recipient to ignore the Range header fields but that instructs the recipient to ignore the Range
header field if the validator doesn't match, resulting in transfer of header field if the validator doesn't match, resulting in transfer of
skipping to change at page 108, line 30 skipping to change at page 115, line 35
byte ranges. byte ranges.
An origin server MUST ignore a Range header field that contains a An origin server MUST ignore a Range header field that contains a
range unit it does not understand. A proxy MAY discard a Range range unit it does not understand. A proxy MAY discard a Range
header field that contains a range unit it does not understand. header field that contains a range unit it does not understand.
A server that supports range requests MAY ignore or reject a Range A server that supports range requests MAY ignore or reject a Range
header field that consists of more than two overlapping ranges, or a header field that consists of more than two overlapping ranges, or a
set of many small ranges that are not listed in ascending order, set of many small ranges that are not listed in ascending order,
since both are indications of either a broken client or a deliberate since both are indications of either a broken client or a deliberate
denial-of-service attack (Section 12.13). A client SHOULD NOT denial-of-service attack (Section 12.14). A client SHOULD NOT
request multiple ranges that are inherently less efficient to process request multiple ranges that are inherently less efficient to process
and transfer than a single range that encompasses the same data. and transfer than a single range that encompasses the same data.
A server that supports range requests MAY ignore a Range header field A server that supports range requests MAY ignore a Range header field
when the selected representation has no body (i.e., the selected when the selected representation has no body (i.e., the selected
representation data is of zero length). representation data is of zero length).
A client that is requesting multiple ranges SHOULD list those ranges A client that is requesting multiple ranges SHOULD list those ranges
in ascending order (the order in which they would typically be in ascending order (the order in which they would typically be
received in a complete representation) unless there is a specific received in a complete representation) unless there is a specific
skipping to change at page 109, line 30 skipping to change at page 116, line 36
9.4. Negotiation 9.4. Negotiation
The following request header fields can be sent by a user agent to The following request header fields can be sent by a user agent to
engage in proactive negotiation of the response content, as defined engage in proactive negotiation of the response content, as defined
in Section 7.4.1. The preferences sent in these fields apply to any in Section 7.4.1. The preferences sent in these fields apply to any
content in the response, including representations of the target content in the response, including representations of the target
resource, representations of error or processing status, and resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear potentially even the miscellaneous text strings that might appear
within the protocol. within the protocol.
+-----------------+---------------+ ----------------- -------
| Field Name | Defined in... | Field Name Ref.
| Accept | Section 9.4.1 | ----------------- -------
| Accept-Charset | Section 9.4.2 | Accept 9.4.1
| Accept-Encoding | Section 9.4.3 | Accept-Charset 9.4.2
| Accept-Language | Section 9.4.4 | Accept-Encoding 9.4.3
+-----------------+---------------+ Accept-Language 9.4.4
----------------- -------
Table 12 Table 14
For each of these header fields, a request that does not contain it For each of these header fields, a request that does not contain it
implies that the user agent has no preference on that axis of implies that the user agent has no preference on that axis of
negotiation. If the header field is present in a request and none of negotiation. If the header field is present in a request and none of
the available representations for the response can be considered the available representations for the response can be considered
acceptable according to it, the origin server can either honor the acceptable according to it, the origin server can either honor the
header field by sending a 406 (Not Acceptable) response or disregard header field by sending a 406 (Not Acceptable) response or disregard
the header field by treating the response as if it is not subject to the header field by treating the response as if it is not subject to
content negotiation for that request header field. This does not content negotiation for that request header field. This does not
imply, however, that the client will be able to use the imply, however, that the client will be able to use the
representation. representation.
*Note:* Sending these header fields makes it easier for a server to *Note:* Sending these header fields makes it easier for a server to
identify an individual by virtue of the user agent's request identify an individual by virtue of the user agent's request
characteristics (Section 12.11). characteristics (Section 12.12).
Each of these header fields defines a wildcard value (often, "*") to Each of these header fields defines a wildcard value (often, "*") to
select unspecified values. If no wildcard is present, all values not select unspecified values. If no wildcard is present, all values not
explicitly mentioned in the field are considered "not acceptable" to explicitly mentioned in the field are considered "not acceptable" to
the client. the client.
*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, for limited practical value, because it is seldom useful to say, for
example, "I prefer image/* more or less than (some other specific example, "I prefer image/* more or less than (some other specific
value)". Clients can explicitly request a 406 (Not Acceptable) value)". Clients can explicitly request a 406 (Not Acceptable)
skipping to change at page 110, line 37 skipping to change at page 117, line 41
specifically limited to a small set of desired types, as in the case specifically limited to a small set of desired types, as in the case
of a request for an in-line image. of a request for an in-line image.
When sent by a server in a response, Accept provides information When sent by a server in a response, Accept provides information
about what content types are preferred in the payload of a subsequent about what content types are preferred in the payload of a subsequent
request to the same resource. request to the same resource.
Accept = #( media-range [ accept-params ] ) Accept = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) *( OWS ";" OWS parameter ) ) parameters
accept-params = weight *( accept-ext ) accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
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 zero or more applicable media Each media-range might be followed by zero or more applicable media
type parameters (e.g., charset), an optional "q" parameter for type parameters (e.g., charset), an optional "q" parameter for
skipping to change at page 112, line 13 skipping to change at page 119, line 13
4. */* 4. */*
The media type quality factor associated with a given type is The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence determined by finding the media range with the highest precedence
that matches the type. For example, that matches the type. For example,
Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed, Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
text/plain;format=fixed;q=0.4, */*;q=0.5 text/plain;format=fixed;q=0.4, */*;q=0.5
would cause the following values to be associated: would cause the following values to be associated:
+--------------------------+---------------+ -------------------------- ---------------
| Media Type | Quality Value | Media Type Quality Value
| text/plain;format=flowed | 1 | -------------------------- ---------------
| text/plain | 0.7 | text/plain;format=flowed 1
| text/html | 0.3 | text/plain 0.7
| image/jpeg | 0.5 | text/html 0.3
| text/plain;format=fixed | 0.4 | image/jpeg 0.5
| text/html;level=3 | 0.7 | text/plain;format=fixed 0.4
+--------------------------+---------------+ text/html;level=3 0.7
-------------------------- ---------------
Table 13 Table 15
*Note:* A user agent might be provided with a default set of quality *Note:* A user agent might be provided with a default set of quality
values for certain media ranges. However, unless the user agent is a values for certain media ranges. However, unless the user agent is a
closed system that cannot interact with other rendering agents, this closed system that cannot interact with other rendering agents, this
default set ought to be configurable by the user. default set ought to be configurable by the user.
9.4.2. Accept-Charset 9.4.2. Accept-Charset
The "Accept-Charset" header field can be sent by a user agent to The "Accept-Charset" header field can be sent by a user agent to
indicate its preferences for charsets in textual response content. indicate its preferences for charsets in textual response content.
For example, this field allows user agents capable of understanding For example, this field allows user agents capable of understanding
more comprehensive or special-purpose charsets to signal that more comprehensive or special-purpose charsets to signal that
capability to an origin server that is capable of representing capability to an origin server that is capable of representing
information in those charsets. information in those charsets.
Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) Accept-Charset = #( ( charset / "*" ) [ weight ] )
Charset names are defined in Section 7.1.1.1. A user agent MAY Charset names are defined in Section 7.1.1.1. A user agent MAY
associate a quality value with each charset to indicate the user's associate a quality value with each charset to indicate the user's
relative preference for that charset, as defined in Section 7.4.4. relative preference for that charset, as defined in Section 7.4.4.
An example is An example is
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, The special value "*", if present in the Accept-Charset field,
matches every charset that is not mentioned elsewhere in the Accept- matches every charset that is not mentioned elsewhere in the Accept-
Charset field. Charset field.
*Note:* Accept-Charset is deprecated because UTF-8 has become nearly *Note:* Accept-Charset is deprecated because UTF-8 has become nearly
ubiquitous and sending a detailed list of user-preferred charsets ubiquitous and sending a detailed list of user-preferred charsets
wastes bandwidth, increases latency, and makes passive fingerprinting wastes bandwidth, increases latency, and makes passive fingerprinting
far too easy (Section 12.11). Most general-purpose user agents do far too easy (Section 12.12). Most general-purpose user agents do
not send Accept-Charset, unless specifically configured to do so. not send Accept-Charset, unless specifically configured to do so.
9.4.3. Accept-Encoding 9.4.3. Accept-Encoding
The "Accept-Encoding" header field can be used to indicate The "Accept-Encoding" header field can be used to indicate
preferences regarding the use of content codings (Section 7.1.2). preferences regarding the use of content codings (Section 7.1.2).
When sent by a user agent in a request, Accept-Encoding indicates the When sent by a user agent in a request, Accept-Encoding indicates the
content codings acceptable in a response. content codings acceptable in a response.
skipping to change at page 115, line 11 skipping to change at page 122, line 11
| qvalues associated with content-codings. This means that | qvalues associated with content-codings. This means that
| qvalues might not work and are not permitted with x-gzip or | qvalues might not work and are not permitted with x-gzip or
| x-compress. | x-compress.
9.4.4. Accept-Language 9.4.4. Accept-Language
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 7.1.3. response. Language tags are defined in Section 7.1.3.
Accept-Language = 1#( language-range [ weight ] ) Accept-Language = #( language-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in Section 7.4.4. For example, specified by that range, as defined in Section 7.4.4. For example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
skipping to change at page 115, line 41 skipping to change at page 122, line 41
found in Section 2.3 of [RFC4647]. found in Section 2.3 of [RFC4647].
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
schemes. Implementations can offer the most appropriate matching schemes. Implementations can offer the most appropriate matching
scheme for their requirements. The "Basic Filtering" scheme scheme for their requirements. The "Basic Filtering" scheme
([RFC4647], Section 3.3.1) is identical to the matching scheme that ([RFC4647], Section 3.3.1) is identical to the matching scheme that
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 12.11). preferences of the user in every request (Section 12.12).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept- does not provide such control to the user MUST NOT send an Accept-
Language header field. Language header field.
| *Note:* User agents ought to provide guidance to users when | *Note:* User agents ought to provide guidance to users when
| setting a preference, since users are rarely familiar with the | setting a preference, since users are rarely familiar with the
skipping to change at page 116, line 20 skipping to change at page 123, line 20
HTTP provides a general framework for access control and HTTP provides a general framework for access control and
authentication, via an extensible set of challenge-response authentication, via an extensible set of challenge-response
authentication schemes, which can be used by a server to challenge a authentication schemes, which can be used by a server to challenge a
client request and by a client to provide authentication information. client request and by a client to provide authentication information.
Two header fields are used for carrying authentication credentials. Two header fields are used for carrying authentication credentials.
Note that various custom mechanisms for user authentication use the Note that various custom mechanisms for user authentication use the
Cookie header field for this purpose, as defined in [RFC6265]. Cookie header field for this purpose, as defined in [RFC6265].
+---------------------+---------------+ --------------------- -------
| Field Name | Defined in... | Field Name Ref.
| Authorization | Section 9.5.3 | --------------------- -------
| Proxy-Authorization | Section 9.5.4 | Authorization 9.5.3
+---------------------+---------------+ Proxy-Authorization 9.5.4
--------------------- -------
Table 14 Table 16
9.5.1. Challenge and Response 9.5.1. Challenge and Response
HTTP provides a simple challenge-response authentication framework HTTP provides a simple challenge-response authentication framework
that can be used by a server to challenge a client request and by a that can be used by a server to challenge a client request and by a
client to provide authentication information. It uses a case- client to provide authentication information. It uses a case-
insensitive token as a means to identify the authentication scheme, insensitive token as a means to identify the authentication scheme,
followed by additional information necessary for achieving followed by additional information necessary for achieving
authentication via that scheme. The latter can be either a comma- authentication via that scheme. The latter can be either a comma-
separated list of parameters or a single sequence of characters separated list of parameters or a single sequence of characters
skipping to change at page 117, line 46 skipping to change at page 124, line 46
Both the Authorization field value and the Proxy-Authorization field Both the Authorization field value and the Proxy-Authorization field
value contain the client's credentials for the realm of the resource value contain the client's credentials for the realm of the resource
being requested, based upon a challenge received in a response being requested, based upon a challenge received in a response
(possibly at some point in the past). When creating their values, (possibly at some point in the past). When creating their values,
the user agent ought to do so by selecting the challenge with what it the user agent ought to do so by selecting the challenge with what it
considers to be the most secure auth-scheme that it understands, considers to be the most secure auth-scheme that it understands,
obtaining credentials from the user as appropriate. Transmission of obtaining credentials from the user as appropriate. Transmission of
credentials within header field values implies significant security credentials within header field values implies significant security
considerations regarding the confidentiality of the underlying considerations regarding the confidentiality of the underlying
connection, as described in Section 12.14.1. connection, as described in Section 12.15.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Upon receipt of a request for a protected resource that omits Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or credentials, contains invalid credentials (e.g., a bad password) or
partial credentials (e.g., when the authentication scheme requires partial credentials (e.g., when the authentication scheme requires
more than one round trip), an origin server SHOULD send a 401 more than one round trip), an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field (Unauthorized) response that contains a WWW-Authenticate header field
with at least one (possibly new) challenge applicable to the with at least one (possibly new) challenge applicable to the
requested resource. requested resource.
skipping to change at page 121, line 51 skipping to change at page 128, line 51
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").
o Schemes using Authentication-Info, Proxy-Authentication-Info, or o 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
consider and document the related security considerations (see consider and document the related security considerations (see
Section 12.14.4). Section 12.15.4).
9.6. Request Context 9.6. Request Context
The following request header fields provide additional information The following request header fields provide additional information
about the request context, including information about the user, user about the request context, including information about the user, user
agent, and resource behind the request. agent, and resource behind the request.
+------------+---------------+ ------------ -------
| Field Name | Defined in... | Field Name Ref.
| From | Section 9.6.1 | ------------ -------
| Referer | Section 9.6.2 | From 9.6.1
| User-Agent | Section 9.6.3 | Referer 9.6.2
+------------+---------------+ User-Agent 9.6.3
------------ -------
Table 15 Table 17
9.6.1. From 9.6.1. From
The "From" header field contains an Internet email address for a The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
skipping to change at page 123, line 46 skipping to change at page 130, line 46
The Referer field has the potential to reveal information about the The Referer field has the potential to reveal information about the
request context or browsing history of the user, which is a privacy request context or browsing history of the user, which is a privacy
concern if the referring resource's identifier reveals personal concern if the referring resource's identifier reveals personal
information (such as an account name) or a resource that is supposed information (such as an account name) or a resource that is supposed
to be confidential (such as behind a firewall or internal to a to be confidential (such as behind a firewall or internal to a
secured service). Most general-purpose user agents do not send the secured service). Most general-purpose user agents do not send the
Referer header field when the referring resource is a local "file" or Referer header field when the referring resource is a local "file" or
"data" URI. A user agent MUST NOT send a Referer header field in an "data" URI. A user agent MUST NOT send a Referer header field in an
unsecured HTTP request if the referring page was received with a unsecured HTTP request if the referring page was received with a
secure protocol. See Section 12.8 for additional security secure protocol. See Section 12.9 for additional security
considerations. considerations.
Some intermediaries have been known to indiscriminately remove Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the Referer header fields from outgoing requests. This has the
unfortunate side effect of interfering with protection against CSRF unfortunate side effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users. attacks, which can be far more harmful to their users.
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
skipping to change at page 126, line 18 skipping to change at page 133, line 18
reason phrases listed here are only recommendations - they can be reason phrases listed here are only recommendations - they can be
replaced by local equivalents without affecting the protocol. replaced by local equivalents without 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.
+-------+-------------------------------+-----------------+ ------- ------------------------------- ---------
| Value | Description | Reference | Value Description Ref.
| 100 | Continue | Section 10.2.1 | ------- ------------------------------- ---------
| 101 | Switching Protocols | Section 10.2.2 | 100 Continue 10.2.1
| 200 | OK | Section 10.3.1 | 101 Switching Protocols 10.2.2
| 201 | Created | Section 10.3.2 | 200 OK 10.3.1
| 202 | Accepted | Section 10.3.3 | 201 Created 10.3.2
| 203 | Non-Authoritative Information | Section 10.3.4 | 202 Accepted 10.3.3
| 204 | No Content | Section 10.3.5 | 203 Non-Authoritative Information 10.3.4
| 205 | Reset Content | Section 10.3.6 | 204 No Content 10.3.5
| 206 | Partial Content | Section 10.3.7 | 205 Reset Content 10.3.6
| 300 | Multiple Choices | Section 10.4.1 | 206 Partial Content 10.3.7
| 301 | Moved Permanently | Section 10.4.2 | 300 Multiple Choices 10.4.1
| 302 | Found | Section 10.4.3 | 301 Moved Permanently 10.4.2
| 303 | See Other | Section 10.4.4 | 302 Found 10.4.3
| 304 | Not Modified | Section 10.4.5 | 303 See Other 10.4.4
| 305 | Use Proxy | Section 10.4.6 | 304 Not Modified 10.4.5
| 306 | (Unused) | Section 10.4.7 | 305 Use Proxy 10.4.6
| 307 | Temporary Redirect | Section 10.4.8 | 306 (Unused) 10.4.7
| 308 | Permanent Redirect | Section 10.4.9 | 307 Temporary Redirect 10.4.8
| 400 | Bad Request | Section 10.5.1 | 308 Permanent Redirect 10.4.9
| 401 | Unauthorized | Section 10.5.2 | 400 Bad Request 10.5.1
| 402 | Payment Required | Section 10.5.3 | 401 Unauthorized 10.5.2
| 403 | Forbidden | Section 10.5.4 | 402 Payment Required 10.5.3
| 404 | Not Found | Section 10.5.5 | 403 Forbidden 10.5.4
| 405 | Method Not Allowed | Section 10.5.6 | 404 Not Found 10.5.5
| 406 | Not Acceptable | Section 10.5.7 | 405 Method Not Allowed 10.5.6
| 407 | Proxy Authentication Required | Section 10.5.8 | 406 Not Acceptable 10.5.7
| 408 | Request Timeout | Section 10.5.9 | 407 Proxy Authentication Required 10.5.8
| 409 | Conflict | Section 10.5.10 | 408 Request Timeout 10.5.9
| 410 | Gone | Section 10.5.11 | 409 Conflict 10.5.10
| 411 | Length Required | Section 10.5.12 | 410 Gone 10.5.11
| 412 | Precondition Failed | Section 10.5.13 | 411 Length Required 10.5.12
| 413 | Payload Too Large | Section 10.5.14 | 412 Precondition Failed 10.5.13
| 414 | URI Too Long | Section 10.5.15 | 413 Payload Too Large 10.5.14
| 415 | Unsupported Media Type | Section 10.5.16 | 414 URI Too Long 10.5.15
| 416 | Range Not Satisfiable | Section 10.5.17 | 415 Unsupported Media Type 10.5.16
| 417 | Expectation Failed | Section 10.5.18 | 416 Range Not Satisfiable 10.5.17
| 418 | (Unused) | Section 10.5.19 | 417 Expectation Failed 10.5.18
| 422 | Unprocessable Payload | Section 10.5.20 | 418 (Unused) 10.5.19
| 426 | Upgrade Required | Section 10.5.21 | 422 Unprocessable Payload 10.5.20
| 500 | Internal Server Error | Section 10.6.1 | 426 Upgrade Required 10.5.21
| 501 | Not Implemented | Section 10.6.2 | 500 Internal Server Error 10.6.1
| 502 | Bad Gateway | Section 10.6.3 | 501 Not Implemented 10.6.2
| 503 | Service Unavailable | Section 10.6.4 | 502 Bad Gateway 10.6.3
| 504 | Gateway Timeout | Section 10.6.5 | 503 Service Unavailable 10.6.4
| 505 | HTTP Version Not Supported | Section 10.6.6 | 504 Gateway Timeout 10.6.5
+-------+-------------------------------+-----------------+ 505 HTTP Version Not Supported 10.6.6
------- ------------------------------- ---------
Table 16 Table 18
Note that this list is not exhaustive - it does not include extension Note that this list is not exhaustive - it does not include extension
status codes defined in other specifications (Section 10.7). status codes defined in other specifications (Section 10.7).
10.2. Informational 1xx 10.2. Informational 1xx
The 1xx (Informational) class of status code indicates an interim The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. 1xx responses are terminated by the end of the header response. 1xx responses are terminated by the end of the header
skipping to change at page 128, line 19 skipping to change at page 135, line 19
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
10.2.2. 101 Switching Protocols 10.2.2. 101 Switching Protocols
The 101 (Switching Protocols) status code indicates that the server The 101 (Switching Protocols) status code indicates that the server
understands and is willing to comply with the client's request, via understands and is willing to comply with the client's request, via
the Upgrade header field (Section 9.9 of [Messaging]), for a change the Upgrade header field (Section 6.7), for a change in the
in the application protocol being used on this connection. The application protocol being used on this connection. The server MUST
server MUST generate an Upgrade header field in the response that generate an Upgrade header field in the response that indicates which
indicates which protocol(s) will be switched to immediately after the protocol(s) will be switched to immediately after the empty line that
empty line that terminates the 101 response. terminates the 101 response.
It is assumed that the server will only agree to switch protocols It is assumed that the server will only agree to switch protocols
when it is advantageous to do so. For example, switching to a newer when it is advantageous to do so. For example, switching to a newer
version of HTTP might be advantageous over older versions, and version of HTTP might be advantageous over older versions, and
switching to a real-time, synchronous protocol might be advantageous switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features. when delivering resources that use such features.
10.3. Successful 2xx 10.3. Successful 2xx
The 2xx (Successful) class of status code indicates that the client's The 2xx (Successful) class of status code indicates that the client's
skipping to change at page 130, line 10 skipping to change at page 137, line 10
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
10.3.4. 203 Non-Authoritative Information 10.3.4. 203 Non-Authoritative Information
The 203 (Non-Authoritative Information) status code indicates that The 203 (Non-Authoritative Information) status code indicates that
the request was successful but the enclosed payload has been modified the request was successful but the enclosed payload 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 6.7.2). This status code allows the proxy to notify proxy (Section 6.6.2). 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).
The 203 response is similar to the Warning code of 214 Transformation The 203 response is similar to the Warning code of 214 Transformation
Applied (Section 5.5 of [Caching]), which has the advantage of being Applied (Section 5.5 of [Caching]), which has the advantage of being
applicable to responses with any status code. applicable to responses with any status code.
A 203 response is heuristically cacheable; i.e., unless otherwise A 203 response is heuristically cacheable; i.e., unless otherwise
skipping to change at page 131, line 38 skipping to change at page 138, line 38
The 206 (Partial Content) status code indicates that the server is The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation. transferring one or more parts of the selected representation.
When a 206 response is generated, the server MUST generate the When a 206 response is generated, the server MUST generate the
following header fields, in addition to those required in the following header fields, in addition to those required in the
subsections below, if the field would have been sent in a 200 (OK) subsections below, if the field would have been sent in a 200 (OK)
response to the same request: Date, Cache-Control, ETag, Expires, response to the same request: Date, Cache-Control, ETag, Expires,
Content-Location, and Vary. Content-Location, and Vary.
A Content-Length field present in a 206 response indicates the number
of octets in the body of this message, which is usually not the
complete length of the selected representation. Each Content-Range
field includes information about the selected representation's
complete length.
If a 206 is generated in response to a request with an If-Range If a 206 is generated in response to a request with an If-Range
header field, the sender SHOULD NOT generate other representation header field, the sender SHOULD NOT generate other representation
header fields beyond those required, because the client is understood header fields beyond those required, because the client is understood
to already have a prior response containing those header fields. to already have a prior response containing those header fields.
Otherwise, the sender MUST generate all of the representation header Otherwise, the sender MUST generate all of the representation header
fields that would have been sent in a 200 (OK) response to the same fields that would have been sent in a 200 (OK) response to the same
request. 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
skipping to change at page 135, line 9 skipping to change at page 141, line 50
following: an incomplete 200 (OK) response if the combined response following: an incomplete 200 (OK) response if the combined response
is a prefix of the representation, a single 206 (Partial Content) is a prefix of the representation, a single 206 (Partial Content)
response containing a multipart/byteranges body, or multiple 206 response containing a multipart/byteranges body, or multiple 206
(Partial Content) responses, each with one continuous range that is (Partial Content) responses, each with one continuous range that is
indicated by a Content-Range header field. indicated by a Content-Range header field.
10.4. Redirection 3xx 10.4. Redirection 3xx
The 3xx (Redirection) class of status code indicates that further The 3xx (Redirection) class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the action needs to be taken by the user agent in order to fulfill the
request. If a Location header field (Section 11.1.2) is provided, request. There are several types of redirects:
the user agent MAY automatically redirect its request to the URI
referenced by the Location field value, even if the specific status
code is not understood. Automatic redirection needs to be done with
care for methods not known to be safe, as defined in Section 8.2.1,
since the user might not wish to redirect an unsafe request.
There are several types of redirects:
1. Redirects that indicate the resource might be available at a 1. Redirects that indicate this resource might be available at a
different URI, as provided by the Location field, as in the different URI, as provided by the Location field, as in the
status codes 301 (Moved Permanently), 302 (Found), 307 (Temporary status codes 301 (Moved Permanently), 302 (Found), 307 (Temporary
Redirect), and 308 (Permanent Redirect). Redirect), and 308 (Permanent Redirect).
2. Redirection that offers a choice of matching resources, each 2. Redirection that offers a choice among matching resources capable
capable of representing the original target resource, as in the of representing this resource, as in the 300 (Multiple Choices)
300 (Multiple Choices) status code. status code.
3. Redirection to a different resource, identified by the Location 3. Redirection to a different resource, identified by the Location
field, that can represent an indirect response to the request, as field, that can represent an indirect response to the request, as
in the 303 (See Other) status code. in the 303 (See Other) status code.
4. Redirection to a previously cached result, as in the 304 (Not 4. Redirection to a previously stored result, as in the 304 (Not
Modified) status code. Modified) status code.
If a Location header field (Section 11.1.2) is provided, the user
agent MAY automatically redirect its request to the URI referenced by
the Location field value, even if the specific status code is not
understood. Automatic redirection needs to be done with care for
methods not known to be safe, as defined in Section 8.2.1, since the
user might not wish to redirect an unsafe request.
When automatically following a redirected request, the user agent
SHOULD resend the original request message with the following
modifications:
1. Replace the target URI with the URI referenced by the redirection
response's Location header field value after resolving it
relative to the original request's target URI.
2. Remove header fields that were automatically generated by the
implementation, replacing them with updated values as appropriate
to the new request. This includes:
1. Connection-specific header fields (see Section 6.8),
2. Header fields specific to the client's proxy configuration,
including (but not limited to) Proxy-Authorization,
3. Origin-specific header fields (if any), including (but not
limited to) Host,
4. Validating header fields that were added by the
implementation's cache (e.g., If-None-Match,
If-Modified-Since),
5. Resource-specific header fields, including (but not limited
to) Referer, Origin, Authorization, and Cookie.
3. Consider removing header fields that were not automatically
generated by the implementation (i.e., those present in the
request because they were added by the calling context) where
there are security implications; this includes but is not limited
to Authorization and Cookie.
4. Change the request method according to the redirecting status
code's semantics, if applicable.
5. If the request method has been changed to GET or HEAD, remove
content-specific header fields, including (but not limited to)
Content-Encoding, Content-Language, Content-Location,
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 | ([RFC1945], 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
skipping to change at page 146, line 35 skipping to change at page 154, line 35
the contained instructions. For example, this status code can be the contained instructions. For example, this status code can be
sent if an XML request payload contains well-formed (i.e., sent if an XML request payload contains well-formed (i.e.,
syntactically correct), but semantically erroneous XML instructions. syntactically correct), but semantically erroneous XML instructions.
10.5.21. 426 Upgrade Required 10.5.21. 426 Upgrade Required
The 426 (Upgrade Required) status code indicates that the server The 426 (Upgrade Required) status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 9.9 of response to indicate the required protocol(s) (Section 6.7).
[Messaging]).
Example: Example:
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
Connection: Upgrade Connection: Upgrade
Content-Length: 53 Content-Length: 53
Content-Type: text/plain Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
skipping to change at page 150, line 22 skipping to change at page 158, line 22
Although each response header field has a defined meaning, in Although each response header field has a defined meaning, in
general, the precise semantics might be further refined by the general, the precise semantics might be further refined by the
semantics of the request method and/or response status code. semantics of the request method and/or response status code.
11.1. Control Data 11.1. Control Data
Response header fields can supply control data that supplements the Response header fields can supply control data that supplements the
status code, directs caching, or instructs the client where to go status code, directs caching, or instructs the client where to go
next. next.
+---------------+--------------------------+ --------------- --------------------------
| Field Name | Defined in... | Field Name Ref.
| Age | Section 5.1 of [Caching] | --------------- --------------------------
| Cache-Control | Section 5.2 of [Caching] | Age Section 5.1 of [Caching]
| Expires | Section 5.3 of [Caching] | Cache-Control Section 5.2 of [Caching]
| Date | Section 11.1.1 | Expires Section 5.3 of [Caching]
| Location | Section 11.1.2 | Date 11.1.1
| Retry-After | Section 11.1.3 | Location 11.1.2
| Vary | Section 11.1.4 | Retry-After 11.1.3
| Warning | Section 5.5 of [Caching] | Vary 11.1.4
+---------------+--------------------------+ Warning Section 5.5 of [Caching]
--------------- --------------------------
Table 17 Table 19
11.1.1. Date 11.1.1. Date
The "Date" header field represents the date and time at which the The "Date" header field represents the date and time at which the
message was originated, having the same semantics as the Origination message was originated, having the same semantics as the Origination
Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
field value is an HTTP-date, as defined in Section 5.4.1.5. field value is an HTTP-date, as defined in Section 5.4.1.5.
Date = HTTP-date Date = HTTP-date
skipping to change at page 152, line 38 skipping to change at page 160, line 38
fragment identifier. fragment identifier.
There are circumstances in which a fragment identifier in a Location There are circumstances in which a fragment identifier in a Location
value would not be appropriate. For example, the Location header value would not be appropriate. For example, the Location header
field in a 201 (Created) response is supposed to provide a URI that field in a 201 (Created) response is supposed to provide a URI that
is specific to the created resource. is specific to the created resource.
| *Note:* Some recipients attempt to recover from Location fields | *Note:* Some recipients attempt to recover from Location fields
| that are not valid URI references. This specification does not | that are not valid URI references. This specification does not
| mandate or define such processing, but does allow it for the | mandate or define such processing, but does allow it for the
| sake of robustness. | sake of robustness. A Location field value cannot allow a list
| of members because the comma list separator is a valid data
| character within a URI-reference. If an invalid message is
| sent with multiple Location field instances, a recipient along
| the path might combine the field instances into one value.
| Recovery of a valid Location field value from that situation is
| difficult and not interoperable across implementations.
| *Note:* The Content-Location header field (Section 7.2.5) | *Note:* The Content-Location header field (Section 7.2.5)
| differs from Location in that the Content-Location refers to | differs from Location in that the Content-Location refers to
| the most specific resource corresponding to the enclosed | the most specific resource corresponding to the enclosed
| representation. It is therefore possible for a response to | representation. It is therefore possible for a response to
| contain both the Location and Content-Location header fields. | contain both the Location and Content-Location header fields.
11.1.3. Retry-After 11.1.3. Retry-After
Servers send the "Retry-After" header field to indicate how long the Servers send the "Retry-After" header field to indicate how long the
skipping to change at page 153, line 35 skipping to change at page 161, line 35
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
11.1.4. Vary 11.1.4. Vary
The "Vary" header field in a response describes what parts of a The "Vary" header field in a response describes what parts of a
request message, aside from the method, Host header field, and target request message, aside from the method and target URI, might
URI, might influence the origin server's process for selecting and influence the origin server's process for selecting and representing
representing this response. this response.
Vary = 1#( "*" / field-name ) Vary = #( "*" / field-name )
A Vary field value is a list of request field names, known as the A Vary field value is a list of request field names, known as the
selecting header fields, that might have a role in selecting the selecting header fields, that might have a role in selecting the
representation for this response. Potential selecting header fields representation for this response. Potential selecting header fields
are not limited to those defined by this specification. are not limited to those defined by this specification.
If the list contains "*", it signals that other aspects of the If the list contains "*", it signals that other aspects of the
request might play a role in selecting the response representation, request might play a role in selecting the response representation,
possibly including elements outside the message syntax (e.g., the possibly including elements outside the message syntax (e.g., the
client's network address). A recipient will not be able to determine client's network address). A recipient will not be able to determine
skipping to change at page 155, line 10 skipping to change at page 163, line 10
In a successful response to a state-changing request, validator In a successful response to a state-changing request, validator
fields describe the new representation that has replaced the prior fields describe the new representation that has replaced the prior
selected representation as a result of processing the request. selected representation as a result of processing the request.
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 9.2. "lost update" problem Section 9.2.
+---------------+----------------+ --------------- --------
| Field Name | Defined in... | Field Name Ref.
| ETag | Section 11.2.3 | --------------- --------
| Last-Modified | Section 11.2.2 | ETag 11.2.3
+---------------+----------------+ Last-Modified 11.2.2
--------------- --------
Table 18 Table 20
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 11.2.2) and opaque entity tags modification dates (Section 11.2.2) and opaque entity tags
(Section 11.2.3). Additional metadata that reflects resource state (Section 11.2.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, [RFC4918]), that are
beyond the scope of this specification. A resource metadata value is beyond the scope of this specification. A resource metadata value is
referred to as a "validator" when it is used within a precondition. referred to as a "validator" when it is used within a precondition.
skipping to change at page 161, line 8 skipping to change at page 169, line 20
o Strong comparison: two entity-tags are equivalent if both are not o 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.
o Weak comparison: two entity-tags are equivalent if their opaque- o Weak comparison: two entity-tags are equivalent if their opaque-
tags match character-by-character, regardless of either or both tags match character-by-character, regardless of either or both
being tagged as "weak". being tagged as "weak".
The example below shows the results for a set of entity-tag pairs and The example below shows the results for a set of entity-tag pairs and
both the weak and strong comparison function results: both the weak and strong comparison function results:
+--------+--------+-------------------+-----------------+ -------- -------- ------------------- -----------------
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | ETag 1 ETag 2 Strong Comparison Weak Comparison
| W/"1" | W/"1" | no match | match | -------- -------- ------------------- -----------------
| W/"1" | W/"2" | no match | no match | W/"1" W/"1" no match match
| W/"1" | "1" | no match | match | W/"1" W/"2" no match no match
| "1" | "1" | match | match | W/"1" "1" no match match
+--------+--------+-------------------+-----------------+ "1" "1" match match
-------- -------- ------------------- -----------------
Table 19 Table 21
11.2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources 11.2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources
Consider a resource that is subject to content negotiation Consider a resource that is subject to content negotiation
(Section 7.4), and where the representations sent in response to a (Section 7.4), and where the representations sent in response to a
GET request vary based on the Accept-Encoding request header field GET request vary based on the Accept-Encoding request header field
(Section 9.4.3): (Section 9.4.3):
>> Request: >> Request:
skipping to change at page 163, line 20 skipping to change at page 171, line 34
o SHOULD send both validators in cache validation requests if both o SHOULD send both validators in cache validation requests if both
an entity-tag and a Last-Modified value have been provided by the an entity-tag and a Last-Modified value have been provided by the
origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
respond appropriately. respond appropriately.
11.3. Authentication Challenges 11.3. Authentication Challenges
Authentication challenges indicate what mechanisms are available for Authentication challenges indicate what mechanisms are available for
the client to provide authentication credentials in future requests. the client to provide authentication credentials in future requests.
+--------------------+----------------+ -------------------- --------
| Field Name | Defined in... | Field Name Ref.
| WWW-Authenticate | Section 11.3.1 | -------------------- --------
| Proxy-Authenticate | Section 11.3.2 | WWW-Authenticate 11.3.1
+--------------------+----------------+ Proxy-Authenticate 11.3.2
-------------------- --------
Table 20 Table 22
Furthermore, the "Authentication-Info" and "Proxy-Authentication- Furthermore, the "Authentication-Info" and "Proxy-Authentication-
Info" response header fields are defined for use in authentication Info" response header fields are defined for use in authentication
schemes that need to return information once the client's schemes that need to return information once the client's
authentication credentials have been accepted. authentication credentials have been accepted.
+---------------------------+----------------+ --------------------------- --------
| Field Name | Defined in... | Field Name Ref.
| Authentication-Info | Section 11.3.3 | --------------------------- --------
| Proxy-Authentication-Info | Section 11.3.4 | Authentication-Info 11.3.3
+---------------------------+----------------+ Proxy-Authentication-Info 11.3.4
--------------------------- --------
Table 21 Table 23
11.3.1. WWW-Authenticate 11.3.1. WWW-Authenticate
The "WWW-Authenticate" header field indicates the authentication The "WWW-Authenticate" header field indicates the authentication
scheme(s) and parameters applicable to the target resource. scheme(s) and parameters applicable to the target resource.
WWW-Authenticate = 1#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
fields in that response. fields in that response.
skipping to change at page 164, line 24 skipping to change at page 172, line 46
For instance: For instance:
WWW-Authenticate: Newauth realm="apps", type=1, WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple" title="Login to \"apps\"", Basic realm="simple"
This header field contains two challenges; one for the "Newauth" This header field contains two challenges; one for the "Newauth"
scheme with a realm value of "apps", and two additional parameters scheme with a realm value of "apps", and two additional parameters
"type" and "title", and another one for the "Basic" scheme with a "type" and "title", and another one for the "Basic" scheme with a
realm value of "simple". realm value of "simple".
Some user agents do not recognise this form, however. As a result,
sending a WWW-Authenticate field value with more than one member on
the same field line might not be interoperable.
| *Note:* The challenge grammar production uses the list syntax | *Note:* The challenge grammar production uses the list syntax
| as well. Therefore, a sequence of comma, whitespace, and comma | as well. Therefore, a sequence of comma, whitespace, and comma
| can be considered either as applying to the preceding | can be considered either as applying to the preceding
| challenge, or to be an empty entry in the list of challenges. | challenge, or to be an empty entry in the list of challenges.
| In practice, this ambiguity does not affect the semantics of | In practice, this ambiguity does not affect the semantics of
| the header field value and thus is harmless. | the header field value and thus is harmless.
11.3.2. Proxy-Authenticate 11.3.2. Proxy-Authenticate
The "Proxy-Authenticate" header field consists of at least one The "Proxy-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameters challenge that indicates the authentication scheme(s) and parameters
applicable to the proxy for this request. A proxy MUST send at least applicable to the proxy for this request. A proxy MUST send at least
one Proxy-Authenticate header field in each 407 (Proxy Authentication one Proxy-Authenticate header field in each 407 (Proxy Authentication
Required) response that it generates. Required) response that it generates.
Proxy-Authenticate = 1#challenge Proxy-Authenticate = #challenge
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the next outbound client on the response chain. This is only to the next outbound client on the response chain. This is
because only the client that chose a given proxy is likely to have because only the client that chose a given proxy is likely to have
the credentials necessary for authentication. However, when multiple the credentials necessary for authentication. However, when multiple
proxies are used within the same administrative domain, such as proxies are used within the same administrative domain, such as
office and regional caching proxies within a large corporate network, office and regional caching proxies within a large corporate network,
it is common for credentials to be generated by the user agent and it is common for credentials to be generated by the user agent and
passed through the hierarchy until consumed. Hence, in such a passed through the hierarchy until consumed. Hence, in such a
configuration, it will appear as if Proxy-Authenticate is being configuration, it will appear as if Proxy-Authenticate is being
skipping to change at page 165, line 34 skipping to change at page 174, line 14
The Authentication-Info header field can be used in any HTTP The Authentication-Info header field can be used in any HTTP
response, independently of request method and status code. Its response, independently of request method and status code. Its
semantics are defined by the authentication scheme indicated by the semantics are defined by the authentication scheme indicated by the
Authorization header field (Section 9.5.3) of the corresponding Authorization header field (Section 9.5.3) of the corresponding
request. request.
A proxy forwarding a response is not allowed to modify the field A proxy forwarding a response is not allowed to modify the field
value in any way. value in any way.
Authentication-Info can be used inside trailers (Section 5.6) when Authentication-Info can be sent as a trailer field (Section 5.6) when
the authentication scheme explicitly allows this. the authentication scheme explicitly allows this.
11.3.3.1. Parameter Value Format 11.3.3.1. Parameter Value Format
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.4.1). string" (Section 5.4.1).
Authentication scheme definitions need to allow both notations, both Authentication scheme definitions need to allow both notations, both
for senders and recipients. This allows recipients to use generic for senders and recipients. This allows recipients to use generic
parsing components, independent of the authentication scheme in use. parsing components, independent of the authentication scheme in use.
skipping to change at page 166, line 32 skipping to change at page 175, line 10
generated by the user agent and passed through the hierarchy until generated by the user agent and passed through the hierarchy until
consumed. Hence, in such a configuration, it will appear as if consumed. Hence, in such a configuration, it will appear as if
Proxy-Authentication-Info is being forwarded because each proxy will Proxy-Authentication-Info is being forwarded because each proxy will
send the same field value. send the same field value.
11.4. Response Context 11.4. Response Context
The remaining response header fields provide more information about The remaining response header fields provide more information about
the target resource for potential use in later requests. the target resource for potential use in later requests.
+---------------+----------------+ --------------- --------
| Field Name | Defined in... | Field Name Ref.
| Accept-Ranges | Section 11.4.1 | --------------- --------
| Allow | Section 11.4.2 | Accept-Ranges 11.4.1
| Server | Section 11.4.3 | Allow 11.4.2
+---------------+----------------+ Server 11.4.3
--------------- --------
Table 22 Table 24
11.4.1. Accept-Ranges 11.4.1. Accept-Ranges
The "Accept-Ranges" header field allows a server to indicate that it The "Accept-Ranges" header field allows a server to indicate that it
supports range requests for the target resource. 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 / "none"
An origin server that supports byte-range requests for a given target An origin server that supports byte-range requests for a given target
skipping to change at page 169, line 16 skipping to change at page 177, line 46
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.
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 2.5.2) is intended to prevent (or at The "https" scheme (Section 2.5.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 TLS connection is secured and authority, provided that the negotiated connection is secured and the
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 6.4.3.1). matches the target URI's authority component (Section 6.3.3.3).
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 extensions; for example, [RFC7838]. Likewise, the set of servers
that a connection is considered authoritative for can be changed with that a connection is considered authoritative for can be changed with
a protocol extension like [RFC8336]. a 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
skipping to change at page 169, line 45 skipping to change at page 178, line 28
branding in hypertext, possibly aided by userinfo obfuscating the branding in hypertext, possibly aided by userinfo obfuscating the
authority component (see Section 2.5.1). User agents can reduce the authority component (see Section 2.5.1). User agents can reduce the
impact of phishing attacks by enabling users to easily inspect a impact of phishing attacks by enabling users to easily inspect a
target URI prior to making an action, by prominently distinguishing target URI prior to making an action, by prominently distinguishing
(or rejecting) userinfo when present, and by not sending stored (or rejecting) userinfo when present, and by not sending stored
credentials and cookies when the referring document is from an credentials and cookies when the referring document is from an
unknown or untrusted source. unknown or untrusted source.
12.2. Risks of Intermediaries 12.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle and, HTTP intermediaries are inherently situated for on-path attacks.
thus, represent an opportunity for man-in-the-middle attacks.
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
skipping to change at page 171, line 44 skipping to change at page 180, line 25
included within a data format that allows embedded scripts. included within a data format that allows embedded scripts.
12.5. Attacks via Protocol Element Length 12.5. Attacks via Protocol Element Length
Because HTTP uses mostly textual, character-delimited fields, parsers Because HTTP uses mostly textual, character-delimited fields, parsers
are often vulnerable to attacks based on sending very long (or very are often vulnerable to attacks based on sending very long (or very
slow) streams of data, particularly where an implementation is slow) streams of data, particularly where an implementation is
expecting a protocol element with no predefined length (Section 3.3). expecting a protocol element with no predefined length (Section 3.3).
To promote interoperability, specific recommendations are made for To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3 of [Messaging]) and minimum size limits on fields (Section 5.2). These are minimum
fields (Section 5). These are minimum recommendations, chosen to be recommendations, chosen to be supportable even by implementations
supportable even by implementations with limited resources; it is with limited resources; it is expected that most implementations will
expected that most implementations will choose substantially higher choose substantially higher limits.
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 10.5.15) or a request payload that is too large (Section 10.5.15) or a request payload that is too large
(Section 10.5.14). Additional status codes related to capacity (Section 10.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
body chunks. Failure to limit such processing can result in buffer body chunks. Failure to limit such processing can result in buffer
overflows, arithmetic overflows, or increased vulnerability to overflows, arithmetic overflows, or increased vulnerability to
denial-of-service attacks. denial-of-service attacks.
12.6. Disclosure of Personal Information 12.6. Attacks using Shared-dictionary Compression
Some attacks on encrypted protocols use the differences in size
created by dynamic compression to reveal confidential information;
for example, [BREACH]. These attacks rely on creating a redundancy
between attacker-controlled content and the confidential information,
such that a dynamic compression algorithm using the same dictionary
for both content will compress more efficiently when the attacker-
controlled content matches parts of the confidential content.
HTTP messages can be compressed in a number of ways, including using
TLS compression, content-codings, transfer-codings, and other
extension or version-specific mechanisms.
The most effective mitigation for this risk is to disable compression
on sensitive data, or to strictly separate sensitive data from
attacker-controlled data so that they cannot share the same
compression dictionary. With careful design, a compression scheme
can be designed in a way that is not considered exploitable in
limited use cases, such as HPACK ([RFC7541]).
12.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.
12.7. Privacy of Server Log Information 12.8. Privacy of Server Log Information
A server is in the position to save personal data about a user's A server is in the position to save personal data about a user's
requests over time, which might identify their reading patterns or requests over time, which might identify their reading patterns or
subjects of interest. In particular, log information gathered at an subjects of interest. In particular, log information gathered at an
intermediary often contains a history of user agent interaction, intermediary often contains a history of user agent interaction,
across a multitude of sites, that can be traced to individual users. across a multitude of sites, that can be traced to individual users.
HTTP log information is confidential in nature; its handling is often HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis. securely stored and appropriate guidelines followed for its analysis.
skipping to change at page 173, line 5 skipping to change at page 182, line 5
characteristics. As such, access traces that are keyed to a specific characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous. client are unsafe to publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log To minimize the risk of theft or accidental publication, log
information ought to be purged of personally identifiable information ought to be purged of personally identifiable
information, including user identifiers, IP addresses, and user- information, including user identifiers, IP addresses, and user-
provided query parameters, as soon as that information is no longer provided query parameters, as soon as that information is no longer
necessary to support operational needs for security, auditing, or necessary to support operational needs for security, auditing, or
fraud control. fraud control.
12.8. Disclosure of Sensitive Information in URIs 12.9. Disclosure of Sensitive Information in URIs
URIs are intended to be shared, not secured, even when they identify URIs are intended to be shared, not secured, even when they identify
secure resources. URIs are often shown on displays, added to secure resources. URIs are often shown on displays, added to
templates when a page is printed, and stored in a variety of templates when a page is printed, and stored in a variety of
unprotected bookmark lists. It is therefore unwise to include unprotected bookmark lists. Many servers, proxies, and user agents
information within a URI that is sensitive, personally identifiable, log or display the target URI in places where it might be visible to
or a risk to disclose. third parties. It is therefore unwise to include information within
a URI that is sensitive, personally identifiable, or a risk to
disclose.
Authors of services ought to avoid GET-based forms for the submission When an application uses client-side mechanisms to construct a target
of sensitive data because that data will be placed in the target URI. URI out of user-provided information, such as the query fields of a
Many existing servers, proxies, and user agents log or display the form using GET, potentially sensitive data might be provided that
target URI in places where it might be visible to third parties. would not be appropriate for disclosure within a URI. POST is often
Such services ought to use POST-based form submission instead. preferred in such cases because it usually doesn't construct a URI;
instead, POST of a form transmits the potentially sensitive data in
the request body. However, this hinders caching and uses an unsafe
method for what would otherwise be a safe request. Alternative
workarounds include transforming the user-provided data prior to
constructing the URI, or filtering the data to only include common
values that are not sensitive. Likewise, redirecting the result of a
query to a different (server-generated) URI can remove potentially
sensitive data from later links and provide a cacheable response for
later reuse.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in URI. Limitations on the Referer header field are described in
Section 9.6.2 to address some of its security considerations. Section 9.6.2 to address some of its security considerations.
12.9. Disclosure of Fragment after Redirects 12.10. Disclosure of Fragment after Redirects
Although fragment identifiers used within URI references are not sent Although fragment identifiers used within URI references are not sent
in requests, implementers ought to be aware that they will be visible in requests, implementers ought to be aware that they will be visible
to the user agent and any extensions or scripts running as a result to the user agent and any extensions or scripts running as a result
of the response. In particular, when a redirect occurs and the of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new original request's fragment identifier is inherited by the new
reference in Location (Section 11.1.2), this might have the effect of reference in Location (Section 11.1.2), this might have the effect of
disclosing one site's fragment to another site. If the first site disclosing one site's fragment to another site. If the first site
uses personal information in fragments, it ought to ensure that uses personal information in fragments, it ought to ensure that
redirects to other sites include a (possibly empty) fragment redirects to other sites include a (possibly empty) fragment
component in order to block that inheritance. component in order to block that inheritance.
12.10. Disclosure of Product Information 12.11. Disclosure of Product Information
The User-Agent (Section 9.6.3), Via (Section 6.7.1), and Server The User-Agent (Section 9.6.3), Via (Section 6.6.1), and Server
(Section 11.4.3) header fields often reveal information about the (Section 11.4.3) header fields often reveal information about the
respective sender's software systems. In theory, this can make it respective sender's software systems. In theory, this can make it
easier for an attacker to exploit known security holes; in practice, easier for an attacker to exploit known security holes; in practice,
attackers tend to try all potential holes regardless of the apparent attackers tend to try all potential holes regardless of the apparent
software versions being used. software versions being used.
Proxies that serve as a portal through a network firewall ought to Proxies that serve as a portal through a network firewall ought to
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.
12.11. Browser Fingerprinting 12.12. 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 its TCP behavior, feature capabilities, and scripting
environment, though of particular interest here is the set of unique environment, though of particular interest here is the set of unique
characteristics that might be communicated via HTTP. Fingerprinting characteristics that might be communicated via HTTP. Fingerprinting
is considered a privacy concern because it enables tracking of a user is considered a privacy concern because it enables tracking of a user
agent's behavior over time ([Bujlow]) without the corresponding agent's behavior over time ([Bujlow]) without the corresponding
controls that the user might have over other forms of data collection controls that the user might have over other forms of data collection
skipping to change at page 175, line 13 skipping to change at page 184, line 23
language negotiation might be useful. language negotiation might be useful.
In environments where proxies are used to enhance privacy, user In environments where proxies are used to enhance privacy, user
agents ought to be conservative in sending proactive negotiation agents ought to be conservative in sending proactive negotiation
header fields. General-purpose user agents that provide a high header fields. General-purpose user agents that provide a high
degree of header field configurability ought to inform users about degree of header field configurability ought to inform users about
the loss of privacy that might result if too much detail is provided. the loss of privacy that might result if too much detail is provided.
As an extreme privacy measure, proxies could filter the proactive As an extreme privacy measure, proxies could filter the proactive
negotiation header fields in relayed requests. negotiation header fields in relayed requests.
12.12. Validator Retention 12.13. Validator Retention
The validators defined by this specification are not intended to The validators defined by this specification are not intended to
ensure the validity of a representation, guard against malicious ensure the validity of a representation, guard against malicious
changes, or detect man-in-the-middle attacks. At best, they enable changes, or detect on-path attacks. At best, they enable more
more efficient cache updates and optimistic concurrent writes when efficient cache updates and optimistic concurrent writes when all
all participants are behaving nicely. At worst, the conditions will participants are behaving nicely. At worst, the conditions will fail
fail and the client will receive a response that is no more harmful and the client will receive a response that is no more harmful than
than an HTTP exchange without conditional requests. an HTTP exchange without conditional requests.
An entity-tag can be abused in ways that create privacy risks. For An entity-tag can be abused in ways that create privacy risks. For
example, a site might deliberately construct a semantically invalid example, a site might deliberately construct a semantically invalid
entity-tag that is unique to the user or user agent, send it in a entity-tag that is unique to the user or user agent, send it in a
cacheable response with a long freshness time, and then read that cacheable response with a long freshness time, and then read that
entity-tag in later conditional requests as a means of re-identifying entity-tag in later conditional requests as a means of re-identifying
that user or user agent. Such an identifying tag would become a that user or user agent. Such an identifying tag would become a
persistent identifier for as long as the user agent retained the persistent identifier for as long as the user agent retained the
original cache entry. User agents that cache representations ought original cache entry. User agents that cache representations ought
to ensure that the cache is cleared or replaced whenever the user to ensure that the cache is cleared or replaced whenever the user
performs privacy-maintaining actions, such as clearing stored cookies performs privacy-maintaining actions, such as clearing stored cookies
or changing to a private browsing mode. or changing to a private browsing mode.
12.13. Denial-of-Service Attacks Using Range 12.14. Denial-of-Service Attacks Using Range
Unconstrained multiple range requests are susceptible to denial-of- Unconstrained multiple range requests are susceptible to denial-of-
service attacks because the effort required to request many service attacks because the effort required to request many
overlapping ranges of the same data is tiny compared to the time, overlapping ranges of the same data is tiny compared to the time,
memory, and bandwidth consumed by attempting to serve the requested memory, and bandwidth consumed by attempting to serve the requested
data in many parts. Servers ought to ignore, coalesce, or reject data in many parts. Servers ought to ignore, coalesce, or reject
egregious range requests, such as requests for more than two egregious range requests, such as requests for more than two
overlapping ranges or for many small ranges in a single set, overlapping ranges or for many small ranges in a single set,
particularly when the ranges are requested out of order for no particularly when the ranges are requested out of order for no
apparent reason. Multipart range requests are not designed to apparent reason. Multipart range requests are not designed to
support random access. support random access.
12.14. Authentication Considerations 12.15. Authentication Considerations
Everything about the topic of HTTP authentication is a security Everything about the topic of HTTP authentication is a security
consideration, so the list of considerations below is not exhaustive. consideration, so the list of considerations below is not exhaustive.
Furthermore, it is limited to security considerations regarding the Furthermore, it is limited to security considerations regarding the
authentication framework, in general, rather than discussing all of authentication framework, in general, rather than discussing all of
the potential considerations for specific authentication schemes the potential considerations for specific authentication schemes
(which ought to be documented in the specifications that define those (which ought to be documented in the specifications that define those
schemes). Various organizations maintain topical information and schemes). Various organizations maintain topical information and
links to current research on Web application security (e.g., links to current research on Web application security (e.g.,
[OWASP]), including common pitfalls for implementing and using the [OWASP]), including common pitfalls for implementing and using the
authentication schemes found in practice. authentication schemes found in practice.
12.14.1. Confidentiality of Credentials 12.15.1. Confidentiality of Credentials
The HTTP authentication framework does not define a single mechanism The HTTP authentication framework does not define a single mechanism
for maintaining the confidentiality of credentials; instead, each for maintaining the confidentiality of credentials; instead, each
authentication scheme defines how the credentials are encoded prior authentication scheme defines how the credentials are encoded prior
to transmission. While this provides flexibility for the development to transmission. While this provides flexibility for the development
of future authentication schemes, it is inadequate for the protection of future authentication schemes, it is inadequate for the protection
of existing schemes that provide no confidentiality on their own, or of existing schemes that provide no confidentiality on their own, or
that do not sufficiently protect against replay attacks. that do not sufficiently protect against replay attacks.
Furthermore, if the server expects credentials that are specific to Furthermore, if the server expects credentials that are specific to
each individual user, the exchange of those credentials will have the each individual user, the exchange of those credentials will have the
skipping to change at page 176, line 42 skipping to change at page 186, line 5
HTTP depends on the security properties of the underlying transport- HTTP depends on the security properties of the underlying transport-
or session-level connection to provide confidential transmission of or session-level connection to provide confidential transmission of
fields. In other words, if a server limits access to authenticated fields. In other words, if a server limits access to authenticated
users using this framework, the server needs to ensure that the users using this framework, the server needs to ensure that the
connection is properly secured in accordance with the nature of the connection is properly secured in accordance with the nature of the
authentication scheme used. For example, services that depend on authentication scheme used. For example, services that depend on
individual user authentication often require a connection to be individual user authentication often require a connection to be
secured with TLS ("Transport Layer Security", [RFC8446]) prior to secured with TLS ("Transport Layer Security", [RFC8446]) prior to
exchanging any credentials. exchanging any credentials.
12.14.2. Credentials and Idle Clients 12.15.2. Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP does not provide a mechanism for the information indefinitely. HTTP does not provide a mechanism for the
origin server to direct clients to discard these cached credentials, origin server to direct clients to discard these cached credentials,
since the protocol has no awareness of how credentials are obtained since the protocol has no awareness of how credentials are obtained
or managed by the user agent. The mechanisms for expiring or or managed by the user agent. The mechanisms for expiring or
revoking credentials can be specified as part of an authentication revoking credentials can be specified as part of an authentication
scheme definition. scheme definition.
Circumstances under which credential caching can interfere with the Circumstances under which credential caching can interfere with the
skipping to change at page 177, line 21 skipping to change at page 186, line 31
o Applications that include a session termination indication (such o Applications that include a session termination indication (such
as a "logout" or "commit" button on a page) after which the server as a "logout" or "commit" button on a page) after which the server
side of the application "knows" that there is no further reason side of the application "knows" that there is no further reason
for the client to retain the credentials. for the client to retain the credentials.
User agents that cache credentials are encouraged to provide a User agents that cache credentials are encouraged to provide a
readily accessible mechanism for discarding cached credentials under readily accessible mechanism for discarding cached credentials under
user control. user control.
12.14.3. Protection Spaces 12.15.3. Protection Spaces
Authentication schemes that solely rely on the "realm" mechanism for Authentication schemes that solely rely on the "realm" mechanism for
establishing a protection space will expose credentials to all establishing a protection space will expose credentials to all
resources on an origin server. Clients that have successfully made resources on an origin server. Clients that have successfully made
authenticated requests with a resource can use the same authenticated requests with a resource can use the same
authentication credentials for other resources on the same origin authentication credentials for other resources on the same origin
server. This makes it possible for a different resource to harvest server. This makes it possible for a different resource to harvest
authentication credentials for other resources. authentication credentials for other resources.
This is of particular concern when an origin server hosts resources This is of particular concern when an origin server hosts resources
for multiple parties under the same canonical root URI for multiple parties under the same canonical root URI
(Section 9.5.2). Possible mitigation strategies include restricting (Section 9.5.2). Possible mitigation strategies include restricting
direct access to authentication credentials (i.e., not making the direct access to authentication credentials (i.e., not making the
content of the Authorization request header field available), and content of the Authorization request header field available), and
separating protection spaces by using a different host name (or port separating protection spaces by using a different host name (or port
number) for each party. number) for each party.
12.14.4. Additional Response Fields 12.15.4. Additional Response Fields
Adding information to responses that are sent over an unencrypted Adding information to responses that are sent over an unencrypted
channel can affect security and privacy. The presence of the channel can affect security and privacy. The presence of the
Authentication-Info and Proxy-Authentication-Info header fields alone Authentication-Info and Proxy-Authentication-Info header fields alone
indicates that HTTP authentication is in use. Additional information indicates that HTTP authentication is in use. Additional information
could be exposed by the contents of the authentication-scheme could be exposed by the contents of the authentication-scheme
specific parameters; this will have to be considered in the specific parameters; this will have to be considered in the
definitions of these schemes. definitions of these schemes.
13. IANA Considerations 13. IANA Considerations
skipping to change at page 180, line 37 skipping to change at page 189, line 51
2. when currently unspecified, set "Assignee" to "IESG" and 2. when currently unspecified, set "Assignee" to "IESG" and
"Contact" to "IETF_Chair". "Contact" to "IETF_Chair".
14. References 14. References
14.1. Normative References 14.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP Caching", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cache-10, July 12, 2020, draft-ietf-httpbis-cache-11, August 27, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-10>. <https://tools.ietf.org/html/draft-ietf-httpbis-cache-11>.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP/1.1 Messaging", Work in Progress, Internet- Ed., "HTTP/1.1 Messaging", Work in Progress, Internet-
Draft, draft-ietf-httpbis-messaging-10, July 12, 2020, Draft, draft-ietf-httpbis-messaging-11, August 27, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging- <https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
10>. 11>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L.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>.
skipping to change at page 182, line 5 skipping to change at page 191, line 14
[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,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>. <https://www.rfc-editor.org/info/rfc6365>.
[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
skipping to change at page 183, line 5 skipping to change at page 192, line 15
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012, Application Protocols", BCP 178, RFC 6648, June 2012,
<https://www.rfc-editor.org/info/bcp178>. <https://www.rfc-editor.org/info/bcp178>.
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, June 2015, RFC 7595, June 2015,
<https://www.rfc-editor.org/info/bcp35>. <https://www.rfc-editor.org/info/bcp35>.
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", July 2013,
<http://breachattack.com/resources/
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>.
[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>.
skipping to change at page 183, line 26 skipping to change at page 192, line 41
<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", DOI 10.1145/2382196.2382204, In Proceedings of
the 2012 ACM Conference on Computer and Communications the 2012 ACM Conference on Computer and Communications
Security (CCS '12), pp. 38-49, October 2012, Security (CCS '12), pp. 38-49, October 2012,
<https://doi.org/10.1145/2382196.2382204>. <https://doi.org/10.1145/2382196.2382204>.
[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-29, June 9, 2020,
<https://tools.ietf.org/html/draft-ietf-quic-http-29>.
[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>.
skipping to change at page 185, line 46 skipping to change at page 195, line 18
[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>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[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,
skipping to change at page 186, line 33 skipping to change at page 195, line 46
Transfer Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
RFC 7231, DOI 10.17487/RFC7231, June 2014, RFC 7231, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
RFC 7232, DOI 10.17487/RFC7232, June 2014, RFC 7232, DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>. <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>. <https://www.rfc-editor.org/info/rfc7233>.
[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 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[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 188, line 19 skipping to change at page 197, line 41
[Sniffing] WHATWG, "MIME Sniffing", [Sniffing] WHATWG, "MIME Sniffing",
<https://mimesniff.spec.whatwg.org>. <https://mimesniff.spec.whatwg.org>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 5.5.1. Section 5.5.1.
Accept = [ ( media-range [ accept-params ] ) *( OWS "," OWS ( Accept = [ ( media-range [ accept-params ] ) *( OWS "," OWS (
media-range [ accept-params ] ) ) ] media-range [ accept-params ] ) ) ]
Accept-Charset = ( ( charset / "*" ) [ weight ] ) *( OWS "," OWS ( ( Accept-Charset = [ ( ( charset / "*" ) [ weight ] ) *( OWS "," OWS (
charset / "*" ) [ weight ] ) ) ( charset / "*" ) [ weight ] ) ) ]
Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [ Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [
weight ] ) ) ] weight ] ) ) ]
Accept-Language = ( language-range [ weight ] ) *( OWS "," OWS ( Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS (
language-range [ weight ] ) ) language-range [ weight ] ) ) ]
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
Allow = [ method *( OWS "," OWS method ) ] Allow = [ method *( OWS "," OWS method ) ]
Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ] Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ]
Authorization = credentials Authorization = credentials
BWS = OWS BWS = OWS
Connection = [ connection-option *( OWS "," OWS connection-option )
Content-Encoding = content-coding *( OWS "," OWS content-coding ) ]
Content-Language = language-tag *( OWS "," OWS language-tag ) Content-Encoding = [ content-coding *( OWS "," OWS content-coding )
]
Content-Language = [ language-tag *( OWS "," OWS language-tag ) ]
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
Content-Range = range-unit SP ( range-resp / unsatisfied-range ) Content-Range = range-unit SP ( range-resp / unsatisfied-range )
Content-Type = media-type Content-Type = media-type
Date = HTTP-date Date = HTTP-date
ETag = entity-tag ETag = entity-tag
Expect = "100-continue" Expect = [ expectation *( OWS "," OWS expectation ) ]
From = mailbox From = mailbox
GMT = %x47.4D.54 ; GMT GMT = %x47.4D.54 ; GMT
HTTP-date = IMF-fixdate / obs-date HTTP-date = IMF-fixdate / obs-date
Host = uri-host [ ":" port ] Host = uri-host [ ":" port ]
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
If-Match = "*" / ( entity-tag *( OWS "," OWS entity-tag ) ) If-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ]
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
If-None-Match = "*" / ( entity-tag *( OWS "," OWS entity-tag ) ) If-None-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ]
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date Last-Modified = HTTP-date
Location = URI-reference Location = URI-reference
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
Proxy-Authenticate = challenge *( OWS "," OWS challenge ) Proxy-Authenticate = [ challenge *( OWS "," OWS challenge ) ]
Proxy-Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) Proxy-Authentication-Info = [ auth-param *( OWS "," OWS auth-param )
] ]
Proxy-Authorization = credentials Proxy-Authorization = credentials
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 ) ]
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 [RFC3986], Section 4.1>
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 ]
"," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS
"," 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 [RFC3986], Section 4.3>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext accept-params = weight *accept-ext
acceptable-ranges = ( range-unit *( OWS "," OWS range-unit ) ) / acceptable-ranges = ( range-unit *( OWS "," OWS range-unit ) ) /
"none" "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
skipping to change at page 190, line 4 skipping to change at page 199, line 31
accept-params = weight *accept-ext accept-params = weight *accept-ext
acceptable-ranges = ( range-unit *( OWS "," OWS range-unit ) ) / acceptable-ranges = ( range-unit *( OWS "," OWS range-unit ) ) /
"none" "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 [RFC3986], 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 ) ] ) ]
charset = token charset = token
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
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 ; ']'-'~'
/ obs-text / obs-text
date1 = day SP month SP year date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
skipping to change at page 190, line 40 skipping to change at page 200, line 19
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday / %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday / %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday / %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday / %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT delay-seconds = 1*DIGIT
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
expectation = token [ "=" ( token / quoted-string ) parameters ]
field-content = field-vchar [ 1*( SP / HTAB / field-vchar ) field-content = field-vchar [ 1*( SP / HTAB / field-vchar )
field-vchar ] field-vchar ]
field-name = token field-name = token
field-value = *field-content field-value = *field-content
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
first-pos = 1*DIGIT first-pos = 1*DIGIT
hour = 2DIGIT hour = 2DIGIT
http-URI = "http://" authority path-abempty [ "?" query ] http-URI = "http://" authority path-abempty [ "?" query ]
https-URI = "https://" authority path-abempty [ "?" query ] https-URI = "https://" authority path-abempty [ "?" query ]
incl-range = first-pos "-" last-pos incl-range = first-pos "-" last-pos
int-range = first-pos "-" [ last-pos ] int-range = first-pos "-" [ last-pos ]
language-range = <language-range, see [RFC4647], Section 2.1> language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
last-pos = 1*DIGIT last-pos = 1*DIGIT
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) )
";" OWS parameter ) parameters
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype parameters
method = token method = token
minute = 2DIGIT minute = 2DIGIT
month = %x4A.61.6E ; Jan month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb / %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar / %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr / %x41.70.72 ; Apr
/ %x4D.61.79 ; May / %x4D.61.79 ; May
/ %x4A.75.6E ; Jun / %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul / %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug / %x41.75.67 ; Aug
skipping to change at page 191, line 39 skipping to change at page 201, line 20
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
obs-text = %x80-FF obs-text = %x80-FF
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 ] )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol-name = <protocol-name, see [Messaging], Section 9.9> protocol = protocol-name [ "/" protocol-version ]
protocol-version = <protocol-version, see [Messaging], Section 9.9> protocol-name = 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 [RFC3986], 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
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
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 [RFC3986], 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 [RFC3986], 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 [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
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 = <transfer-coding, see [Messaging], Section 7>
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 [RFC3986], 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
skipping to change at page 193, line 5 skipping to change at page 202, line 39
B.1. Changes from RFC 2818 B.1. Changes from RFC 2818
None yet. None yet.
B.2. Changes from RFC 7230 B.2. Changes from RFC 7230
The sections introducing HTTP's design goals, history, architecture, The sections introducing HTTP's design goals, history, architecture,
conformance criteria, protocol versioning, URIs, message routing, and conformance criteria, protocol versioning, URIs, message routing, and
header fields have been moved here (without substantive change). header fields have been moved here (without substantive change).
The description of an origin and authoritative access to origin
servers has been extended for both "http" and "https" URIs to account
for alternative services and secured connections that are not
necessarily based on TCP. (Section 2.5.1, Section 2.5.2,
Section 6.2, Section 6.3.3)
"Field value" now refers to the value after multiple instances are "Field value" now refers to the value after multiple instances 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 5) single header line's value, use "field line value". (Section 5)
Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons. (Section 5.4.1.4)
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
defines that usage and to only allow merging into the header section defines that usage and to only allow merging into the header section
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 5.6.2) them instead of merging. (Section 5.6.2)
Trailer fields can now potentially appear as multiple trailer
sections, if allowed by the HTTP version and framing in use, with
processing described as being iterative as each section is received.
(Section 5.6.3)
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 6.6) (Section 6.5)
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 [RFC3986] that are
not desirable for Via. For simplicity, we have removed uri-host from not desirable for Via. For simplicity, we have removed uri-host from
the received-by production because it can be encompassed by the the received-by production because it can be encompassed by the
existing grammar for pseudonym. In particular, this change removed existing grammar for pseudonym. In particular, this change removed
comma from the allowed set of charaters for a host name in received- comma from the allowed set of charaters for a host name in received-
by. (Section 6.7.1) by. (Section 6.6.1)
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 10.4.9) defined closer to status codes 301, 302, and 307. (Section 10.4.9)
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 10.5.20) [RFC4918]) because of its general applicability. (Section 10.5.20)
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 2.5.1, Section 2.5.2, necessarily based on TCP. (Section 2.5.1, Section 2.5.2,
Section 6.2, Section 6.4) Section 6.2, Section 6.3.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 2.5) recommended. (Section 2.5)
Clarify that control characters in field values are to be rejected or Clarify that control characters in field values are to be rejected or
mapped to SP. (Section 5.4) mapped to SP. (Section 5.4)
Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons. (Section 5.4.1.4)
The term "effective request URI" has been replaced with "target URI". The term "effective request URI" has been replaced with "target URI".
(Section 6.1) (Section 6.1)
Range units are compared in a case insensitive fashion. Range units are compared in a case insensitive fashion.
(Section 7.1.4) (Section 7.1.4)
Restrictions on client retries have been loosened, to reflect Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 8.2.2) implementation behavior. (Section 8.2.2)
Clarified that request bodies on GET and DELETE are not Clarified that request bodies on GET and DELETE are not
interoperable. (Section 8.3.1, Section 8.3.5) interoperable. (Section 8.3.1, Section 8.3.5)
Removed a superfluous requirement about setting Content-Length from Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 8.3.7) the description of the OPTIONS method. (Section 8.3.7)
Restore list-based grammar for Expect for compatibility with RFC
2616. (Section 9.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 9.4) introduced by [RFC7694]. (Section 9.4)
The process of creating a redirected request has been clarified.
(Section 10.4)
The semantics of "*" in the Vary header field when other values are
present was clarified. (Section 11.1.4)
B.4. Changes from RFC 7232 B.4. Changes from RFC 7232
Clarify that If-Unmodified-Since doesn't apply to a resource without Preconditions can now be evaluated before the request body is
a concept of modification time. (Section 9.2.6) processed rather than waiting until the response would otherwise be
successful. (Section 9.2.1)
Removed edge case requirement on If-Match and If-Unmodified-Since
that a validator not be sent in a 2xx response when validation fails
and the server decides that the same change request has already been
applied. (Section 9.2.3 and Section 9.2.6)
Clarified that If-Unmodified-Since doesn't apply to a resource
without a concept of modification time. (Section 9.2.6)
B.5. Changes from RFC 7233 B.5. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other- (extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing range-unit by defining range units generically as a token and placing
extensions within the scope of a range-spec (other-range). This extensions within the scope of a range-spec (other-range). This
disambiguates the role of list syntax (commas) in all range sets, disambiguates the role of list syntax (commas) in all range sets,
including extension range units, for indicating a range-set of more including extension range units, for indicating a range-set of more
skipping to change at page 195, line 5 skipping to change at page 205, line 30
None yet. None yet.
B.7. Changes from RFC 7538 B.7. Changes from RFC 7538
None yet. None yet.
B.8. Changes from RFC 7615 B.8. Changes from RFC 7615
None yet. None yet.
Appendix C. Changes from RFC 7694 B.9. Changes from RFC 7694
This specification includes the extension defined in [RFC7694], but This specification includes the extension defined in [RFC7694], but
leaves out examples and deployment considerations. leaves out examples and deployment considerations.
Appendix D. Change Log Appendix C. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
D.1. Between RFC723x and draft 00 C.1. Between RFC723x and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
o Remove version "1.1" from document title, indicating that this o Remove version "1.1" from document title, indicating that this
specification applies to all HTTP versions. specification applies to all HTTP versions.
o Adjust historical notes. o Adjust historical notes.
o Update links to sibling specifications. o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x. sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x. o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered. o Move "Acknowledgements" to the very end and make them unnumbered.
D.2. Since draft-ietf-httpbis-semantics-00 C.2. Since draft-ietf-httpbis-semantics-00
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:
o Merged introduction, architecture, conformance, and ABNF o Merged introduction, architecture, conformance, and ABNF
extensions from RFC 7230 (Messaging). extensions from RFC 7230 (Messaging).
o Rearranged architecture to extract conformance, http(s) schemes, o Rearranged architecture to extract conformance, http(s) schemes,
and protocol versioning into a separate major section. and protocol versioning into a separate major section.
skipping to change at page 196, line 12 skipping to change at page 206, line 37
o Merged entire content of RFC 7233 (Range Requests). o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework). o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
D.3. Since draft-ietf-httpbis-semantics-01 C.3. Since draft-ietf-httpbis-semantics-01
o Improve [Welch] citation (<https://github.com/httpwg/http-core/ o Improve [Welch] citation (<https://github.com/httpwg/http-core/
issues/63>) issues/63>)
o Remove HTTP/1.1-ism about Range Requests o Remove HTTP/1.1-ism about Range Requests
(<https://github.com/httpwg/http-core/issues/71>) (<https://github.com/httpwg/http-core/issues/71>)
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/ o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>) http-core/issues/75>)
skipping to change at page 197, line 30 skipping to change at page 208, line 5
o In Section 5.5, fixed an example that had trailing whitespace o In Section 5.5, fixed an example that had trailing whitespace
where it shouldn't (<https://github.com/httpwg/http-core/ where it shouldn't (<https://github.com/httpwg/http-core/
issues/104>, <https://www.rfc-editor.org/errata/eid4169>) issues/104>, <https://www.rfc-editor.org/errata/eid4169>)
o In Section 10.3.7, remove words that were potentially misleading o In Section 10.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>, (<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>) <https://www.rfc-editor.org/errata/eid4358>)
D.4. Since draft-ietf-httpbis-semantics-02 C.4. Since draft-ietf-httpbis-semantics-02
o Included (Proxy-)Auth-Info header field definition from RFC 7615 o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>) (<https://github.com/httpwg/http-core/issues/9>)
o In Section 8.3.3, clarify POST caching o In Section 8.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>) (<https://github.com/httpwg/http-core/issues/17>)
o Add Section 10.5.19 to reserve the 418 status code o Add Section 10.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>) (<https://github.com/httpwg/http-core/issues/43>)
skipping to change at page 198, line 27 skipping to change at page 208, line 46
issues/123>) issues/123>)
o In Section 10.5.17, fixed prose about byte range comparison o In Section 10.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>)
o In Section 2.1, explain that request/response correlation is o In Section 2.1, 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>)
D.5. Since draft-ietf-httpbis-semantics-03 C.5. Since draft-ietf-httpbis-semantics-03
o In Section 10.4.9, include status code 308 from RFC 7538 o In Section 10.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>) (<https://github.com/httpwg/http-core/issues/3>)
o In Section 7.1.1, clarify that the charset parameter value is o In Section 7.1.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046 case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>) (<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>) (<https://github.com/httpwg/http-core/issues/42>)
skipping to change at page 199, line 15 skipping to change at page 209, line 37
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 2.1 to be more version-independent o Rework Section 2.1 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>) (<https://github.com/httpwg/http-core/issues/142>)
o In Section 8.3.5, clarify that DELETE needs to be successful to o In Section 8.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/ invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>) issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
D.6. Since draft-ietf-httpbis-semantics-04 C.6. Since draft-ietf-httpbis-semantics-04
o In Section 5.4, fix field-content ABNF o In Section 5.4, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o Move Section 5.4.1.4 into its own section o Move Section 5.4.1.4 into its own section
(<https://github.com/httpwg/http-core/issues/45>) (<https://github.com/httpwg/http-core/issues/45>)
o In Section 7.2.1, reference MIME Sniffing o In Section 7.2.1, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>) (<https://github.com/httpwg/http-core/issues/51>)
skipping to change at page 199, line 45 skipping to change at page 210, line 19
o Fix editorial issue in Section 7 (<https://github.com/httpwg/http- o Fix editorial issue in Section 7 (<https://github.com/httpwg/http-
core/issues/223>) core/issues/223>)
o In Section 10.5.20, rephrase language not to use "entity" anymore, o In Section 10.5.20, 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>)
o Move discussion of retries from [Messaging] into Section 8.2.2 o Move discussion of retries from [Messaging] into Section 8.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
D.7. Since draft-ietf-httpbis-semantics-05 C.7. Since draft-ietf-httpbis-semantics-05
o Moved transport-independent part of the description of trailers o Moved transport-independent part of the description of trailers
into Section 5.6 (<https://github.com/httpwg/http-core/issues/16>) into Section 5.6 (<https://github.com/httpwg/http-core/issues/16>)
o Loosen requirements on retries based upon implementation behavior o Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>) (<https://github.com/httpwg/http-core/issues/27>)
o In Section 13.9, update IANA port registry for TCP/UDP on ports 80 o In Section 13.9, update IANA port registry for TCP/UDP on ports 80
and 443 (<https://github.com/httpwg/http-core/issues/36>) and 443 (<https://github.com/httpwg/http-core/issues/36>)
skipping to change at page 201, line 5 skipping to change at page 211, line 28
o In Section 8.3.7, removed a misleading statement about Content- o In Section 8.3.7, removed a misleading statement about Content-
Length (<https://github.com/httpwg/http-core/issues/235>, Length (<https://github.com/httpwg/http-core/issues/235>,
<https://www.rfc-editor.org/errata/eid5806>) <https://www.rfc-editor.org/errata/eid5806>)
o In Section 12.1, add text from RFC 2818 o In Section 12.1, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
o Changed "cacheable by default" to "heuristically cacheable" o Changed "cacheable by default" to "heuristically cacheable"
throughout (<https://github.com/httpwg/http-core/issues/242>) throughout (<https://github.com/httpwg/http-core/issues/242>)
D.8. Since draft-ietf-httpbis-semantics-06 C.8. Since draft-ietf-httpbis-semantics-06
o In Section 6.7.1, simplify received-by grammar (and disallow comma o In Section 6.6.1, simplify received-by grammar (and disallow comma
character) (<https://github.com/httpwg/http-core/issues/24>) character) (<https://github.com/httpwg/http-core/issues/24>)
o In Section 5.3, give guidance on interoperable field names o In Section 5.3, give guidance on interoperable field names
(<https://github.com/httpwg/http-core/issues/30>) (<https://github.com/httpwg/http-core/issues/30>)
o In Section 1.2.1, define the semantics and possible replacement of o In Section 1.6.1, define the semantics and possible replacement of
whitespace when it is known to occur (<https://github.com/httpwg/ whitespace when it is known to occur (<https://github.com/httpwg/
http-core/issues/53>, <https://www.rfc-editor.org/errata/eid5163>) http-core/issues/53>, <https://www.rfc-editor.org/errata/eid5163>)
o In Section 5, introduce field terminology and distinguish between o In Section 5, introduce field terminology and distinguish between
field line values and field values; use terminology consistently field line values and field values; use terminology consistently
throughout (<https://github.com/httpwg/http-core/issues/111>) throughout (<https://github.com/httpwg/http-core/issues/111>)
o Moved #rule definition into Section 5.4 and whitespace into o Moved #rule definition into Section 5.4 and whitespace into
Section 1.2 (<https://github.com/httpwg/http-core/issues/162>) Section 1.6 (<https://github.com/httpwg/http-core/issues/162>)
o In Section 7.1.4, explicitly call out range unit names as case- o In Section 7.1.4, explicitly call out range unit names as case-
insensitive, and encourage registration insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>) (<https://github.com/httpwg/http-core/issues/179>)
o In Section 7.1.2, explicitly call out content codings as case- o In Section 7.1.2, explicitly call out content codings as case-
insensitive, and encourage registration insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>) (<https://github.com/httpwg/http-core/issues/179>)
o In Section 5.3, explicitly call out field names as case- o In Section 5.3, explicitly call out field names as case-
insensitive (<https://github.com/httpwg/http-core/issues/179>) insensitive (<https://github.com/httpwg/http-core/issues/179>)
o In Section 12.11, cite [Bujlow] (<https://github.com/httpwg/http- o In Section 12.12, cite [Bujlow] (<https://github.com/httpwg/http-
core/issues/185>) core/issues/185>)
o In Section 10, formally define "final" and "interim" status codes o In Section 10, formally define "final" and "interim" status codes
(<https://github.com/httpwg/http-core/issues/245>) (<https://github.com/httpwg/http-core/issues/245>)
o In Section 8.3.5, caution against a request body more strongly o In Section 8.3.5, caution against a request body more strongly
(<https://github.com/httpwg/http-core/issues/258>) (<https://github.com/httpwg/http-core/issues/258>)
o In Section 11.2.3, note that Etag can be used in trailers o In Section 11.2.3, note that Etag can be used in trailers
(<https://github.com/httpwg/http-core/issues/262>) (<https://github.com/httpwg/http-core/issues/262>)
skipping to change at page 202, line 8 skipping to change at page 212, line 34
o In Section 13.4, consider reserved fields as well o In Section 13.4, consider reserved fields as well
(<https://github.com/httpwg/http-core/issues/273>) (<https://github.com/httpwg/http-core/issues/273>)
o In Section 2.5.4, be more correct about what was deprecated by RFC o In Section 2.5.4, be more correct about what was deprecated by RFC
3986 (<https://github.com/httpwg/http-core/issues/278>, 3986 (<https://github.com/httpwg/http-core/issues/278>,
<https://www.rfc-editor.org/errata/eid5964>) <https://www.rfc-editor.org/errata/eid5964>)
o In Section 5.1, recommend comma SP when combining field lines o In Section 5.1, recommend comma SP when combining field lines
(<https://github.com/httpwg/http-core/issues/148>) (<https://github.com/httpwg/http-core/issues/148>)
o In Section 6.6, make explicit requirements on origin server to use o In Section 6.5, make explicit requirements on origin server to use
authority from absolute-form when available authority from absolute-form when available
(<https://github.com/httpwg/http-core/issues/191>) (<https://github.com/httpwg/http-core/issues/191>)
o In Section 2.5.1, Section 2.5.2, Section 6.2, and Section 6.4, o In Section 2.5.1, Section 2.5.2, Section 6.2, and Section 6.3.3,
refactored schemes to define origin and authoritative access to an refactored schemes to define origin and authoritative access to an
origin server for both "http" and "https" URIs to account for origin server for both "http" and "https" URIs to account for
alternative services and secured connections that are not alternative services and secured connections that are not
necessarily based on TCP (<https://github.com/httpwg/http-core/ necessarily based on TCP (<https://github.com/httpwg/http-core/
issues/237>) issues/237>)
o In Section 1.1, reference RFC 8174 as well o In Section 1.5, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>) (<https://github.com/httpwg/http-core/issues/303>)
D.9. Since draft-ietf-httpbis-semantics-07 C.9. Since draft-ietf-httpbis-semantics-07
o In Section 9.3, explicitly reference the definition of o In Section 9.3, 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>)
o Move TE: trailers from [Messaging] into Section 5.6.2 o Move TE: trailers from [Messaging] into Section 5.6.2
(<https://github.com/httpwg/http-core/issues/18>) (<https://github.com/httpwg/http-core/issues/18>)
o In Section 7.2.4, adjust requirements for handling multiple o In Section 7.2.4, adjust requirements for handling multiple
content-length values (<https://github.com/httpwg/http-core/ content-length values (<https://github.com/httpwg/http-core/
skipping to change at page 203, line 42 skipping to change at page 214, line 19
(<https://github.com/httpwg/http-core/issues/334>) (<https://github.com/httpwg/http-core/issues/334>)
o In Section 6.1, Section 8.3.6, and Section 8.3.7, refine use of o In Section 6.1, Section 8.3.6, and Section 8.3.7, refine use of
"request target" (<https://github.com/httpwg/http-core/ "request target" (<https://github.com/httpwg/http-core/
issues/340>) issues/340>)
o Throughout, remove "status-line" and "request-line", as these are o Throughout, remove "status-line" and "request-line", as these are
HTTP/1.1-specific (<https://github.com/httpwg/http-core/ HTTP/1.1-specific (<https://github.com/httpwg/http-core/
issues/361>) issues/361>)
D.10. Since draft-ietf-httpbis-semantics-08 C.10. Since draft-ietf-httpbis-semantics-08
o In Section 10.5.17, remove duplicate definition of what makes a o In Section 10.5.17, remove duplicate definition of what makes a
range satisfiable and refer instead to each range unit's range satisfiable and refer instead to each range unit's
definition (<https://github.com/httpwg/http-core/issues/12>) definition (<https://github.com/httpwg/http-core/issues/12>)
o In Section 7.1.4.2 and Section 9.3, clarify that a selected o In Section 7.1.4.2 and Section 9.3, clarify that a selected
representation of zero length can only be satisfiable as a suffix representation of zero length can only be satisfiable as a suffix
range and that a server can still ignore Range for that case range and that a server can still ignore Range for that case
(<https://github.com/httpwg/http-core/issues/12>) (<https://github.com/httpwg/http-core/issues/12>)
skipping to change at page 204, line 51 skipping to change at page 215, line 29
o Add Section 4 about Extending and Versioning HTTP o Add Section 4 about Extending and Versioning HTTP
(<https://github.com/httpwg/http-core/issues/384>) (<https://github.com/httpwg/http-core/issues/384>)
o In Section 10.1, include status 308 in list of heuristically o In Section 10.1, include status 308 in list of heuristically
cacheable status codes (<https://github.com/httpwg/http-core/ cacheable status codes (<https://github.com/httpwg/http-core/
issues/385>) issues/385>)
o In Section 7.2.2, make it clearer that "identity" is not to be o In Section 7.2.2, make it clearer that "identity" is not to be
included (<https://github.com/httpwg/http-core/issues/388>) included (<https://github.com/httpwg/http-core/issues/388>)
D.11. Since draft-ietf-httpbis-semantics-09 C.11. Since draft-ietf-httpbis-semantics-09
o Switch to xml2rfc v3 mode for draft generation o Switch to xml2rfc v3 mode for draft generation
(<https://github.com/httpwg/http-core/issues/394>) (<https://github.com/httpwg/http-core/issues/394>)
C.12. Since draft-ietf-httpbis-semantics-10
o In Section 12.6, mention compression attacks
(<https://github.com/httpwg/http-core/issues/6>)
o In Section 7.1.2.4, advise to make new content codings self-
descriptive (<https://github.com/httpwg/http-core/issues/21>)
o In Section 5.4.1.4, introduced the "parameters" ABNF rule,
allowing empty parameters and trailing semicolons within media
type, media range, and expectation (<https://github.com/httpwg/
http-core/issues/33>)
o In Section 10.4, explain how to create a redirected request
(<https://github.com/httpwg/http-core/issues/38>)
o In Section 7.2.1, defined error handling for multiple members
(<https://github.com/httpwg/http-core/issues/39>)
o In Section 1, revise the introduction and introduce HTTP/2 and
HTTP/3 (<https://github.com/httpwg/http-core/issues/64>)
o In Section 7.2.4, added a definition for Content-Length that
encompasses its various roles in describing message payload or
selected representation length; in Section 10.3.7, noted that
Content-Length counts only the message body (not the selected
representation) and that the complete length is in each
Content-Range (<https://github.com/httpwg/http-core/issues/118>)
o Noted that "WWW-Authenticate" with more than one value on a line
is sometimes not interoperable [Messaging]
(<https://github.com/httpwg/http-core/issues/136>)
o In Section 9.2.3 and Section 9.2.6, removed requirement that a
validator not be sent in a 2xx response when validation fails and
the server decides that the same change request has already been
applied (<https://github.com/httpwg/http-core/issues/166>)
o Moved requirements specific to HTTP/1.1 from Section 6.5 to
[Messaging] (<https://github.com/httpwg/http-core/issues/182>)
o In Section 5.4, introduce the terms "singleton field" and "list-
based field" (also - in various places - discuss what to do when a
singleton field is received as a list)
(<https://github.com/httpwg/http-core/issues/193>)
o In Section 9.1.1, change the ABNF back to be a list of
expectations, as defined in RFC 2616 (<https://github.com/httpwg/
http-core/issues/203>)
o In Section 5.6.4 (Trailer), Section 6.6.1 (Via), Section 6.7
(Upgrade), Section 6.8 (Connection), Section 7.2.2
(Content-Encoding), Section 7.2.3 (Content-Language),
Section 9.1.1 (Expect), Section 9.2.3 (If-Match), Section 9.2.4
(If-None-Match), Section 9.4.2 (Accept-Charset), Section 9.4.4
(Accept-Language), Section 11.1.4 (Vary), Section 11.3.1
(WWW-Authenticate), and Section 11.3.2 (Proxy-Authenticate),
adjust ABNF to allow empty lists (<https://github.com/httpwg/http-
core/issues/210>)
o In Section 8.3.1 and Section 12.9, provide a more nuanced
explanation of sensitive data in GET-based forms and describe
workarounds (<https://github.com/httpwg/http-core/issues/277>)
o In Section 9.2.1, allow preconditions to be evaluated before the
request body (if any) is processed (<https://github.com/httpwg/
http-core/issues/261>)
o In Section 5 and Section 5.6.3, allow for trailer fields in
multiple trailer sections, depending on the HTTP version and
framing in use, with processing being iterative as each section is
received (<https://github.com/httpwg/http-core/issues/313>)
o Moved definitions of "TE" and "Upgrade" from [Messaging]
(<https://github.com/httpwg/http-core/issues/392>)
o Moved 1.1-specific discussion of TLS to Messaging and rewrote
Section 6.3.3.3 to refer to RFC6125 (<https://github.com/httpwg/
http-core/issues/404>)
o Moved definition of "Connection" from [Messaging]
(<https://github.com/httpwg/http-core/issues/407>)
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616, contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616,
and RFC 2818, including substantial contributions made by the and RFC 2818, including substantial contributions made by the
previous authors, editors, and Working Group Chairs: Tim Berners-Lee, previous authors, editors, and Working Group Chairs: Tim Berners-Lee,
Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jean-François Groff, Ari Luotonen, Roy T. Fielding, Henrik Frystyk
Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, Eric Rescorla, and Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J.
Yves Lafon. Leach, Eric Rescorla, and Yves Lafon.
See Section 10 of [RFC7230] for further acknowledgements from prior See Section 10 of [RFC7230] for further acknowledgements from prior
revisions. revisions.
In addition, this document has reincorporated the HTTP Authentication In addition, this document has reincorporated the HTTP Authentication
Framework, previously defined in RFC 7235 and RFC 2617. We thank Framework, previously defined in RFC 7235 and RFC 2617. We thank
John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart
for their work on that specification. See Section 6 of [RFC2617] for for their work on that specification. See Section 6 of [RFC2617] for
further acknowledgements. further acknowledgements.
skipping to change at page 205, line 39 skipping to change at page 218, line 4
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
United States of America United States of America
Email: fielding@gbiv.com Email: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
Prahran VIC
Australia
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
48155 Münster 48155 Münster
Germany Germany
 End of changes. 259 change blocks. 
1065 lines changed or deleted 1650 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/